c++.de :: PHP

pyhax Mitglied 21:23:00 25.04.2012 Titel:

Berechne es doch mit Template Magie zur Compile Zeit, dann bist du schnell

314159265358979 Mitglied 21:32:08 25.04.2012 Titel:

@Zeus: Immerhin Faktor 3. Gar nicht mal so schlecht für eine Scriptsprache, hätte mit mehr gerechnet.

pyhax schrieb:

Berechne es doch mit Template Magie zur Compile Zeit, dann bist du schnell

Das wäre doch geschummelt. :o)

Zeus Mitglied 21:46:10 25.04.2012 Titel:

314159265358979 schrieb:

@Zeus: Immerhin Faktor 3. Gar nicht mal so schlecht für eine Scriptsprache, hätte mit mehr gerechnet.

Ist es auch Faktor ~7.

314159265358979 schrieb:

pyhax schrieb:

Berechne es doch mit Template Magie zur Compile Zeit, dann bist du schnell

Das wäre doch geschummelt. :o)

Können wir die Compilezeit mitrechnen, dann würde C++ verlieren

314159265358979 Mitglied 21:57:55 25.04.2012 Titel:

Zeus schrieb:

Ist es auch Faktor ~7.

LOL, hab ich mich doch tatsächlich dabei verrechnet. Wie peinlich :eek:

zwutz Mitglied 00:45:08 26.04.2012 Titel:

314159265358979 schrieb:

Aber extra für dich, ein kleines Benchmark, damit du einsiehst, was für fatalen Mist du von dir gibst. Gegeben seien die beiden folgenden Programme:

spielt das eine Rolle? Ernsthaft? Ergebnis wird gecached und der nächste hats in ner 100stel Sekunde, irrelevant also. Sowas wird im Webbereich niemals ständig neu berechnet. Wär ja unsinnig, wenn die Ergebnismenge endlich ist

PHP _ist_ langsamer, da sind wir uns einig. Eine Skriptsprache kann nunmal nicht gegen eine kompilierte Sprache bestehen. Wer sowas vergleicht hat aber mMn nicht wirklich die Stärken von Skriptsprachen verstanden. In der Praxis (also das Ding, was später auch Relevanz hat) ist die Laufzeit der PHP-Skripte irrelevant. Was wichtig ist, sind Filesystem- und Datenbank-Zugriffe. memcached oder ne Datenbank installieren und deine fibonacci-Seuche ist Geschichte. Was länger dauert, wird über nen jobworker oder cron im Hintergrund ausgeführt. Du bist hier nicht im Desktop-Bereich, wo man nach dem Mausklick ein Ergebnis haben will. Allein der Ping zum Webserver ist idR weit höher als die Skriptausführungszeit.

Wir setzen PHP als Skriptsprache ein und wenn wir mal Probleme wegen der Geschwindigkeit der Abfrage haben, dann ist nicht PHP der Grund (ok, außer wenn wir wegen eines Skriptfehlers mal wieder 10^9 verschiedene Varianten berechnen; da macht aber auch der Server schlapp)

Klar hat PHP Grenzen, aber die muss man erstmal erreichen. Und selbst dann gibt es Auswege (hiphop z.B.)

Unregistrierter

Im Übrigen berechnen nur Idioten den Fibonacci rekursiv, weil der, im Gegensatz zur iterativen Variante, exponentielle Laufzeit hat.

LOL Alter! Wenn ich was von diesem PI lese, roflt es mir regelrecht eine Glatze. Im wahrsten Sinne lolt es mich gerade quer durchs Treppenhaus, wenn ich seine dummen Kommentare über Skriptsprachen lese.

Unregistrierter

Achja, zum eigentlichen Problem:
Die Breitensuche dieser Größenordnung ist auch für PHP kein Problem. Nimm eine Adjazenzliste, um die Daten sinnvoll zu kodieren. Sei der Graph mit G = (V,E) gegeben, wobei V die Knotenmenge, E die Kantenmenge, so benötigt die Breitensuche O(|V| + |E|) = O(n).

314159265358979 Mitglied 08:06:46 26.04.2012 Titel:

Ihr seid halt einfach nur zu blöd, die Message in meinem Text zu verstehen. Ob der Algorithmus schlecht ist, spielt überhaupt keine Rolle. Ob man das mit Caching optimieren kann, ist ebenso scheißegal.

Der TE meinte, wenn der Algorithmus in PHP zu langsam ist, nimmt er einen anderen. Vielleicht eher die richtige Programmiersprache für rechenintensives Zeug aussuchen, anstatt zu behaupten, der Algorithmus wäre ungeeignet. DAS ist die Message.

Learn to read. Learn to understand.
fcktards

zwutz Mitglied 09:15:13 26.04.2012 Titel:

314159265358979 schrieb:

fcktards

Und du erwartest dann ernsthaft, dass man mit dir diskutieren will?

314159265358979 Mitglied 09:16:36 26.04.2012 Titel:

Die Diskussion ist für mich gelaufen, ihr habt euch disqualifiziert.