python 2.7

[sma]

Wird 2.7 eigentlich noch langsamer als 2.6?

Wäre doch eine gute Strategie, um die Leute in Richtung 3.x zu stoßen (vorausgesetzt, diese wird eher schneller als langsamer).

Stefan

[snafu]

@sma: Meinst du wirklich? Meistens fallen Pythons Geschwindigkeitsdefizite doch gar nicht auf. Und für komplizierte Berechnungen eignet sich bekanntlich NumPy ganz gut. Ich könnte mir das nur beim Zugriff auf extrem große Datensätze (sprich: sehr große Wörterbücher, Sets oder Listen) vorstellen, falls es nicht auch dafür irgendein Spezialmodul gibt, das in C implementiert ist. Ich lasse mich aber gerne eines Besseren belehren.

[Leonidas]

Naja, Parser sind in Python auch nicht sonderlich schnell. Ich war letztens erstaunt wie fürchterlich lange Python für eine 7 MB große Textdatei gebraucht hat, zumindest auf dem 2,4 GHz (!) Celeron (es ist übrigens erstaunlich was L2 Cache ausmachen kann: mit 128 KB dauerte das Parsen ca. 90 Sekunden, mit 256 KB auf einem etwas langsameren Pentium 4 ca. 30% weniger und mit 2048 KB auf einem noch langsameren Core 2 nur 10 Sekunden). Habe echt überlegt, den Parser dann in C auszulagern (oder in OCaml, aber das gibt an allen Ecken und Enden Probleme, obwohl Parsen mit OCaml sicherlich viel angenehmer als in C ist).

[numerix]

Meistens fallen Pythons Geschwindigkeitsdefizite doch gar nicht auf. Und für komplizierte Berechnungen eignet sich bekanntlich NumPy ganz gut.

Die Frage von hendrikS dürfte vor dem Hintergrund seiner aktuellen (unangenehmen) Erfahrungen mit der Geschwindigkeit von 2.6 im Vergleich zu 2.5 auf den SPOJ-Rechnern zu verstehen sein: Da wurde vor ein paar Tagen auf 2.6 upgedatet und seitdem lässt sich erstens psyco nicht mehr nutzen und zweitens ist 2.6 je nach Algorithmus erheblich (meist aber nur ein wenig) langsamer als der gleiche Code unter 2.5. Da NumPy dort nicht verwendbar ist, es für die Lösung der Problemstellungen Zeitlimits gibt, die sich in der Regel an Sprachen wie C/C++ orientieren und man es teils mit enormen Mengen an I/O zu tun hat, lassen sich zahlreiche Aufgabenstellungen von SPOJ nunmehr mit Python schlichtweg überhaupt nicht mehr lösen und das ist frustrierend ...

[hendrikS]

Ja, hier http://www.spoj.pl/forum/viewtopic.php? ... e76784ef08
stehen die Fakten. Und ich war speziell über die 78 Prozent fast schon schockiert. 2.6 hat doch eigentlich nur geringfügige Änderungen. Wie können dann solche Verschlechterungen entstehen. Im Moment würde ich sagen "Lang lebe 2.5!"
Machen die Python Entwickler eigentlich Tests hinsichtlich Performance? Oder wird einfach draufzu gehackt. Hauptsache es geht.
Selbst alle grossen komerziellen Anbieter von Software haben doch inzwischen erkannt, dass Geschwindigkeit/Zeit ein Faktor ist. Schade, dass dieser Trend bei Python noch nicht angekommen ist.

[lunar]

Machen die Python Entwickler eigentlich Tests hinsichtlich Performance?

Mit Sicherheit. Allerdings sollte es dich nicht wundern, wenn die reine Laufzeitgeschwindigkeit nicht im Vordergrund steht. CPython ist nun mal per se schon nicht schnell, insofern ist es nur verständlich, wenn der Fokus der Entwicklung nicht auf der Laufzeitgeschwindigkeit des Interpreters liegt. Schließlich hat insbesondere die Standardbibliothek genug Ecken und Kanten, die bei der täglichen Arbeit mehr stören als die Laufzeitgeschwindigkeit.

Selbst alle grossen komerziellen Anbieter von Software haben doch inzwischen erkannt, dass Geschwindigkeit/Zeit ein Faktor ist. Schade, dass dieser Trend bei Python noch nicht angekommen ist.

So? Wo siehst Du denn da einen allgemeinen Trend?

[hendrikS]

So? Wo siehst Du denn da einen allgemeinen Trend?

Na zumindest bei den Webbrowsern war das Thema Speed zuletzt akut. Und es gibt, denke ich, bei allen wirklich Bemühungen hier schneller zu werden. Ebenso bei den OS. Soweit ich weis, war oder ist das bei MS ein Thema für das neue Windows.
Insofern meine ich da schon einen Trend sehen zu können.

[Hyperion]

So? Wo siehst Du denn da einen allgemeinen Trend?

Na zumindest bei den Webbrowsern war das Thema Speed zuletzt akut.

Das ist aber doch eher eine Frage der Effizienz von Algorithmen oder der Verwendung von besseren (weil eben effizienteren Bibliotheken). Der neue Chrome Browser hat angeblich viel durch eine bessere JavaScript-Engines an Speed gewonnen. Ich denke nicht, dass google dort einfach die zugrunde liegende Programmiersprache ausgetauscht hat

Bei Implememtierungen von Sprachen designt ja niemand gezielt auf eine langsame Ausführung. Aber prinzipiell sollte hier erst einmal die 100% Funktionstüchtigkeit sicher gestellt sein. Ein CPython nützt einem nicht viel, wenn es durch hohe Geschwindigkeit, aber auch viele Bugs auffällt, oder?

[hendrikS]

Das ist aber doch eher eine Frage der Effizienz von Algorithmen oder der Verwendung von besseren (weil eben effizienteren Bibliotheken).

Yep, genau darum geht es gerade.

[Leonidas]

Und es gibt, denke ich, bei allen wirklich Bemühungen hier schneller zu werden. Ebenso bei den OS. Soweit ich weis, war oder ist das bei MS ein Thema für das neue Windows.

Ich habe hier ein Windows 7 mal installiert, um die Gerüchte zu prüfen (ende der Woche wirds plattgemacht und durch ein Linux ersetzt) und ich finde es nicht schneller als etwa XP. Es hat sicherlich weniger Bloat als Vista, wodurch es sich weniger träge anfühlt, aber subjektiv ist es wohl nur deswegen schnell weil frisch installiert.

Und Linux wird irgendwie auch nicht schneller. Alles was der Kernel etc. gutmacht wird durch weitere Abstraktionsebenen absorbiert. Seit einer halben Woche nutze ich etwa X.org 7.4 statt 7.3 und dort ist die ganze Konfiguration der Eingabegeräte aus dem X-Server zu HAL und dbus übergelaufen, was zwar ziemlich cool und erfreulich ist, aber performancetechnisch sicherlich nicht schneller.

[numerix]

Ja, hier http://www.spoj.pl/forum/viewtopic.php? ... e76784ef08
stehen die Fakten. Und ich war speziell über die 78 Prozent fast schon schockiert. 2.6 hat doch eigentlich nur geringfügige Änderungen.

Ich habe mal ein bisschen experimentiert und dabei ist u.a. folgendes herausgekommen:
Die Umwandlung von Zeichenketten in Ganzzahlen mittels int() - ohnehin auch bislang schon vielfach ein Flaschenhals bei viel Input - dauert unter 2.6 (auf meinem Rechner) ca. 4x so lange wie unter 2.5; unter 3.0 6x so lange und unter 3.1 7x so lange .... oh Schreck.

[sma]

Meine Vermutung wäre, dass 2.6 langsamer als 2.5 ist, weil der Interpreter Tests für diese Warnfunktion für 3.x machen muss. Wenn diese Tests auf eine kritischen Pfad des Programms liegen, kann das zeitlich signifikant sein.

Wer's schneller haben will, soll seine Sachen mit JavaScript schreiben. Auch 'ne schöne Sprache. Noch ein bisschen wenig Batterien dabei, aber ich sage nur Narwhal und Jack bzw. JSGI.

Irgendwann wird vielleicht auch mal Unloaden Swallow in Python einfließen, doch zur Zeit sieht es so auch, als ob auch dies nur ein paar Prozent, nicht aber einen Faktor von 10 oder so für die Laufzeit bringen wird.

Python ist die falsche Sprache, wenn es einfach schnell sein soll (das selbe gilt für Ruby). Bei JavaScript, speziell Googles V8, arbeitet ein Team von Spezialisten, die sich seit mehr als 10 Jahren mit dem Thema beschäftigen. Lars Bak hatte vorher an der Hotspot VM von Sun gearbeitet, davor AFAIK an Strongtalk und davor an Self, zwischen drin noch an speziellen VMs für Java und Smalltalk-artige Sprachen für embedded systems. Die aufgezählten Beispiele zum jeweiligen Zeitpunkt die besten Systeme gewesen. So etwas bauen auch engagierte Freiwillige nicht mal eben an einem Wochenende (obwohl der Quelltext der meisten Systeme vorhanden ist). V8 nutzt die selben Optimierungen wie die Self-VM, die auch Strongtalk und Hotspot schnell gemacht haben. Prinzipbedingt ist das bei Python leider nicht genau so möglich. Zudem machen diese Optimierungen objektorientierte Programme schneller und legen keinen so großen Wert auf z.B. numerische Performance. Somit würde das für derartige Benchmarks wenig bringen.

Ich denke, man könnte einiges an Arbeit sparen, wenn man auf V8 aufsetzt, allerdings ist das kein von diesem Projekt vorgesehener Weg, weil sie explizit keine generische VM sein wollen, sondern nur eine schnelle JavaScript-Engine und z.B. auch keinen Bytecode oder ähnliches haben, sondern direkt aus als C++-Strukturen vorliegenden ASTs von JavaScript Maschinencode erzeugen.

Wie auch immer, nur wünschen macht Python nicht schneller, und außer den Google-Leuten, die an Unloaden Swallow arbeiten, sind alle anderen mir bekannten Projekte mit anderen Sprachen unterwegs. Schade eigentlich.

Wollte da nicht jemand auch Psyco wieder aufleben lassen?

Stefan

[BlackVivi]

Wer's schneller haben will, soll seine Sachen mit JavaScript schreiben. Auch 'ne schöne Sprache. Noch ein bisschen wenig Batterien dabei, aber ich sage nur Narwhal und Jack bzw. JSGI.

Aber...

1. Wie schreibt man Desktopapplikationen in Javascript? Die Leute benötigen ja dann immer einen Browser.
2. Wer sagt, dass sie eine schnelle Version des JS-Intepreters benutzen? Das garantiert ja niemand...

[Hyperion]

Wer's schneller haben will, soll seine Sachen mit JavaScript schreiben. Auch 'ne schöne Sprache. Noch ein bisschen wenig Batterien dabei, aber ich sage nur Narwhal und Jack bzw. JSGI.

Aber...

1. Wie schreibt man Desktopapplikationen in Javascript? Die Leute benötigen ja dann immer einen Browser.

Nö! KDE und Gnome beweisen doch grad, dass man auch GUIs mit JS erstellen kann. Plasmoide (KDE) lassen sich damit bereits entwickeln, bei Gnome entwicklen sie die neue Gnome-Shell für die 3.xer Serie in JS. Unlängst erschien auch ein Plugin für den Firefox, der es Usern ermöglichen soll, komplette Addons in JS zu entwickeln.

Durch Frameworks wie Kross wird JS auch generell in vielen KDE-Applikationen immer beliebter als Scriptsprache.

Ich gebe zu, dass mich JS bisher immer irgend wie abgeschreckt hat, aber so langsam wächst mein Interesse daran schon. Eben vor allem, weil man nicht mehr so stark aufs Web beschränkt ist

[BlackVivi]

Nö! KDE und Gnome beweisen doch grad, dass man auch GUIs mit JS erstellen kann. Plasmoide (KDE) lassen sich damit bereits entwickeln, bei Gnome entwicklen sie die neue Gnome-Shell für die 3.xer Serie in JS. Unlängst erschien auch ein Plugin für den Firefox, der es Usern ermöglichen soll, komplette Addons in JS zu entwickeln.

Mhm... kannte ich gar nicht.

In Ordnung, ich möchte Javascript lernen. Wollte eh mal wieder was neues anfangen... Wie fängt man am besten an, Javascript zu lernen? Finds immer mühevoll im Browser es "auszuführen" und zu "debuggen".

Meh, ich weiß. Furchtbar Off Topic. Ich hoffe das ist nich alzu schlimm... Vielleicht könnte das jemand abspalten und woanders hinschieben oder so ;_;

[Hyperion]

das meinte ich:
http://www.pro-linux.de/news/2009/14687.html

Also eigentlich ist das Ausführen ja nur einmal "F5" zusätzlich gibts ja einige Debugger für denn FF. Also ich würde das als durchaus komfortabel bezeichnen.

[Darii]

Wie auch immer, nur wünschen macht Python nicht schneller, und außer den Google-Leuten, die an Unloaden Swallow arbeiten, sind alle anderen mir bekannten Projekte mit anderen Sprachen unterwegs. Schade eigentlich.

pypy? Einen Faktor 10 haben sie in Spezialfällen zumindest schonmal rausgeholt. Und das es in Python implementiert ist macht es nicht gerade unsympathischer.

[sma]

1. Wie schreibt man Desktopapplikationen in Javascript? Die Leute benötigen ja dann immer einen Browser.
2. Wer sagt, dass sie eine schnelle Version des JS-Intepreters benutzen? Das garantiert ja niemand...

Desktopanwendungen z.B. mit Hilfe von AIR oder Titanium. Opera kann's mittels Widgets auch. Doch auch Firefox und Chrome entwickeln sich weiter und haben viel versprechende Plugin-Schnittstellen, die nicht mehr so ein Krampf sind wie die jetzigen Extensions von Firefox. Und der Mac hat sein Dashboard. Wer will, kann sich natürlich auch einfach SpiderMonkey oder V8 nehmen und mit ein bisschen C-Anbindung so loslegen. Diese Arbeit haben aber die oben genannten Projekte ja schon alle gemacht.

Die Frage nach der schnellen Version verstehe ich nicht so ganz. Eigentlich alles, was ich erwähnt habe (außer Opera), nutzt Webkit und die haben die zweitschnellste JavaScript-Engine nach V8. Die Konkurrenz unter den Plattform sorgt schon von alle dafür, dass die Engines aktuell bleiben und schneller werden.

Zum JavaScript-Lernen kann ich "JavaScript: The Good Parts" von Crockford empfehlen, gibt es als Buch und auch mehrere Videos im YUI Theater. Ich meine, der Mann hat auch einen Google-Techtalk zu dem Thema gehalten. Vielleicht reicht ja aber auch schon https://developer.mozilla.org/en/A_re-i ... JavaScript

Der beste Weg, IMHO, eine Sprache zu lernen, ist natürlich, sie zu implementieren. Vielleicht mache ich das mal demnächst für ein Subset von JavaScript in Python.


Stefan