Java vs. C. Performance-Vergleich
-
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.
-
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.
-
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 JavaQuelle: 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, ...)
-
Mist. Was gabs denn zu gewinnen?
-
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.
-
noobLolo schrieb:
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.
In der Java-Standardbibliothek sind an einigen Stellen tatsächlich Dinge über nativen Code implementiert. Allerdings ist man davon in den letzten Jahren abgekommen. Die JVM hat halt Fortschritte gemacht, so dass es sich oft nicht mehr lohnt, nativen Code für irgendetwas zu nehmen. Es ist inzwischen oft so, dass eine reine Java-Implementierung schneller als ein entsprechender Aufruf einer nativen Funktion ist. Das liegt nicht daran, dass nativer Code langsam ist, sondern daran, dass so ein Aufruf aus einem Javaprogramm heraus eben doch sehr viel Zeit kostet. Wenn dann in einer Funktion nicht so viel gemacht wird, dann überwiegen die Kosten für den Aufruf und eine reine Java-Implementierung ist besser.
-
noobLolo schrieb:
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.
das liest sich ja fast so, als wenn du traurig darüber wärst, dass man C zu 'ner low-level sprache 'degradiert' hat. keine angst, C ist in seinem einsatzgebiet nahezu unersetzbar. ich z.b. mag C sehr gern, aber Java auch.
-
-
knivil schrieb:
ich glaub nicht, dass er sandkörner zählen musste. dann schon eher diese vielen klammern seiner lieblings-programmiersprache *fg*
-
Der Raytracer Sunflow ist in der Javaversion gerade mal 20% langsamer also macht es auch bei rechenintensiven Aufgaben nicht immer einen großen Unterschied ob nun C/C++ oder Java.
http://strattonbrazil.blogspot.com/2008/11/sunflow-java-ray-tracer.html
-
Wenn man in c++ wie in java Code schreibt, dann kann man nicht erwarten schneller zu sein. Wenn man in c++ optimierten Code schreibt, dann ist er nicht mehr zu java vergleichbar.
Am Ende kommt es auf die Erfahrung an, jemand der seinen GCC gut kennt wird dem Code vorwerfen den der Compiler gut verdaut, dieser kann dem VC sehr schlecht bekommen, und umgekehrt. Trotz der selben Sprache!
Verschiedene Sprachen und Compiler kann man noch schlechter vergleichen, schon die CPU auf der man benchmarkt kann den ganzen unterschied ausmachen. i7 als beispiel haben Optimierungen um V-Table Calls wie eine normalen Call zu durchlaufen, alle AMD cpus bis heute haben die selben Kosten wie bei einem Branch-Miss.Schreibst du also einen Raytracer der Objektorientiert bei jedem Hit die Materialklasse anspringt und diese das BRDF und PDF berechnet, kannst du in c++ 4mal langsammer sein als wenn du 16Pixel in einem batch hast und ohne branch ein komplexereres BRDF benutzt was das branching erspart weil es das Material-Setup mittels Parametern erledigt, und trotz mehr Rechenaufwand.
Ein Freund von mir studiert quasi Raytracing in Utah und jedes Jahr am Anfang gibt es Gruppen die den selben Raytracer schreiben sollen und jeder darf entscheiden zu welcher Gruppe (basierend auf der verwendeten Sprache) er teilnehmen will. Jedes Jahr liegt c knapp vor c++, ich hatte letztes Jahr das c++ Team bei der Analyse unterstützt und aufgrund von ein paar returns von Temporaries war c++ nicht schneller zu bekommen als c(z.b. operator* vs Dot(dstReal,srcVecA,srcVecB); ), ohne dass man auf c-style gewechselt wäre, weil gcc das schlichweg nicht wahrhaben wollte, dass es kein aliasing gibt und ein direktes Assignment erlaubt ist.
Java und C# waren um einiges abgeschlagen.
Aber bei den nächsten Assignments haben doch die meisten java und c# benutzt. Mein Freund hatte dann auch seinen Raytracer auf c# portiert und "beautified" wodurch er nur noch 25% der Geschwindigkeit hatte (Octree-Traversal hatte da besonders geschwindigkeit verloren), aber Geschwindigkeit war bei kaum jemanden ein Argument nicht die Sprache zu nutzen in der er sich am besten zurecht fand.
Studenten typisches exzessives OOP/RTTI war angesagter.Deswegen, ja im normalfall ist assembler schneller als c, C ist schneller als c++, c++ ist schneller als C#/Java/VisualBasic und PSP ist schneller als DS und PS3 ist schneller als Wii und Ferrari ist schneller als ein Smart.
-
je höher die sprache desto höher die abstraktion von dem darunterliegendem system => bedeutet in vielen fällen weniger kenntnis von den der abstraktion zugrunde liegenden algorithmen => langsamere software
-
Der JIT hat da gerade mal an der Oberfläche gkratzt da wird in der Richtung noch einiges passieren. Von der Theorie her könnte ein JIT jedes statische Kompiliat, solange es nicht nur auf eine CPU hin hochoptimiert wurde, schlagen. Da er das umliegende System zur Laufzeit erfassen kann und alles nutzen kann was die CPUs hergeben.
Wenn viel Speicher ins Spiel kommt ist ein gescheiter GC eh besser gegen Fragmentierung.
-
schnellschneller schrieb:
Von der Theorie her könnte ein JIT jedes statische Kompiliat, solange es nicht nur auf eine CPU hin hochoptimiert wurde, schlagen. Da er das umliegende System zur Laufzeit erfassen kann und alles nutzen kann was die CPUs hergeben.
In theory, there is no difference between theory and practice. But, in practice, there is.
schnellschneller schrieb:
Wenn viel Speicher ins Spiel kommt ist ein gescheiter GC eh besser gegen Fragmentierung.
kommt darauf an in welcher blockgröße du dir das vom os besorgst. imho wird die arbeit mehrfach gemacht. einmal vom os und dann von der clib/java mit dem unterschied dass ich auf das java teil nicht verzichten kann weil es bestandteil der sprache ist.
-
Ein viertel der Geschwindigkeit bei einer sehr rechenintensiven Anwendung ist schon einmal nicht schlecht wenn man bedenkt dass dadurch der ganze hässliche C++ mit all seinen Altlasten und Unannehmlichkeiten weg fällt und man sauberen und schön wartbaren Code erhält. Java wird ja auch nicht langsamer in Zukunft werden, sondern eher noch mehr aufholen.
-
nichtschlechtherrspecht schrieb:
Ein viertel der Geschwindigkeit bei einer sehr rechenintensiven Anwendung ist schon einmal nicht schlecht wenn man bedenkt dass dadurch der ganze hässliche C++ mit all seinen Altlasten und Unannehmlichkeiten weg fällt und man sauberen und schön wartbaren Code erhält. Java wird ja auch nicht langsamer in Zukunft werden, sondern eher noch mehr aufholen.
Java ist vermutlich grade dabei, Altlasten aufzubauen^^
