Java vs. C. Performance-Vergleich
-
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^^
-
So lange da nicht mit Header- und Implementierungsdateien und mit Makros für die verschiedenen Compiler und Plattformen gewurstelt werden muss geht das noch in Ordnung.
-
najasolala schrieb:
So lange da nicht mit Header- und Implementierungsdateien und mit Makros für die verschiedenen Compiler und Plattformen gewurstelt werden muss geht das noch in Ordnung.
und denkst in java wird gezaubert? die c performance kommt größtenteils daher, dass viele std. lib implementationen in assembler programmiert sind. das ist nicht notwendig bingt aber geschwindigkeit. aber ihr in java versteckt euch lieber hinter ner 50mb runtime nach dem motto was ich nicht weiß macht mich nicht heiß...
@edit: und das schlimme, ihr denkt dann noch es würde nicht existieren.
-
SunflowRay schrieb:
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
20 % ist kein großer Unterschied??????
-
dloooooooooooooool schrieb:
SunflowRay schrieb:
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
20 % ist kein großer Unterschied??????
Nö eigentlich nicht, aber in deinem Alter ist ja auch noch jeder Geburtstag was besonderes...
Was mich wundert, ist warum hier jemand nach fast einem Jahr noch antwortet und warum der Thread überhaupt noch offen ist
-
nöööööö denn 20% Unterschied haste heute schon bei unterschiedlichen CPU caches aus der gleichen Prozessorfamilie. Wenn man hochoptimiert mit C++ arbeitet müsste jedes Programm für jede unterschiedlich CPU neu kompiliert werden um wirklich den großen Unterschied zu bewirken, meist sind sie aber gerade mal für 386 oder 686 kompiliert und sowas könnte ein JIT in Zukunft auf jeden Fall schlagen und das ohne 100 C++ Tricks und Regeln anwenden zu müssen.
