Java vs. C. Performance-Vergleich

Ein ganz kleines Bisschen langsamer? Zwischen 502ms und 779ms liegen 55%, das ist mehr als ein ganz kleines Bisschen.

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.

knivil

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.

Gregor

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.

Man muss halt die richtigen Dinge benchmarken. Dann kommt genau das raus, was man sehen möchte. Bei simplen Mikrobenchmarks, die nur ein bischen Numerik machen, gibt es eben nicht so große Unterschiede. Wenn Du einen Benchmark sehen möchtest, in dem Java wirklich schlecht abschneidet, dann überleg Dir mal, welche Performanceschwächen Java wohl hat.

Aber andererseits ist das ja eh alles irrelevant. Das einzig relevante ist, dass die Java-Toolchain haushoch überlegen ist. Das ist bei der Frage, welche Programmiersprache man einsetzt, eindeutig ein wesentlich bedeutenderer Faktor. :p

Verwechselt ihr hier nicht "Programmiersprachen" mit "Optimierfähigkeit des Compilers"?

rapso

dhfdhdhj schrieb:

Verwechselt ihr hier nicht "Programmiersprachen" mit "Optimierfähigkeit des Compilers"?

ich glaube entscheidender ist die optimierfaehigkeit des programmierers.

Ich kann mich nur immer wieder wiederholen:
Das lustige und traurige zugleich bei den benchmarks die (zumeist von anfaengern) angestellt werden ist, dass sie nicht die faehigkeiten von sprachen und compilern auf die probe stellen, sondern ihre eigenen blossstellen.

Die restlichen programmierer wissen mit der zeit was sache ist. Selbstverstaendlich ist assembler die sprache mit der man am schnellsten sein kann, c/c++ ist schneller als java und java schneller als lua. Aber nur aufgrund dessen zu entscheiden ist wirklich naiv. die meisten die von java auf c++ umsteigen schaffen es nichtmal die optimieroptionen der compiler einzuschalten weil sie garnichts davon wissen. vom optimalen code ganz zu schweigen, da wird der compiler im debug mode auch keine wunder bewirken.

Und was bringt es am ende einen aussagekraeftigen benchmark zu machen? vermutlich nichts.
- weil jeder sich an zwei fingern abzaehlen kann wie die performanceeigenschaften in bestimmen situationen sind (was braechte sonst ein benchmark den man nicht versteht?)
- weil niemand seinen webserver from scratch in assembler schreiben wird. und niemand seinen echtzeitraytracer (wenn ihm wirklich an geschwindigkeit gelegen ist) in lua.

Mehr als um sprachen sollte man sich um seine eigenen faehigkeiten kuemmern, und mit die wichtigste ist ohne befangenheit das beste tool zu nutzen was einem erlaubt sein ziel zu erreichen. wenn man mal eben was machen muss und man kennt sich mit dem optimalen weg nicht aus, dann nutzt man was man kann. und falls man laenger plant einer sache nachzugehen, sollte man den optimalen/gaengigen weg lernen.

byto

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.

Du kennst die meisten Java Programme? Respekt!

^^so ist es. deswegen sind programmiersprachen-geschwindigkeitstests jeder art auch wenig aussagekräftig, können im besten fall nur ganz grobe hinweise geben. und je umfangreicher eine software ist, desto mehr schwindet die bedeutung solcher tests. dann entscheidet nur noch die fähigkeit des programmierers.

byto

Java ist vor allem wegen JEE so weit verbreitet. Niemand kommt heutzutage noch auf die Idee, Client-Server-Datenbank Anwendungen in C zu schreiben. Auch wenn C in solchen Microbenchmarks besser abschneidet.

Bestes Beispiel ist Ebay:
- anfangs alles in Perl
- dann von Perl auf C/C++ migriert
- dann von C/C++ auf Java/C++ migriert
- heute gar kein C++ mehr, alles in Java

Quelle: http://highscalability.com/blog/2009/3/31/ebay-history-and-architecture.html

PS: Aber das ist ja nur "Webzeugs"...

Gregor, byto, ihr habt verloren. Bitte verzichtet auf eure Rückzugsgefechte (Toolchain, ebay, ...)

byto

Mist. Was gabs denn zu gewinnen?

hustbaer

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.

Das liegt am Framework. Man sehe sich bloss mal .NET GUIs an, da schlafen einem auch die Füsse ein. Trotz dem recht guten Optimizer und JITer des C# Compilers bzw. der .NET Runtime.

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.

endlich bringts mal einer auf den punkt

also ab seite 4 oder 5 dachte ich es wiederholen sich die posts, ich wollte nur mal einwerfen und zu überlegen geben wie java entwickelt ist bzw. in welcher sprache.

ist doch logisch das ein bytecode der eine c function aufruft nicht langsam ist, da ist doch der fuctions aufruf das kleinste problem, und die function ist dann eh in c... deswegen kommt die jvm ja auch gleich mit 50 mb im speicher daher weil es jede function schon fertig in c entwickelt mitbringt.

gut c zu können ist kein nachteil und lässt sich auch nicht mit solchen komischen benchmarks belegen, die ganze welt liebt java na dann entwickelt doch mit java, ist doch eine gängige entwicklung das das was früher high level sprachen waren low level sprachen werden, früher war c high level und assembler low level, heute ist c low level und java high level und morgen ist java low level und python o.ä. script sprachen high level das ist eine stetige entwicklung, aber wir wären doch keine software entwickler würden wir uns nicht täglich auf neue gegebenheiten einstellen.

ach für mich ists ok wenn alle java lernen und entwickeln, dann kann ich mich mit c um die java entwicklung kümmern

nur meine 5 cent

Jawa ist was für Weicheier die es nur schön einfach haben wollen. Aber tolle Programme wie wir sie mit C/C++ proggen kriegen die nicht hin. Die ganze „Jawa versus C“-Diskussion ist eine reine Neid-Diskussion. Es heißt immer „Jawa ist so... wie C“ dabei wird immer versucht Jawa auf die gleiche Stufe zustellen wie C. wenn Jawa so überlegen wäre, würde man erst gar keine Vergleiche mit C ziehen.
C ist nun mal das Original und Jawa der Abklatsch für Deppen.