Entwickelt wurde OCaml eigentlich für scientific computing (daher auch die Performance). Schau dir mal den Caml Hump an (änlich PyPI oder CPAN), da sieht man was die Leute so damit machen
Zu Dylan: Hatte das nicht ursprünglich Lisp ähnliche Syntax?
Python Tempo
Caml: Hmm interssant, aber die Syntax scheint mir auch n bisschen strange mit den 2 Semikolons etc... (hab gerade A hundred lines of Caml angelesen)
Dylan: Weiß ich nicht, kann sein, dass das Original-Dylan so eine Syntax hatte, Gwydion-dylan
hat AFAIK aber eine andere Syntax
Henning
Dylan: Weiß ich nicht, kann sein, dass das Original-Dylan so eine Syntax hatte, Gwydion-dylan
hat AFAIK aber eine andere Syntax
Henning
Daß man in Dylan zur späteren Optimierung von Programmen "nachträglich" Typen festlegen kann, ist eine gute Idee. Das könnte man vielleicht auch in eine zukünftige Version von Python einbauen, ohne daß älterer Code
inkompatibel wird.
inkompatibel wird.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Find ich gut... Vielleicht würde es helfen, einen Compiler zu bauen, den ich mir sehr wünschen würde...
Wir haben eine Seite dafür im Wiki:
http://www.pythonwiki.de/PythonWunschliste
Wir haben eine Seite dafür im Wiki:
http://www.pythonwiki.de/PythonWunschliste
Gibt es tatsächlich keinen Compiler, der Python in native Binaries oder
zumindest nach C übersetzt ? Ist so etwas geplant ?
zumindest nach C übersetzt ? Ist so etwas geplant ?
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Aus der FAQ http://www.pythonwiki.de/PythonDeForum/ ... d0279836ed:
Um ganz exakt zu sein, ist CPython eigentlich ein "kompilierender Interpreter"; er kompiliert allerdings Python-Quellcode (PY) in Python-Bytecode (PYC). Aber gesucht ist wahrscheinlich eine Lösung um Pythonprogramme ohne Interpreter auszuführen. Solche Lösungen sind [WWW] py2exe, [WWW] Installer, [WWW] cx_Freeze. Einen anderen Ansatz verfolgt Python2C oder [WWW] PyPy.
Meines wissens nach bauen py2exe & co. aber im grunde auch nur nen interpreter mit bytecode zusammen oder?
Was mich interessieren würde:
Gibt es eine Untermenge der Sprache Python die man z.B. nach C übersetzen könnte, wenn man evtl. noch Typfestlegungen angibt?
Meine Überlegung ist folgende: Auch wenn Python-Bytecode ja irgendwie was compiliertes ist, muss er ja auch noch interpretiert werden, was das ganze ja halbwegs unperformant macht.
Dass das "volle" Python hingegen kaum mit Performancegewinn "wirklich" zu compilen ist, ist aber natürlich auch klar, da die Sprache dazu viel zu flexibel ist (in vielerlei hinsicht).
Was mich interessieren würde:
Gibt es eine Untermenge der Sprache Python die man z.B. nach C übersetzen könnte, wenn man evtl. noch Typfestlegungen angibt?
Meine Überlegung ist folgende: Auch wenn Python-Bytecode ja irgendwie was compiliertes ist, muss er ja auch noch interpretiert werden, was das ganze ja halbwegs unperformant macht.
Dass das "volle" Python hingegen kaum mit Performancegewinn "wirklich" zu compilen ist, ist aber natürlich auch klar, da die Sprache dazu viel zu flexibel ist (in vielerlei hinsicht).
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Also ich wünschte mir auch einen echten Python compiler und dachte das PyPy in die richtige Richtung geht, s. http://www.python-forum.de/viewtopic.php?t=3696
Also für extrem preformante Geschichten muß man zumindest Teile in C auslagern, was ja auch viele Python-Built-In-Module sind.
Python's stärke liegt halt nicht in der Preformance der Ausführung. Allerdings ist das mit den heutigen Rechnern IMHO fast immer egal.
Also für extrem preformante Geschichten muß man zumindest Teile in C auslagern, was ja auch viele Python-Built-In-Module sind.
Python's stärke liegt halt nicht in der Preformance der Ausführung. Allerdings ist das mit den heutigen Rechnern IMHO fast immer egal.
Mag sein, aber man fühlt sich trotzdem sicherer, wenn man ein Projekt startet, dessen Umfang man vorher schlecht abschätzen kann, wenn man weiß, dass man seinen Code einfach (durch das hinzufügen von type-definitionen) schneller machen kann und das Rad nicht nochmal stellenweise nach C portieren muss ,-)
(auch wenn mir pythons Geschwindigkeit bis jetzt immer gereicht hat)
Übrigens gibts in PEP3000 auch nen Vorschlag zu dem Thema:
http://www.artima.com/weblogs/viewpost.jsp?thread=89161
edit: Ich hab gerade Python2C entdeckt, den find ich persönlich auch sehr interessant, wenn er auch noch seeehr ausbaufähig ist, aber so mancher Beispielcode
wird doch schon recht beeindruckend umgewandelt.
(Auch wenn syntaktische Analyse, etc... bis her noch fehlt.)
(auch wenn mir pythons Geschwindigkeit bis jetzt immer gereicht hat)
Übrigens gibts in PEP3000 auch nen Vorschlag zu dem Thema:
http://www.artima.com/weblogs/viewpost.jsp?thread=89161
edit: Ich hab gerade Python2C entdeckt, den find ich persönlich auch sehr interessant, wenn er auch noch seeehr ausbaufähig ist, aber so mancher Beispielcode
wird doch schon recht beeindruckend umgewandelt.
(Auch wenn syntaktische Analyse, etc... bis her noch fehlt.)
Zwei Punkte: In Python sind Alles Objekte. Python arbeitet mit Referenzen.henning hat geschrieben:Mag sein, aber man fühlt sich trotzdem sicherer, wenn man ein Projekt startet, dessen Umfang man vorher schlecht abschätzen kann, wenn man weiß, dass man seinen Code einfach (durch das hinzufügen von type-definitionen) schneller machen kann und das Rad nicht nochmal stellenweise nach C portieren muss ,-)
(auch wenn mir pythons Geschwindigkeit bis jetzt immer gereicht hat)
Aus diesen Zwei Prinzipien ergibt sich, dass in Python auch Funktionen Objekte sind, die als Pointer in z.B. einer Klasse representiert werden. Für den Interpreter würde eine statische Typendeklaration keinen geschwindigkeits Vorteil geben. Lediglich ein compiler würde davon profitieren, da der Interpreter die z.B. Funktionen immer noch nachschauen müsste.
Wenn die Geschwindigkeit immer gereicht hat, dann verstehe ich den Wunsch nach einem Compiler nicht. In den meisten Fällen wo man wirklich etwas schneller machen möchte bringt das neuschreiben in C nur recht wenig, während man mit einem besserem Algorithmus oder einer besseren Datenstruktur oft viel mehr herausholen kann. Und ein Programm in Python umstrukturieren geht wesentlich einfacher als in C.henning hat geschrieben:Mag sein, aber man fühlt sich trotzdem sicherer, wenn man ein Projekt startet, dessen Umfang man vorher schlecht abschätzen kann, wenn man weiß, dass man seinen Code einfach (durch das hinzufügen von type-definitionen) schneller machen kann und das Rad nicht nochmal stellenweise nach C portieren muss ,-)
(auch wenn mir pythons Geschwindigkeit bis jetzt immer gereicht hat)
Ich hatte bisher auch noch nichts, das unbedingt schneller sein musste, aber schon mal den Fall wo's ganz nett wäre. Da hat mir Psyco (JIT-Compiler) immer gereicht.
Für den Notfall gibt's dann noch Pyrex, was die Frage nach der compilierbaren Python-Untermenge beantwortet.
Bei solchen Sachen, wo es nur auf die Rechenpower ankommt, z.B. bei einer Pixelbasierten kollisionserkennung von zwei Bitmaps, da hilft es eben auch nicht, einfach die Daten als statisch zu markieren oder die sStruktur zu ändern, um mehr Performance zu bekommen. Bei so was nimmt man nen Profiler und wenn man die richtigen stellen gefunden hat, dann nimmt man PyRex, C oder Assembly (wenn man so verrückt ist, dann als inline Assembly von C...).BlackJack hat geschrieben:Wenn die Geschwindigkeit immer gereicht hat, dann verstehe ich den Wunsch nach einem Compiler nicht. In den meisten Fällen wo man wirklich etwas schneller machen möchte bringt das neuschreiben in C nur recht wenig, während man mit einem besserem Algorithmus oder einer besseren Datenstruktur oft viel mehr herausholen kann. Und ein Programm in Python umstrukturieren geht wesentlich einfacher als in C.
In Python kann man den Profiler relativ leicht einsetzten. Wenn man wirklich mehr Performance braucht, dann kann man optimieren. Aber warum soll man sich mit nen Compiler rumschlagen, wenn man nur ne kleine .py Datei weiter geben muss...
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Weil nicht jeder Python installiert hat? Eine echt complilierte EXE ist auch nicht wirklich groß.ProgChild hat geschrieben:Aber warum soll man sich mit nen Compiler rumschlagen, wenn man nur ne kleine .py Datei weiter geben muss...
Es fragen immer wieder Leute danach wie man eine EXE Datei bekommt, von daher ist der Wunsch nach einem Compiler schon da...
Das kannst du aber nicht aus der Performance herraus begründen. Klein und Groß sind sowieso relativ und da heute sowieso fast jeder nen CD Brenner oder einen Internetanschluss hat, ist es nicht besonders schwer Jemandem Python mitzuliefern.jens hat geschrieben:Weil nicht jeder Python installiert hat? Eine echt complilierte EXE ist auch nicht wirklich groß.ProgChild hat geschrieben:Aber warum soll man sich mit nen Compiler rumschlagen, wenn man nur ne kleine .py Datei weiter geben muss...
Es fragen immer wieder Leute danach wie man eine EXE Datei bekommt, von daher ist der Wunsch nach einem Compiler schon da...
Ich kann die Leute gut verstehen, die gerne einfach nur eine kleine .EXE weitergeben wollen, aber welchen praktischen Nutzen sollte das haben? Python mitzuliefern ist nicht wirklich schwer. Mit Py2Exe sind die Dateien zwar größer, aber das ist ja Heut zu Tage auch nicht das Problem.
Mit Assembly kann ich Programme schreiben, die sind unter 2KB groß. Ich hab aber nix davon. Ich kann mein Programm 700 mal auf ne Diskette packen. Dafür hab ich aber viele, sehr viele Nachteile. Mein Programm läuft nur auf einem Prozessor und nur auf einem Betriebssystem.
Eine .EXE macht quasi nur auf Windows Sinn, da nur da nur ein Prozessortyp vorhanden ist. Auf MacOS X, auf den meisten Linux und BSD Distributionen ist Python schon installiert.
Ich weis nicht, warum man so viel aufgeben will, nur um "Windows Like" seine .EXE weiter geben zu können, wo die .PY Datei warscheinlich auf allen anderen Systemen sofort läuft und auf jeden fall kleiner ist, als die .EXE-
Ack
Je mehr ich hier lese und drüber nachdenke desto mehr wird mir klar, dass der Wunsch nach einem "echten" Compiler einfach nur ein Psychologisches Problem ist:
Man stellt sich halt vor: "Okay, es gibt da diesen Interpreter, der wird vom Prozessor interpretiert, und interpretiert seinerseits das Python-Programm"
Diese Schachtelung hat bei mir wohl gleich die Assoziation zur Vorzeige-Schachtelung schlechthin, nämlich der von Zwei Zählschleifen geführt und damit im Hinterkopf das unwohle Gefühl von einer quadratischen oder zumindest astronomisch hohen Laufzeit erzeugt.
Dass das totaler Blödsinn ist, wusste mein Verstand natürlich auch schon vorher, aber mein Unterbewusstsein ist jetzt auch bereit, diesen Gedanken anzunehmen
Je mehr ich hier lese und drüber nachdenke desto mehr wird mir klar, dass der Wunsch nach einem "echten" Compiler einfach nur ein Psychologisches Problem ist:
Man stellt sich halt vor: "Okay, es gibt da diesen Interpreter, der wird vom Prozessor interpretiert, und interpretiert seinerseits das Python-Programm"
Diese Schachtelung hat bei mir wohl gleich die Assoziation zur Vorzeige-Schachtelung schlechthin, nämlich der von Zwei Zählschleifen geführt und damit im Hinterkopf das unwohle Gefühl von einer quadratischen oder zumindest astronomisch hohen Laufzeit erzeugt.
Dass das totaler Blödsinn ist, wusste mein Verstand natürlich auch schon vorher, aber mein Unterbewusstsein ist jetzt auch bereit, diesen Gedanken anzunehmen