Java vs. C. Performance-Vergleich
-
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.
-
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"?
-
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
