Java vs. C. Performance-Vergleich
-
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.
-
Den schnellsten Algorithmus wählt der Programmierer die beste Anpassung auf die jeweilige Umgebung der JIT, denn das kann bei zunehmender Komplexität kein Programmierer mehr für alles Umgebungen wirtschaftlich hin bekommen.
-
Den schnellsten Algorithmus wählt der Programmierer die beste Anpassung auf die jeweilige Umgebung der COMPILER
-
Trollalarm
-
donkong schrieb:
Den schnellsten Algorithmus wählt der Programmierer die beste Anpassung auf die jeweilige Umgebung der COMPILER
Weil auch für jede Umgebung neu kompiliert, gelle?
-
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.
Ein Viertel ist absolut unterirdisch und für HPC total ungeeignet.