Hallo Leute,
ich habe hier ein C++-Programm, dass eine groesseres double-Feld als Text in eine Datei schreibt (insgesamt 13 MB). Die Gesamtlaufzeit betraegt 43 s. Laesst man die Ausgabe weg, braucht es 20 s. Konvertiert man die Werte nach float und gibt sie nur binaer aus, so dauert das ebenfalls 20 s; die Differenz ist kaum messbar. Ein in perl geschriebener Konverter fuer binaer nach Text braucht 14 s.
Ergo: Binaerausgabe + perl-Konverter ist merklich schneller als direkte Textausgabe in C++. Ganz super! Hat jemand aehnliche Erfahrungen?
Torsten
On Sun, Jul 22, 2001 at 08:15:07PM +0200, Torsten Werner wrote: Morgen!
ich habe hier ein C++-Programm, dass eine groesseres double-Feld als Text in eine Datei schreibt (insgesamt 13 MB). Die Gesamtlaufzeit betraegt 43 s. Laesst man die Ausgabe weg, braucht es 20 s. Konvertiert man die Werte nach float und gibt sie nur binaer aus, so dauert das ebenfalls 20 s; die Differenz ist kaum messbar. Ein in perl geschriebener Konverter fuer binaer nach Text braucht 14 s.
<Ein Schuß ins Blaue> Stell mal die ganzen locale-Variablen LC_xxx und LANG ab. Ändert das was? Solaris gibt jedenfalls offiziell zu, bei Einsatz von locale-Zeugs langsamer zu arbeiten. Gerade bei der Ausgabe dürfte das eine Rolle spielen. </...>
Reinhard
Am Dienstag, dem 24. Juli 2001 um 05:59:21, schrieb Reinhard Foerster:
Stell mal die ganzen locale-Variablen LC_xxx und LANG ab. Ändert das was?
Noe, das aendert leider nichts. Auch -O3 mal nur fuer die Ausgaberoutine angewendet bringt nichts. Mysterioes, wahrscheinlich muesste man sich die C++-Bibliothek angucken, ich verwende die stlport-Variante. Vielleicht ist das der Grund.
Torsten
On Sunday 22 July 2001 20:15, Torsten Werner wrote:
Ergo: Binaerausgabe + perl-Konverter ist merklich schneller als direkte Textausgabe in C++. Ganz super! Hat jemand aehnliche Erfahrungen?
Es gibt sowohl in C++ als auch in Perl tausend Wege, ein Problem zu lösen. Wenn es nicht unbedingt High-Level-C++ sein muß würde ich die Cache-Verwaltung einfach selbst implementieren, d.h. blockweise alles in ein dickes fettes Array rein und das dann in eine Datei oder auf den Bildschirm dumpen.
Die reine Ein- und Ausgabe von 13 MB in und aus einer Datei mit den C++-Operatoren dauert hier (Athlon500) 24+10 = 24 Sekunden (Textformat). In optimiertem C sind es noch 3+0 = (aufgerundet) 4 Sekunden (Binärformat). Das dann auf den Bildschirm ausgeben ist tricky, weil printf elend lahm ist, da müsste man schon was eigenes schreiben - aber das soll nicht wirklich schnell sein, oder?
Die angehängte Datei demonstriert das mal. Mit 130 MB (zehnfache Menge) gibt es hier nur eine Performance-Bremse, das ist meine nicht-hdparm-optimierte Festplatte. Achso, und ein Quickhack ist auch drin weil der Modulo-Operator "%" unbedingt meint, große Zahlen folgen anderen mathematischen Gesetzen (32499999 % 32500000 ist bei ihm 8124999) - mit Ruby wär das nicht passiert :-)
Josef Spillner
Am Dienstag, dem 24. Juli 2001 um 19:55:20, schrieb Josef Spillner:
Wenn es nicht unbedingt High-Level-C++ sein muß würde ich die Cache-Verwaltung einfach selbst implementieren, d.h. blockweise alles in ein dickes fettes Array rein und das dann in eine Datei oder auf den Bildschirm dumpen.
Das habe ich nun so gemacht, ist aber eventuell nicht so portabel bzw. ich brauche im Ernstfall immer einen Konverter nach Text - nicht wirklich schlimm, da das fast ein perl-one-liner ist.
Die reine Ein- und Ausgabe von 13 MB in und aus einer Datei mit den C++-Operatoren dauert hier (Athlon500) 24+10 = 24 Sekunden
^^^^^^^^^^ aha
(Textformat). In optimiertem C sind es noch 3+0 = (aufgerundet) 4 Sekunden (Binärformat).
Statt C kann man auch die write/read-Funktionen von iostream nehmen, die sind genauso schnell.
Das dann auf den Bildschirm ausgeben ist tricky, weil printf elend lahm ist, da müsste man schon was eigenes schreiben - aber das soll nicht wirklich schnell sein, oder?
perl ist trotz Interpreter offensichtlich schneller, komisch nicht?
Achso, und ein Quickhack ist auch drin weil der Modulo-Operator "%" unbedingt meint, große Zahlen folgen anderen mathematischen Gesetzen (32499999 % 32500000 ist bei ihm 8124999) - mit Ruby wär das nicht passiert :-)
Aehm bei mir ist alles korrekt (gcc 2.95.3).
#include <iostream> int main () { std::cout << 32499999 % 32500000 << '\n'; }
gibt wie erwartet 32499999 aus.
Torsten
On Tue, Jul 24, 2001 at 09:58:31PM +0200, Torsten Werner wrote:
perl ist trotz Interpreter offensichtlich schneller, komisch nicht?
nein, perl übersetzt erstmal den Kode komplett und führt ihn dann aus - ist also kein interpreter.
Reinhard
On Tuesday 24 July 2001 22:26, Reinhard Foerster wrote:
On Tue, Jul 24, 2001 at 09:58:31PM +0200, Torsten Werner wrote:
perl ist trotz Interpreter offensichtlich schneller, komisch nicht?
nein, perl übersetzt erstmal den Kode komplett und führt ihn dann aus - ist also kein interpreter.
Was bei dieser Übersetzung rauskommt ist AFAIK Bytecode. Also wird doch interpretiert - halt nur Binärdaten statt Text.
Konrad
Am Mittwoch, dem 25. Juli 2001 um 06:59:40, schrieb Konrad Rosenbaum:
On Tuesday 24 July 2001 22:26, Reinhard Foerster wrote:
nein, perl übersetzt erstmal den Kode komplett und führt ihn dann aus - ist also kein interpreter.
Was bei dieser Übersetzung rauskommt ist AFAIK Bytecode. Also wird doch interpretiert - halt nur Binärdaten statt Text.
Im Prinzip hast du recht, aber es gibt mit perlcc auch einen "echten" Compiler. Der erzeugt in meinem Fall aus einem 244 Byte grossen Skript eine 900 kB grosse C-Datei, die dann ein etwa 400 kB grosses Binary ergibt. Schneller als das Skript ist das dann aber nicht.
Torsten
On Wed, Jul 25, 2001 at 06:59:40AM +0200, Konrad Rosenbaum wrote:
On Tuesday 24 July 2001 22:26, Reinhard Foerster wrote:
On Tue, Jul 24, 2001 at 09:58:31PM +0200, Torsten Werner wrote:
perl ist trotz Interpreter offensichtlich schneller, komisch nicht?
nein, perl übersetzt erstmal den Kode komplett und führt ihn dann aus - ist also kein interpreter.
Was bei dieser Übersetzung rauskommt ist AFAIK Bytecode. Also wird doch interpretiert - halt nur Binärdaten statt Text.
Wie wir das von Java ja auch kennen, und ich glaube, die Idee war nicht neu, Pascal machte sowas auch schon. In dem einen Fall (Pascal) wurde die Runtime-Umgebung (der P-Code-Interpreter) mit gelinkt, bei Java und Perl müssen diese auf dem Zielsystem vorhanden sein, nur daß bei Perl die Umsetzung in den "Byte"-Code erst auf dem Zielsystem erfolgt, bei Java dagegen auf dem Buildsystem.
Ich denke, so war's.
Heiko
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Josef Spillner -
konrad.rosenbaum＠t-online.de -
Reinhard Foerster -
Torsten Werner