Candletalk

Manche Sprachen unterstützen übrigens den Zugriff auf File-Mappings, die vom Betriebs-System als Service angeboten werden. Zu deren Nutzung rechnet man die Daten einmalig in die interne Darstellung im Hauptspeicher um und blendet dann einfach die im File abgespeicherten internen Darstellungen in den virtuellen Speicher ein. Dabei findet der kleinst-mögliche I/O-Overhead statt, der überhaupt möglich ist. Gerade bei vielen verschiedenen ähnlichen Auswertungen über dem gleichen Daten-Bestand kann man dabei das Warten auf die I/O drastisch reduzieren.

Einige Bibliotheken in Python unterstützen nach ihren Dokumentatione diese Technik auch, ich habe aber noch keine Messungen dazu durchgeführt.

Wenngleich solche Aufgaben mit Python einfach zu lösen sind, muß man bei der Berechnung also nicht unbedingt dabei sitzen und auf blitzartige Resultate hoffen. Andererseits kann man mit den Zeiten leben, solange man nicht irgendeine Aufgabe durchführt, die ähnliche Berechnungen in Echtzeit über sehr vielen Instrumenten durchführen muß. (Als Beispiel mal: Der Tages-Datenfeed einer mir bekannten Börse ist etwa 14 GiB groß.)

Andererseits sind die Zeiten noch gar nicht lange her, als selbst simpelste Berechnungen im Rechenzentrums-Betrieb in Stapel-Verarbeitungen nach Tagen und nicht nach Mikro-Sekunden abgewickelt wurden und ob man Input für statistische Auswertungen nun nach Sekunden oder erst Minuten zur Verfügung hat, ist für viele Anwendungs-Felder egal. Außerdem ist es sowieso eine Riesen-Unsitte, den Computer bei längeren Berechnungen zu beobachten, der rechnet dadurch weder schneller noch genauer.

Auch wenn eine compilierte Sprache wie z. B. C schon Prinzip-bedingt deutlich schneller ist, lasse ich einen solchen Vergleich trotzdem mal offen, da die genauen Resultate für so eine Aufgabe mit sequentiellem Lesen auch sehr stark vom I/O-System des Computers abhängen und damit eine faire Bewertung der Sprachen untereinander nur sehr eingeschränkt möglich ist.

Um einen Eindruck von der zuweilen bemängelten Geschwindigkeit von Python zu erhalten, führe ich hier mal ein Beispiel eines Python-Programmes an, bei dem nichts optimiert wurde, sondern nur auf gute Lesbarkeit Wert gelegt wurde. Es rechnet für die Untersuchung zu bo1's Idee aus dem Gold-Thread Tickdaten für 2011 in Minuten-Daten um, also einer typischen simplen Daten-Vorbereitungs-Aufgabe mit

• sequentiellem Lesens einiger Files (je eins pro Woche) mit jeweils einigen Hunderttausend Zeilen,
• der Prüfung gegen ein Muster (regulärer Ausdruck),
• einigen simplen Subtraktionen und
• dem Schreiben einiger Files mit jeweils etwa 6.500 Zeilen.

Zuerst habe ich ein System mit AMD Dual-Core QL-66, 2,2 GHz, 4 MiB RAM, Windows 7, Python(X,Y) 2.7 benutzt, welches folgende Geschwindigkeit lieferte:

Der ursprüngliche Daten-Bestand in 44 Files mit insgesamt 596 MiB (gezippt immer noch 64 MiB) in etwa 8,5 Mio. Tick-Daten-Sätzen wurde zu 299.000 Minuten-Sätzen mit 27 MiB (gezippt 4,25 MiB) herunter gerechnet.

Das Python-Skript brauchte dafür 790 Sekunden und schaffte 10.750 Input-Zeilen pro Sekunde zu verarbeiten.

Weil die Werte nicht gerade super sind, habe ich die gleiche Aufgabe noch auf einer anderen Maschine mit 2 x Intel Core i5 750, 2.67 GHz, 32 GiB RAM, CentOS 5, CPython 2.4 durchgerechnet und da war es zwar in etwa doppelt so schnell, aber damit immer noch ziemlich langsam.

Die Geschwindigkeit von Python wird oft bemängelt, denn in der wichtigsten Implementation CPython werden Symbole zur Runtime fortlaufend in Dictionaries nachgeschlagen, was in compilierten Sprachen mit einem direkten und sofortigen Zugriff auf die richtige Speicher-Adresse realisiert wird.

Konzeptuelle Leistungs-Fähigkeit und ein leichter Round-Turn bei Änderungen werden also mit Abstrichen bei der Leistung erkauft und die Frage ist nur, wie hoch dieser Abstrich ausfällt. In sehr vielen Szenarien, gerade bei der Lösung von ad-hoc-Aufgaben, spielt aber für den Gesamt-Aufwand die Ausführungs-Geschwindigkeit gegenüber dem Programmier-Aufwand nur eine untergeordnete Rolle, so daß das Haupt-Ziel der meisten IT-Projekte darin besteht, den teuersten Faktor der menschlichen Arbeits-Zeit zu reduzieren.

Nebenbei sei dazu aber angemerkt, daß die Gewinne an Round-Turn-Zeit (Editieren, Übersetzen, Debuggen, .... und wieder von vorne) bei Umgebungen, die inkrementell übersetzen (wie z. B. Eclipse für Java) heute lange nicht mehr so beachtlich sind, wie früher als man wirklich längere Übersetzungs-Läufe starten mußte oder gar Tage-weise getaktet auf ein Rechen-Zentrum warten mußte. Außerdem werden durch die sehr strenge Typ-Prüfung bei der Übersetzung viele Fehler nicht richtig passender Operationen sofort erkannt und müssen nicht erst später mühsam raus debuggt werden, wie bei Skript-Sprachen, wo keine Variablen inkl. ihrer Typen deklariert werden. Möglicherweise sind ist der Ruf der Skript-Sprachen darum heute besser als ihr realer Produktivitäts-Gewinn, wenn man nicht nur die technischen Zeiten sondern die Gesamt-Zeit inkl. Debugging ansieht.

Andererseits gibt es gerade für Python viele Bibliotheken und die einfache Syntax der Sprache ermöglicht nach meinen bisherigen Erfahrungen ein recht glattes Arbeiten ohne größere Probleme. Die Sprache kann sehr gut Programmier-Anfängern empfohlen werden, ist aber auch für Profis voll Leistungs-fähig.

Für die Hauptspeicher-interne Arbeit stehen mit numpy und vielen anderen auch Bibliotheken bereit, die komplexe Verarbeitungen mit hoch-optimierten (oft in C implementierten) Algorithmen mit Größen-Orndungs-mäßig vergleichbarer Geschwindigkeit wie in kompilierten Sprachen bereit stellen. Darüber ist auch die Anbindung selbst geschriebener optimierter Algorithmen in anderen Sprachen über gleich mehrere verschiedene Integrations-Schnittstellen sehr einfach. In der .NET-Implementation können alle öglichkeiten der CLR genutzt werden, in der Jython-Implementation viele Möglichkeiten der Java-VM.

Als ein unverbindliches Beispiel für den Zeitbedarf einer einfachen Aufgabe, unter der sich jedermann was vorstellen kann, gebe ich hier mal den Rechen-Aufwand für die simple Vorbereitungs-Handlung der Konvertierung von Tick-Daten-Files in Minuten-Daten an, ohne irgendeine Form von Geschwindigkeits-Optimierung oder überhaupt professioneller Programmierung zu versprechen, weil es eher Teil einer Technologie-Studie war.

Diese Aufgabe fiel im Zusammenhang mit einer noch nicht abgeschlossenen Untersuchung zu bo's Behauptung eines bestimmten Verhaltens des Gold-Futures an. Die folgenden Texte hatte ich schon am 24.11.2011 geschrieben, wollte sie ursprünglich aber erst zusammen mit der Auswertung publizieren.

Daß die Untersuchung sich übrigens ewig hinzieht, liegt darin, daß ich sie nicht so sehr aus Interesse an ihrem Resultat durchführe, von dem ich 1) eine recht genaue Vorstellung habe, 2) mangels intensiven Gold-Tradens auch wenig eigenen Nutzen ziehe, sondern daß ich sie mit einem neuen Software-Baustein-System ausführe, wo für mich aktuell das Verständnis der Technologie im Vordergrund steht und ich 3) auch noch Anderes zu tun habe.

Da MB/8 mich heute im Theorie-Thread was zu numerischen Aufwänden fragte, habe ich als Beispiel einfach den Rest der folgenden ursprünglichen Artikels so gelassen und sie für das Zahlen-Beispiel mitgenutzt.

Da viele Programmierer auch im Zeitalter von Eclipse, Netbeans, Visual Studio & Co. den vi-Nachfolger gvim als Editor nutzen, weil man damit bei ausreichender Einarbeitung sehr produktiv arbeiten kann, sei angemerkt, daß er bereits von Hause aus Python 2 und Python 3 mit den Befehlen ':py' bzw. ':py3' unterstützt, so er die DLL's im Suchpfad des Betriebs-Systems finden kann. Mit 'from vim import *' s. Hilfe ':h py' bekommt man auch Zugriff auf die Editor-Puffer zum Lesen und Schreiben, so daß man selbst so einen Dino-Saurier mit Python automatisieren kann.

Ich kann den vi übrigens durchaus einigermaßen vernünftig bedienen, aber bin nicht sein allergrößter Freak, weil er bei der Navigation in größeren Systemen auf die es wesentlich mehr ankommt als auf klein-teiliges Programmieren gegenüber GUI-IDEs schon etwas verstaubt aussieht, wenngleich es mit eclim sogar eine Voll-Integration vim/Eclipse gibt. Wenn ich einen nackten Editor (außerhalb einer IDE) nach freier Wahl benutzen kann, nehme ich übrigens meistens Ultra-Edit Version 10, die vorigen Releases konten nicht genug, die folgenden waren mir zu bunt überladen.

Es ist immer sehr ärgerlich, wenn es eine nicht abwärts-kompatible Sprach-Version gibt, wie das mit Python 2 und 3 ist. Für einen menschlichen Programm-Autor sind die Unterschiede aber nicht wirklich gravierend. Schlechter ist das mit der Kompatibilität von Bibliotheken oder Ausgaben von Programm-Generatoren.

In vielen Fällen kann das Problem schon mit der Nutzung des im Paket enthaltenen Konverters 2to3 gelöst werden. Manche größere Bibliotheken sind aber noch nicht umgestellt und ehe man da experimentiert und nur etwas umstellt, um zwanghaft modern zu sein, kann man für praktische Zwecke auch noch eine Weile mit Python 2 weiter arbeiten.

Da das Interesse an einem nicht oberflächlichem Laber-Thread ja wieder einmal "exorbitant" ist, reiche ich mal eine recht ordentlich gelungene Arbeit mit dem Titel Eignet sich die Skriptsprache Python für schnelle Entwicklungen im Softwareentwicklungsprozess? (bereits aus dem Jahr 2002) nach, die mir in anderem Zusammenhang als diesem Forum untergekommen ist.

Das wird das Für und Wider zu Python umfassend beleuchtet und die richtigen - für Python gar nicht mal schlecht ausfallenden - Schlüsse gezogen. Alle, die eine Laune oder Mode weniger interessierter Herren mit einem privaten Python-Spleen befürchteten, können sich da noch einmal ausführlich oder zusammenfassend von Dritter Seite beraten lassen.

Das von Grisu empfohlene, recht ordentlich gemachte Python-Tutorial sollte man bei etwas IT-Interesse einfach mal lesen, vielleicht sogar ohne den ausgeprägten Wunsch, Python später auch zu nutzen. Dann kann man die Sprache wenigstens schon mal einordnen und findet vielleicht sogar weiteres Interesse daran, insbesondere wenn man in einer der vielen unkomplizierten Entwicklungs-Umgebungen ein wenig praktisch damit arbeitet.

Ich hätte erwartet, daß im ursprünglich von Purri erwähnten Sho die eine Grundlage für viele andere wissenschaftliche Pakete bildenden Pakete scipy inkl. seiner Basis numpy und die Leistungs-fähige Graphik-Bibliothek matplotlib schon mit integriert sind. Da die in Sho teils ähnlichen, aber ansonsten anderen und auch weniger funktionalen Schnittstellen nicht dem Python-Mainstream entsprechen, halte ich Sho nicht für das Optimum.

Man kann diese Pakete nach der im Post #6 beschriebenen Grund-Installation manuell nachinstallieren, wie hier beschrieben. Damit es dann überhaupt läuft, muß beim Aufruf des IronPython-Interpreters ...\IronPython-Installations-Verzeichnis\ipy.exe unbedingt die zusätzliche Kommando-Zeilen-Option -X:Frames angegeben werden.

Eine Python-Distribution für mathematische Arbeiten, die umfangreiche bereits fertig aufeinander abgestimmte Installations-Pakete enthält, ist PythonXY. Bei deren Installation sollte man aber unbedingt selbst gewählte Verzeichnisse im Installations-Dialog angeben, damit die Einzel-Teile nicht quer über das System, u. a. auch ins Root-Verzeichnis der System-Festplatte, verstreut werden.

Diese Installation belegt, wenn man alle Komponenten auswählt, knapp 1 GiB auf der Festplatte. Die Installation dieser Distribution scheint mir durchaus empfehlenswert.

Wer für eigene Auswertungen Anregungen braucht, kann in der Bilder-Gallerie von matplotlib nachsehen, wo zusammen mit den Bildern auch die (meist nur kurzen) Quelltexte zu ihrer Erzeugung angegeben sind.

Mir hat die auch unter dem Namen PyLab bezeichnete Umgebung, die als Kern in der sehr umfassenden PythonXY-Distribution enthalten ist, subjektiv deutlich besser gefallen als Microsofts Sho.

In der PythonXY-Distribution ist übrigens mit Spyder auch eine brauchbare integrierte Entwicklungs-Umgebung drin.

Bei mit 1 GiB doch schon recht üppigen Installationen kannn man überlegen, ob man mit nur noch etwas mehr Overkill gleich ein komplettes Computer-Algebra-System wie Sage, dessen Installation auch nur 4 GiB belegt, die sich aus dem knapp 1,5 GiB großen importierbaren Appliance-File sage-4.7.1.ova bilden. Linux-User können natürlich die Pakete auch ohne VM direkt einspielen oder eine fertige wissenschaftliche Linux-Distribution nutzen. Ich selber nutze übrigens Sage bisher nicht produktiv, weil sich Mathematica dann doch besser anfühlt. Ebenso wäre das Verhältnis von Einarbeitungs-Aufwand in die vielen einzelnen Module im Verhältnis zum für meine Trading-Zwecke meist ausreichenden Statistik-zentrierten R mit ebenfalls guten Graphik-Fähigkeiten nicht sinnvoll.

In vielen Fällen tun es auch schon kleinere Systeme wie Octave oder für ein schnelles Malerchen Gnuplot - aber in diesem Thread sollte ja Python als voll ausgebaute Programmier-Sprache (derzeit etwa Rang 6 in der Beliebtheit [je nach Meß-Verfahren]) mit seinen vielen Leistungs-starken Bibliotheken im Vordergrund stehen.

Bezugnehmend auf Purri's Post #35 im Backtest-Thread, würde sich das mit dem flinken Einstieg über das Tutorial aus der Intention eines "Common Formats" zur allgemeinen Präsentation solcher Untersuchungen für eine breitere User-Schar heraus eher gut anhören, daß da so schnell Ergebnisse erzielbar sind. Wenn noch ein paar normale Weit-Mehr-Trader-als-Programmierer ähnlich geringe Berührungs-Ängste zeigen, wäre das doch schon mal ein guter Einstieg.

Daß man das "Einziehen" einer neuen Programmier-Sprache auch halbwegs locker angehen kann, zeigt das bei Wikipedia: Python verlinkte Buch für Kinder (ab 8 ?? Jahren) Schlangengerangel für Kinder, Programmieren lernen mit Python.

( ... wenn ich mal davon absehe, daß die Turtle-Graphik unter meiner IronPython-Installation im Husch-Husch-Hyper-Eil-Durchlauf ohne auch nur eine Sekunde auf Ursachen-Forschung zu verschwenden - wie man das als seriös arbeitender IT-Experte eigentlich machen sollte - wegen eines fehlenden Moduls nicht lief und unter CPython nur von der Console (nicht aus IDLE heraus) und unter einem schon betagten Cygwin die Graphik ganz verendete. - Aber ganz Tschakka weiß ich auch, daß Alle immer nur Lösungen sehen wollen, keine Probleme )

Ich hab ja vorbildlich "OT" davor geschrieben.

Eigentlich möchte ich nicht, daß aus einer Rand-Frage, einer der vielen nutzlosen Glaubens-Kriege wird. Nach nunmehr fast 20 Jahren als in der eher größeren Industrie nicht nur in D tätiger Berater mußte ich meine Erkenntnisse, Schlußfolgerungen, Konzeptionen und Implementationen oft genug einigermaßen pingeligen Checks durch sachkundige Fach-Kundschaft unterziehen lassen, oft in direkter sehr scharfer Konkurrenz zu deren eigenen Fach-Abteilungen.

Daher gestatte ich mir völlig unabhängig von anderen Ansichten, schon behaupten zu dürfen, zu wissen, was im Umfeld wirklich großer und heterogener IT-Systeme abgeht und kenne oft die widerstreitenden Überlegungen für die gegensätzlichen Lösungen, die ich möglicherweise auch schon in unterschiedlichen Zusammenhängen auf beiden Seiten vertreten habe, manchmal sogar wegen geänderter Umstände in zeitlichem Abstand beim gleichen Kunden bzw. zur gleichen Zeit in verschiedenen Abteilungen mit unterschiedlicher Ausgangs-Lage.

Darüber hinaus war das Thema des Threads ja gerade eine Plattform-übergreifende Sprach-Umgebung.

Trotzdem möchte ich zu sehr um sich greifenden Unix-Hype heraus nehmen, indem ich einigermaßen Emotions-los feststelle, daß mit riesigen und berechtigten Erfolgen unixoide Systeme an vielen Stellen im Einsatz sind, über alle Geräte-Klassen hinweg vom Hochleistungs-Groß-Rechner bis zu extrem abgespeckten Embedded Devices und die Open-Source-Systeme einen prinzipiellen Zusatz-Bonus haben.

Genauso Emotions-los stelle ich aber auch fest, daß andererseits öfter mal darüber hinweg gesehen wird, daß im Bereich großer industrieller und sehr kritischer Steuerungen Windows durchaus einen festen Platz mit hohen Markt-Anteilen hat (z. B. auch durch den deutschen Markt-Führer) und zwar von den zentralen Server-Farmen über Einzel-Maschinen-Steuerungen bis hinunter zu kleinsten Devices mit Windows CE, mit denen es fast nie Ärger gibt. Ebenso gibt es einen großen Markt-Anteil von auch großen SAP-Installationen und Virtualisierungs-Lösungen für ganze Konzerne mit Windows, bei denen kein Unternehmen unnötige Risiken eingehen würde. Selbst in der Steuerung von Atom-U-Booten wurde Windows schon eingesetzt und das nicht nur auf der Spiele-Konsole für die Mannschaft.

Wie sicher ein ausgereift aufgesetztes Window ist, kann man an den Spiele-Konsolen sehen, von denen ich heute noch eine habe, die ich eigentlich mit Linux betreiben wollte, bei deren Serien-Nummer der Firmware aber keiner der bekannten Jailbreak-Hacks klappt. Das sind nahezu absolut wasserdichte Windows-Systeme.

Daß Windows mit der Zeit angeblich immer langsamer wird, ist schon seit Jahren als Gerücht enttarnt worden, wenn es fachgerecht administriert wird - wie viele andere Mythen um Windows auch.

Auch die vermeintliche Super-Linux-Sicherheit ist so eine Sache, denn die hängt davon ab, wieviele Leute die Quelltexte wirklich qualifiziert gegenlesen und auch subtile Änderungen bemerken, wie z. B. als vorsätzlich ein Hack im IP-Stack (Super-GAU, betrifft eine sensible Stelle und kompromittiert sofort alles) über die Initialisierung von Arrays mit Hex-Konstanten eingebaut wurde. Nicht umsonst gibt es ganze Firmen, die sich mit der Härtung von unixoiden Systemen als einzigem Geschäfts-Zweck beschäftigen.

Wie man an der Menge der Patches für Linux-Applikationen sieht, hilft übrigens selbst das beste Betriebs-System nichts, wenn die darauf laufenden Applikationen Sicherheits-Löcher größer als Scheunen-Tore haben. Und fast alle gehackten Web-Präsenzen laufen auf standard-mäßigen Linux-Installationen, die selbst große Betreiber auch nach über 10-jähriger Erfahrung nicht sicher hin kriegen, was nicht nur an der Unfähigkeit der Endnutzer liegt, die mit schludrigen Web-Präsenzen noch weitere Instabilitäten einbringen, sondern auch an nach langer Zeit noch unentdeckten Lücken in Millionen-fach eingesetzter Standard-Software.

Völlig unabhängig vom Betriebs-System ist die fachliche Qualifikation und Motivation der Admistratoren ein sehr ernstes Problem, wie mir gerade am Anfang dieses Jahres von einem für die Branche eher großen IT-Unternehmen (alleine um die 20 Admins) und gleich mehreren von ihm parallel verschlissener Rechen-Zentren demonstriert wurde.