cgi mit c und html

Scheppertreiber

Interessant.

Die Laufzeiten sind in der Praxis natürlich auch von der Komplexität der
Anwendung abhängig. Wenn Du da Zugriffsrechte laden und größere Datenbanken
abfragst sieht's halt anders aus.

Ich habe zB mal eine Woche in PHP investiert und habe es dann doch wieder
in C gemacht. Die Vorteile, die ich durch die nun wirklich legendäre Flexibilität
und frei definierbare Strukturen habe kann PHP einfach nicht. Dafür ist es ja
auch nicht gemacht.

Würde ich solche Benchmarks machen, müßte ich das in PHP nachbauen, halt eine
Sauarbeit. Interessant wäre es schon.

Gruß Joe.

Könntest du den Benchmark mal mit "Numbercrunching" wiederholen.
Also z.b. rekursives Berechen von fibo(11) oder so ?

tntnet

WurzelGnom schrieb:

Könntest du den Benchmark mal mit "Numbercrunching" wiederholen.
Also z.b. rekursives Berechen von fibo(11) oder so ?

Sag mir mal, wie das in PHP geht. Dann mache ich den Benchmark.

tntnet

Um mir mal selbst zu antworten: http://www.scriptol.org/fibonacci-any-programming-language.html#php. utfg (use the fine google) . Benchmark kommt heute Abend.

tntnet

ok - wie versprochen hier die Ergebnisse. Aber zunächst eine kleine Korrektur. Ich habe in dem C-Programm das puts durch printf ersetzt und da kommt das auf ca. 300 #/sec. Ich begreife nicht, wie printf schneller sein kann, als puts. Aber man muss ja nicht alles verstehen.

Also jetzt zum Fibonacci. Eigentlich ist es ja ein ziemlich sinnfreier Test, da zumindest ich ein Numbercruncher-Programm nicht als Webapplikation programmieren würde. Aber dennoch zeigt es, was wir sehen wollen: C ist viel besser als PHP. Zumindest als Numbercruncher. Hier die Ergebnisse für fibo(11), fibo(20) und fibo(30):

CGI/Perl:   28 /   19 / 0,5
CGI/C:     303 /  286 / 87
PHP:      1323 /   58 / 0,36
Tntnet:   7452 / 5068 / 109

Wir sehen hier tatsächlich, dass PHP in der Ausführungsgeschwindigkeit offensichtlich noch hinter Perl liegt. Die compilierten Varianten sind natürlich weit im Vorteil. Für mich ist es wieder mal erfreulich (und nicht anders zu erwarten), dass Tntnet allen weit überlegen ist, da es sowohl persistent als auch compiliert ist. Bei längeren Berechnungszeiten wird natürlich die Startzeit des Programms vernachlässigbar. Interessanter wäre sicher eine richtige Webanwendung mit Datenbankanbindung und so.

tntnet schrieb:

Ich begreife nicht, wie printf schneller sein kann, als puts.

puts macht jedesmal einen system-call um den string sofort auszugeben. printf puffert die daten und braucht daher weniger syscalls. mach printf ohne pufferung und es wird langsamer sein als puts

tntnet

fricky schrieb:

tntnet schrieb:

Ich begreife nicht, wie printf schneller sein kann, als puts.

puts macht jedesmal einen system-call um den string sofort auszugeben. printf puffert die daten und braucht daher weniger syscalls. mach printf ohne pufferung und es wird langsamer sein als puts

Eine schöne Erklärung, erklärt aber leider nicht diesen Fall. Wenn Du Dir meinen C-Code anschaust, jage ich die komplette HTML-Seite mit einem einzigen puts auf die Standardausgabe. Da müsste ja puts von sich aus mehrere Systemaufrufe pro Aufruf machen.

Scheppertreiber

puts(), printf() etc machen buffered I/O, write schreibt's direkt.
Steht in jedem Manual.

tntnet

Scheppertreiber schrieb:

puts(), printf() etc machen buffered I/O, write schreibt's direkt.
Steht in jedem Manual.

Das ist schon klar. Das Problem ist ein anderes. Warum ist:

printf("<html>blah blah blah</html>");

schneller als:

puts("<html>blah blah blah</html>");

Wie Du sagst machen beide buffered I/O. Nach meinem Verständnis müsste puts mindestens so schnell sein, als printf. Printf parst ja sogar zur Laufzeit den String. Da müsste es ja eher langsamer sein. Ich würde ja verstehen, wenn die beiden genauso schnell wären. Da könnte man noch argumentieren, daß das Parsen im rahmen der Messungenauigkeit im Rauschen untergeht.

Aber nochmal: printf ist (bei meiner Umgebung) schneller als puts (Steht in jeder Nachricht von mir)

Scheppertreiber

Hi TNT,

erkläre erst mal wie Du das gemessen hast. Eigentlich sollte puts schneller sein.
Vielleicht ist aber printf optimiert und erkennt wenn keine Formatierung notwendig
ist. kA.