|
Anzeige
|
Wer ist schneller PHP vs. Perl
Gast
#710383
Hallo, ich möchte gern ein Bild berechnen und ausgeben bzw. als eine Datei abspeichern. Für dieses Bild sind so einge Berechnungen geplant, vielleicht mit Transformationsmatrizen, die wahrscheinlich nicht wenig an Rechenzeit benötigen. Da ich bei meinem webspace nur perl cgi's verwenden kann, frage ich mich, ob perl mir vor php einen Geschwindigkeitsvorteil bringt. Beides sind ja nur Interpreter. Weiss jemand Bescheid?
Gast
#710401
Perl ist kein (reiner) Interpreter. Der Quellcode wird beim starten übersetzt und erst danach ausgeführt. Dadurch erreicht Perl eine sehr hohe Geschwindigkeit. Natürlich nicht so schnell wie C, dafür aber mit den Vorteilen einer Scriptsprache. Der Interpreter bleibt im Hintergrund und hilft wenn das übersetzte Script nicht mehr weiterkommt (z.b. eval(), Typenumwandlung,...). Der Zeitverlust für das Übersetzten beim starten kann durch einen presistenten Perlinterpreter im Webserver auf annähernd 0 reduziert werden (z.b. mod_perl, speedy,...) Bei kurzen Scripten die lange rechnen ist Perl gegenüber PHP sicherlich im vorteil. Für simplen Bild I/O ist GD bzw GD2 ganz brauchbar.
Gast
#710411
Perl dürfte wie erläutert schneller sein. Allerdings dürfte der Unterschied so minim sein, dass der Benutzer nichts merkt - weil eben Latenzen und die Übertragungsdauer übers Netz sowieso viel länger dauern. Eine andere Meinung hat natürlich dein Provider: Bei einigen wenigen Zugriffen stört der sich nicht daran, wenn hingegen permanent Bilder erstellt werden müssen, wird der dir bald auf die Decke steigen. Tim: > Perl ist kein (reiner) Interpreter. Der Quellcode wird beim starten > übersetzt und erst danach ausgeführt. Das ist bei PHP genauso, deshalb ist Perl auch nicht viel schneller: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=perl Ruby: > Für dieses Bild sind so einge Berechnungen geplant, vielleicht mit > Transformationsmatrizen, die wahrscheinlich nicht wenig an Rechenzeit > benötigen. Bei solchen Berechnungen können Skriptsprachen schon mal um einen Faktor >> 100 langsamer sein als kompilierter Code. Wenn die Rechenzeit wirklich eine Rolle spielt wirst du an reinem PHP/Perl-Code vermutlich keine Freude haben.
Gast
#710565
Es gibt sonst auch noch die Methode die Berechnungen dem Client anzuhaengen. Das waere mit Javascript machbar. Oder man haengt ein compiliertes Binary an den Server Tim wrote: > Perl ist kein (reiner) Interpreter. Der Quellcode wird beim starten > übersetzt und erst danach ausgeführt. Das ist eine übliche Interpretationstechnik, die praktisch von allen einigermaßen komplexen interpretierten Sprachen angewandt wird. Sprachen wie Python oder Perl speichern das Compilat zur späteren wiederbenutzung ab, JavaScript üblicherweise nicht. Ein prinzipieller Unterschied ist das jedoch nicht.
Gast
#710862
Danke für Eure Antworten! So wie das klingt, gibt es nicht viel Unterschied, obwohl doch ein Perlkompilat vorliegen soll. Eigentlich habe ich mir überlegt, Rotationen kleiner 3D-geometrischen Formen in APNG, welches ja vom nächsten Firefox unterstüzt wird, zu visualisieren. Wenn ich aber nun bedenke, dass auch noch einn primitives Raytracing hinzukommt, kann ich ja mit Scripten gleich einpacken. Im Prinzip wie hier http://dearcomputer.nl/bugs/, bloß dreidimensional. Per JS Auslagern ist auch keine Geschwindigkeitsalternative und ActionScript ist mit Version 3 auch nicht wirklich schneller geworden. Ich werde mich wohl mal näher mit der "write-only" Sprache anfreunden und die Idee abspecken. :)
Gast
#710887
Rechenzeitkritische Routinen lassen sich bei Perl, PHP und anderen Skriptsprachen in Erweiterungsmodule auslagern. Diese werden in C/C++ implementiert und dynamisch an den Interpreter gelinkt. PHP: http://devzone.zend.com/node/view/id/1021 Perl: Advanced Perl Programming (Panther Book) von O'Reilly
Gast
#710948
Hallo, also wenn CGI möglich ist, würde ich ein compilertes Programm direkt dazu verwenden. Oder wie schon erwähnt ein Programm aus PHP/Perl ausführen lassen, so der Provider denn unter PHP/Perl exec() erlaubt ;-) Und selbst compilierte Programme auch ausgeführt werden ! Eine Alternative wäre ebenfalls JAVA-Enterprise wo dann via JNI ein natives compiliertes Programm ausgeführt wird. Wäre mächtiger als exec() aber auch wesentlich mehr Aufwand insgesamt. OK dann muß ich "leider" noch .NET erwähnen, welches ebenfalls nativ übersetzt sein kann, wie JAVA eigentlich auch :-P Wenn der Provider allerdings ausschließlich Skriptsprachen zuläßt wird's wohl nicht so prikelnd ... Antwort schreiben |
Anzeige
|
