Performance Vergleich von Perl und Ruby gesucht

Hallo Leute !

Für ein neu aufzusetzendes (Teil)Projekt könnte Perl oder Ruby zum Einsatz
kommen.

Input: Ein paar Hundert Textdateien verschiedenster Größe.

Funktion: pro Datei: Auffinden konkreter Variablen/Werte und Überprüfen
diverser Kriterien
(Wertebereiche, Eindeutigkeit, ...)

Output: (1) für jede Datei: O.K. / not O.K. plus kurze textuelle
Beschreibung des Fehlersymptoms
(2) Statistik über alle Dateien

Durch die große Anzahl der Dateien und anzuwendenden Regeln wird die
Laufzeit zu einem wichtigen Kriterium.

Für o.a. Anwendung kristallisieren sich für mich folgende Schwerpunkte
heraus:
(.) File-I/O
(.) String Operationen incl. Pattern Matching mit RegExps
(.) Hashes

Gibt's da bereits Performace-Vergleiche zwischen Perl und Ruby ?

Jeder Hinweis ist willkommen !
Christoph

Re: Performance Vergleich von Perl und Ruby gesucht

On 2006-10-19 15:48, Christoph Neubauer wrote:
> Für ein neu aufzusetzendes (Teil)Projekt könnte Perl oder Ruby zum Einsatz
> kommen.
[...]
>
> Gibt's da bereits Performace-Vergleiche zwischen Perl und Ruby ?

Generell: Wenn Du wissen willst, wie gut oder schlecht die Performance
für Deine Applikation mit Deinen Daten ist, musst Du einen Benchmark mit
Deiner Applikation und Deinen Daten durchführen.

Benchmarks mit anderen Applikationen und anderen Daten können maximal
erste, grobe Richtwerte geben.

Nachdem das gesagt ist, hat es mich ungefähr 2 Minuten Googeln gekostet,
das da zu finden:

http://shootout.alioth.debian.org/gp4/ruby.php

Das schaut nicht gut für Ruby aus, wenn Du nicht gerade Pi berechnen
willst.

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Performance Vergleich von Perl und Ruby gesucht

"Peter J. Holzer" writes:

[...]
>
> Nachdem das gesagt ist, hat es mich ungefähr 2 Minuten Googeln gekostet,
> das da zu finden:
>
> http://shootout.alioth.debian.org/gp4/ruby.php
>
> Das schaut nicht gut für Ruby aus, wenn Du nicht gerade Pi berechnen
> willst.
>

Und das perl hier so schlecht ist, liegt einfach nur daran, dass auf
der Shootout-Maschine GMP nicht installiert ist und Math::BigInt im
(sehr langsamen) Pure-Perl-Fallback-Modus arbeitet.

AFAIK wird an einer Lösung gearbeitet.

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net

Re: Performance Vergleich von Perl und Ruby gesucht

"Peter J. Holzer" wrote in message
news:...

>

> Nachdem das gesagt ist, hat es mich ungefähr 2 Minuten Googeln gekostet,

> das da zu finden:

>

> http://shootout.alioth.debian.org/gp4/ruby.php

>

Danke für den Link !

Das Ganze sieht sehr professionell aus.

Christoph

Re: Performance Vergleich von Perl und Ruby gesucht

Slaven Rezic!

> Und das perl hier so schlecht ist, liegt einfach nur daran, dass auf
> der Shootout-Maschine GMP nicht installiert ist und Math::BigInt im
> (sehr langsamen) Pure-Perl-Fallback-Modus arbeitet.

Das ist irgendwie ziemlich offensichtlich. Jede Sprache, die ungefähr mit
perl gleichauf liegt, ist beim PI berechnen um Größenordnungen schneller :-)
Typischer Fehler für Leute, die denken, dass man Sprachen einfach so
gegeneinander benchmarken kann, ohne zu gewährleisten, dass jede einzelne
Implementation die gleichen Bedingungen hat.


Gruß
Daniel

Re: Performance Vergleich von Perl und Ruby gesucht

Christoph Neubauer!

> Das Ganze sieht sehr professionell aus.

Das täuscht. So ein Benchmark kann man eigentlich nicht professionell
machen. In diesem Fall wird jeder Sprache der selbe Algorithmus
aufgezwungen. Dadurch kann man an den Ergebnissen zwar vergleichen, welche
Sprache sich für einen bestimmten Algorithmus besser eignet, aber
keinesfalls, mit welcher Sprache man das dazugehörige Problem am besten
lösen kann.

Würde man der Implementierung jede Freiheit lassen, könnte man das zwar
besser vergleichen, hätte aber immer noch nicht berücksichtigt, dass es
auch auf die Erfahrung des Programmierers ankommt. Der braucht ja
eventuell nur ein winziges Detail nicht zu kennen und produziert in der
selben Sprache für das selbe Problem sofort eine wahnsinnig ineffiziente
Lösung, die sich nur dadurch auszeichnet, dass sie vielleicht nahe liegt.

Als Beispiel eignen sich die Berechnungen beim "recursive"-Test mit am
besten. Die Perl-Implementierungen sind ganz am Ende der Tabelle, C++ ist
ganz oben. Die C++-Implementierung ist ziemlich straight forward, wie alle
Programme bei diesem Test. Sie strotzt auch nur so vor Compiler-Spezifika.
Trotzdem kriege ich den Perl-Code mit einer simplen* Modifikation um eine
Größenordnung schneller als den C++-Code. Den C++-Code könnte man mit
messbar mehr Aufwand selbstverständlich ebenso beschleunigen. Was sagt
der Test also überhaupt aus?


Gruß
Daniel

(*) Caching

Re: Performance Vergleich von Perl und Ruby gesucht

Daniel Fischer wrote:

> Das täuscht. So ein Benchmark kann man eigentlich nicht professionell
> machen.

Die genauen Bedingungen sind sicherlich schwer zu definieren.
Eine größere Zahl an unterschiedlichen Tests ist bestimmt hilfreich.
Dass Perl unter den Skriptsprachen herausragend schnell ist,
ist aber allgemein bekannt und geht aus diesem Test
übers Ganze gesehen auch deutlich hervor.

> (*) Caching

Bei einem Algorithmus, der sowas nicht vorsieht, ist das meiner
Meinung nach auf jeden Fall geschummelt.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Performance Vergleich von Perl und Ruby gesucht

Frank Seitz!

>> (*) Caching
>
> Bei einem Algorithmus, der sowas nicht vorsieht, ist das meiner
> Meinung nach auf jeden Fall geschummelt.

Deshalb schicke ich sowas ja nicht ein. Aber mal ganz ehrlich, in einer
Situation, wo man sich die Frage stellt, ob man für eine konkrete Aufgabe
Perl oder eher Ruby einsetzt - fragt man sich da eher, welche Sprache bei
einer naiven Implementierung schneller ist, oder in welcher
Sprache man geringfügig weniger naiven Code schneller schreiben kann?

Ich nehme als Beispiel mal aus recursive.pl nur die Funktion Fib. Die
sieht im Benchmark so aus:

sub Fib {
my ($n) = @_;
return 1 if $n < 2;
my $f1 = Fib($n - 1);
my $f2 = Fib($n - 2);
return $f2 + $f1;
}

$ time perl rec3a.pl 3
Fib(30.0): 1346269.0
Fib(3): 3

real 0m2.960s
user 0m2.948s
sys 0m0.012s

Und ich schaue mir die selbe Funktion in C an (Code spare ich mir hier):
$ time ./rec3a 3
Fib(30.0): 1346269.0
Fib(3): 3

real 0m0.056s
user 0m0.052s
sys 0m0.004s


Nun Perl mit folgender trivialer Modifikation:

sub Fib {
my ($n) = @_;
return (1, 1) if $n < 2;
my ($a, $b) = Fib($n-1);
return ($a + $b), $a;
}

$ time perl rec3.pl 3
Fib(30.0): 1346269.0
Fib(3): 3

real 0m0.010s
user 0m0.000s
sys 0m0.000s

Mit anderen Worten, ich sehe hier: Perl braucht auf meinem Rechner zwar
drei Sekunden, um Fib(30) auszurechnen, aber wenn ich 10 Sekunden
aufwende, um den Code zu verbessern, braucht es plötzlich fast nichts
mehr. In C ist die Änderung auch möglich, aber deutlich aufwändiger,
wenn man nicht auf die Threadsicherheit verzichten will. Danach brauchen
beide ungefähr gleich lang. Die vorgegebene Lösung dagegen ist messbar
(wenn auch nicht schlimm) langsamer als meine Perl-Lösung.


Gruß
Daniel

Re: Performance Vergleich von Perl und Ruby gesucht

Daniel Fischer wrote:

> Aber mal ganz ehrlich, in einer
> Situation, wo man sich die Frage stellt, ob man für eine konkrete Aufgabe
> Perl oder eher Ruby einsetzt - fragt man sich da eher, welche Sprache bei
> einer naiven Implementierung schneller ist, oder in welcher
> Sprache man geringfügig weniger naiven Code schneller schreiben kann?

Beides, würde ich sagen. Und noch einiges mehr.

> Nun Perl mit folgender trivialer Modifikation:
>
> sub Fib {
> my ($n) = @_;
> return (1, 1) if $n < 2;
> my ($a, $b) = Fib($n-1);
> return ($a + $b), $a;
> }

Das ist nicht mehr die gleiche Funktion. Die Modifikation
mag trivial sein, aber das ist mit Sicherheit keine
naive Implementierung mehr, von der Du oben gesprochen hast.

> $ time perl rec3.pl 3
> Fib(30.0): 1346269.0
> Fib(3): 3
>
> real 0m0.010s
> user 0m0.000s
> sys 0m0.000s

Erstaunlich, dass das soviel ausmacht.

> Mit anderen Worten, ich sehe hier: Perl braucht auf meinem Rechner zwar
> drei Sekunden, um Fib(30) auszurechnen, aber wenn ich 10 Sekunden
> aufwende, um den Code zu verbessern, braucht es plötzlich fast nichts
> mehr. In C ist die Änderung auch möglich, aber deutlich aufwändiger,
> wenn man nicht auf die Threadsicherheit verzichten will. Danach brauchen
> beide ungefähr gleich lang. Die vorgegebene Lösung dagegen ist messbar
> (wenn auch nicht schlimm) langsamer als meine Perl-Lösung.

Hm, in C müsste sich das durch Einführung eines struct
für den Returnwert ähnlich leicht einführen lassen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Performance Vergleich von Perl und Ruby gesucht

Frank Seitz!

> Das ist nicht mehr die gleiche Funktion. Die Modifikation
> mag trivial sein, aber das ist mit Sicherheit keine
> naive Implementierung mehr, von der Du oben gesprochen hast.

Natürlich ist das weniger naiv. Aber in anderen Sprachen (denk
funktionale) erledigt sowas der Compiler. Perl stellt mir auch die Mittel
für diese Optimierung zur Verfügung. Sie sind nichtmal schwer zu
benutzen. Warum darf ich sie nur in Perl nicht einsetzen? Dadurch werden
die Fähigkeiten der Sprache für das Benchmark künstlich eingeschränkt,
und dadurch sagt das Benchmark eben gar nichts mehr über die Sprache
selbst aus.

> Erstaunlich, dass das soviel ausmacht.

Naja, ich vermute ein wenig aufsehenerregendes Speicherplatzproblem.

> Hm, in C müsste sich das durch Einführung eines struct
> für den Returnwert ähnlich leicht einführen lassen.

Das sehe ich schon als deutlich mehr Aufwand, da dann existierender Code,
der die Funktion aufruft, angepasst werden muss. Man kommt um das struct
auch herum, wenn man mag, zum Beispiel so:

double FibFP(double n) {
static double m = 1.0;
if (n < 2.0)
return m = 1.0;
double tmp = FibFP(n-1);
double k = m;
m = tmp;
return tmp + k;
}

Das hat natürlich andere Nachteile. In jedem Fall macht mir Perl die
Optimierung einfacher, aber das Benchmark berücksichtigt sowas überhaupt
nicht.


Gruß
Daniel

Re: Performance Vergleich von Perl und Ruby gesucht

Daniel Fischer schrieb:

> Nun Perl mit folgender trivialer Modifikation:
>
> sub Fib {
> my ($n) =3D @_;
> return (1, 1) if $n < 2;
> my ($a, $b) =3D Fib($n-1);
> return ($a + $b), $a;
> }
>
> $ time perl rec3.pl 3
> Fib(30.0): 1346269.0
> Fib(3): 3
>
> real 0m0.010s
> user 0m0.000s
> sys 0m0.000s
>
> Mit anderen Worten, ich sehe hier: Perl braucht auf meinem Rechner zwar
> drei Sekunden, um Fib(30) auszurechnen, aber wenn ich 10 Sekunden
> aufwende, um den Code zu verbessern, braucht es plötzlich fast nichts
> mehr.

Sorry, daß ich hier widerspreche.
Der Sinn dieses Tests ist, heruaszufinden, wie stark rekursive
Funktionen sich verhalten in Bezug auf Performance. Wenn man nur
rausfinden wollte, was die n. Fibonacchi Zahl ist, kann man das auch in
einem schnellen loop ohne jegliche Rekursion machen. Es geht hier aber
eben nicht darum, wer den besten Algorithmus findet (der ja bei fib
altbekannt ist), sondern man nimmt bewußt den "naiven" Algrithmus.
Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir
dort gelingt, in 10 Sekunden eine einfache Modifikation zu finden, die
die Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich
nächstes Jahr einen Nobelpreis.

Und nein, es gibt meines Wissens keine Sprache, auch keine funktionale,
die einen besseren, äquivalenten Algorithmus sucht und auch findet.
Die üblichen Optimierungen werden gemacht, von denen es bei
funktionalen Sprachen aufgrund der Rahmenbedingungen erstaunlich viele
gibt. Aber das wars dann auch.

> In C ist die Änderung auch möglich, aber deutlich aufwändiger,

Nein. DIese Änderung, die Du gemacht hast, würde man nicht machen,
weil sie immer noch suboptimal ist.

fib n =3D let
fib' k a b =3D if k == n then a+b else fib' (k+1) b (a+b) -- tail
call --> optimiert zu loop
in case n of
0 -> 1
1 -> 1
_ -> fib' 2 1 1

(Das kann man auch in C oder Perl als Loop schreiben.)


> wenn man nicht auf die Threadsicherheit verzichten will. Danach brauchen
> beide ungefähr gleich lang. Die vorgegebene Lösung dagegen ist messbar
> (wenn auch nicht schlimm) langsamer als meine Perl-Lösung.

Mit obigem Algorithmus dürfte selbst fib.pl 2000 kaum meßbar sein.
Geschweige denn optimiertes C++ oder gar Fortran.

Re: Performance Vergleich von Perl und Ruby gesucht

On 2006-10-20 14:55, Frank Seitz wrote:
> Daniel Fischer wrote:
>
>> Aber mal ganz ehrlich, in einer
>> Situation, wo man sich die Frage stellt, ob man für eine konkrete Aufgabe
>> Perl oder eher Ruby einsetzt - fragt man sich da eher, welche Sprache bei
>> einer naiven Implementierung schneller ist, oder in welcher
>> Sprache man geringfügig weniger naiven Code schneller schreiben kann?
>
> Beides, würde ich sagen. Und noch einiges mehr.
>
>> Nun Perl mit folgender trivialer Modifikation:
>>
>> sub Fib {
>> my ($n) = @_;
>> return (1, 1) if $n < 2;
>> my ($a, $b) = Fib($n-1);
>> return ($a + $b), $a;
>> }
>
> Das ist nicht mehr die gleiche Funktion. Die Modifikation
> mag trivial sein, aber das ist mit Sicherheit keine
> naive Implementierung mehr, von der Du oben gesprochen hast.

Eben nicht. Das war IMHO genau das Argument von Daniel: Dass es in Perl
trivial ist, nicht-naive Lösungen zu verwenden. Und dass sie deshalb "in
real life" auch verwendet werden, wodurch ein Benchmark der naiven
Lösung wenig über die Real-Life-Performance aussagt.


> Erstaunlich, dass das soviel ausmacht.

Ich finde das nicht erstaunlich. Die Anzahl der Aufrufe der naiven
Implementation von Fib wächst exponentiell mit dem Parameter (eine
Erhöhung um 1 verdoppelt die Anzahl der Aufrufe). Bei Daniels Variante
hingegegen wächst die Zahl der Aufrufe linear. Baue einen einfachen
Zähler ein und Du siehst das:

../rec
....
Fib(27.0): 317811.0
time: 1.96348786354065, called: 635621
Fib2(27.0): 317811.0
time: 0.00719499588012695, called: 27
....

../rec 3
....
Fib(30.0): 1346269.0
time: 8.4042980670929, called: 2692537
Fib2(30.0): 1346269.0
time: 0.00719404220581055, called: 30


>> Mit anderen Worten, ich sehe hier: Perl braucht auf meinem Rechner zwar
>> drei Sekunden, um Fib(30) auszurechnen, aber wenn ich 10 Sekunden
>> aufwende, um den Code zu verbessern, braucht es plötzlich fast nichts
>> mehr. In C ist die Änderung auch möglich, aber deutlich aufwändiger,
>> wenn man nicht auf die Threadsicherheit verzichten will. Danach brauchen
>> beide ungefähr gleich lang. Die vorgegebene Lösung dagegen ist messbar
>> (wenn auch nicht schlimm) langsamer als meine Perl-Lösung.
>
> Hm, in C müsste sich das durch Einführung eines struct
> für den Returnwert ähnlich leicht einführen lassen.

Ja. Aber wie andere schon angemerkt haben, änderst Du damit die Signatur
der Funktion. In Perl (und anderen Sprachen mit dynamischem Typsystem)
lassen sich solche Änderungen leichter machen.

Natürlich kannst Du auch in C sowas machen:

typedef struct TwoDoubles { double a, b };

TwoDoubles FibStruct(double n) {
TwoDoubles f, f1;

if (n < 2.0) {
f.a = f.b = 1;
return f;
}
f1 = FibFP(n - 1);
f.a = f1.a + f1.b;
f.b = f1.a;
return f;
}

double FibFP(double n) {
return FibStruct(n).a;
}

und damit die Signatur erhalten (um den kleinen Preis einer zusätzlichen
Wrapperfunktion).

(Wo kommen eigentlich die ganzen Großbuchstaben her? Das ist weder in C
noch in Perl üblich)

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Performance Vergleich von Perl und Ruby gesucht

On 2006-10-20 16:43, Ingo Menger wrote:
>
> Daniel Fischer schrieb:
>> Mit anderen Worten, ich sehe hier: Perl braucht auf meinem Rechner zwar
>> drei Sekunden, um Fib(30) auszurechnen, aber wenn ich 10 Sekunden
>> aufwende, um den Code zu verbessern, braucht es plötzlich fast nichts
>> mehr.
>
> Sorry, daß ich hier widerspreche.
> Der Sinn dieses Tests ist, heruaszufinden, wie stark rekursive
> Funktionen sich verhalten in Bezug auf Performance.

Das ist der Sinn des Tests, aber hat der Test praktische Relevanz?

[...]
> Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir
> dort gelingt, in 10 Sekunden eine einfache Modifikation zu finden, die
> die Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich
> nächstes Jahr einen Nobelpreis.

Nicht gerade O(n) aber deutlich besser als die naive Version:

{
my %ack_cache;

sub Ack2
{
no warnings 'recursion';
my ($x, $y) = @_;
$called++;
if (defined ($ack_cache{$x}{$y})) {
return $ack_cache{$x}{$y};
}

if ($x == 0) {
return $ack_cache{$x}{$y} = $y + 1;
}
if ($y == 0) {
return $ack_cache{$x}{$y} = Ack2($x - 1, 1);
}

my $y2 = Ack2($x, $y - 1);
my $ret = Ack2($x - 1, $y2);
return $ack_cache{$x}{$y} = $ret;
}
}

(unterscheidet sich vom Original nur durch das Cachen der Return-Werte -
im Prinzip genau das, was Memoize macht. In der Praxis schreibt man also
einfach "use Memoize; memoize('Ack')" - um das hinzutippen braucht man
sogar weniger als 10 Sekunden :-)):

yoyo:~/tmp 14:35 151% ./rec.pl 6
Ack(3,6): 509
time: 0.674147129058838, called: 172233
Ack2(3,6): 509
time: 0.0234529972076416, called: 1536
yoyo:~/tmp 14:35 152% ./rec.pl 7
Ack(3,7): 1021
time: 3.11296606063843, called: 693964
Ack2(3,7): 1021
time: 0.0378398895263672, called: 3074
../rec.pl 7 3.13s user 0.00s system 96% cpu 3.239 total
yoyo:~/tmp 14:36 153% ./rec.pl 8
Ack(3,8): 2045
time: 13.6519548892975, called: 2785999
Ack2(3,8): 2045
time: 0.0671930313110352, called: 6148

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Performance-Vergleich von Perl und Ruby gesucht

Christoph Neubauer wrote:
> Hallo Leute !
>
> Für ein neu aufzusetzendes (Teil)Projekt könnte Perl oder Ruby zum Einsatz
> kommen.

Du schreibst jetzt nicht, ob das ganze irgendwie in
Echtzeit ablaufen soll, d.h. ob jemand vor dem Rechner
sitzt und auf ein Ergebnis wartet oder ob die Sachen
z.B. über Nacht durchlaufen sollen.

Wenn es um Echtzeit oder Beinahe-Echtzeit geht, dann
ist die Frage vielleicht, ob Teile oder das ganze
Projekt nicht besser in C gemacht werden sollten
(sage ich mal obwohl ich eine C-Katastrophe bin).

Wenn es als Batch laufen soll, dann ist die Frage,
wie groß das Zeitfenster ist.

> Input: Ein paar Hundert Textdateien verschiedenster Größe.

Ein paar Hundert Dateien sind ja u.U. nix. Es kommt
halt darauf an, was genau mit den Dateien gemacht
werden soll.

Was heißt "verschiedenste Größe"?
Sind da Dateien im Gigabyte-Bereich dabei?
Kann man mal Test-Skripts machen, um überhaupt
eine Idee zu kriegen, wie lange es dauert?
Diese Tests sollten dann ohne jede Kosmetik die
teuersten Operationen durchzuführen.
Das kann man in Perl und Ruby sicher schnell
machen.

Wenn beide Sprachen ganz locker ins Zeitfenster
passen (z.B. nur ein paar Minuten brauchen, wenn
ihr 12 Stunden Zeit habt), dann würde ich die
Sprache nicht nach Ausführungsgeschwindigkeit
auswählen, sondern nach geschätzter Entwicklungszeit.
Die hängt wiederum von den Entwicklern ab.

MP

Re: Performance Vergleich von Perl und Ruby gesucht

Peter J. Holzer wrote:
> On 2006-10-20 16:43, Ingo Menger wrote:
> >
> > Daniel Fischer schrieb:
> >> Mit anderen Worten, ich sehe hier: Perl braucht auf meinem Rechner zwar
> >> drei Sekunden, um Fib(30) auszurechnen, aber wenn ich 10 Sekunden
> >> aufwende, um den Code zu verbessern, braucht es plötzlich fast nichts
> >> mehr.
> >
> > Sorry, daß ich hier widerspreche.
> > Der Sinn dieses Tests ist, heruaszufinden, wie stark rekursive
> > Funktionen sich verhalten in Bezug auf Performance.
>
> Das ist der Sinn des Tests, aber hat der Test praktische Relevanz?

Das steht zwar hier nicht zur Debatte, aber meiner Meinung nach schon.
Im Prinzip ist das stark rekursive Fib eine Möglichkeit, Aussagen
über die Performance eines Programmes zu gewinnen, das sich
hauptsächlich mit Funktionsaufrufen und Integer-Arithmetik
beschäftigt. Programmiersprachenimplementationen, in denen
Funktionsaufrufe teuer sind, fallen hier durch hohe Laufzeiten auf.
Wogegen ich mich gewandt habe war die Aussage: man kann den Perl-Code
in 10 Minuten verbessern *und in anderen Programmiersprachen (z.B. C)
geht das nicht*.
Das ist im Falle von fib erstens falsch und zweitens, selbst wenn es
wahr wäre, ist das nun ein ganz anderes Thema (Wartbarkeit).

Re: Performance Vergleich von Perl und Ruby gesucht

Peter J. Holzer wrote:
> On 2006-10-20 16:43, Ingo Menger wrote:
> >

> > Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir
> > dort gelingt, in 10 Sekunden eine einfache Modifikation zu finden, die
> > die Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich
> > nächstes Jahr einen Nobelpreis.
>
> Nicht gerade O(n) aber deutlich besser als die naive Version:
>
[code snipped]
> (unterscheidet sich vom Original nur durch das Cachen der Return-Werte -
> im Prinzip genau das, was Memoize macht. In der Praxis schreibt man also
> einfach "use Memoize; memoize('Ack')" - um das hinzutippen braucht man
> sogar weniger als 10 Sekunden :-)):

1:0 für Dich. Allerdings ist auch Memoization nichts, wo Perl ein
Monopol drauf hätte.

Re: Performance Vergleich von Perl und Ruby gesucht

Ingo Menger!

> Der Sinn dieses Tests ist, heruaszufinden, wie stark rekursive
> Funktionen sich verhalten in Bezug auf Performance.

Das kommt ja auch bei anderen Sprachen schon nicht mehr alleine auf den
Algorithmus an. Die C-Benchmarks beziehen sich auf den gcc. Der gcc kann
z.B. tail recursion optimieren. Allerdings nur, wenn man ihm das so ein
klein wenig vorkaut, sprich nicht in allen Fällen. Du kannst also C-Code
schreiben, der sich ggf. wenig von anderem rekursiven C-Code
unterscheidet, vom gcc aber deutlich besser optimiert wird. Wenn Du also
ein Benchmark explizit für C mit gcc machst, wirst Du diese Optimierung
auch machen. Sie sieht vielleicht nicht weniger trivial aus, aber man muss
trotzdem erstmal wissen, dass es geht. Warum darf ich jetzt aber die
Rekursion bei Perl nicht optimieren? Nur weil der Code komplizierter
aussieht? Wo ist dann die Grenze?

> Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir dort
> gelingt, in 10 Sekunden eine einfache Modifikation zu finden, die die
> Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich nächstes
> Jahr einen Nobelpreis.

Ja ist es, die einfache Modifikation hat hp ja schon geposted. Caching
funktioniert hier, weil die Ackermann-Funktion sich häufig mit den selben
Werten mehrfach aufruft und ein Cache das gleich am Anfang einer ggf.
sonst recht langen Rekursionskette abwürgen kann. Das ist allgemein
bekannt, da muss ich gar nicht nachdenken, ob ich Caching implementiere.

Wo ich das also weiß, ist die Frage doch eher: In welcher Sprache kriege
ich das am einfachsten hin? Das sagt mir deutlich mehr als welche Sprache
das unoptimierte Verfahren schneller schafft. Dass Scriptsprachen bei
sowas nicht glänzen, ist keine so neue Erkenntnis. Die anderen
unterscheiden sich zuwenig, um die Einfachheit der Implementierung
ignorieren zu können. Das Benchmark sagt hier also nichts aus.

> Und nein, es gibt meines Wissens keine Sprache, auch keine funktionale,
> die einen besseren, äquivalenten Algorithmus sucht und auch findet.

Wenn es so eine Sprache gäbe, dass wäre das Benchmark ja wieder
nützlich. Dann würde diese Sprache überall gewinnen und wäre
vermutlich auch die, in der man jedes gegebene Problem mit dem wenigsten
Aufwand formulieren könnte.

> Mit obigem Algorithmus dürfte selbst fib.pl 2000 kaum meßbar sein.
> Geschweige denn optimiertes C++ oder gar Fortran.

Es gibt auch eine Formel, mit der man jeden Wert direkt berechnen kann...


Gruß
Daniel

Re: Performance Vergleich von Perl und Ruby gesucht

On 2006-10-23 10:53, Ingo Menger wrote:
> Peter J. Holzer wrote:
>> On 2006-10-20 16:43, Ingo Menger wrote:
>> > Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir
>> > dort gelingt, in 10 Sekunden eine einfache Modifikation zu finden, die
>> > die Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich
>> > nächstes Jahr einen Nobelpreis.
>>
>> Nicht gerade O(n) aber deutlich besser als die naive Version:
>>
> [code snipped]
>> (unterscheidet sich vom Original nur durch das Cachen der Return-Werte -
>> im Prinzip genau das, was Memoize macht. In der Praxis schreibt man also
>> einfach "use Memoize; memoize('Ack')" - um das hinzutippen braucht man
>> sogar weniger als 10 Sekunden :-)):
>
> 1:0 für Dich. Allerdings ist auch Memoization nichts, wo Perl ein
> Monopol drauf hätte.

Habe ich das behauptet? Dann muss ich mich unglücklich ausgedrückt
haben. Es gibt nichts, worauf eine Sprache ein Monopol drauf hätte -
letztlich kann man in jeder turing-vollständigen Sprache alles machen.

Es gibt aber Sprachen, die gewisse Dinge leichter machen, teils durch
Sprachkonstrukte, teils durch Standard-Libraries, teils einfach durch
Memes in der Community.

Diese Dinge werden in diesen Sprachen dann auch verwendet. Der
durchschnittliche Perl-Programmierer kennt Hashes (sie sind schließlich
einer der grundlegenden Datentypen von Perl) und hat das "Orcish
Maneuver" wahrscheinlich schon mal gesehen. Mal schnell ein Hash als
Cache zu verwenden, ist vielleicht nicht in seinem Standard-Repertoire
enthalten, aber der Sprung dorthin ist nicht weit. Der durchschnittliche
C-Programmierer hat zwar auch schon mal von Hashes gehört, hat aber
keine Implementation in seiner Standard-Library. Um sie zu verwenden,
muss er erstmal eine Library finden oder selbst implementieren, er muss
sich Gedanken über Speicherverwaltung machen, ob das ganze auch portabel
ist, etc. Um das zu tun, muss es erst mal wehtun.

Somit hat die leichte Verfügbarkeit von Features sehr wohl einen Einfluß
auf die Performance von Programmen, weil die performantere Lösung für
den Programmierer auch die einfachere ist und er daher eher diese wählt,
als wenn er Performance und Entwicklungszeit gegeneinander abwägen muss.
Das schlägt sich in Benchmarks üblicherweise nicht nieder weil
Benchmarks meistens sehr einfach sind und ein Problem auf eine bestimmte
(meistens nicht optimale) Art lösen. Interessant wäre eine Vergleich von
Programmiersprachen, bei denen mehrere nicht-triviale Aufgaben von den
Programmierern auf beliebige Art gelöst werden dürfen.

[Das ist übrigens kein "Perl ist die superste Programmiersprache
überhaupt"-Argument. Mir fallen auch Beispiele ein, wo C Perl
locker schlägt, und für jedes beliebige Paar von Programmiersprachen
gibt es sicherlich ebenfalls Beispiele in der einen oder anderen
Richtung. Ich würde aber Perl eher im oberen Feld der
Programmiersprachen sehen, was Ausdruckskraft betrifft (Lutz Donnerhacke
hat mal geschrieben "Perl code is an executable brain-dump" und das
trifft auf mich voll zu - ich kann meistens meine Lösung "einfach so"
hinschreiben und muss mir selten Gedanken über Implementierungsdetails
machen)]

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Performance Vergleich von Perl und Ruby gesucht

Daniel Fischer wrote:
> Ingo Menger!
>
> > Der Sinn dieses Tests ist, heruaszufinden, wie stark rekursive
> > Funktionen sich verhalten in Bezug auf Performance.
>
> Das kommt ja auch bei anderen Sprachen schon nicht mehr alleine auf den
> Algorithmus an. Die C-Benchmarks beziehen sich auf den gcc. Der gcc kann
> z.B. tail recursion optimieren.

Das mag sein, spielt aber hier keine Rolle, da fib nicht tailrekursiv
ist.
Daß alle tail-calls (nicht nur rekursive) optimiert gehören, ist doch
ohnehin klar.

> Warum darf ich jetzt aber die
> Rekursion bei Perl nicht optimieren?

Lies die FAQ dort (http://shootout.alioth.debian.org/gp4/faq.php):

"We are only trying to show the performance of various programming
language implementations, on a limited number of flawed benchmarks.

We are not trying to

compare different algorithms
showcase the capabilities of different languages
compare programming language productivity
contest programmer effort and sneaky tricks
etc etc"

> Nur weil der Code komplizierter
> aussieht? Wo ist dann die Grenze?
>
> > Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir do=
rt
> > gelingt, in 10 Sekunden eine einfache Modifikation zu finden, die die
> > Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich nächstes
> > Jahr einen Nobelpreis.
>
> Ja ist es, die einfache Modifikation hat hp ja schon geposted. Caching
> funktioniert hier, weil die Ackermann-Funktion sich häufig mit den selb=
en
> Werten mehrfach aufruft und ein Cache das gleich am Anfang einer ggf.
> sonst recht langen Rekursionskette abwürgen kann. Das ist allgemein
> bekannt, da muss ich gar nicht nachdenken, ob ich Caching implementiere.

Siehe oben. Es soll eben nicht verglichen werden, welche Möglichkeiten
die Sprache bietet und welche effizienzsteigernden Tricks die
Programmierer derselben kennen.

Nochmal zurück zu fib: Wenn alle Teilnehmer sich die Freiheit nehmen,
den loop statt der Rekursion zu implementieren, würde man keinerlei
Informationen mehr über die Performance dieser
Programmiersprachenimplementierung bei Vorliegen vieler (rekursiver,
aber das ist außer für Fortran eigentlich egal) Funktionsaufrufe
erhalten. Was ist schlimm daran, wenn man erfährt, daß perl oder eben
auch ruby nicht so besonders performant sind für die Art von
Problemen, wo der function-call-overhead besonders groß ist?

Daß die ausgewählten Benchmarks "flawed" sind, ist ja schon
zugegeben.

> Wo ich das also weiß, ist die Frage doch eher: In welcher Sprache kriege
> ich das am einfachsten hin?

siehe oben: We are not trying to compare programming language
productivity.
Dafür ist das einfach die falsche Seite.

Re: Performance Vergleich von Perl und Ruby gesucht

Peter J. Holzer wrote:
> On 2006-10-23 10:53, Ingo Menger wrote:
> > Peter J. Holzer wrote:
> >> On 2006-10-20 16:43, Ingo Menger wrote:
> >> > Ich weiß nicht ob Ackermann in dem Test auch drin ist. Wenn es Dir
> >> > dort gelingt, in 10 Sekunden eine einfache Modifikation zu finden, d=
ie
> >> > die Komplexität auf O(n) senkt, dann kriegst Du wahrscheinlich
> >> > nächstes Jahr einen Nobelpreis.
> >>
> >> Nicht gerade O(n) aber deutlich besser als die naive Version:
> >>
> > [code snipped]
> >> (unterscheidet sich vom Original nur durch das Cachen der Return-Werte=
-
> >> im Prinzip genau das, was Memoize macht. In der Praxis schreibt man al=
so
> >> einfach "use Memoize; memoize('Ack')" - um das hinzutippen braucht man
> >> sogar weniger als 10 Sekunden :-)):
> >
> > 1:0 für Dich. Allerdings ist auch Memoization nichts, wo Perl ein
> > Monopol drauf hätte.
>
> Habe ich das behauptet?

Nein.

> Das schlägt sich in Benchmarks üblicherweise nicht nieder weil
> Benchmarks meistens sehr einfach sind und ein Problem auf eine bestimmte
> (meistens nicht optimale) Art lösen.

Ja eben, um *bestimmte* Informationen zu erhalten. Hier z.B., wie sich
hoher function call/return overhead wohl auswirkt.
Wir sind uns doch einig, daß solche Benchmarks generell zweifelhafte
Ergebnisse liefern. Aber, wenn man Algorithmen/zu verwendende Techniken
nicht vorgibt, hätte man noch nicht mal zweifelhafte Ergebnisse.

> Interessant wäre eine Vergleich von
> Programmiersprachen, bei denen mehrere nicht-triviale Aufgaben von den
> Programmierern auf beliebige Art gelöst werden dürfen.

Auch das gibt es, z.B.: http://icfpcontest.org/index.shtml

Hier geht es jedes Jahr um ein Spiel, das die verschiedenen
eingereichten Programme gegeneinander spielen müssen. Hier kann man
zeigen, daß man in seiner Liebelingsprogrammiersprache eine
korrekte/bessere Lösung in endlicher Zeit (meist 1 WE) hinkriegt.