Java vs. C. Performance-Vergleich
-
Icematix schrieb:
;fricky schrieb:
Icematix schrieb:
...dabei kannst du so ziemlich alle Java-Konstrukte nachbauen.
dann klick mal auf den link von byto. viel spass beim nachbauen *fg*
Ich bezog mich nicht auf Optimierungen, sondern Sachen wie zb den Garbage Collector.
naja, selbst das dürfte nicht so einfach sein (ein spezieller heap, gc_malloc statt malloc und ein hintergrund-thread als müllsamler müssten her). aber ich finde, in C macht ein GC meistens nicht so viel sinn, dafür ist C einfach zu 'low-levelig'. und wenn man ein programm machen will, dass von garbage collection und OOP profitiert, wird man wohl kaum C nehmen.
byto schrieb:
Deswegen sind grade solche Microbenchmarks ja total dämlich. Denn sie berücksichtigen nicht alle Stärken der getesteten Sprachen, sondern beschränken sich auf einen gemeinsamen Nenner.
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.
-
datengetriebenen Anwendungsfällen
Was sind datengetriebene Anwendungsfaelle?
-
Damit meine ich Anwendungen, deren primärer Zweck die Verwaltung größerer strukturierter Datenmengen ist.
-
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.
