Java vs. C. Performance-Vergleich
-
Das kann alles sein von Datenbanken ueber number crunching bis hin zu Computerspielen.
-
Das erklärt ja auch, warum OOP so beliebt ist.
-
Ich dachte eher das liegt daran, dass man das irgendwann vor 20 Jahren mal so hindefiniert hat und es seitdem nie hinterfragt hat
-
DEvent schrieb:
TheTester schrieb:
Das größte Problem beim benchmarken ist sowieso zu verhindern das der
Benchmarkcode als "toter Code" erkannt wird.Das größte Problem beim benchmarken ist es, dass es vollkommen Sinnlos ist. Wenn du beide Sprachen schon vergleichen willst, dann bitte baue auch in C einen Exceptions, GC, Threads, OOP usw. usf. ein, das was du in Java schon alles zur Verfügung hast.
Dann kannst du erst C und Java vergleichen und ich garantiere dir, dass Java wesentlich schneller oder gleich mit C sein wird, denn ich bezweifle, dass du die Java Sprachfeatures besser implementieren kannst als es die Sun-Leute können.
sorry, aber das is grober unfug.
wenn man wissen will ob algorithmus bzw. programm X in java oder C schneller ist, dann programmiert man ihn runter, jeweils unter verwendung der zur verfügung stehenden sprachmittel.
je nach algorithmus bzw. programm wird dann rauskommen dass java bzw. C schneller ist. dann hat man eine sinnvolle aussage, mit der man was anfangen kann.nach deiner logik müsste man dann auch sagen dass python gleich schnell wie C ist, weil man ja in C erstmal alle python features nachprogrammieren müsste, und natürlich auch alles über dynamic dispatch lösen, auch wenn man nur 2+2 rechnet, und .... sorry, aber das ist IMO wie schon gesagt totaler unfug.
-
byto schrieb:
Das erklärt ja auch, warum OOP so beliebt ist.
Datengetrieben bedeutet nicht automatisch OOP.
-
;fricky schrieb:
aber nur um die reine code-ausführungsgeschwindigeit zu vergleichen sind sie doch gut. für den programmiereralltag mag das vielleicht nicht wichtig sein, trotzdem ist es doch eine erkenntnis, wenn man sieht, dass keine welten zwischen der geschwindigkeit von C- und Java-code liegen.
Wenn ich nur "code-ausführungsgeschwindigeit" brauche, dann nehme ich doch gleich Maschinensprache, optimiert für eine spezielle CPU.
hustbaer schrieb:
nach deiner logik müsste man dann auch sagen dass python gleich schnell wie C ist, weil man ja in C erstmal alle python features nachprogrammieren müsste, und natürlich auch alles über dynamic dispatch lösen, auch wenn man nur 2+2 rechnet, und .... sorry, aber das ist IMO wie schon gesagt totaler unfug.
Nein, ist es nicht. Wieso nimmt man den Python, PHP oder Java? Weil man eben GC, Exceptions, dynamic dispatch oder was anderes braucht. Diese Microbanchmakts gehen doch alle an der Realität vorbei und sind deswegen vollkommen nutzlos.
Wenn du nur 2+2 ausrechnen willst, dann nimm Assembler oder gleich Maschinensprache, optimiert für eine CPU und freu dich, dass es unter xx ms berechnet wird.
-
Wenn ich quicksort in C und Java vergleichen will brauch ich doch keinen GC! Was soll der Unsinn?
-
Tyrdal schrieb:
Wenn ich quicksort in C und Java vergleichen will brauch ich doch keinen GC! Was soll der Unsinn?
Und vorher kommen deine Daten zum sortieren? Die fallen wohl vom Himmel.
-
Und was bringt Dir solch ein Vergleich am Ende, ausser dass Du dann weisst, welche Sprache am schnellsten mit Quicksort sortiert?
-
Wenn mein Urlaub vorbei ist, werde ich mich wieder einem kleinen Optimierungsproblem widmen. Kern dieses Optimierungsproblems ist ein kleines (definitiv weniger komplex als quicksort) physikalisches Modell, das für die Fitnessfunktion berechnet werden muss. Das Modell ist gegenwärtig in Simulink implementiert. Die Laufzeit des Modells in dieser Implementierung und den gewählten Messdaten liegt bei ~30s. Um ein ordentliches Ergebnis zu bekommen, muss die Fitnessfunktion (und damit das Modell) rund 500 mal berechnet werden. Das sind ~4,2h, für nur einen Testdatensatz. Ich weiss, dass ich das Modell auch in C formulieren und so in Matlab einbinden kann. Damit werde ich bestimmt Faktor 50 rausholen können. Die gesamte Laufzeit also auf ~5min reduzieren.
Ich finde schon, dass mir der Vergleich was bringt.
-
DEvent schrieb:
Wenn ich nur "code-ausführungsgeschwindigeit" brauche, dann nehme ich doch gleich Maschinensprache, optimiert für eine spezielle CPU.
es geht doch garnicht so sher ums brauchen, nur um den aha-effekt. es gibt viele, die denken, java wäre *immer saulangsam* (weil es interpretiert wird, weil es in einer VM läuft usw.). mit solchen versuchen können sie sich vom gegenteil überzeugen, nämlich dass unter günstigen bedingungen (normaler PC mit genügend speicher) Java-code nur ein ganz kleines bisschen langsamer ist als C.
-
Ein ganz kleines Bisschen langsamer? Zwischen 502ms und 779ms liegen 55%, das ist mehr als ein ganz kleines Bisschen.
-
@fricky schrieb:
Ein ganz kleines Bisschen langsamer? Zwischen 502ms und 779ms liegen 55%, das ist mehr als ein ganz kleines Bisschen.
naja, aber die schleife lief 10 mio. mal durch, d.h. ein fak()-funktionsaufruf war im schnitt unter Java bloss ~20ns langsamer als unter C. und beachte auch tobikings ergebnis, bei dem Java und verschiedene C-compiler fast gleich schnell waren. ich sag' doch auch nicht, dass Java für rechenintensive anwendungen das optimum ist, sondern nur dass es schneller ist, als viele glauben.
-
;fricky schrieb:
DEvent schrieb:
Wenn ich nur "code-ausführungsgeschwindigeit" brauche, dann nehme ich doch gleich Maschinensprache, optimiert für eine spezielle CPU.
es geht doch garnicht so sher ums brauchen, nur um den aha-effekt. es gibt viele, die denken, java wäre *immer saulangsam* (weil es interpretiert wird, weil es in einer VM läuft usw.). mit solchen versuchen können sie sich vom gegenteil überzeugen, nämlich dass unter günstigen bedingungen (normaler PC mit genügend speicher) Java-code nur ein ganz kleines bisschen langsamer ist als C.
Wobei Du Dir da auch zumindest bei den genannten Beispielen in die eigene Tasche lügst weil Du die Laufzeit der GC komplett aussen vorläßt.
GC verzerrt die Meßergebnisse, weil ein Teil der Arbeit die bei C "synchron" passiert (malloc/free) bei Java "asynchron" passiert. ZUgegeben, daß ist ja gerade einer der Vorteile einer GC, aber bei einem Benchmark sollte man fairerweise auch das ganze Programm benchen und nicht nur den Teil der einem grad in die Argumentation passt... Sprich man sollte die Laufzeit der GC mitmessen und dann vergleichen. Bzw, bench das Programm komplett von Anfang bis Ende (inklusive GC-Run zum aufräumen) und vergleich dann mal.
Um es vorwegzunehmen, klar kann eine (gute) GC die "gefühlte" Performances eines Programmes deutlich verbessern, weil die Anforderung von Speicher sehr schnell geht, wodurch das Programm nicht darauf warten muß. Dafür wird der aufwendige Teil der GC idealerweise in idle-Zeiten des Programms verlagert. Das funktioniert aber auch nur solange, wie man idle-Zeiten hat, bzw. den Luxus mit der GC auf die nächste idle-Zeit warten zu können. Ist das nicht der Fall kann eine gestresste Speicherverwaltung mit GC schnell zum Performance-Killer werden...
-
loks schrieb:
Wobei Du Dir da auch zumindest bei den genannten Beispielen in die eigene Tasche lügst weil Du die Laufzeit der GC komplett aussen vorläßt.
nö. ist doch gut, dass der testcode den GC nicht beschäftigt. getestet wird nur das fundamentalste, funktionsaufrufe, schleifen und ein bisschen rechnen mit integern. wenn das zu langsam wäre, wär alles andere auch zu langsam. GC vs. malloc kann man ja separat testen wenn man will. obwohl's eigentlich nicht nötig ist. es ist ja allgemein bekannt, dass malloc/free (für c++ler: new/delete/delete[]) lahme krücken sind.
-
GC vs. malloc kann man ja separat testen wenn man will. obwohl's eigentlich nicht nötig ist. es ist ja allgemein bekannt, dass malloc/free (für c++ler: new/delete/delete[]) lahme krücken sind.
Kann behoben werden, indem man sich seinen eigenen Speichermanager schreibt. Auch sind es keine lahmen Kruecken, sondern sind optimiert fuer die Anforderung von viel Speicher. Im Vergleich dazu sind Objekte mit ihren 60 Byte eher sehr klein.
-
knivil schrieb:
Auch sind es keine lahmen Kruecken, sondern sind optimiert fuer die Anforderung von viel Speicher.
optimiert? ja, so kann man's auch nennen *fg*, einmal den ganzen speicher anfordern, dann sind sie natürlich nicht mehr lahm, weil ein zweiter aufruf hinfällig wäre, ne? im ernst: ich würde lieber systemfunktionen nehmen (sbrk bei unuxoiden bzw. VirtualAlloc u.ä. unter windoof). *die* sind wenigstens wirklich optimiert für grosse speichermengen. gängige implementationen von malloc/free (und ihre heimlichen c++-wrapper new/delete[]) müssen sich durch verkettete listen hangeln, manchmal listenelemente umsortieren und so. das ist schon eine ziemlich behäbige angelegenheit.
-
Bei fak() wird noch nichteinmal viel herumgerechnet, das sind zwei bedingte Sprünge und ein Aufruf, und trotzdem ist Java langsamer. D
ie 55% bleiben, ob das jetzt auf Ebene von Nano- oder Millisekunden ausgedrückt wird ist dabei nicht relevant.
-
Da uns alle Benchmarks zeigen, dass Java und C annähernd gleich schnell sind, aber fast alle Realworld-Javaprogramme deutlich langsamer laufen, müsse die meisten Javaprogrammierer Schnarchzapfen sein.
-
@fricky schrieb:
Bei fak() wird noch nichteinmal viel herumgerechnet, das sind zwei bedingte Sprünge und ein Aufruf, und trotzdem ist Java langsamer. D
ie 55% bleiben, ob das jetzt auf Ebene von Nano- oder Millisekunden ausgedrückt wird ist dabei nicht relevant.klar ist java im durchschnitt langsamer als C. ich hab doch nie was gegenteiliges behauptet. aber dafür, dass alles in einem 'managed environment' läuft, ist es trotzdem überraschend schnell. vergleichs mal mit anderen interpretierten sprachen, Java wird dabei ziemlich gut abschneiden.
Résumé schrieb:
Da uns alle Benchmarks zeigen, dass Java und C annähernd gleich schnell sind, aber fast alle Realworld-Javaprogramme deutlich langsamer laufen, müsse die meisten Javaprogrammierer Schnarchzapfen sein.
nee, erstmal gibts in Java viele performance-fussangeln (da sind ganze bücher drüber geschrieben worden, wie man sowas vermeiden kann) und zweitens, spielt langsamkeit an gewissen stellen oft einfach keine rolle. dafür hat man z.b. den vorteil, dass die programme sehr robust sind.
