Compiler & Co.

joost · Freitag 11. Mai 2007, 15:04

Wenn ich mit 'Dir' gemeint sein sollte (bin ja nicht Eröffner dieses Threads): Vielen Dank !

Sql selbst ist sehr mächtig, es gibt Programmierer, die aus Spass mal OOP damit implementiert haben, die Objekte waren dabei Tabellen. Ich habe mal für ein Statistik-Modul ein System programmiert, worin Sql verwendet wurde, um Sql-Abfragen erst zu erzeugen (wir wollten das von außen anpassbar an Kundenwünsche halten und hätten so - allerdings dann doch ziemlich eng begrenzt - neue Statistik-Abfragen aus einer Datenbank heraus erzeugen können, ohne am Programmcode etwas ändern zu müssen).
Auf den ersten Blick halte ich - frech und brutal gesagt - SqlAlchemy für überflüssig und wieder etwas, dass Performance zugunsten von Programmier-Bequemlichkeit kostet. Anpassungen an unterschiedliche Datenbanken könnte man teilweise wahrscheinlich wirklich in Datenbankbeschreibungstabellen legen.

mitsuhiko · Freitag 11. Mai 2007, 15:17

joost hat geschrieben:Auf den ersten Blick halte ich - frech und brutal gesagt - SqlAlchemy für überflüssig und wieder etwas, dass Performance zugunsten von Programmier-Bequemlichkeit kostet.

Der Overhead von SQLAlchemy ist nicht messbar. Ich kann es mir mittlerweile auch nicht mehr vorstellen ohne SQLAlchemy auf Datenbanken zugreifen zu müssen.

Leonidas · Freitag 11. Mai 2007, 15:21

joost hat geschrieben:Auf den ersten Blick halte ich - frech und brutal gesagt - SqlAlchemy für überflüssig und wieder etwas, dass Performance zugunsten von Programmier-Bequemlichkeit kostet.

Husch husch, zurück zu Assembler. Dort gibt es keine Klassen, die ja nur Performance zugunsten von Programmierer-Bequemlichkeit verschwenden. Wie Python übrigens auch.

joost · Freitag 11. Mai 2007, 15:26

Der Overhead von SQLAlchemy ist nicht messbar. Ich kann es mir mittlerweile auch nicht mehr vorstellen ohne SQLAlchemy auf Datenbanken zugreifen zu müssen.

Klingt gut - nehm ich mir erstmal zu Herzen. Ein dickes 'Sorry' an alle SqlAlchemy-Entwickler.

Husch husch, zurück zu Assembler. Dort gibt es keine Klassen, die ja nur Performance zugunsten von Programmierer-Bequemlichkeit verschwenden. Wie Python übrigens auch.

Ja leider. Nicht nur ich vermisse einen echten Compiler - das tun viele Leute.

jens · Freitag 11. Mai 2007, 15:27

joost hat geschrieben:
Husch husch, zurück zu Assembler.
Ja leider. Nicht nur ich vermisse einen echten Compiler - das tun viele Leute.

Du kannst dir ja mal PyPy und RPython ansehen

BlackJack · Freitag 11. Mai 2007, 15:36

Was ist ein echter Compiler? CPython hat einen Compiler. Der ist echt. Keine Einbildung.

jens · Freitag 11. Mai 2007, 15:38

Gemeint ist wohl, echte EXE Dateien backen...

Leonidas · Freitag 11. Mai 2007, 15:41

jens hat geschrieben:Gemeint ist wohl, echte EXE Dateien backen...

Das konnte Visual Basic auch lange nicht (P-Code), .NET kann sowas immer noch nicht und das so berühmte Java benennt seine Executables gar ``.class``.

joost · Freitag 11. Mai 2007, 15:43

Java und .net wollen das gar nicht. Ich meine etwas, das reinen Maschinencode (vor allem erst einmal für i386-CPUs) produziert. Für mich ist das die Bedeutung des Wortes 'Compiler'.

@Jens: In diesem Sinne fand ich PyPy bisher nicht wirklich interessant. Da Du Dir die Mühe gemacht hast, dies zu schreiben, hab ich aber noch einmal auf deren Seite gesehen. Da scheint doch wirklich etwas Interessantes los zu sein, auch wenn am Ende vielleicht wieder "nur" ByteCode-Interpreter herauskommen.

BlackJack · Freitag 11. Mai 2007, 15:57

Beim CPython-Compiler kommt reiner Maschinencode raus. Für eine Python-VM. Du willst Maschinencode für eine andere VM. Also ist der Begriff Compiler in beiden Fällen der passende, selbst wenn man ihn unnötig auf "Maschinencode für eine VM" einschränkt.

mitsuhiko · Freitag 11. Mai 2007, 15:59

joost hat geschrieben:Java und .net wollen das gar nicht. Ich meine etwas, das reinen Maschinencode (vor allem erst einmal für i386-CPUs) produziert. Für mich ist das die Bedeutung des Wortes 'Compiler'.

Ist aber die falsche Bedeutung. Und warum zum Henker brauchst du "reinen Maschinencode"? Ich seh da nur Nachteile...

joost · Freitag 11. Mai 2007, 16:01

Eine VM ist Software. Und aus meiner Sicht ist 90% aller Software Schrott. Ich will möglichst wenig Software zwischen mir und der CPU.

mitsuhiko · Freitag 11. Mai 2007, 16:06

joost hat geschrieben:Eine VM ist Software. Und aus meiner Sicht ist 90% aller Software Schrott. Ich will möglichst wenig Software zwischen mir und der CPU.

><o(((°>, mehr fällt mir jetzt nicht ein.

BlackJack · Freitag 11. Mai 2007, 16:10

@joost: Dann schreib Deine Programme in Assembler. Viel Spass.

Und wie Dir vielleicht aufgefallen ist, habe ich geschrieben dass Du nur Maschinencode für eine andere *VM* haben willst. Auf fast keinem modernen Prozessor läuft x86-Maschinencode. Da läuft für gewöhnlich ein "Compiler" im Prozessor der den x86-Code intern in einen RISC-Befehlssatz übersetzt un optimiert, der dann letztendlich auf der Hardware läuft. Die Grenzen zwischen Hardware, VM, Bytecode und "echtem" Maschinencode sind fliessend.

Also vergiss meinen Vorschlag und programmiere gleich in Microcode.

Auf jeden Fall bist Du bei Python sowohl was die technische, als auch die philosphische Seite angeht, bei der falschen Sprache gelandet.

Und viel Software ist vielleicht auch deswegen Schrott, weil die Leute viel zu nah an der Hardware und weniger nah am Problem programmieren.

Leonidas · Freitag 11. Mai 2007, 16:12

joost hat geschrieben:Eine VM ist Software.

Wie siehts mit Lisp-Maschinen aus? Eine "VM" muss gar nicht Software sein.

joost · Freitag 11. Mai 2007, 16:20

Auf jeden Fall bist Du bei Python sowohl was die technische, als auch die philosphische Seite angeht, bei der falschen Sprache gelandet.

Noch einmal: Ich bedaure nicht allein, dass es keinen Compiler in meinem Sinne gibt. Was ist mit Psyco z.B. ? Das ist eine Kröte, die ich schlucke. Würde ich C schreiben, hätte ich nun andere Kröten zu schlucken.

Und viel Software ist vielleicht auch deswegen Schrott, weil die Leute viel zu nah an der Hardware und weniger nah am Problem programmieren.

Ja.
Edit: Wenn man uns als User des Python-Interpreters sieht, dann ist Python halt sehr User-freundlich. So User-freundlich, wie ein Programm im Zeitalter der GUIs eben sein soll. Und ohne im Gegenzug Beschränkungen aufzuerlegen. So User-freundlich, wie auch ich versuche, meine Programme zu machen. Deshalb bleibe ich bei Python.

mitsuhiko · Freitag 11. Mai 2007, 16:23

joost hat geschrieben:Noch einmal: Ich bedaure nicht allein, dass es keinen Compiler in meinem Sinne gibt. Was ist mit Psyco z.B. ? Das ist eine Kröte, die ich schlucke. Würde ich C schreiben, hätte ich nun andere Kröten zu schlucken.

Du wirst von Post zu Post undeutlicher... Kein OS, keine Hardware, keine Compiler. Vielleicht denkst du einfach in einsen und nullen und bist dir dein eigener Computer. Sogesehen wären so manche deiner Aussagen wieder bis zu einem gewissen Punkt logisch.

Leonidas · Freitag 11. Mai 2007, 16:32

joost hat geschrieben:Noch einmal: Ich bedaure nicht allein, dass es keinen Compiler in meinem Sinne gibt. Was ist mit Psyco z.B. ? Das ist eine Kröte, die ich schlucke. Würde ich C schreiben, hätte ich nun andere Kröten zu schlucken.

Und was hat Psyco nun mit deinem "reinen Maschinencode" zu tun? Psyco ist auch ein Compiler, klar, aber das siehst du (laut eigener Aussage) nicht als Compiler an.

joost · Freitag 11. Mai 2007, 16:34

Du wirst von Post zu Post undeutlicher... Kein OS, keine Hardware, keine Compiler. Vielleicht denkst du einfach in einsen und nullen und bist dir dein eigener Computer. Sogesehen wären so manche deiner Aussagen wieder bis zu einem gewissen Punkt logisch.

Wenn ich Dich richtig verstehe, möchtest Du sagen, dass auch ein Compiler etwas ist, das zwischen meinem Code und der CPU steht. Das stimmt natürlich.
Vom OS abstrahiert Python halt. Und wenn ich einmal Vertrauen zu einem Programm habe, wie ich es zum Python-Kern voll und ganz habe, dann sehe ich es nicht mehr als Barriere zwischen mir und der CPU an. Edit: Ich habe dann das Vertrauen, dass die von mir gemeinte CPU-Aktion eben auch ausgeführt wird.
@Leonidas:

Und was hat Psyco nun mit deinem "reinen Maschinencode" zu tun? Psyco ist auch ein Compiler, klar, aber das siehst du (laut eigener Aussage) nicht als Compiler an.

Stimmt, weiß ich. Sind aber halt Leute, die die geringere Performance durch Interpretieren statt Compilieren offenbar wurmt.

EnTeQuAk · Freitag 11. Mai 2007, 16:40

Sorry, für noch mehr Offtopic:
Aber... ist es möglich, das jemand die etlichen sinnlosen Disskussionen von Mr. joost einfach mal verschiebt?

Das hat (wie in etlichen anderen Threads) nichts mit dem Thema zu tun und ich persönlich als Threadersteller hätte keinen bock mehr mich durch die Posts zu wurschteln.

Und wenn der entsprechende Moderator grad dabei ist... diesen Post entweder löschen oder mitverschieben, damit hier was sinnvolles bei rauskommt.

DANKEE!!

(oder habe ich jetzt eine Antwort vom Threadersteller verpasst gehabt?)

MfG EnTeQuAk

Edit:
aber eins möchte ich noch zutragen:

Stimmt, weiß ich. Sind aber halt Leute, die die geringere Performance durch Interpretieren statt Compilieren offenbar wurmt.

Es gibt immer noch C, C++ etc... niemand zwingt dich zu Python.
Und ich denke mal... nicht umsonst hat Python so geniale C-APIs. Damit du auch in Python deine mili/nano-Sekundengenauigkeit und geschwindigkeitsverbesserungen erreichen kannst.

Oder hast du wirklich ernsthafte Probleme mit der Performance von Python?