Java vs. C. Performance-Vergleich
-
Solche Microbenchmarks sind doch sinnlos. Erstrecht wenn man sie so stümperhaft ausführt :).
Aber wenn schon, dann http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all
-
SideWinder schrieb:
[...] Ist es *fix*, dass er volatile niemals nie optimieren darf in Java?
Nö, steht nirgendwo das er das nicht darf. Volatile wird eigentlich auch nur
für Multithreading verwendet und dort muss dann garantiert sein das die als
volatile gekennzeichnete Variable für alle Threads sichtbar ist und einen
konsistenten Wert enthält. Kann gut sein, das wenn die Variable nur im main-
Thread deklariert ist und nirgendwo anders verwendet wird, der Compiler das
wegoptimiert.Java-Programme kann man im Allgemeinen nicht so benchmarken wie C-Programme.
Die ersten drei einfachen Sachen sind zuerst mit dem javac und optimize flag
kompilieren. Eclipse hat z.B. seinen eigenen Builder.
Die JVM mit -server starten, für eine noch strengere Codeoptimierung während
der Laufzeit.
Und als dritte Maßnahme nie benchmarken ohne Warm-up (ein paar Minuten), damit
der dynamische Compiler eine Chance hat VOR dem eigentlichen Benchmark zu
optimieren oder gar Code in nativen Maschinencode umzuwandeln und nicht während
des Benchmarks.
Desweiteren muss man auch schauen was der GC so treibt und vielleicht den
Speicher erhöhen damit er nicht während des Benchmarks aktiv wird.Das größte Problem beim benchmarken ist sowieso zu verhindern das der
Benchmarkcode als "toter Code" erkannt wird.
-
rüdiger schrieb:
Solche Microbenchmarks sind doch sinnlos. Erstrecht wenn man sie so stümperhaft ausführt.
garnicht, die zeigen zumindest, dass der zeitliche unterschied bei reiner codeausführung zwischen Java und C viel kleiner ist, als die meisten glauben. C ist zwar schneller, aber nicht viel. (die von dir verlinkte seite zeigt das ja auch).
-
garnicht ... zwischen Java und C viel kleiner ... verlinkte seite zeigt das ja auch
Mir zeigt diese Seite in erster Linie, dass Java im Vergleich zu C++ abkackt.
-
und...wtf im Vergleich zu Haskell!
Das hätte ich ja nie gedacht. Krasse Sache das.
-
knivil schrieb:
garnicht ... zwischen Java und C viel kleiner ... verlinkte seite zeigt das ja auch
Mir zeigt diese Seite in erster Linie, dass Java im Vergleich zu C++ abkackt.
...und machmal gewinnt sogar Javascript *fg*.
bei den zweifelhaften tests auf der seite sind überall noch ausgaberoutinen (printf usw.) mit drin, die das ergebnis verfälschen können. die haben wir hier wenigstens rausgeschmissen. bei uns stört nur noch das multitasking des OS.
-
Der Vergleich bringt doch nichts. Ein interpretierter Code und sei es der feinste Bytecode in einer hochoptimierten Runtime wird niemals die Performance von Nativ-Code erreichen. Und was von dieser physikalischen Hürde übrig bleibt, liegt im Geschick des Programmierers.
-
Cpp_Junky schrieb:
Der Vergleich bringt doch nichts. Ein interpretierter Code und sei es der feinste Bytecode in einer hochoptimierten Runtime wird niemals die Performance von Nativ-Code erreichen.
^^deswegen macht Java ja auch aus zeitkritischen abschnitten maschinencode (und hat dabei mehr optimierungsmöglichkeiten als ein C compiler, dessen output statisch ist) http://en.wikipedia.org/wiki/Adaptive_optimization
gut gemachte C-programme wird java geschwindigkeitsmässig wohl trotzdem nie überholen, aber möglichst nah ranzukommen ist ja auch schon was wert.
-
Cpp_Junky schrieb:
Der Vergleich bringt doch nichts. Ein interpretierter Code und sei es der feinste Bytecode in einer hochoptimierten Runtime wird niemals die Performance von Nativ-Code erreichen. Und was von dieser physikalischen Hürde übrig bleibt, liegt im Geschick des Programmierers.
Doch, denn:
[...]adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion to decrease context switching.
Siehe auch: http://en.wikipedia.org/wiki/Java_performance#Other_optimization_techniques
-
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.
-
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.
Das wäre so richtig sinnlos. Es klingt so als würde man C und Lisp nur vergleichen können wenn man in C alles wie in Lisp machen würde. Dass das totaler Schwachsinn ist hätte sogar dir auffallen müssen...
Ein sinnvoller Vergleich von zwei Sprachen ist imho nur möglich wenn das gleiche Problem mit den gleichen Algorithmen bearbeitet wird, aber in einem für die jeweiligen Sprachen üblichen/guten Stil. Das ist wohl auch der Grund warum solche Vergleiche auch nur auf minimale Probleme anwendbar sind, da man dies bei größeren Programmen kaum noch garantieren kann.
-
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.
C++ ist performanter als Java, dabei kannst du so ziemlich alle Java-Konstrukte nachbauen.
-
Es stimmt aber durchaus, dass selbst der schnellst C-Code langsamer werden würde, wenn man ihn so programmiert, dass er z.B. unter keinen Umständen jemals auf nicht allozierten Speicher zugreifen kann.
-
Icematix schrieb:
...dabei kannst du so ziemlich alle Java-Konstrukte nachbauen.
dann klick mal auf den link von byto. viel spass beim nachbauen *fg*
-
;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.
Das meinte ich:
Wenn du beide Sprachen schon vergleichen willst, dann bitte baue auch in C einen Exceptions, GC, Threads, OOP usw. usf. ein
-
Grade bei extrem datengetriebenen Anwendungsfällen sind OOP + der GC ja extrem hilfreich. Und dann gibts noch Anwendungsfälle, wo gegenteiliges der Fall ist.
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.
Das ist so als sage ich "ein Sportwagen ist besser als ein LKW, weil er schneller beschleunigt".
-
oder als wenn man sagt "ein Sportwagen ist schneller als ein LKW, weil die Benzinuhr schneller abläuft"
-
also "ein LKW schneller als ein Sportwagen", meinte ich jetzt.
-
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?