Geschwindigkeitsvergleich PHP C++

Hiho, nachdem hier oft Leute erzählen,
dass sie gewisse Funktionen in C++ programmieren,
würde mich mal interessieren, wieviel schneller C++ denn im Endeffekt ist.

Hab per Google nix darüber gefunden

Naja die Frage ist schonmal was man in C/C++ codet.

Codet man nur bestimmte Teile in C++ ist der Geschwindigkeitsvorteil geringer als wenn man das ganze Spiel in C++ codet.
Das hängt davon ab da php die Daten ja erst an das C++ schicken muss.

Bei 10 Spielern ist der Geschwindigkeitsvorteil aber noch minimal.

Jedoch bei mehreren tausend Spielern ist der unterschied zwischen reinem PHP mit MySql z.b. oder reinem C++ oder C++ mit PHP oder C++ mit PHP und MySql schon um einiges größer.

Was man nun benutz ist meiner Meinung nach abhängig wie groß das Projekt werden soll, wie umfangreich und welche möglichkeiten, erfahrungen der Coder hat.

Denn was in C++ zu schreiben ohne Ahnung oder Erfahrung in C++ zu haben ist sehr gewagt.

Ach ja ein riesenvorteil von C++ ist wenn mans richtig macht die Sicherheit. Mit c++ habe ich eine viel höhere Hackbarkeitssicherheit als mit PHP
Und mit C++ habe ich die möglichkeit ein Spiel auch für andere Plattformen schneller umzucoden. Also z.b. ein WAP Portal oder nen Client, etc. dazuzucoden

So das mein Wissen/oder das was ich so in den Jahren gelernt hab drüber

Ich hatte vor längerer Zeit mal ein Test durchgeführt und kam zu folgendem Ergebnis:


Geschwindigkeitsvergleich
von PHP und C++

Testbedingungen

Hardware:
Pentium-M Banias 1,4 GHz
512 MB Ram

Software:
Windows XP Professional Service Pack 1
Apache 2.0.47
PHP 4.3.4 als Apache-Modul
mySQL 4.0.17
Mozilla 1.6
Microsoft Visual C++ 6.0 Service Pack 3

Vorwort

Mit diesen Tests soll der Geschwindigskeitsgewinn von C++ gegenüber PHP ermittelt werden.
Es werden verschiedene Aufgabenstellungen vorgegeben. Diese werden dann in die jeweilige Programmiersprache übertragen.
Der PHP-Code wird als Skript für den Webserver Apache abgelegt und per Web-Browser abgerufen. Die Overhead durch Apache und Web-Browser kann vernachlässigt werden, da nur die Zeit für die Ausführung der eigentlichen Testroutine gestoppt wird. Die Laufzeit wird mit der Funktion microtime ermittelt
Der C++-Code wird als Release kompiliert und ausgeführt. Die Laufzeit wird mit der Funktion GetTickCount ermittelt.

Die Ergebnisse

Zusammenzählen der ersten 100.000.000 Millionen Zahlen

C++: 0,220 Sekunden
PHP: 93,896 Sekunden

1.000 faches Ausführen einer Datenbankabfrage mit 12 Spalten und 250 Ergebniszeilen. Zubereitung des Ergebnisses in einem Array nach Zeilen und Spalten sortiert.

C++: 3,685 Sekunden
PHP: 8,747 Sekunden

1.000faches Ausführen einer Datenbankabfrage mit 12 Spalten und 1 Ergebniszeile. Zubereitung des Ergebnisses in einem Array nach Zeilen und Spalten sortiert.

C++: 0,391 Sekunden
PHP: 0,452 Sekunden

1.000.000faches Ausführen folgenden Algorithmus:
string1 = 'Hallo';
string2 = 'Welt';
string3 = string1 + string2;

C++: 1,468 Sekunden
PHP: 2,644 Sekunden

Ermitteln aller Primzahlen von 2 bis 1.000.000 mit Hilfe des Sieb des Eratosthenes (78.498 Primzahlen):

C++: 0,381 Sekunden
PHP: 7,18 Sekunden

Fazit

Wie deutlich zu sehen ist, besitzt C++ in puren Algorithmen mit reinen Zahlen einen ungemeinen Vorteil (Faktor 20-300). Betrachtet man allerdings die Zeiten in denen Datenbank und Zeichenketten-Verarbeitung eine Rolle spielen, so sieht man deutlich, das PHP in etwa mit C++ mithalten kann. Ein Faktor von 2-3 gegenüber C++ rechtfertigt die wesentlich geringere Entwicklungszeit für PHP.

Hinweis

Dies ist ein synthetischer Benchmark und kann nicht das Verhalten von PHP bzw C++ unter Last beschreiben. Man kann aber ein Gefühl erhalten, wie schnell C++ gegenüber PHP ist. In der Praxis haben sich bei mir ungefähr folgende Faktoren bewährt:

C++ <-> PHP : 1 : 10
C# <-> PHP : 1: 7
C# <-> PHP: 1 : 1,3
C# <-> Java: 1 : 1 (leichter Vorteil für C#)

Diese Zahlen gelten nur für bestimmte Algorithmen. Bei anderen Problemstellungen können die Verhältnisse wieder ganz anders aussehen.

Sehr cool, danke für die Infos

Noch ein paar Fragen ... hab keinerlei Ahnung von C++:

Ist es denn sonderlich aufwändig,
wenn man bisher keine Ahnung von C++ hat,
z.b ein Kampfscript (sind ja normalerweise nur ein paar Variablen und deren Berechnung doch recht simple Mathematik)
in C++ umzusetzen?
Also ich denke mal, grundsätzliche Mathematische Funktionen
können ja nichtmal von der Syntax her einen großen Unterschied zu PHP haben.


Und was muss ich alles machen/auf dem Server installieren,
damit PHP das C++-Programm ausführen und die Rückgaben erhalten kann?
Ich vermute mal, dass man dafür richtig Zugriff auf den Server benötigt,
also nur per FTP wird da nix gehen?

Da das gerade zum Thema passt: Ich habe mein Kampfskript nach und nach von PHP nach Java, und von dort nach C++ portiert, weil das ganz erhebliche Geschwindigkeitsvorteile mit sich brachte.

Wenn du allerdings bisher nichts mit C++ gemacht hast: als einen 1:1-Umstieg kannst du dir das nicht vorstellen. Die Gewöhnung an die C++-Syntax geht zwar meines Erachtens relativ schnell, allerdings musst du mit Zeigern, Referenzen, und vor allem mit Datentypen arbeiten, wenn du unter C++ effektiv sein willst.

PHP z. B. kann $x = "12.5" automatisch ohne Aufruf weiterer Funktionen intern als Gleitkommazahl interpretieren (so dass du z. B. $y = $x + 14; ohne weitere Vorbehandlung notieren kannst. In C++ sind das alles verschiedene Typen, die du erst ineinander überführen musst.

Ebenso kommst du (wie gesagt) bei C++ fast nicht drumherum, mit Zeigern auf Objekte zu arbeiten, und dieses System braucht seine Zeit, bis man es durchschaut hat - ich spreche aus Erfahrung

Dazu sollte man aber auch sagen, dass mein Kampfskript (für ein Rollenspiel) überdurchschnittlich kompliziert ist, da es die einzelnen Gegner genau modelliert und den Kampf Runde für Runde sehr genau durchspielt.

Und du brauchst für die Ausführung eines solchen Programms auf jeden Fall direkten (shell-)Zugriff auf den Server - "herkömmlicher" Webspace verbietet in der Regel das Ausführen von beliebigen Programmen durch ein PHP-Skript.

Gibt es gute Tutorials die sich auf C/C++ beziehen? Ich habe mir jetzt schon ein C++ Buch bestellt (noch nicht angekommen), aber darin werden Datenbanken warscheinlich nicht behandelt. Eine Seite, die mit bis jetzt empfolen wurde und ich gut finde ist pronix.de. Gibt es noch weitere gute Seiten?

Zur Anbindung von (MySQL)-Datenbanken gilt ebenfalls, dass du damit mehr Arbeit haben wirst - da musst du dann die MySQL-Bibliotheken verlinken oder dir eine gute Wrapper-Klasse im Internet suchen. Du kannst dir auf der MySQL-Seite die Dokumentation zu den C-Bibliotheken unter dev.mysql.com/doc/mysql/en/c.html anschauen. Alternativ gibts für C++ tangentsoft.net/mysql++/. (Ich gehe mal davon aus, dass du MySQL-Datenbanken und kein anderes Format ansprechen willst).

Wenn du wirklich mit C/C++ anfängst, würde ich empfehlen, Datenbanken erstmal auszuklammern, das wird am Anfang zu happig für die ersten Übungen, weil du da bereits mit Zeigern etc. arbeiten musst.

ich würde für ein BG eh den Teil Datenbank extern ganz ausschließen

Denn das C Programm müsste sich ja immer die Daten aus der DB holen und das dauert
Da ist eine interne DB viel schneller.
Dauert länger und Backups machen ist bisschen aufwendiger aber es sparrt nochmal später an Zeit

Wenn C++, dann gleich alles darüber.
Das programm sollte an Port 80 lauschen und die Daten selbst speichern. Ansonsten ist PHP besser geeignet.

Und mit C++ habe ich die möglichkeit ein Spiel auch für andere Plattformen schneller umzucoden. Also z.b. ein WAP Portal oder nen Client, etc. dazuzucoden
Dem stimme ich nicht zu. Gibt ja Templates-Systeme, die kann ich mit PHP oder mit C++ nutzen.

Performancemäßig - naja, C++ ist schneller, aber mit E-Accelator und "gutem" PHP-Code hält sich das in Grenzen - bei ner normalen Spiellast kommt auch ein PHP mit einem normalen Rechner (so 3 Gig) aus.

@Tweety:
Ja, ich will nur MySQL Datenbanken benutzen. Natürlich ist mir klar, dass ich beim erlernen einer neuen Sprache von ganz vorne anfange - nicht erst ein bissel Grundlegendes, und dann gleich mit dem Schwierigsten weitermachen.
Die meisten Berechnungen werden/sollen eigentlich mit PHP gemacht werden. Warum sollte ich dann auf MySQL verzichten und was eigenes Coden? Wie Kampfhoernchen es meint (alles in C) ist mir da viel zu aufwendig, C/C++ soll nur zur Unterstützung sein.

Wenn ich Daten in einer PHP-Datei in ein multidimensionales Array speichere, kann ich auf die Daten auch mit C/C++ zugreifen? Oder würde sich da eine XML-Datei empfehlen?

Also mein Spiel ist komplett in C programmiert, inclusive Serverprogramm und Datenbank. Die benötigte Prozessorleistung ist (bei ca 150 Spielern) so klein, dass sie kaum noch messbar ist. Und die Datenbank kann man so optimieren (hab ich allerdings leider nicht), dass man nur noch ganze selten auf die Datenbank zugreift und alle wichtigen Daten persistent im Speicher hat, so dass die Datenbank nur noch als Backup dient.

Hier ein paar Statistiken:
http://garia.drownedworld.de/status

Zur Angabe des verbrauchten RAMs muss ich noch sagen, dass die Grafiken auch im RAM zwischengespeichert werden und dass da noch irgendein Memoryleak ist, das ich noch nicht gefunden habe. Dass das Spiel über port 80 läuft ist nur über einen Proxy möglich. Aber wenn man einen Server ganz für sich hat, sollte das kein Problem sein.

Und zum Serverpart muss ich sagen, dass der an Port 9990 lauscht, da Port 80 an diesem Server schon von Apache belegt ist.

Der Nachteil von C/C++ ist allerdings, dass man sauberer coden muss, da schon bei einem kleinen Programmierfehler das Programm abstürzen kann und so das Spiel nicht mehr erreichbar ist. Und natürlich ist es aufwändiger als die PHP Variante.

Hat eigentlich jemand schon Erfahrungen mit einem C/C++ Programm als cgi gemacht?
Von der Variante, dass ein C++ Programm per Cronjob für die Tickberechnung gestartet wird hab ich schon gehört.

Original von TheUndeadable
Ich hatte vor längerer Zeit mal ein Test durchgeführt und kam zu folgendem Ergebnis:


Zusammenzählen der ersten 100.000.000 Millionen Zahlen

C++: 0,220 Sekunden
PHP: 93,896 Sekunden

code? Ohne code kann man das schlecht beurteilen.

Ich habe das hier mal Spaßeshalber mit Perl gemacht.

P4 1.8GHz

Ad-Hoc Version:

my $sum;
for (0..100_000_000) {
$sum+=$_;
}

45 bis 47 sek.

Die DB-Geschichten sind ohnehin von der DB selbst abhängig, da bringt
C IMHO recht wenig bis nix.

Wenn ich natürlich den lieben Gauss hernehme...

$sum = 100_000_000*100000001/2;

dann brauche ich 2.2e-05 sekunden

Fazit

Wie deutlich zu sehen ist, besitzt C++ in puren Algorithmen mit reinen Zahlen einen ungemeinen Vorteil (Faktor 20-300). Betrachtet man allerdings die Zeiten in denen Datenbank und Zeichenketten-Verarbeitung eine Rolle spielen, so sieht man deutlich, das PHP in etwa mit C++ mithalten kann. Ein Faktor von 2-3 gegenüber C++ rechtfertigt die wesentlich geringere Entwicklungszeit für PHP.


Ich denke auch, daß beides seine Berechtigung hat. Wobei mir persönlich
das rapid development wichtiger ist, denn optimieren kann man immer noch.
Wichtig ist, daß man eben ein gutes Design hinstellt und da behaupte ich mal,
bieten Skriptsprachen die bessere Möglichkeit (weil höherer Abstraktionsgrad).

so long,
Marcel

Der Code war eine einfache For-Schleife. Wollte wissen, ob PHP seinen Opcode wie C++ optimiert oder nicht.

Daher wuerde ich diesen Benchmark herausfallen lassen, da dies ein wirklicher Spezialfall ist, den man durch mathematische Umformungen auf eine einfache Zuweisung umformen kann.

RAD ist fuer mich auch wichtiger nur habe ich mich fuer C-Sharp statt PHP entschieden. Der Grund fuer mich persoenlich war die schnellere Ausfuehrung und das besser strukturierte Framework. Dass ich mich gegen Java entschieden hatte, war mehr oder weniger eine Laune (bzw das Visual Studio). Ansonsten liegt ja wie du schon gesagt hast, ein grosser Teil der Last an der Db, da kein ein C++-Backend nicht sehr viel machen, es sei denn man entscheidet sich diese Db auch noch selbst zu implementieren und auf das Bg zu optimieren.

(Sry fuer fehlende Umlaute, bin gerade unter links)

Mich würde es interesieren, wie man eine Seite komplett in C schreibt. könnt ihr mal ein Grundgerüst zeigen? Vllt. ja auch in die snippets-DB rein tun

Schau dir mal "ectroverse" an...
Ist meines Wissens ja komplett in C geschrieben.
Oder uga-agga, als Mischung von PHP und C.

Original von Fornax
Mich würde es interesieren, wie man eine Seite komplett in C schreibt. könnt ihr mal ein Grundgerüst zeigen? Vllt. ja auch in die snippets-DB rein tun

Eine "simple" Seite in C++ zu schreiben ist nicht mal so einfach, wie es auf den ersten Blick zu schein erscheint. Wieso?
Im gegensatz zu PHP ist C++ nicht für den spezifischen Einsatz als Web- Sprache ausgelegt. Es kann problemlos dazu verwendet werden, da gibts aber diverse Möglichkeiten.

Beispielsweise:
- CGI (sprich Webserver ruft ein EXE auf, dieses gibt (praktisch mit printfs HTML an Webserver zurück)
- ISAPI / NSAPI: Code läuft über standardisierte Schnittstelle direkt IM Webserver (1 Fehler da crashed kompletten WEbserver / zumindest grosse Teile)
- Apache Plugin: Stärker verbunden zu Server als ISAPI / NSAPI
- Eigener Webserver

Der Aufwand ist ungefähr auch nach dieser Auflistung. Mit ca. 5 bis 10 Stunden kucken wie wo was schafft man es, in nakigem C++ eine CGI Applikation zu bauen, welche einfach einen GET / POST Auswertet und diesen wiederum darstellt (echo GET[param])

ISAPI / NSAPI braucht mehr. Vorallem auch viel knowhow und Testing. 1 Fehler hat fatale Auswirkungen
Apache Plugin ist noch extremer
Und eigener Webserver ist nur für leute mit spezifischen Anforderungen / zu viel Freizeit

Deshalb wird oft ein "Zwischenweg" genommen, dass PHP dem C++ Berechnungen gibt und die Antworten auswertet. Hier ist die Kommunikation PHP C++ jedoch wiederum recht mühselig und einer Doktorarbeit würdig

Fazit: Du profitierst extrem von C++, benötigst aber auch extrem viel mehr Zeit. -> Setz es erst ein, wenn du mit PHP an die Grenzen stösst?

Gruss

Also außer vielleicht Performance sehe ich keine Grenzen mit PHP. Es gibt doch für alles Addons zum Nachrüsten.

Interessanter als theoretische Messergebnisse wie 10x, 100x schneller fände ich eine praktische Erfahrung wie z.B. wieviele Spieler mehr bekomme ich auf einen Server wenn das Spiel in C++ statt auf PHP basiert...50% mehr oder 100% gegenüber der PHP Version?

Erst daraus könne ich irgend eine praktische Verwendbarkeit/Wirtschaftlichkeit ableiten. Ansonten wenn die Server nicht bis an die Grenzen ausgereizt sind, ist es für mich egal ob die Kiste unter 10% Last oder 30% steht. Für den Spieler dürfte das ja auch uninteressant sein, da die Seitenauslieferung von der gefühlten Geschwindigkeit einfach kaum einen Unterschied macht oder?

Wenn du C++ in Reinkultur betreibst, sehr viel Zeit investierst. Dann kriegst du auf einem handelsüblichen Billig- Server etwa das:

ca. 512 MB Ram
2 GHz Single Prozessor (Qualitätsding; ned so ne Billig Celeron oder AMD Kacke)
Schnelle Festplatte

Ein Spiel mit einer mit OGame verlgiechbaren UnKomplexität.
==>> ca. 100'000 Spieler pro Server

Gruss

Hm, tut mir leid, wenn ich euch den Spass etwas verderbe, aber PHP gut gecodet ist in jedemfalle besser, als C++ schlecht gecodet, somit ist der vorne aufgeführte vergleich eh unerheblich, ...

@Bit: Ja und in einem Zelt in einer bitter kalten Nacht zu schlafen ist auch besser als in einem Haus zu schlafen, wenn es brennt.

Das sollte eigentlich klar sein. Ich geh davon aus, dass der Programmierer schon sein Handwerk beherrscht und da ist eine kompilierte Sprache der Sprache PHP in Sachen Performance voraus.

Ein gut programiertes PHP ist im Regelfall langsamer als gut programmiertes C++. Nur sollte sich der Programmierer vorher überlegen, ob sich der Mehraufwand für C++ lohnt.

Ich würde die Diskussion gern mal etwas erweitern,
da C++ für mich keine Alternative darstellt.

Mir schwebt Java vor.
Hat da jemand bereits Erfahrungen gesammelt ?

Also ein Performancevergleich PHP - Java, Java - C++.

EDIT:

Ich hatte mal ne irgendwo ne .pdf zum Thema PHP - Java.

Daraus ging hervor, das Apache 2 mit mod_php circa 150 Requests / Sekunde
einer 64 kb Datei mit MySQL Connect beantworten kann
und das stabil auch bei 5000 ankommenden Requests / Sekunde.

Java mit Tomcat schafft bei gleichen Bedingungen knapp über 300 Responses / Sekunde.

Wäre mit vergleichbarem Aufwand ( zur Javamethode ) mit C++ höhere Performance möglich ?

java ist genau das gleiche... Leistung viel grösser. Aba die Gefahr ist gross dass man probleme hat wenn man sich damit zu wenig auskennt.

Also ich hab gehört, das Java im Verlgeich zu C/C++ recht schlecht sein soll. Leider kann ich hierzu keine Infos geben, da ich jetzt nix mehr mit Java mache. Das war vor ein paar Jahren an einem P2 266Mhz. <- Das sagt glaub ich einiges aus :lol: Warscheinlich hat sich da schon einiges getan

hehe, die Zeiten zu denen Java langsam war, sind langsam vorbei.
Java, wie C# bewegt sich in etwa in der Größenordnung von C++. Bei stark OOP-orientierten Projekten kann eine gejittete Sprache manchmal sogar schneller sein, da der Jitter mehr Informationen zur Optimierung zur Verfügung hat als eine statische Compiler.
Ich würde im Allgemeinen den Faktor 2 ansetzen. Allerdings hat sich bei mir die Programmierzeit um den Faktor 5 durch die Nutzung von C# reduziert. Dies war es mir wert. Das gleiche würde wahrscheinlich auch für Java gelten.

Neue Sprachen wie Java und C# sind meiner Meinung nach sehr angenehm zu programmieren .

Mal eine andere Frage:

Der Interpreter von PHP ist ja meines Wissens auch in C geschrieben, oder?
Kann man da nicht einfach eine neue Bibliothek schreiben und einbinden, die Funktionen enthält, bei denen C einen deutlichen Vorteil gegenüber PHP hat?

Wenn das geht, dann hat man zumindest einen kleinen Geschwindigkeitsvorteil, oder?

Yep kannst du.

Schau mal in deine php.ini, dort findest du viele Zeilen im Format:

;extension=php_pdf.dll
bzw php_pdf.so

Dies sind in C oder einer anderen kompilierten Sprache geschriebene Bibliotheken, die sich in das PHP-Framework einbetten. Auf www.php.net findest du ein gar nicht mal so schlechtes Tutorial, wie du eigene Bibliotheken schreiben kannst.

Original von Störti
Wenn das geht, dann hat man zumindest einen kleinen Geschwindigkeitsvorteil, oder?

Es gibt Lösungen (auch kostenlose) die den PHP code precompilen was enorme geschwindigkeitsvorteile mit sich bringt.

Es wäre toll wen TheUndeadable auch einmal dieses Verfahren mit seinem Test auswertet. :roll:

reg4rds
chojin

Zum Thema hier ein Artikel der iX, der verschiedene dynamische Web-Technologien vergleicht.

Unglücklicherweise ist mal wieder IMO (ich kenne den Originalartikel nicht, der PHP und C im März verglichen hat) nicht daran gedacht worden, Präkompilierung bei PHP mit einzubeziehen, wohingegen auf Java-Optimierung eingegangen wird.

Ich behaupte, dass die Präkompilierung bei meinem Fall keinen Geschwindigkeitsvorteil gebracht hätte, da die Testskripts aus etwa 10 bis 20 Zeilen bestanden haben, die innerhalb von Millisekunden geparst wären. Dies macht bei Laufzeiten von mehreren Sekunden nichts aus.

Allerdings weiß ich nicht, ob Technologien wie der PHP Optimizer, MM Turck oder was es auch immer noch gibt, nicht den PHP-Code auch optimiert.

Eine Sache, die bisher noch gar nicht erwähnt wurde, die meines Erachtens aber enorm nützlich ist: ein Debugger. Sowohl C++ wie auch Java oder C# haben alle wunderbare Entwicklungsumgebungen mit integriertem Debugger, der einem erlaubt seine Programme schrittweise auszuführen, zu unterbrechen, den Status (Variableninhalte) zu überwachen etc... Für PHP gibt es so etwas meines Wissens nach (noch) nicht. Es gibt ein kostenpflichtiges VisualStudio PHP plugin, was eine Art Debugger beinhaltet, dieser schien mir jedoch noch nicht so ausgereift.
Man verfällt also in einen Zyklus von schreiben, Browser ausführen, Fehler bemerken, die($diagnostic) einbauen, wiederholen... Das ist mühsam, zeitaufwendig und ineffizient. Bitte nennt mir eine bessere Methode! ;-)

Meine eigene Erfahrung zu PHP von einem C++ Hintergrund zu kommen war recht gemischt. Zum einen habe ich den Debugger und vernünftige IDE (Intellisense!) sehr vermisst und PHPs Syntax ist auch sehr inkonsistent und überladen. Zum anderen gefallen mir PHPs assoziativen arrays und Typen-Deduktion hervorragend. Es ist die erste Sprache, die ich neu gelernt habe, bei der ich spontane "wow, das geht ja tatsächlich so einfach" Erlebnisse hatte. Es fühlt sich manchmal wirklich wie "Do what I mean" anstatt wie "Do what I say" an.

Mein Ratschlag wäre aber für Webanwendungen bei PHP bzw der Sprache, die man bereits am besten beherrscht, zu bleiben. Die Unterschiede zwischen den Sprachen lohnen den zusätzlichen Lernaufwand einfach nicht.

mfG,
Sören

Disclaimer: Ich habe jahrelange C++ und Java Erfahrung mit diversen kommerziell realisierten Projekten, bin aber ein kompletter PHP Neuling und als solcher vielleicht falsch informiert.

Ach so, noch etwas. Jemand führte an C++ sei unter anderem wegen der Pointer schwerer zu verstehen als PHP. Tsts. I respectfully disagree. Es ist ohne weiteres möglich non-triviale, pointer-freie C++ Programme zu schreiben. Andersherum braucht man sie in PHP teilweise genauso wie in C++. Vielleicht geht es ja nur um die Begrifflichkeit - das in beiden Sprachen gleichnamige Konstrukt, das Pointerfunktionalität bietet wären Referenzen ;-)

mfG,
Sören

PS: Ja, ich kenne den Unterschied zwischen nem Pointer und ner Referenz in C++ ;-)

Original von BuschnicK
Sowohl C++ wie auch Java oder C# haben alle wunderbare Entwicklungsumgebungen mit integriertem Debugger, der einem erlaubt seine Programme schrittweise auszuführen, zu unterbrechen, den Status (Variableninhalte) zu überwachen etc... Für PHP gibt es so etwas meines Wissens nach (noch) nicht. Es gibt ein kostenpflichtiges VisualStudio PHP plugin, was eine Art Debugger beinhaltet, dieser schien mir jedoch noch nicht so ausgereift.

Es gibt das kostenpflichtige Zend Studio mit integriertem Debugger (wahlweise serverdebugging oder clientdebugging) und nem Profiler. Dann gibts unter linux noch DDD mit php-plugin und schon haste nochn guten debugger.

Ansonsten empfehle ich "Brain 1.0", "Inline Doku Pro" und var_dump() als Stort-Tag. Das geht dann auch nicht langsamer als Breakpoints zu setzen

Auch wenn der Thread schon ein wenig älter ist, habe ich noch ein paar Anmerkungen, die ganz interessant sein könnten, für Leute, die wie ich, erst jetzt auf diesen Thread stossen.
Irgendwo in der Diskussion wurde gesagt, dass die gewählte keine Relefanz hätte, was den Datenbankzugriff betrifft. Dies stimmt so nicht ganz. Greift man z.B. mit C/C++ direkt auf die MySQL API zu, dürfte dies schon einen gewissen Unterschied bringen, im Gegensatz zu Sprachen wie PHP, die über eine Zwischenschicht zugreifen.
Neben der alten Diskussion kompilierte Sprachen vs. interpretierte Sprachen, kann der Einsatz von C/C++ im BG Umfled noch andere Vorteile bringen. Gerade im Linux/Unix Umfeld, bei Windows weiß ich es nicht genau, da es nicht (mehr) meine Welt ist, kann man mit C/C++ sehr systemnah programmieren. Dies kann z.B. sehr interessant für Hintergrundtasks, also Berechnungen, die normalerweise per Cronjob ausgelöst werden, sein. Dämonprozesse, Pipes, Message-Queues, Semaphore und Shared Memory Segmente seien nur mal als Beispiel genannt.
Ich habe selbst einmal eine zeitlang eine Machbarkeitsstudie begleitet, in der es darum ging, solche Mechanismen für BGs zu testen. Das vorgehen war dabei eigentlich sehr simpel. Die "Oberfläche" selbst war über PHP umgesetzt. Die Berechnungen wurden allerdings von einem Dämonprozess übernommen. Ich bin mir jetzt nicht mehr sicher, ob der Prozess die Berechnungstickets über eine Socketverbindung bekommen hat oder über eine Message-Queue. Der Prozess hat auf jeden Fall die Daten für Berechnungen , wenn diese fällig waren, aus der DB bezogen und je nach Typ an unterschiedliche Threads zur Berechnung gegeben. Damit es dabei nicht zu race Conditions oder Deadlocks kam, wurde ein gegenseitiger Ausschluss für verschiedene Betriebsmittel (z.B. die DB) mit Hilfe von Mutexen und Semaphoren implementiert.
Der Ansatz hatte gerade aus Performance-Sicht einige Vorteile:
- schneller Db Zugriff durch direkte Nutzung der MySQL API
- Trennung von Interface Code und Berechnungscode, wahlweise auf getrennte Maschinen
- Sehr gute Skalierbarkeit, man konnte den Dämon auf mehreren Rechnern laufen lassen oder die Anzahl der Threads optimieren
- Ausnutzung von MultiCore oder mehrprozessormaschinen
Man sieht also, dass man mit C/C++ sehr felxible entwickeln kann. Der Entwicklungsprozess ist aber aufwendiger und man kann es nicht mal eben so lernen (also kein "Ich kaufe mir mal eben ein Buch und schriebe dann ein BG in C/C++"). man braucht schon fundierte Kenntnisse in der Sprache, Programmierung allgemein und Netzwerk- und Betriebssystemtheorie.

> Gerade im Linux/Unix Umfeld, bei Windows weiß ich es nicht genau,
> da es nicht (mehr) meine Welt ist, kann man mit C/C++ sehr systemnah programmieren.
> Dies kann z.B. sehr interessant für Hintergrundtasks, also Berechnungen,
> die normalerweise per Cronjob ausgelöst werden, sein. Dämonprozesse,
> Pipes, Message-Queues, Semaphore und Shared Memory Segmente
> seien nur mal als Beispiel genannt.
Nur zur Ergänzung:
Windows oder Linux geben sich bei der systemnahem programmierung nichts.
> Greift man z.B. mit C/C++ direkt auf die MySQL API zu, dürfte dies schon
> einen gewissen Unterschied bringen, im Gegensatz zu Sprachen wie
> PHP, die über eine Zwischenschicht zugreifen.
Da haben meine Tests höchstens nen Performanceschub von 10 bis 20 % gezeigt. Hast du da andere Werte?

Original von TheUndeadable
Da haben meine Tests höchstens nen Performanceschub von 10 bis 20 % gezeigt. Hast du da andere Werte?

Nein, die Zahlen decken sich mit meinen Erfahrungen. Auch die Umstellung im Rails Bereich auf ein native binding über die MySQL API hat einen Wert von 10 bis 15% gezeigt.
Mich wundert aber ein wenig dein "höchstens". 10-20% mehr haben ist doch gar nicht so schlecht. Gerade wenn sich die Datenbankanbindung zum Flaschenhals entwickelt. Gerade wenn man seine Abfragen schön optimiert hat, ist dass doch schon einiges an Leistung.

> Mich wundert aber ein wenig dein "höchstens". 10-20% mehr haben ist
> doch gar nicht so schlecht. Gerade wenn sich die Datenbankanbindung
> zum Flaschenhals entwickelt. Gerade wenn man seine Abfragen schön
> optimiert hat, ist dass doch schon einiges an Leistung.
Ich denke da recht pragmatisch. Wenn ich für eine C++ Applikation 50% bis 100% mehr Aufwand als PHP habe, dann lohnen sich für mich 10-20 % mehr Performance nicht. In diesem Monat Mehraufwand im Coding ist ein neuer Server auf dem Markt, der 10 bis 20% schneller ist. Dann hätte ich mir gleich das C++ sparen können und in der Zeit lieber eins, zwei Features implementieren können.
Was anderes wären Größenordnungen, wie man sie bei numerischen Berechnungen wie Kämpfe oder ähnliches hat. Da würde ich klar auf C++/.Net/Java setzen. Bei zeitkritischen Sachen evtl nur auf C++, wobei da die Anbindung an ein bestehendes Framework immer etwas schwieriger ist. Momentan bin ich bei .Net noch nicht an die Grenzen gestoßen und kann die von dir erwähnte systemnahe Ebene nutzen.
Lieber würde ich die Zeit nutzen grundlegende Dinge zu ändern, bei denen man Teils mehr Performancegewinn erreichen kann. Sei es nur ein schnöder Index, der die Dauer für gewisse SQL-Abfragen halbiert. Bei mir spielt die Entwicklungszeit eine große Rolle, daher verzichte ich persönlich auf 30% Performance und entwickle Applikationen in der halben Zeit und brauch mir keine Gedanken über gewisse Eigenarten mancher sehr schneller Programmiersprachen zu machen. Andere sehen dies selbstverständlich anders.

OK, da gebe ich Dir natürlich recht. Primär kommt es auf Intension und Fähigkeiten des Entwicklers an. Wenn man mit C/C++ groß geworden ist, ist das was anderes, als wenn man auf RAD Sprachen/Umgebungen geeicht ist und mit den "Eigenheiten" von C/C++ zu kämpfen hat.
Dazu kommt, dass die Datenbankanbindung nicht alles ist. Ich denke ein BG auf Basis von C/C++, FastCGI, direkte Nutzung der MySQL API und Systemprogrammierung (mit viel Zeit und viel BS Theorie könnte man sicherlich eine interessante Diskussion führen, warum .NET vermutlich nicht wirklich Systemnah ist) wird man auf weit mehr als 20% Performancezuwachs kommen und vermutlich nicht so viel mehr Zeit in Anspruch nehmen, wenn man in diesen Bereichen wirklich heimisch ist.

dumdidum.. kurzer Einschub bzgl. Optimizer.
Ich benutze eAccelerator 9.5.1b für 64 bit kompiliert auf unserem Server, wobei sich der Geschwindigkeitsunterschied von Ein/Aus in einem Faktor von 10-20fach wiederspiegelt.
Die größte Flasche (bzw. der größte Flaschenhals) ist die Datenbank, da kann ich noch soviele Queries optimieren. Ich habe max. 20-30% PHP-Berechnungszeit. (Ich speichere vor den Queries die Zeit und danach.)
Selbst bei größeren Seiten (wenn mal bei den Privaten Nachrichten 10 ganz große Nachrichten kommen) ist die Regular Expression noch immer fix drüber - maximale was ich da je erlebt habe war 2 Sekunden, war aber auch ein Wahnsinnig großer Text. Das meiste spielt sich im 0,01 Sekundenbereich ab, und auch die Speedrunde war kein Problem. Dauerhaft 60-70 User Online, 3 Tage lang, jede Minute ein Tick der 10-20 Sek. rechnet und der Server war noch nichtmal ausgelastet.

Thx Nuky, hab mir auch grad den eAccelerator auf meine Maschine geworfen (gibt übrigens mittlerweile eine rc1 vom 9.5) und Geschwindigkeitszuwachs ist definitiv vorhanden, durchschnittlich (inkl. SQL-Abfragen) ein Performancezuwachs Faktor 2, bei sehr Rechenintensiven Skripten ohne viele SQL Zugriffe Faktor 4-5.

Bitte gern Itchy!
Am besten kommt der Vergleich raus bei häufig verwendeten Regular Expressions. Mein php-"chat" hat eben den genannten Faktor von ca. 20fach, von durchschnittlich 0,4 auf ca. 0,013x Sekunden..

Da würde mich direkt mal interessieren, wie Du die Werte gemessen hast. Beruhen die Daten darauf, dass du direkt im Code zeitmarken genommen hast, oder hast Du einen Server Benchmark, wie den Apach Benchmark genommen?

Also mein Benchmark ist In-Game, wo 100 mal eine Aktion simuliert wird und davon stoppe ich die Zeit mit.

eAcc. zeichnet sich ja daruch aus, die Skripte schon vorzukompilieren, damit sie nicht immer geparst werden müssen. Theoretisch dürfte das die Zeitmessung durch eigene Funktionen im Skript nicht beieinflussen, da $time1 = microtime(true) eigentlich nach dem parsen hätte ausgefgührt werden müssen. Tatsächlich ist das aber nicht so, was sich durch die Verwendung von eAcc. zeigt. Außerdem fällt mir ein Unterschied auf, wenn ich hunderte Zeilen Code einbinde, die aber durch if(false) nie ausgeführt werden.
PHP arbeitet also nicht nachvollziehbar. Da hilft wohl nur ein Blick in den Quelltext.
Darüber hinaus gibt es noch Möglichkeiten, die Laufzeit von außen festzustellen. Undead hat dazu ein Blog geschrieben.

> Undead hat dazu ein Blog geschrieben.
Dem muss ich widersprechen...
Ich hatte mal nen Benchmark gemacht, aber das war mit PHP im Apache.

Original von TheUndeadable
> Undead hat dazu ein Blog geschrieben.
Dem muss ich widersprechen...
Ich hatte mal nen Benchmark gemacht, aber das war mit PHP im Apache.

Tut mir Leid, dann habe ich jemanden verwechselt. Dummerweise finde ich den Blogeintrag nicht mehr wieder, da die Liste mit WoC überfüllt ist und ein weiterblättern nicht möglich ist.

ich mache das direkt per microtime() und schaue mir den unterschied an bei einigen aufrufen. die zeit bleibt prinzipiell bis auf geringste schwankungen (1-10%) immer gleich.
[quote=Klaus]
eAcc. zeichnet sich ja daruch aus, die Skripte schon vorzukompilieren, damit sie nicht immer geparst werden müssen. Theoretisch dürfte das die Zeitmessung durch eigene Funktionen im Skript nicht beieinflussen, da $time1 = microtime(true) eigentlich nach dem parsen hätte ausgefgührt werden müssen. Tatsächlich ist das aber nicht so, was sich durch die Verwendung von eAcc. zeigt. Außerdem fällt mir ein Unterschied auf, wenn ich hunderte Zeilen Code einbinde, die aber durch if(false) nie ausgeführt werden.
ich verstehe nicht genau was du meinst. dass dein $time1 = microtime(true) beim vorkompilieren von eacc schon mit einem wert belegt sein müsste?
weiters: ein if(false) so geschrieben wie es hier steht?
prinzipiell geparst werden muss das alles trotzdem, schliesslich kann sich dort irgendwo das } verstecken, und du weißt nie ob das jetzt ev. nur in einem string vorkommt o.ä.. ich verstehe nicht, warum du meinst dass php sich nicht nachvollziehbar verhält - das dachte ich auch schon öfters, bin aber bis jetzt immer draufgekommen dass das ein denkfehler von mir war.

Darüber hinaus gibt es noch Möglichkeiten, die Laufzeit von außen festzustellen.

So mache ich das auch. Ich habe mir ein kleines Skript geschrieben, das Anfragen an den Webserver schickt und die Zeit wird in den Skripten des Webservers, sondern im Skript gemessen, das die Anfragen schickt.

Original von Nuky
ich verstehe nicht genau was du meinst. dass dein $time1 = microtime(true) beim vorkompilieren von eacc schon mit einem wert belegt sein müsste?
weiters: ein if(false) so geschrieben wie es hier steht?
prinzipiell geparst werden muss das alles trotzdem, schliesslich kann sich dort irgendwo das } verstecken, und du weißt nie ob das jetzt ev. nur in einem string vorkommt o.ä.. ich verstehe nicht, warum du meinst dass php sich nicht nachvollziehbar verhält - das dachte ich auch schon öfters, bin aber bis jetzt immer draufgekommen dass das ein denkfehler von mir war.

Das soll heißen, dass man mit der üblichen Methode ($time2-$time1) auch die Zeit zum Parsen mit inbegriffen ist.
Dafür spricht, dass die Verwendung von eAcc. so messbar ist und zum anderen

$test1 = microtime(true);

if(false)
{
ganzvielzumparsen();
}
$test2 = microtime(true);
...
eine längere Laufzeit hat, als wenn man den If-Block weglässt. Beides habe ich getestet, und beides hat mich verwirrt.
Dies lässt wohl darauf schließen, dass PHP schon Codeteile beim Parsen ausführt.

Worauf ich hinauswollte:
Wenn man direkt die Zeitnahme im vorkompilierten Skript macht, verwundern mich Zahlen wie Faktor 10-20 nicht sonderlich. Man lässt aber einen wichtigen Aspekt aussen vor. Man hat eine weitere Komponente laufen, die einfach auch ihre Rechenleistung braucht, in dem Fall der eAccelerator.
Um also realistisch messen zu können, muss man von aussen messen, und dabei am besten etwas last verursachen. Da bietet sich der Apache Benchmark an, der beim Apache Server dabei ist. Der Aufruf ist eigentlich ganz einfach: ab -n Anzahl der Aufrufe -c Anzahl der parallel Aufrufe URL des Scripts
Würde mich wirklich mal interessieren, ob ein ab -n 5000 -c 10 URL des Skripts immer noch einen Faktor 20 liefert?

habe nicht vor mittem im betrieb wenn grad 40 user online sind den server abzuschiessen, dann eacc abzuschalten und wieder den server abzuschiessen. nächsten reset mach ich das gern mal.

Mit Accelerator:

Concurrency Level: 10
Time taken for tests: 4.256850 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 21004264 bytes
HTML transferred: 20987700 bytes
Requests per second: 23.49 [#/sec] (mean)
Time per request: 425.685 [ms] (mean)
Time per request: 42.568 [ms] (mean, across all concurrent requests)
Transfer rate: 4818.35 [Kbytes/sec] received
Ohne:

Concurrency Level: 10
Time taken for tests: 8.60983 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 20803500 bytes
HTML transferred: 20787100 bytes
Requests per second: 12.41 [#/sec] (mean)
Time per request: 806.098 [ms] (mean)
Time per request: 80.610 [ms] (mean, across all concurrent requests)
Transfer rate: 2520.16 [Kbytes/sec] received
So wie ichs gesagt hab, im Durchschnitt Faktor 2 bei mir Gut genug, um das Ding zu benutzen

Den Faktor 2 habe ich Dir auch ohne mit der Wimper zu zucken abgenommen. Nur den Faktor 20 von Nuky finde ich etwas heftig, lasse mich aber gerne eines bessern belehren. Interessant finde ich aber, dass mit Accelerator anscheinend etwas Overhead in der Übermittlung generiert wird.

kann gut sein dass der faktor gewaltig schrumpft wenn man es so betrachtet, kann dir das wie gesagt erst viel später sagen..
denke aber das ein faktor von 5 insgesamt locker drin is...

Original von Agmemon
Den Faktor 2 habe ich Dir auch ohne mit der Wimper zu zucken abgenommen. Nur den Faktor 20 von Nuky finde ich etwas heftig, lasse mich aber gerne eines bessern belehren. Interessant finde ich aber, dass mit Accelerator anscheinend etwas Overhead in der Übermittlung generiert wird.

Hmm ja, das ist in der Tat interessant. Ich werde mir mal den Code beider Varianten abspeichern und vergleichen - mal sehen, was dabei rauskommt.