Javas Hotspot schneller als C?

Ich lerne gerade C++ und interessiere mich aber auch für Java. Ist da was dran dass Java mit seinem Hotspot teilweise schneller sein kann als ein C Programm bei gleichem Algorithmus? Ich habe gelesen das man die FFT in Java schneller realisieren kann als in C.

Bitte keinen Flameware hier anfangen, vielleicht melden sich nur Leute die beide Sprachen kennen und auch mit arbeiten.

Siassei

Wie ist dein Name verehrter Herr?
Deine Weisheiten hast du evlt aus [url="Softwarerenderer in Java oder C++?"]http://www.c-plusplus.net/forum/viewtopic-var-t-is-274394.html[/url]

Was tut mein Name zu Sache. Ich hätte gerne eine Antwort, wenn du sie nicht weißt dann antworte auch nicht. Ich frage halt lieber nach als irgendwelchen Blogs zu glauben. Wenn du hier noch rumtrollen willst dann lass es lieber ich hätte gerne was von den Profis dazu gehört.

knivil

Nein!

Bitte keinen Flameware hier anfangen ... du hier noch rumtrollen willst dann

Genau so fangt man einen Flamewar an, indem man selbst flamed. Zumindest ist Siassei registriert und deine Frage ist eben eine typische Trollfrage.

Die Antwort auf die Frage lautet wahrscheinlich einfach: Ja, für eine Plattform optimierter Code ist meist schneller als nicht optimierter.

Beispiel: Du nimmst deinen FFT-Algorithmus und übersetzt ihn einmal mit C z.B. mit 80386 als Zielsystem und einmal mit Java.

Dann lässt du das auf einem hypermodernen Core i-xxx laufen. Das C-Programm besteht aus festen Anweisung und kann aus den Features des neueren Prozessors keine Vorteile ziehen. Eine Runtime, die Optimierung betreibt, kann einmal den erweiterten Befehlssatz der CPU nutzen und Codeteile so verschieben, dass die Architektur optimal ausgenutzt werden kann.

Wenn man jetzt aber hergeht und das C-Programm neu übersetzt z.B. mit den aktuellen Intel-Compiler mit den optimalen Einstellungen für diese CPU und dann noch mittels Profile Guided Optimisation den Programmlauf analysiert und den Code danach optimal neu anordnet, dann ist das vermutlich noch ein ganzes Stück schneller.

Fazit: C ist lansamer als Java, aber C ist schneller als Java.

Danke, das ist doch mal eine vernünftige Antwort und erklärt warum Java manchmal schneller ist als C. Wer hat schon immer eine auf das jeweilige System optimierte Version seiner Software installiert?

Gregor

nn schrieb:

Dann lässt du das auf einem hypermodernen Core i-xxx laufen. Das C-Programm besteht aus festen Anweisung und kann aus den Features des neueren Prozessors keine Vorteile ziehen. Eine Runtime, die Optimierung betreibt, kann einmal den erweiterten Befehlssatz der CPU nutzen und Codeteile so verschieben, dass die Architektur optimal ausgenutzt werden kann.

Das halte ich für eine Legende. Mir ist zumindest nicht bekannt, dass es JVMs gibt, die derartige Optimierungen betreiben. Auch wenn man sich in der Theorie vorstellt, dass dies möglich ist. Ich denke, der entscheidende Punkt ist ein ganz anderer:

Java ist eine recht einfache Sprache. Man hat dort wenige Stellschrauben und kann relativ leicht überblicken, warum es an einer Stelle Performanceprobleme geben könnte. Wenn man C oder C++ nutzt, dann muss man aber mehr Verständnis mitbringen, um schnellen Code zu schreiben. Das führt dazu, dass es Bereiche gibt, in denen Javacode durchaus recht flott ist. In anderen Bereichen kommen dafür andere Spracheigenschaften zum tragen: Zum Beispiel der Overhead, den in Java jedes Objekt mit sich bringt. Wenn man viele kleine Objekte hat, dann sprengt man mit Java ganz schnell den Cache, während es mit C++ keinerlei Probleme in diesem Zusammenhang gibt.

Generell muss man wohl folgendes sagen: Java hatte vor vielen Jahren ein ernsthaftes Performanceproblem. In diesem Zusammenhang hat sich aber sehr viel getan, so dass Javacode inzwischen auch sehr schnell sein kann. Allerdings kann man mit C++ trotzdem noch etwas mehr rausholen. Dafür muss man C++ aber auch beherrschen.

Gregor schrieb:

Das halte ich für eine Legende. Mir ist zumindest nicht bekannt, dass es JVMs gibt, die derartige Optimierungen betreiben.

Deswegen habe ich ja auch nur allgemein geschrieben "Eine Runtime, die Optimierung betreibt, kann ...". Dass aktuelle JVMs so weit gehen, ist mir auch nicht bekannt.

Im übrigen ging es ja nur um einen einzelnen Algorithmus, der in beiden Sprachen gleich sein soll, da kann ein gut gewähltes Beispiel sicher solche Effekte erzeugen.

Gregor schrieb:

...
Wenn man C oder C++ nutzt, dann muss man aber mehr Verständnis mitbringen, um schnellen Code zu schreiben.
...
In anderen Bereichen kommen dafür andere Spracheigenschaften zum tragen: Zum Beispiel der Overhead, den in Java jedes Objekt mit sich bringt.
...
Java hatte vor vielen Jahren ein ernsthaftes Performanceproblem. In diesem Zusammenhang hat sich aber sehr viel getan, so dass Javacode inzwischen auch sehr schnell sein kann. Allerdings kann man mit C++ trotzdem noch etwas mehr rausholen. Dafür muss man C++ aber auch beherrschen.

Da stimme ich dir voll zu.

Fakt ist auch das ein Javaprogramm immer optimal auf das gerade verwendete System angepasst ist und vielleicht auch in Zukunft gleich die GPU mit einbeziehen kann. Das sind Wege die C++ nicht mitgehen kann und da auch irgendwann nicht mehr mithalten kann was die Performance angeht.

Mal ehrlich wer tut sich noch den Krampf oder hat soviel Zeit sein C++ Programm derart zu optimieren das es viel schneller läuft als eine Javasoftware? Wieviel Jahre braucht man um nur die Sprache so gut zu lernen das man derart optimieren kann 2-5?

Da muss man gar nicht auf GPU warten, sobald die "two tier compilation" umgesetzt wird gibt es noch mal einen ordentlichen Performanceschub. Vorbereitet ist dafür schon alles.

Nur ca. 1% der Software muss hochoptimiert laufen, also who cares the perfect performance? Java kommt in der Performancerangliste gleich hinter C++ und das ohne sich jahrelang mit der Sprache auseinandersetzen zu müssen.

hubbybub schrieb:

Nur ca. 1% der Software muss hochoptimiert laufen, also who cares the perfect performance? Java kommt in der Performancerangliste gleich hinter C++ und das ohne sich jahrelang mit der Sprache auseinandersetzen zu müssen.

http://de.wikipedia.org/wiki/Wirthsches_Gesetz

Ich glaube solche Sprüche sind oft Schuld daran. Dabei sind wohl irgenwelche Benchmarks zur Messung der Performance ziemlich witzlos, interessant ist, wie sich das Programm zur Laufzeit verhält. Speicherbedarf rückt da schnell in den Vordergrund, genauso wie im Hintergrund nebenher laufende Prozesse wie Laufzeitoptimierungen. Die typischen Benchmarks zeigen doch nur, wie sich das Programm verhält, wenn es quasi alleine auf dem System ist und tagelang unter Vollast irgendwelche komplizierten Berechnungen durchführen muss.

Meiner Meinung nach spielt Ressourcenbedarf/Performance immer dann eine Rolle, wenn man die genauen Laufzeitverhältnisse nicht kennt und daher nicht weiß, ab wann eine Software zufriedenstellend läuft. Und das sind weit mehr als 1%! Egal ist Performance doch fast nur bei Individualsoftware, von der man weiß, wo sie laufen soll und welche Bedingungen sie zu erfüllen hat.

Ob nun C, Java, oder Python. Ein schlankes Design sollte immer wichtig sein. Zum Beispiel finde ich es ziemlich upassend, dass die leichtgewichtige Desktopungebung LXDE GMixer als Mixer verwendet. Nur um die Lautstärke zu regeln erhöht das den Speicherbedarf des Systems schnell mal auf fast das Doppelte. Wieso ist das so? Weil "Performance nur in 1% der Fälle wichtig ist", und ein Mixer anscheinend zu den 99% gehören soll, in denen es absolut egal ist!

Übrigens verhält sich diese Zahl, die man immer wieder zu hören bekommt, ziemlich inflationär. Von "bei der Hälfte der Software sollte Performance keine Rolle spielen", über die "80/20-Regel" bis "99%" hört man das doch immer wieder.

Das Gesetzt ist totaler Mumpitz, da in der heutigen Zeit mehr Performance drauf geht für:

- Wirtschaftlichkeit(weniger Individuallösungen)
- Sicherheit(VMs, Firewall, Antivir,etc.)
- Komfort(Automatismen, Dienste)

Natürlich. Der genannte GMixer belegt aber nicht so viele Resourcen, weil er sicherer und komfortabler ist, als Alternativen.

Du hast schon Recht, dass für so etwas auch Resourcen drauf gehen. Es geht mir ja auch nicht darum, sondern es geht mir um die unter Entwicklern scheinbar allgemein vorherrschende, da immer wieder aus Entwicklerkreisen gehörte, Meinung, dass Performanz keine Rolle spielt. Meinst du nicht, das nimmt auch Einfluss auf die Qualität entwickelter Software?

Der Herr Professor Wirth hat ja auch nicht nur heiße Luft gespuckt, sondern durchaus auch Studien, teilweise anhand praktischer Arbeiten (Oberon System), zu dem Thema durchgeführt.

Sicher spielt auch Performance eine Rolle aber es wird halt nicht mehr wie früher jedes Fitzelchen per Assembler auf Laufzeit und Speicherverbrauch optimiert weil es keiner mehr bezahlen könnte bei der heutigen Komplexität der Software. Und wenn dann doch auch noch auf unterster Ebene so stark optimiert werden muss dann sind das meist Spezialanwendungen die nun mal nicht wirklich viele Prozent der gesamten Softwarebranche ausmachen.

Sicher könnte alles viel schneller und ressourcensparender sein, die Software könnte aber keiner mehr bezahlen bzw wäre sie bei weitem nicht so ausgereift weil viel zu viel Zeit fürs Optimieren drauf gegangen ist.

Scheppertreiber

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

Lies dir mal ein paar Schriften von Niklaus Wirth durch, dann verstehst du, was genau er meint. Es geht nicht um Mikrooptimierung, sondern es geht um von vornherein vernünftig designte Software. Da kannst du schnell mal 2 Fliegen mit einer Klappe schlagen: Ressourcen sparen und Produktivität erhöhen. Das schließt sich überhaupt nicht aus. Deswegen habe ich ja auf das Oberon-System verwiesen. Das war für seine Zeit durchaus ein voll funktionsfähiges Betriebssystem, wurde aber von nur 2 Personen innerhalb eines Jahres neben den anderen Pflichten, die sie an der Universität hatten, fertig entwickelt. Es geht also definitiv nicht um zeitraubende Mikrooptimierung.

A Plea for Lean Software:
d.linux-bg.org/download/docs/wirth.pdf

Die aktuelle Version nennt sich Active Oberon System (AOS) oder Bluebottle. Auch diese ist von einer Person als Dissertation entwickelt worden. Kein Assembler drin. Das kann man durchaus Produktiv und wirtschaftlich nennen.
http://e-collection.ethbib.ethz.ch/view/eth:26082

Es kann natürlich von den Features her nicht mit einem modernen Linux/Unix/Windows System mithalten, aber die Prinzipien nach denen dort entwickelt werden, finde ich genial. Und darum geht es ja in erster Linie in den Arbeiten.

Scheppertreiber schrieb:

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

Ein Java Programm wird erst interpretiert und dann entscheidet der JIT welche Teile in Maschinencode übersetzt werden. Dieses Kompilieren ist dann selbstverständlich auf die gerade eingesetzte Umgebung sehr gut angepasst. In späteren Versionen ist dann noch geplant das Assembler dann noch hochzuoptimieren, so dass es theoretisch möglich ist jedes C Programm alt aussehen zu lassen. Das schöne ist die ganzen Optimierungen laufen ohne zutun des Entwicklers, der sollte natürlich seinen Code auch performant schreiben denn auch in Java kann man gut mal den Faktor 100 raus holen in dem man Sachen anders implementiert.

Bei Java kannst du also davon ausgehen das Berechnungen in Schleifen schnell nur als reine nativer Maschinencode laufen und zwar nicht nur 386 optimiert sondern immer da was die CPU gerade hergibt.

WN schrieb:

Lies dir mal ein paar Schriften von Niklaus Wirth durch, dann verstehst du, was genau er meint. Es geht nicht um Mikrooptimierung, sondern es geht um von vornherein vernünftig designte Software. Da kannst du schnell mal 2 Fliegen mit einer Klappe schlagen: Ressourcen sparen und Produktivität erhöhen. Das schließt sich überhaupt nicht aus. Deswegen habe ich ja auf das Oberon-System verwiesen. Das war für seine Zeit durchaus ein voll funktionsfähiges Betriebssystem, wurde aber von nur 2 Personen innerhalb eines Jahres neben den anderen Pflichten, die sie an der Universität hatten, fertig entwickelt. Es geht also definitiv nicht um zeitraubende Mikrooptimierung.

A Plea for Lean Software:
d.linux-bg.org/download/docs/wirth.pdf

Die aktuelle Version nennt sich Active Oberon System (AOS) oder Bluebottle. Auch diese ist von einer Person als Dissertation entwickelt worden. Kein Assembler drin. Das kann man durchaus Produktiv und wirtschaftlich nennen.
http://e-collection.ethbib.ethz.ch/view/eth:26082

Es kann natürlich von den Features her nicht mit einem modernen Linux/Unix/Windows System mithalten, aber die Prinzipien nach denen dort entwickelt werden, finde ich genial. Und darum geht es ja in erster Linie in den Arbeiten.

Wenn die Leute irgend was Revolutionäres erfunden hätte, dann hätte sich Microsoft oder ein anderes Unternehmen schon die Leute und das KnowHow eingekauft, so wie sie es immer tun. Der Knall im All war es dann wahrscheinlich nicht.

Scheppertreiber schrieb:

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

Wir leben doch nicht mehr in den 90er wo Java nur interpretiert wurde, das ist schon ganz lange History. Ich gehe jede Wette ein dass das dynamische Compilieren dem statischen Compilieren bald die Performancekrone streitig machen wird. Da steckt noch jede Menge Potential drin.