Hi Leute,
Ich stelle mir nun die Frage wie effizient eine kompiliertes C++ Programm was mittels fastcgi aufgerufen wird gegen über PHP ist.
Beides würde ich als fastcgi laufen lassen.
Selber vergleichen kann ich schlecht da ich noch keine Ansatzweise vergleichs Software für C++ habe.
Und nur ein cout oder echo zähl ich jetzt mal nicht dazu ;)
Also wieviel mal schneller ist C++ gegenüber PHP wenn beides oop aufgebaut ist.
Bzw lohnt sich der Aufwand von PHP nach C++ umzusteigen?
Original von Dracosan
Also wieviel mal schneller ist C++ gegenüber PHP wenn beides oop aufgebaut ist.
Hängt von deiner Anwendung ab. Schneller dürfte es allerdings fast immer sein (insofern es vernünftig geschrieben ist).
Original von Dracosan
Bzw lohnt sich der Aufwand von PHP nach C++ umzusteigen?
Nicht bei 50 Spielern online.......
Wollte auch mal beginnen Komponenten die in PHP waren in C++ zu schreiben. Einfach zum üben, habs dann aber leider aufgegeben. Schneller ist es aber sicher J. In Browsergames werden oft Kampfscripte oder ähnliches in C++ geschrieben, da es eben schneller geht und dadurch viel Server Leistung eingespart wird.
Musst halt drauf achten das es auch ordentlich geproggt is
Hier würde mich echt mal interessieren, wie man das sinnvoll anstellt? Ich habe mich noch nie wirklich mit dem Thema beschäftigt, daher kann ich mir momentan nichtmal vorstellen, wie ich sinnvoll z.B. die Session von php nach c++ und zurück weitergeben soll, ohne einen gigantischen manuellen Aufwand zu betreiben. Kann das jemand mal in kompakter Art zusammenfassen, wie man das prinzipiell aufbaut?
Eine Mischkombination würde ich nicht empfehlen. Wenn dann höchstens einen Daemon in C++ schreiben. Nichtsdestotrotz ist der Arbeitsaufwand exorbitant höher als mit der PHP-Lösung.
Wenn es nur um Performance geht, dann seid ihr hier sowieso auf den völlig falschen Dampfer. Ein Großteil eurer CPU-Zeit geht an die Datenbank sowie an den Overhead von PHP verloren. Bei der eigentlichen Ausführung des PHP-Codes kommen nur Peanuts zusammen.
Wenn ihr also von PHP weg wollt, dann ist es klug sich einen Application-Server zuzulegen. Sowas findet sich z.B. bei Java oder .Net. Mit Java oder C# entwickelt es sich außerdem drastisch zügiger als mit C++.
Wer will schon von PHP weg ;) Die Datenbank ist bei uns nicht das Problem, die läuft jeweils auf eigenen Servern / Clustern. Aber wenn ich pro - sagen wir - 50.000 Spieler einen Webserver sparen kann, wär das ja schon fein. Deinen Ausführungen nach aber lohnt es sich im Bezug auf Kosten / Nutzen nicht, jedenfalls nicht in dem für uns relevanten Kontext.
Zum Thema hab ich hier einen Blogeintrag, der ist ja ganz schön vernichtend für PHP ausgefallen. In Zahlen braucht PHP fas 200 mal länger für das selbe Problem als C++, Java ist dann nochmal knapp doppelt so schnell als C++. Nur "spezialoptimiert" ist dann doch C++ wieder schneller.
PHP 5.2.3-1ubuntu6.3 - 593 ms
C++ 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Compiled with optimisation -O3 - 3 ms
Steinigt mich jetzt aber nicht, ich habe das Vorwort des Bloggers schon gelesen und ich weis, dass ein Schwanzvergleich nichts über Variable c,d,e und f sagt...
Ziemlich daemliches Blogposting, wenn man vor allem beruecksichtigt, dass man das selbe Problem mit einem besseren Algorithmus je nach Sprache viel performanter loesen kann.. Siehe Comments. Es macht keinen Sinn einer Sprache einen Stil aufzuzwingen, wenn es anders besser geht. Daher ist das was _er_ tut ein Aepfel<>Birnen Vergleich und eben nicht das was die Kommentarposter tun.
Man muss die jeweils optimale (und dennoch wartbare) Variante jeder Sprache beruecksichtigen und nicht versuchen denselben Algorithmus ueberall 1:1 zu implementieren.
Original von Klaus
Wenn es nur um Performance geht, dann seid ihr hier sowieso auf den völlig falschen Dampfer. Ein Großteil eurer CPU-Zeit geht an die Datenbank sowie an den Overhead von PHP verloren. Bei der eigentlichen Ausführung des PHP-Codes kommen nur Peanuts zusammen.
Dies Problem hab ich auch festgestellt. Nur wie will man dies umgehen. Der Zugriff zur Datenbank ist schon elementar. Und Caching bei zeitkritischen Anwendungen ist ein Problem
Du hast zwei möglichkeiten:
- Eigener Webserver in z.B. C#, der alle Objekte selbst zentral für alle Sessions / Requests cached und die Datenbank mit INSERT DELAYED (oder ähnlichem) nur als Backup verwendet.
- Die Datenbank als Rechenzeitschlucker akzeptieren.
Da die Hardware immer schneller bzw. günstiger wird, ist das zweite durchaus akzeptabel. Man muss bedenken, Browsergames liefen auch schon auf Hardware von 2001. Wir haben jetzt 2009, und für nen 100-Euro-Server bekommt man heute statt 512 MB RAM mal eben 4 Gig und nen 4-Kern-Prozessor statt nem damaligen 2 GHz-Prozessor.
Und wie skalierst du bei Variante 1 weiter nach oben? Ist recht komplex, das distributed ueber mehrere Kisten zu machen. Zumindest ab dem Moment ab dem der erste Service, der fuer sich stehen kann, ausgelastet ist.
Naja du müsstest dann deinen Webserver in 2,3... aufteilen und die dann miteinander kommunizieren lassen. Ich denke wer nen Webserver hinbekommt, der sollte dann die interne Kommunikation auch hinbekommen (ist auch garnicht sooo schwer, z.B. stellst du von deinem Demon aus verschiedene Service-Endpoints zur Verfügung, ob dann der User (direkt oder indirekt) oder ein andere Demon darauf zugreift ist dem Service ja egal). Eventuell benötigst du irgendwann noch nen Webserver der die Aufrufe an den richtigen Demon weiterleitet.
P.s: verteilte Rechennetzwerke schaffen das ja auch irgendwie ;-)
Ja, so der Knackpunkt ist eben nur der richtige Daemon. ;) Sobald der am Limit ist, ist alles vorbei, ausser man betreibt richtig Aufwand. Und wenn die Webserver immer erst remote connecten muessen fuer jeden Request, dann geht der Vorteil des Appservers ebenfalls verloren und man ist wieder bei Scripting Interface <> Backend, nur eben ohne DBMS.
Klar ist Socket Kommunikation an sich nicht schwierig, nur muessen gewisse Dienste (die entsprechenden Daemons, z.B. fuer Kampfberechnungen) ja Zugriff auf alle notwendingen Daten haben und dabei ACID-konform sein. Wenn diese weder in einem DBMS stecken, noch lokal vorgehalten werden, ist das keine leichte Aufgabe...
Original von altertoby
P.s: verteilte Rechennetzwerke schaffen das ja auch irgendwie ;-)
Die Sache bei den meisten VR-Anwendungen ist, dass keine zeitkritische Arbeit ausgeführt wird, sondern im Vorhinnein schon die Arbeitspakete erstellt werden.
Faktor 200 im Durchschnitt kommt nach gängigen Testreihen schon hin, und bei seriöseren Tests wird auch versucht, den Code in vergleichbarer Qualität zu halten falls technisch überhaupt möglich. Wenn du zum Beispiel vorwiegend Listen verarbeitest oder viel über Exceptions steuerst, dann stinkst du so ziemlich mit allem anderen gegen einen ordentlichen Lisp-Dialekt ab.
Es gibt aber auch die Möglichkeit, mit recht sparsamen Mitteln Mischarchitekturen zu verwenden.
Um ein Beispiel zu geben:
Weil du dich damit wohlfühlst, möchtest du dein Spiel gern in PHP implementieren, stellst aber fest, dass du Flaschenhälse im Datenbankzugriffen und oder Webservices bekommst. Zudem verwendest du vielleicht viele reguläre Ausdrücke und möchtest ganz gern xml dokumente verarbeiten.
Was spricht dagegen, auf das in der Datenbank abgebildete Model auf zwei völlig unterschiedlichen Wegen zuzugreifen: über PHP für die Grundseiten, und zum Beispiel über Java-Servlets mit ordentlichem connection pooling, vorkompilierten Regexp und XPath's zu arbeiten, für schnelle und zahlreiche AJAX Updates. Wenn du mehrere connection pools verwendest, kannst du damit auch Datenbankzugriffe optimieren, in ähnlicher Form wie traffic shaping funktioniert. Das setzt natürlich voraus, dass du ein paar Gedanken in die Architektur investierst und dir ein Bewertungskriterium für Zugriffspriorität und akzeptable Latenz bei einzelnen Queries überlegst.
Original von Tron
Faktor 200 im Durchschnitt kommt nach gängigen Testreihen schon hin [...]
Darueber dass obiges Blogposting absoluter Bullshit ist und die 200 bei realen Szenarien absolut keinen Realitaetsbezug hat, muessen wir hier hoffentlich nicht diskutieren, oder? Ich bin auch kein PHP Freund, aber irgendwann ist es auch gut mit dem Bashing.
Was spricht dagegen, auf das in der Datenbank abgebildete Model auf zwei völlig unterschiedlichen Wegen zuzugreifen [...]
Primaer wohl, dass man quasi den gesamten Code (oder den Grossteil, sprich Datenstrukturen abbilden, Algorithmen, etc.) des Spiels doppelt schreiben und auch pflegen muss? Ich hab genau das frueher gehabt und kann sagen, dass ich das nie wieder tun wuerde. Reusability ist einer der wichtigsten Punkte ueberhaupt, maintenance sowieso.
Da Du ja fast cgi erwähnst, kannst Du da ja auch die Datenbankverbindungen mit PHP poolen und das sollte man sicher auch machen. Da würde es keinen Unterschied geben. Das parsen des requests und das Ausliefern der Seite an die Browser übernimmt der Webserver, da gibt es also auch keinen Unterschied. Die Datenbank Anfragen werden auch von beiden Sprachen gemacht, da kann es höchstens im binding zu Datenbank Unterschiede geben.
Ich würde vermuten, dass man bei einem "üblichen" Browser-Spiel am meisten an der DB an Resourcen sparen kann.
> Also wieviel mal schneller ist C++ gegenüber PHP wenn beides oop aufgebaut ist.
Je nach Aufgaben könnte ich mir schon vorstellen, das da Faktor 1000 dazwischen liegen kann. Bei C++ gibt übrigends faktisch keinen overhead für OO, wenn man es vernünftig macht.
> Bzw lohnt sich der Aufwand von PHP nach C++ umzusteigen?
Glaube ich nicht. Wenn man es ganz extrem treiben will, dann könnte man den Webserver auch mit schreiben und die Datenhaltung auch. Das ganz mit asynchronem IO in C++ und alles in einem Prozess und man hat sicher ein sehr performantes Spiel, dass mit kleiner Hardware auskommt. Allerdings hat man dann auch recht viel Zeit mit der Erstellung verbracht ;-)
und för c++ haben die leute von PT auch gleich das passende programmiert: http://oss.pixeltamer.net/ :D
Aber dazu gibts keinen support!
Meines Wissens nach enthält das OSS-Paket von PT keinen Webserver.
nicht? dann ist der bestimmt schnell implementiert! :D
Oder guckst Du hier:
Original von Kallisti
Original von Tron
Faktor 200 im Durchschnitt kommt nach gängigen Testreihen schon hin [...]
Darueber dass obiges Blogposting absoluter Bullshit ist und die 200 bei realen Szenarien absolut keinen Realitaetsbezug hat, muessen wir hier hoffentlich nicht diskutieren, oder? Ich bin auch kein PHP Freund, aber irgendwann ist es auch gut mit dem Bashing.
Wenn hier gebashed würde, machte der Kommentar Sinn... Sagt dir das Worte "Durchschnitt" was, hast du den Rest nicht gelesen, oder zitierst du bewusst nur Auszüge, auf denen du rumhacken kannst?
Das ein Durchschnitt in diesem Zusammenhang immer willkürlich gewählt ist sollte jedem klar sein. In den Testergebnissen sind die Faktoren idR detaillierter angegeben, und der Durchschnitt wird dann über verschiedene Aufgaben gebildet. Wie diese Aufgaben im betrachteten Projekt vertreten sind ist eine Betrachtung, die dann notwendig wäre um reale Performanceunterschiede abzuschätzen,
PHP ist ohne weiteres zutun erstmal eine interpretierte Scriptsprache. Man kann da ne Menge rausholen mit diversen Hilfsmitteln, wissen die meisten langzeit PHP-benutzer, aber einen Apfel langziehen macht noch keine Birne. (ich hoffe ich verpasse hier nicht einen allgemein gesehenen Qualitätsunterschied zwischen Obstsorten, damit nicht wieder wer Schaum vorm Mund kriegt). C++ und Java hingegen werden prinzipiell kompiliert, Java hierbei mit einem JIT Compiler, was letztlich dazu geführt hat, Java in einigen Bereichen performanter zu bekommen als C++, da JIT ermöglicht, gezielter auf die konkrete Plattform einzugehen auf der der Code letztlich läuft. (Zum besseren Verständnis: ein C++ Kompilat muss Code produzieren der gleichermassen auf einem Atom läuft wie auf einem Quad Core, mit & ohne MatheCoprozessor etc.)
PHP zu ersetzen durch eine Performantere Alternative KANN also Sinn machen, wenn man aufwändige Berechnungen zu tätigen hat für kompakte Ergebnisse. Um einfach nur eine Datenbankabfrage von der Datenbank über den Webserver an den Client zu liefern eher weniger, da in diesem Fall eher die Netzverbindung das Nadelöhr ist.
Was spricht dagegen, auf das in der Datenbank abgebildete Model auf zwei völlig unterschiedlichen Wegen zuzugreifen [...]
Primaer wohl, dass man quasi den gesamten Code (oder den Grossteil, sprich Datenstrukturen abbilden, Algorithmen, etc.) des Spiels doppelt schreiben und auch pflegen muss? Ich hab genau das frueher gehabt und kann sagen, dass ich das nie wieder tun wuerde. Reusability ist einer der wichtigsten Punkte ueberhaupt, maintenance sowieso.
Das ist Unsinn. Ich spreche hier von einem sehr typischen Fall des Browsergames, wo ein grosser Teil des Modells schlicht und einfach im Datenbankmodell steckt. In diesen Fällen machen Datenbankstruktur und definierte Abfragen den grössten Teil der Logik aus, und eine Pflege in diesem Bereich wird kaum davon beeinflusst, ob ich Viewseitig mit einer, zwei oder 14 verschiedenen Programmiersprachen arbeite. Ein Interface, um Post-daten auszulesen und ein Json oder XML Ergebnis zurückzulierfern schreibe ich normalerweise einmal und verwende es wieder, wenn ich daran viel rumpflegen muss, dann läuft eh was falsch.
Das Reusability und Codepflege in erster Linie mal wichtiger sind als Performance ist offensichtlich und widerspricht sich nicht Grundsätzlich mit meinem Vorschlag. Aber damit du das verstehen kannst, geb ich gern ein konkretes Beispiel:
Ein kleines Team entwickelt ein Browsergame. Die Architektur nebst Datenbankmodell steht, Für das Frontend wird ein PHP-Framework verwendet, welches sich um Seitenkomposition etc kümmert. Einer der Entwickler im Team ist PHP- und Frameworkexperte und kümmert sich um diese Seite des Projekts.
Der Spielablauf findet dann über eine Vielzahl von AJAX-requests statt, die aus Performancegründen zum Beispiel über eine Java Applikation bedient werden. Clientrequests werden über mod_rewrite an die Appserver weitergeleitet, der die Requests über Servlets behandelt. Die PHP scripte können sich bei Bedarf über localhost auch mal dort bedienen wenn notwendig. Auch für diese Seite hats in dem Team einen Entwickler. Und weil beide in jungen Jahren bei Galaxy-news im Entwicklerbereich abgelehnt wurden, können sie sogar miteinander kommunizieren, ohne sich die Schädel einzuschlagen ;)
ein C++ Kompilat muss Code produzieren der gleichermassen auf einem Atom läuft wie auf einem Quad Core, mit & ohne MatheCoprozessor etc.)
Dies ist so pauschal nicht korrekt. Nicht umsonst gibt es bei allen Compilern bestimmte Flags, die auf Zielplattformen optimieren. Die Gentoo-Nutzer können ein Lied davon singen.
Zum Beispiel lautet beim unsäglichen GCC das Flag -march.
Ich persönlich habe übrigens bei eigenen Tests einen Faktor 5 bis 20 ausgemacht. Insbesondere bei großen String-Operationen, die für das Web notwendig sind, kam PHP nahezu an die Geschwindigkeit von einem kompilierten C++-Programm. Einfach selbst mal testen. Bei reinem Numbercrunching, wie es bei BGs eigentlich weniger vorkommt, ist C++ natürlich um den von dir genannten Faktor überlegen. Der Durchschnitt von 200 ist weniger praxisnah.
Und zu deinem Vorschlag:
Ich würde darauf achten, dass Backend und Frontend die gleiche Runtime nutzen, da man ansonsten unsägliche Code-Duplikation haben.
Da bieten sich Runtimes wie Java oder .Net an. (Stichwort: Phalanger [PHP für .Net], IronRuby, IronPython, C#, VB und natürlich Managed C++, das managed Code mit unmanaged Code mischen kann). So kannst du mit einer Bibliothek im Frontend und Backend arbeiten.
Praxisnah für reine Benchmarks vielleicht nicht, aber da gehen ja auch noch Unterschiede mit ein, ob der Lebenszyklus meiner Objekte ein tatsächlicher ist, oder ob er sich durch von Datenbankschlaf unterbrochene Wachphasen in einem Scriptaufruf abbilden lässt. Das ständige Instantiieren, serialisen, reinstantiieren und repopulieren kann einen finsteren Overhead produzieren.
Hast du mit Iron Python persönliche Erfahrungen gemacht? Ich hatte nette Dinge darüber gelesen, aber bislang noch keine Zeit gehabt mich damit näher zu befassen.