Wie schnell das sein könnte ...

[elcaleuche]

... wenn es nicht in JAVA geschrieben wäre.

[Suven]

Immer dieses Java-Gebashe.. Gerade diese Software beweist doch, dass Java-Anwendnungen durchaus sehr sehr performant sein können.

[Ingwar]

Jetzt kann man das entkräften und sagen: es wäre deutlich schneller in kompiliertem C oder C++ Code, wobei ich für wieder 10 Leute finden werde die mir sagen, dass C++ langsamer sein wird. :)

[kelox]

Was mich mal interessieren würde, welche Optimierungen die JVM zur Laufzeit vornimmt? Kennt da vielleicht jemand eine detailierte Beschreibung?

Bezüglich Java, ich denke, dass Java schon langsamer ist, jedoch wird der Unterschied nicht so groß sein. Der Vorteil von Java ist wahrscheinlich, dass es einfacher wartbar ist.

[Nephtys]

Ingwar schrieb:
--------------------------------------------------------------------------------
> Jetzt kann man das entkräften und sagen: es wäre deutlich schneller in
> kompiliertem C oder C++ Code
Auch eine haltlose Behauptung. Die Geschwindigkeit von C/C++ Code ist stark abhängig von der Source und dessen Qualität.
Bei Java sind dagegen auch mittelmäßig optimierte Programme schon 'schnell'.

PS: Java ist übrigens wirklich langsamer nur dann, wenn die VM verlassen werden muss. Das ist auch der Fall bei C, aber bei C laufen System-Calls eben schneller... und dank Zeiger kann man Compiler und OS komplett umgehen.

[Suven]

Es kommt immer darauf an was man macht.

JIT-Compilier haben natürlich einen gewissen Mehraufwand durch das zusätzliche compilieren, dafür auch andere Vorteile die das wett machen. Nicht umsonst ist Java-Script mitlerweile auch so verdammt rasant und beliebt.

Aber um ein Beispiel für Java zu geben: Wenn Halbkonstanten erst zur Laufzeit bekannt werden, dann aber Sprünge von ihnen abhängen, wird ein Flush der CPU-Pipeline durch falsche Sprungvorhersage vermieden. Ein JIT-Compiliat kann dann also viel effizienter sein, als das vorher je möglich gewesen wäre: http://de.wikipedia.org/wiki/Java_Virtual_Machine#Dynamische_Optimierung

Edit:\ Übrigens kann man mit ein wenig Kreativität auf viele solcher Beispiele kommen, in denen einen das Laufzeitwissen helfen kann. Es könnte durchaus auch Dead-Code geben, der über eine Bedingung erreicht werden könnte, den man aber, sobald man weiß das die Bedingung nie zutreffen wird, dann weder compilieren, noch im Programmstack, noch sonst wo haben muss. Man kann sich sogar die zukünftige Auswertung der Bedingung sparen.



1 mal bearbeitet, zuletzt am 07.11.13 12:00 durch Suven.

[Ingwar]

Meine Aussage war eher allgemeiner gehalten. Natürlich kommt es auch stark auf die Quelle (Code) an, wenn ich miserablen und unperformanten Code in C nehme, oder hochoptimierten Java Code kann die Sache wiederum anders ausgehen.

[Suven]

Mein Punkt ist, dass es keine allgemeine Wahrheit gibt ;)

Es kommt nicht nur auf den Code, sondern vielmehr auf das zu lösende Problem an.

[Trolltech]

Der MapReduce Algorithmus ist in den gängigen Implementierungen in Java um einiges schneller als in C++... Google dürfte genügends Benchmarks ausspucken.

Aber interessant wie viele immer auf die Java-Trolle einsteigen. Als ich das 1. Mal Java im Artikel gelesen habe, war mir schon klar, dass es hierzu wieder einen Thread gibt.



1 mal bearbeitet, zuletzt am 07.11.13 12:37 durch Trolltech.

[twothe]

Das Problem ist eigentlich fast immer der Code den die Programmierer schreiben und nicht Java oder C/C++. Ich hab schon so viel Grütze gesehen, wer mal wirklich Schmerzen haben will: einfach auf Stackoverflow die Java-Fragen durchblättern.

Beliebtester Fehler: Erstmal die Standard-Libs nachprogrammierern. Gerade in Java kommt dabei fast immer deutlich schlechterer und langsamerer Code bei raus, da die Libs von herausragender Qualität sind. Bestes Beispiel sind hier die Apache-Common Libs, die teilweise einfach nur sinnlose Wrapper-Klassen oder miese Neuimplementationen der bekannten Funktionen sind.

Zweit-beliebtester Fehler: "Ich hab keine Ahnung aber tipp mal so rum bis es läuft..." Wenn man keine Ahnung hat, erst mal informieren. Ich hab schon genügend Profis gesehen, die es eigentlich können müssten, aber anstatt das sie zugeben das sie eine Ahnungslücke haben, wird stattdessen einfach wild geraten, und das Ergebnis reicht bestenfalls noch für die Mülltonne.

Der einzige Vorteil den C/C++ hier hat, ist das der gcc einiges mehr an Performance rausholen kann, als das dem JIT überhaupt möglich ist. Das liegt aber weniger an der Qualität der Compiler, als an der Tatsache das Java viel häufiger ganze Code-Bausteine liefert, die - falsch zusammen gebaut - einfach nicht optimierbar sind. Wer eben ein großes Synchronized um den ganzen Code schnallt, muss sich nicht wundern, wenn die Thread-Performance dann im Keller ist.

[a user]

Trolltech schrieb:
--------------------------------------------------------------------------------
> Der MapReduce Algorithmus ist in den gängigen Implementierungen in Java um
> einiges schneller als in C++... Google dürfte genügends Benchmarks
> ausspucken.
diese aussage ist so schlichtweg quatsch und völlig unmöglich.
java kann, richtig eingesetzt, bei vielen problemen mit der performance von c oder c++ mithalten. aber schneller kann es unmöglich sein. die javavm ist in c++ geschrieben ;)

oder auch anders: was java nativ übersetzten kann, kann c++ sowieso.

d.h. c++ im allgemeinen ist IMMER mindestens so schnell wie jedes java programm.

>
> Aber interessant wie viele immer auf die Java-Trolle einsteigen.
was bist du? ein java oder ein c++ troll?
> Als ich
> das 1. Mal Java im Artikel gelesen habe, war mir schon klar, dass es hierzu
> wieder einen Thread gibt.
mir auch.

das über die performance von java oft aus falschen gründen geschimpft wird kommt ja verdammt oft vor, aber fast genau so oft werden die performancelimitierungen von java genauso ignoriert. und davon hat java ne menge.

[dabbes]

die Quellen sind OpenSource, du kannst gerne loslegen.

Oder konvertier die Daten nach C++ und kompiliere das ganze.
Dann gib uns deine Benchmarkergebnisse.

Wenn die Java-Applikation geladen im Speicher ist, dann besteht 0 Unterschied zu einem Programm in einer x-beliebigen anderen Sprache, da gibts keine Performanceunterschiede.

[Suven]

Das ist schlicht falsch. Einige Gründe habe ich genannt. Andere hier:
http://de.wikipedia.org/wiki/Just-in-time-Kompilierung#Optimierungsm.C3.B6glichkeiten

Natürlich ist es ansonsten schneller, wenn das Programm vorkompiliert wäre, keine Frage. Aber generalisierte Aussagen zu treffen wie A ist immer besser als B sind meist keine gute Idee.. Solche Aussagen treffen solange zu, bis einer einen Gedanken hat auf den man vorher nicht kam.

[schap23]

Unnötige Locks werden aber häufig von der JVM entfernt. Die Performance von Javacode wird umso besser, je mehr Daten er verarbeitet, da die JVM kritische Codestellen erkennt und weiter optimiert.

Der große Nachteil daran für den Entwickler ist, daß es unglaublich schwierig ist, die Performance von Javacode vernünftig zu messen. Wenn ich denselben Code bei einer frisch gestarteten Anwendung messe oder nachdem sie einige Male gelaufen ist, bekomme ich deutlich unterschiedliche Ergebnisse.

Wichtig ist es natürlich auch die JVM mit den richtigen Parametern zu starten. Meistens kann man zwischen Server und Client Betrieb unterscheiden, wobei ersterer mehr optimiert und zweiterer schneller startet. Und dann muß der richtige GC gewählt werden.

Im übrigen ist die JVM in C geschrieben, so daß ein gewiefter C-Programmierer alle Tricks auch in sein Programm einbauen kann. Viel Spaß dabei.

[YoungManKlaus]

Die Sprache ist relativ egal (und außerdem ist wennschon die VM schuld, die man ja austauschen und/oder optimieren kann).
Der Algorithmus ist viel entscheidender - denn wenn du n^2 Ausführungszeit hast hilft dir die performanteste Sprache nix.

[YoungManKlaus]

> diese aussage ist so schlichtweg quatsch und völlig unmöglich.
> java kann, richtig eingesetzt, bei vielen problemen mit der performance von
> c oder c++ mithalten. aber schneller kann es unmöglich sein. die javavm ist
> in c++ geschrieben ;)
Meeeep, 5, setzen. Einfachstes Beispiel: der JIT-Compiler wirft dir wahrscheinlich eine Schleife die nichts tut einfach weg (so geschehen bei einem javascript-benchmark, auch wenn ich mich nicht mehr erinnere welcher das war). Ein compiler macht das wahrscheinlich ohne extra angeführte Optimierungen nicht.

[a user]

Suven schrieb:
--------------------------------------------------------------------------------
> Das ist schlicht falsch. Einige Gründe habe ich genannt. Andere hier:
> de.wikipedia.org#Optimierungsm.C3.B6glichkeiten
entweder du hast meinen post nicht verstanden oder den link von dir nicht.
zeig mir bitte, wie java code schneller als c++ code seien kann unter der vorrasusetzung, dass beide optimal programmiert wurden.

[Morpf]

Wenn ich in C mit nem mutex nen riesigen Bereich abtrenne verliere ich da genau so Performance im Multithreading. Das ist dann einfach Dummheit des Programmierers und kein Problem der Sprache.

Bitte erkläre aber mal, warum gcc per Definition schnelleren Code liefern kann als ein JIT-Compiler. Potentiell kann der JIT-Compiler Laufzeitinformationen verwenden, die der gcc einfach nicht hat.

[AwayFromTheSun82]

Das ist so leider auch falsch. Nur weil die JVM (teilweise) in C++ geschrieben ist, kann der JIT compiler sehr wohl schnelleren Code erzeugen.

Man muss sich das ganze so vor Augen führen: Ein C(++) Compiler liest C Code, erzeugt eine Zwischendarstellung, lässt Optimierungen springen und erzeugt dann Maschinen-Code.

Der Java-Compiler liest Java-Code, erzeugt dabei eine Zwischendarstellung (ein .class File). Die JVM lädt das und kann es auch sofort ausführen (langsam). Nach einer gewissen Zeit springt der JIT an, nimmt die Zwischendarstellung, lässt Optimierungen drüber laufen und erzeugt dann Maschine-Code der ausgeführt wird. Im Großen und Ganzen ist der Prozess also gleich. Der Unterschied ist, dass Java langsamer sein KANN, wenn man Objekt-Orientiert programmiert und nicht immer genau klar ist welche Methode aufgerufen wird (ist bei allen OOP Sprachen so). Die Auswahl der passenden Methode kostet Zeit. Auf der anderen Seite kann der JIT teilweise Sachen besser optimieren, da er den Code zur Laufzeit beobachtet und bessere Annahmen zur Sprungvorhersage etc. machen kann.

Es ist also völliger Quark zu sagen, das C, C++ oder Java schneller sind - es kommt immer auf den Einzelfall an.

[a user]

AwayFromTheSun82 schrieb:
--------------------------------------------------------------------------------
> Das ist so leider auch falsch. Nur weil die JVM (teilweise) in C++
> geschrieben ist, kann der JIT compiler sehr wohl schnelleren Code
> erzeugen.
du vergleichst hier compiler mit einander!

es geht nicht darum, ob ein c++ compiler langsameren oder schnelleren code generieren kann als ein JIT compiler für JAVAVM.

das hat wenig mit dem vergleich zwischen c++ und java auf einer JVM zu tun.