PHP - Breitensuche
-
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.
Können wir die Compilezeit mitrechnen, dann würde C++ verlieren
-
Zeus schrieb:
Ist es auch Faktor ~7.
LOL, hab ich mich doch tatsächlich dabei verrechnet. Wie peinlich
-
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.)
-
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.
-
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).
-
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
-
314159265358979 schrieb:
fcktards
Und du erwartest dann ernsthaft, dass man mit dir diskutieren will?
-
Die Diskussion ist für mich gelaufen, ihr habt euch disqualifiziert.
-
314159265358979 schrieb:
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.
lol, PIs gesicht möcht ich sehen wenn er in 5 Jahren zum ersten Mal in einem Hörsal sitzt und der Dozent versucht ihm das auszutrichtern
> Wenn der Algorithmus zu langsam ist einfach mal eine andere Sprache benutzen, und dann am besten das assembler optimieren
-
weißt du wie oft ich schon in js/php implementierten algorithmen gelesen hab, dass sie von c portiert wurden?
es gibt ein level an abstraktion, ab dem man einfach langsamer wird, weil man sich ständig für überdimensionierte algorithmen und datenstrukturen entscheidet. automatische typumwandlungen und immutable strings erledigen dann meist den rest.
jeder der hier behauptet, dass es nur auf den algo ankommt hat einfach keinen plan vom business... denn meist haben besser bezahlte programmierer auch mehr ahnung von algorithmen und der hardware und php ist neben js eine der schlecht bezahltesten sprachen der welt!
-
triptop schrieb:
denn meist haben besser bezahlte programmierer auch mehr ahnung von algorithmen und der hardware und php ist neben js eine der schlecht bezahltesten sprachen der welt!
Die bestbezahlten Programmierer sind laut c't für COBOL, ABAP und ähnliche Grausamkeiten unterwegs (ich hab die Ausgabe nicht mehr vorliegen, vielleicht mag das nochmal jemand verifizieren), das sind mit Sicherheit keine Algorithmen- oder Hardware-Experten. Am Gehalt würde ich es also nicht festmachen.
-
triptop schrieb:
jeder der hier behauptet, dass es nur auf den algo ankommt hat einfach keinen plan vom business... denn meist haben besser bezahlte programmierer auch mehr ahnung von algorithmen und der hardware und php ist neben js eine der schlecht bezahltesten sprachen der welt!
Ahja, es kommt nicht nur auf den Algorithmus an, denn besser bezahlte Programmierer haben mehr Ahnung von Algorithmen. LOL Alter! Wenn ich sowas lese, roflt es bei mir das Frühstück wieder hoch.
Die untere Schranke wurde mit O(n) schon genannt, die algorithmische Analyse ist damit abgeschlossen, die optimale Suche ist trivial. Dass PHP langsamer als eine C-Implementierung ist, hat hier niemand behauptet. Und generell kommt es natürlich nicht nur auf den Algorithmus an. Aussage hier war: in den meisten Fällen spielen bei Webanwendungen andere Kriterien eine Rolle.
Hast du das jetzt geschnallt? Wenn ja, erklär es noch PI.
-
Äh PHP "schneller" hat niemand behauptet!
LOL Alter! Wenn ich sehe, was ich schreibe, roflt es mir die Zehnägel quer.
-
mit typen, wo sich die zehennägel rofln und loln will ich nichts zu tun haben. ich schätze ernsthaftigkeit mehr als einen clown.
-
314159265358979 schrieb:
Aber extra für dich, ein kleines Benchmark, damit du einsiehst, was für fatalen Mist du von dir gibst.
Eine Astreine Themenverfehlung.
Weil du nicht kapierst worum es geht.Du hängst dich an Details auf die im Big-Picture(tm) irrelevant sind.
Schreib den Code mal so, wie er in der freien Wildbahn vorkommen würde. Nämlich mit caching und 1000 concurrent requests. Dann wirst du recht schnell feststellen, dass PHP um Dimensionen schneller ist oder du um Dimensionen mehr Zeit in das C++ Programm stecken musst.
Zum Mitschreiben: 1 Request ist vollkommen irrelevant. Die Performance einer Anwendung hängt davon ab wieviel concurrent requests sie bearbeiten kann.
-
du solltest langsam die fresse halten, bevor das noch jemand glaubt
-
Shade of Mine hat vollkommen recht. Es ist offensichtlich, dass du im Bereich Webentwicklung noch nicht wirklich an größeren Projekten mitgewirkt hast. Wie so oft ist nicht alles schwarz oder weiß - Entscheidungsfindungen hängen von mehreren Parametern ab und sind doch etwas komplexer als "Sprache A ist schneller als Sprache B".
Die einzigen, die hier im Unrecht sind, sind leider du und PI.
Damit wäre meine Frage, ob du es jetzt endlich geschnallt hättest, aber beantwortet. Welch überraschendes Resultat.
-
Hat mal jemand einen Link für Web-Dummies wie mich, der mal darlegt, warum PHP so gigantisch überlegen sein soll? Insbesondere das hier:
Shade schrieb:
Du hast nur 1 PHP Instanz aber N C++ Instanzen. DAS ist der Punkt. C++ ist nicht trivial Skalierbar auf den Server zu bekommen. CGI, FastCGI, etc. ist alles Schrott. Du brauchst einen App Server.
Wieso ist das alles Schrott, und wie funktioniert PHP dagegen?
Ich war immer der Ansicht, dass PHP nur deshalb so beliebt ist, weil es jeder Billighoster dabei hat. Stimmt ja offenbar nicht.
-
dann sollten sich wohl die zusammenschließen, die gleicher meinung sind. mit euch will ich eh nicht arbeiten, da liegen die meinungen einfach viel zu weit auseinander.
-
Bashar schrieb:
Shade schrieb:
Du hast nur 1 PHP Instanz aber N C++ Instanzen. DAS ist der Punkt. C++ ist nicht trivial Skalierbar auf den Server zu bekommen. CGI, FastCGI, etc. ist alles Schrott. Du brauchst einen App Server.
Wieso ist das alles Schrott, und wie funktioniert PHP dagegen?
Ich war immer der Ansicht, dass PHP nur deshalb so beliebt ist, weil es jeder Billighoster dabei hat. Stimmt ja offenbar nicht.
Das ist natürlich der Fall - also PHP ist so beliebt weil es so easy zu installieren ist.
PHP läuft als apache Module direkt im Kontext des Servers. Was enorme Performance Vorteile gegenüber zB CGI bringt. CGI ist ja sehr dumm und startet jedesmal einen neuen Prozess. FastCGI ist da schon etwas besser, aber immer noch nicht auf dem Niveau eines Apache Modules.
Das ganze kombiniert mit einem OpCode Cache reduziert die Startzeiten von PHP Code auf quasi 0. Das ist halt ziemlich genial - da man idR nur sehr wenig Zeit mit der Ausführung von Code verbringt. Das ist der große Vorteil von Sprachen wie PHP und Ruby gegenüber zB C++ Code.
Und dennoch ist alles gesandboxt. dh ein Request kann keinen anderen Request abschießen. Was gerade in shared Umgebungen Gold Wert ist.
PHP ist natürlich dennoch ziemlicher Schrott.