Das ewige Thema Java-Performance
-
Gerard schrieb:
ist nicht grade 1.5 aktuel?
Nein, die aktuelle Version heißt tatsächlich 5.0. Die haben wohl ein paar Versionsnummern übersprungen.
-
Es gibt schon seit ner Ewigkeit C für µController. Seit wann gibt es nochmal Java auf Handys? :p
-
net schrieb:
aber java-compiler könnte man prima in java selbst coden. das macht sun aber nicht, weil sie nicht komplett alles neu schreiben wollen.
javac wurde in Java geschrieben.
Wir könnten Wetten abschließen, wie viele Seiten der Thread hier bekommen wird. Ich tippe auf 5 (ein MOD könnte mir ja helfen und wir teilen dann den Gewinn)
-
interpreter schrieb:
javac wurde in Java geschrieben.
wow, hätt ich nicht gedacht.
-
Juchu,
wieder ein Thread, der die Welt verändert. Ich tippe mal auf ca. 15-20 Seiten, bevor er geschlossen wird.
-
CarstenJ schrieb:
Ich tippe mal auf ca. 15-20 Seiten, bevor er geschlossen wird.
Intervalle sind unfair
-
Ok, 18 Seiten!
-
CarstenJ schrieb:
Ok, 18 Seiten!
ich tippe auf 4 seiten
aber dann wird er nicht geschlossen, sondern es kommt nichts neues mehr
-
CarstenJ schrieb:
Ok, 18 Seiten!
:p
Das ist die einzig sinnvolle Methode, wie man auf so einen Thread reagieren kann: Ihn mit OT Postings ins Lächerliche ziehen
-
Ja, zumal ja jeder weiss, dass C++ die absolute obermegaruler Sprache ist, wogegen nix und niemand in diesem Universum ankommt und die auch 1000 mal schneller ist als Assembler.
-
Ich find Java toll. Es ist so schön bequem während dem Programmstart einen Kaffee holen zu können oder aufs Klo zu gehen
.
-
Ich bin da optimistischer und tippe auf 14 Seiten.
GPC schrieb:
Klar, da Java zu sagen wir mal 20% interpretiert ist kann es nie so schnell sein wie eine kompilierte Sprache wie C++.
Was sollen diese 20% sein? Ich behaupte mal frech, dass die VM sich im Großen und Ganzen darauf beschränkt, den JIT-Compiler rüberzujagen und dann gar nichts mehr interpretiert. Vielleicht mit ein paar Ausnahmen, wenn man Reflection nutzt, da woaß i's net.
Mit dem nächsten Sprung auf Java 5.0 kann man auch wieder erhebliche Verbesserungen erwarten.
Die Performance kommt der von C++ immer näher. Ob sie erreicht wird ist fraglich, manche behaupten es wäre möglich Java schneller als C++ zu machen. Das glaube ich aber erst wenn ich's sehe.Das hängt vom Anwendungsfall ab. Java kann durchaus schneller sein als C++. Kann auch durchaus anders rum sein.
Aber da stellt sich eine andere Frage: Braucht man überhaupt noch die totale Performance?
Ja! Aber die holt man sich heutzutage nur noch selten über irgendwelche Byte-Hacks.
SirLant schrieb:
Und wie soll ein Javaprogramm schneller sein als ein kompilliertes Programm? Dazu müsste die JVM entfernt werden und das javaprogramm ebenfalls kompilliert werden, da die JVM ganz einfach auch Zeit braucht welche sie dem Programm nunmal klauen muss.
Diese Aussage ist ebenfalls nicht richtig. Der Code wird zur Laufzeit compiliert und liegt als Native Code im RAM vor. Desweiteren kann die VM (Stichwort HotSpot) Optimierungen vornehmen, die bei compilierten Sprachen nur mit einer Menge Probedurchgänge möglich sind.
Und um ehrlich zu sein ich merke den Unterschied deutlich, so ist z.B. Eclipse sehr schnell, schaue ich mir andere Javaprogramme an merke ich doch deutlich, dass die GUI einfach langsamer als die von "normalen" Anwendungen ist. bei einer GUI aus dem .NET Framework kann ich das nicht feststellen (ebenso wie z.B. in Eclipse).
Naja, ich benutze Java 5.0 beta 2 und habe mit Swing keine Probleme festgestellt.
Steven schrieb:
Aber der Garbage Collector frisst Ressourcen ...
It depends...
Garbage Collection kann auch durchaus schneller sein als manuelle Speicherverwaltung. Oder schreibst du wirklich jedesmal einen absolut für diesen Zweck optimalen Allokator?
-
Ok,
Steven schrieb:
Es gibt schon seit ner Ewigkeit C für µController. Seit wann gibt es nochmal Java auf Handys? :p
Ok, 1:0 für dich, hab ich nicht beachtet. Aber da könnte man auch mit Asm ran.
An alle die meine vermeintliche Inkompetenz in C++ rügen: Zählt mir mal diese enormen Entwicklungen von C++ auf!
Die Daten stammen aus einem pdf Dokument das den Titel Evaluating Game Performance in Java trägt. In diesem Dokument wird Java und C++ analysiert, speziell in Betracht auf performance und geprüft ob sich Java für spiele (richtige also GTA, CS, Unreal) eignen würde.
Meldet euch falls der Link erwünscht ist.
-
Meldet euch falls der Link erwünscht ist.
Warum postest du ihn nicht einfach?! Wen das nicht interessiert, liest es einfach nicht.....
-
-
Ich bin gewiss kein Experte, aber wenn man manche Vergleiche zwischen Java und C++ überfliegt, stellt man oft fest, dass der Tester entweder die eine oder die andere Sprache nicht beherrscht. So sind die Ergebnisse sehr unterschiedlich und imho auch nicht unbedingt representativ. Ich denke, wenn man wirklich Programmierer ist, dann gehören einfach verschiedene Sprachen und Tools zum Repertoire und unterschiedliche Aufgaben erfordern eben unterschiedliche Lösungen.
Wenn jemand wie er oder sie, welche unzweifelhaft beides beherrschen, so einen Vergleich machen, dann kann man davon ausgehen, dass es aussagekräftig und kompetent ist.
-
GPC schrieb:
Ok,
Steven schrieb:
Es gibt schon seit ner Ewigkeit C für µController. Seit wann gibt es nochmal Java auf Handys? :p
Ok, 1:0 für dich, hab ich nicht beachtet. Aber da könnte man auch mit Asm ran.
Genauso kann man, aber auch Software für den PC mit C/C++ programmieren, man nimmt dort, aber C damit man ne gewisse Plattformunabhängigkeit hat, da ja die Controller unterschiedliche Assembler haben und so muss man nur die Bibliothek für den Controller schreiben und schon passt es wieder.
Und genau aus dem Grund sprichst du dich doch auch für Java aus, oder nicht?
@Optimizer wenn einmal alles kompiliert wird, was hat dieser JIT-Compiler dann für einen sinn? Ich dachte der kompiliert immer das benötigte und spart sich so Zeit, da er nicht benutzte Teile einfach erst dann kompiliert wenn sie benötigt werden
-
SirLant schrieb:
@Optimizer wenn einmal alles kompiliert wird, was hat dieser JIT-Compiler dann für einen sinn? Ich dachte der kompiliert immer das benötigte und spart sich so Zeit, da er nicht benutzte Teile einfach erst dann kompiliert wenn sie benötigt werden
Das ist ja auch nicht falsch. Aber wieso folgerst du daraus
Und wie soll ein Javaprogramm schneller sein als ein kompilliertes Programm? Dazu müsste die JVM entfernt werden und das javaprogramm ebenfalls kompilliert werden, da die JVM ganz einfach auch Zeit braucht welche sie dem Programm nunmal klauen muss.
?
Wenn das Programm einmal als Native Code vorliegt gibt es ja keinen Grund mehr, warum die VM noch ständig Zeit brauchen soll. Die VM compiliert jede Funktion selbstverständlich nur einmal.
-
Also Theoretisch könnte ich mir schon vorstellen, das Bytecode-Sprachen mit JIT (egal ob Java, Net oder was auch immer) schneller sein könnten als C++.
Der Grund ist einfach, dass die für die Plattform optimieren können, auf der das Programm letztlich ausgeführt wird. Ich bezweifle dass die Masse an C++ Programmen für Pentium4/Athlon 64 optimiert sind... Und wenn ich 'nen Pentium III habe, nützt mir Optimierung für P4 nichts etc. Ein JIT kann genau das umgehen.
Das Problem dabei ist nur, dass das Compilieren natürlich auch Zeit braucht...
-
Das Problem dabei ist nur, dass das Compilieren natürlich auch Zeit braucht...
Das ist IMHO nicht das Problem, da es ein einmaliger Vorgang ist.
Das Problem ist einfach, dass der JIT-Compiler wenig Zeit hat. Verdammt wenig Zeit. Ein statischer Compiler kann 5000 Stunden lang den Kontrollfluss analysieren, dass kann sich ein JIT-Compiler nicht leisten.