JAVA schneller als C++ ? Stimmt das???
-
rapso schrieb:
ich weiß echt nicht wozu man immmer java/c# als schneller oder genausoschnell debatieren muss.
Fragst Du jetzt, warum Leute das behaupten, oder fragst Du, warum es Leute gibt, die das abstreiten?
-
So klar ist der Fall für mich auch noch nicht. Ich finde viele Punkte von rapso ziemlich gut, aber teilweise zu praxisnah. z.B.:
Speicherschutz macht eh die Hardware -> da fehlt die Überlegung, ob man ohne dem effizientere Hardware bauen könnte. Was war denn zuerst da? Richtig, unsichere Programme, die irgendwann Betriebssysteme mit Speicherschutz notwendig gemacht haben, den man idealerweise natürlich in Hardware gegossen hat... das selbe gilt für zusätzliche Adressberechnungen, warum kann ein x86 das so gut? Weil er es oft braucht...
Und bei solchen Dingen reden wir nämlich aneinander vorbei. Meine Behauptung ist nicht, dass Java- oder .Net-Programme in der Praxis schneller sind. Meine Behauptung ist, dass das Konzept an sich überlegen ist und theoretisch schnellere Ausführung erlauben müsste. Man muss das theoretisch betrachten, andernfalls kann man sowieso nur Implementierungen vergleichen.
Mir ist dieser Thread auch zu Sprachen-lastig geworden... ich wollte eigentlich nicht damit anfangen, welche Sprache mehr Skill erfordert und wo man mehr kompetente Programmierer findet. Es gibt auch JIT-compiliertes C++ in .Net, also kein Grund, die Sprachen ins Spiel zu bringen.Auch dass man den Sourcecode zu libs oft zur Verfügung hat: Was war zuerst da, die Idee ständig den eigenen Sourcecode offen zu legen und dann hat sich herausgestellt, dass damit der statische Compiler besser modulübergreifend optimieren kann, oder vielleicht auch manchmal anders herum?
Und die high-level Optimierungen mit der for-Schleife: Der Compiler, der den Bytecode erzeugt kann sicherlich genau solche Absichten auch erkennen. Man muss sich halt schon genau überlegen, welche Optimierung von welchem Compiler vorgenommen wird. Meine Vermutung wäre auch, dass high-level Betrachtungsweisen eher der statische Compiler machen muss, der den Sourcecode hat. So Sachen wie Inlining kann ein JIT aber besser (aus den angesprochenen Gründen). Ich sehe hier jedenfalls keinen Verlust an Optimierungspotenzial, eher nur Verbesserungen.
-
DEvent schrieb:
Ich habe den Thread jetzt ziemlich genau vefolgt und ist echt interessant bis jetzt. Aber groovemaster, du langweilst langsam. Du trollst jetzt einfach nur rum.
Optimizer hat etliche sehr gute Argumente genannt wieso ein JIT besser optimieren könnte als es ein C++ Compiler je kann.Tja, tut mir leid für dich. Aber du hast die Betrachtungsweise wohl immer noch nicht verstanden. Irgendwann habe auch ich keine Lust mehr zu singen...
DEvent schrieb:
x + y + z = e1 // c++
w + x + y + z = e2 // javatolle Rechnung
Ich würde die Rechung eher so schreiben:
x1 + y1 + z1 = e1 // c++
w + x2 + y2 + z2 = e2
denn weder x, y noch z sind bei C++ und Java gleich.So sieht es in der Tat in der Praxis aus. Aber was willst du damit bezwecken? Anfangen kannst du damit nix. Deshalb müssen wir erstmal davon ausgehen, dass main sowohl beim C++ als auch beim Java Programm die gleiche Laufzeit hat, damit die Rahmenbedingungen auf beiden Seiten die gleichen sind. Wie das letztendlich durch die Implementation realisiert ist, spielt keine Rolle. Gleiches gilt für Programmstart und -ende.
DEvent schrieb:
Ein JIT kennt einfach das System auf dem das Programm läuft zu 100%. Wärend man bei C++ doch nur fürn x beliebigen x86 compiliert.
System, nicht x86.
DEvent schrieb:
Ausserdem kennt der JIT alles von dem Code. Egal ob es dein Programm ist oder Librarys von Marsmännchen. Somit kann er nun das komplette Programm genauestens optimieren. Wärend der C++ Compiler das Programm nur für einen Standard x86 optimiert und die fremd-Libs nicht anfassen kann.
Ja, das wurde ja bereits besprochen, dass JIT hier Vorteile hat. Aber wer sagt denn, dass Fremdbibliotheken unzureichend optimiert sind?
DEvent schrieb:
und wozu die ganzen Freaks mit ihren ach so tollen C++ super duper micro bit-shift, mem-align optimierungen?
Bitshifts sind nicht Micro, sondern gehören in der digitalen Rechentechnik zu den ganz "normalen" Rechenmöglichkeiten, genauso wie Addition oder Multiplikation. Leider gibt es immer noch Leute, die glauben, besser x << 1 schreiben zu müssen, anstatt 2 * x, weil das besser optimiert ist. Was aber vollkommener Blödsinn ist. Und warum nutzt man dann Bitshifts? Nun, weil sie in manchen Situationen nunmal genau das ausdrücken, was man machen möchte. Also der Situation angemessen sind. Und Memory Alignment nimmt man sowieso nicht für Performance Optimierungen. Zumindest nicht der Programmierer, darum kümmert sich schon der Compiler. Memory Alignment nimmt man nur, wenn es benötigt wird. Wie zB bei MMX. Macht man das nicht, gibts 'ne CPU Exception. Wobei ich mir nichtmal sicher bin, ob MMX im kompletten Umfang die Funktionalität für nicht ausgerichteten Speicher bietet.
Und sowas ist auch ein Grund, warum man Code, der solche speziellen CPU Möglichkeiten nutzt, momentan eher in nativen Sprachen sieht. Hast du schon mal versucht, eine spezielle Matrizenberechnung, so wie man sie häufig in 3D Spielen antrifft, mit Java zu implementieren? Ich könnte dir zB selbst nicht sagen, inwiefern Java dafür Möglichkeiten bietet. Würde mich allerdings selbst mal interessieren, wie gut Java entsprechende Formeln von high- nach low-level umsetzen kann. Naja, momentan wird die Logik wohl noch nicht ausreichen, um mit handgeschriebenen Optimierungen mitzuhalten.
-
Und sowas ist auch ein Grund, warum man Code, der solche speziellen CPU Möglichkeiten nutzt, momentan eher in nativen Sprachen sieht. Hast du schon mal versucht, eine spezielle Matrizenberechnung, so wie man sie häufig in 3D Spielen antrifft, mit Java zu implementieren? Ich könnte dir zB selbst nicht sagen, inwiefern Java dafür Möglichkeiten bietet. Würde mich allerdings selbst mal interessieren, wie gut Java entsprechende Formeln von high- nach low-level umsetzen kann. Naja, momentan wird die Logik wohl noch nicht ausreichen, um mit handgeschriebenen Optimierungen mitzuhalten.
Das macht eben die JIT. In Java brauch man eigentlich solche Möglichkeiten gar nicht, weil das eben ausgelagert ist.
Mit dem JIT und Hot-Technologie hat man eben die Implementation von der micro-Optimierung getrennt. Der Programmierer sorgt dafür das der Algo eine min. Laufzeit ( also optimal in O(n logn) oder noch besser in O(n) ) hat. Der Compiler sorgt dann dafür das dieser Algo auf dem System auf dem er läuft mit min. Aufwand ausgeführt wird.
zB: Ist das System ein MMX-Prozessor macht die JIT in dem Code die speziellen Optimierungen, ist es kein MMX dann lässt die JIT es.
Hast du C++ musst du dich entscheiden ob mit oder ohne Optimierungen. Die Alternative wäre für jeden Prozessortyp und BSys. binaries zu erstellen.
In Java schreibst du zB x * x * sqrt(y). Die JIT optimiert diesen Code für den Prozessor und System auf dem das Programm zur Zeit läuft. Ich als Programmierer kann in den Algorithmen optimieren. (zB statt Insertsort lieber Quicksort verwenden, sowas kann kein Computer-Tool für mich entscheiden)Ich überlasse lieber den Profis die tagein,tagaus nur Compiler schreiben und Asm als erste Sprache sprechen, die Optimierungen für die Prozessoren. Ich als Programmierer schreibe guten Code, der eine gute Laufzeit hat.
-
groovemaster schrieb:
DEvent schrieb:
x + y + z = e1 // c++
w + x + y + z = e2 // javatolle Rechnung
Ich würde die Rechung eher so schreiben:
x1 + y1 + z1 = e1 // c++
w + x2 + y2 + z2 = e2
denn weder x, y noch z sind bei C++ und Java gleich.So sieht es in der Tat in der Praxis aus. Aber was willst du damit bezwecken? Anfangen kannst du damit nix. Deshalb müssen wir erstmal davon ausgehen, dass main sowohl beim C++ als auch beim Java Programm die gleiche Laufzeit hat, damit die Rahmenbedingungen auf beiden Seiten die gleichen sind.
Es geht doch gerade darum, daß der JIT-Compiler möglicherweise effizienteren Code generieren kann und damit die Laufzeit des Programms gegenüber der C++-Version drücken kann. Wenn Du das natürlich von vornherein ausschließt bleibt natürlich genau das JIT-kompilieren als Overhead übrig.
-
in diesem thread die theorie, da http://www.c-plusplus.net/forum/viewtopic-var-t-is-149891-and-start-is-10.html
die praxis
-
groovemaster schrieb:
Leider gibt es immer noch Leute, die glauben, besser x << 1 schreiben zu müssen, anstatt 2 * x, weil das besser optimiert ist.
nö, sondern weil's schneller ist. man sollte sich nicht unbedingt darauf verlassen, dass ein compiler aus 'x*2' automatisch x<<1 macht.
-
Darauf verlasse ich mich schon. Wenn ich meine "durch 2 teilen", dann schreibe ich das auch genauso hin. Ein Compiler, der das nicht kann, wandert sofort auf den Müll.
-
-
Argument schrieb:
Au weia. Da steht ja nichtmal _was_ die VM genau übernimmt. "zum Teil in Java implementiert" kann ja alles heissen.
"Echtzeit-Systeme müssen auf externe Ereignisse innerhalb eine garantierten Zeitspanne reagieren – selbst unter schwierigen Bedingungen."
Schön, dass heise hier (wieder einmal) erzählt was Echtzeit bedeutet, aber ohne die Angabe von tatsächlichen Antwortzeiten ist der Satz, ebenso wie der Artikel, einfach nur Müll. Blubber.
Die Frage ist also: was kann eine solche VM garantieren? Durch welche Einschränkungen hat man sich das erkauft?
-
Warum kommt überhaupt Java in der News vor? Schön das die Drohne Java inside hat. In was ist denn der Rest der Drohne programmiert, wenn man schon eine Sprache nennt? Kommt ADA, C, C++ u.a. zum Einsatz? Ich wette das eine dieser Sprachen auch dabei ist, da Java nur in einem Teil der Drohne zum Einsatz kommt.
Warum überhaupt Java wenn erst noch eine VM entwickelt werden mußte? Der Benefit erschliesst sich mir hier überhaupt nicht. Sehe nur Zeitaufwand (bekanntlich ist Zeit auch Geld). Hätte man nicht einfach einen (kostenlosen) C++ Compiler nehmen können? Ich wette, der Part den jetzt Java übernimmt, wäre mit C++ früher fertig geworden (und somit auch billiger).
Komisch...
-
Artchi schrieb:
Ich wette das eine dieser Sprachen auch dabei ist, da Java nur in einem Teil der Drohne zum Einsatz kommt.
100%ig. Ich könnte mir vorstellen, dass der Java-Part Sachen wie Kommunikation mit der Basis oder ähnliche Sachen übernimmt. Die Flugregelung usw., also die wirklich harten Echtzeitanforderungen, werden in einer anderen Sprache realisiert sein. Da macht Java (bzw. dessen allgemeine Vorteile) auch gar keinen Sinn.
-
TactX schrieb:
Die Flugregelung usw., also die wirklich harten Echtzeitanforderungen, werden in einer anderen Sprache realisiert sein. Da macht Java (bzw. dessen allgemeine Vorteile) auch gar keinen Sinn.
warum nicht? mit java kriegt man locker reaktionszeiten im sekundenbereich hin. mehr ist für die steuerung eines flugzeuig doch nicht nötig. aber klar, in so'nem flieger sind immer mehrere minicomputer. z.b. die auswertung von messdaten während des fluges macht sicher ein schnelleres system und gibt die ergebnisse dann an's java programm...
-
net schrieb:
warum nicht? mit java kriegt man locker reaktionszeiten im sekundenbereich hin. mehr ist für die steuerung eines flugzeuig doch nicht nötig. ...
Wie kommt man auf eine solche Behauptung?? Dir ist bekannt das dies eine Düsenangetriebe Drohne ist!?!
Und selbst bei nur 950km/h (Turbo-Prop Antrieb) bedeutet, das die Drohne innerhalb einer Sekunde rund 260m sinkt oder steigt - Weg zurücklegt. Bei einem Landeanflug von 500km/h (was sehr niedrig ist, bei diesem Flügeln) sind das 130m in einer Sekunde!
-
hihi, ich stelle mir einen F16-Piloten vor, der eine Sekunde für eine Reaktion bräuchte. Wow!
Man, da ist ja mein Opa schneller im Reagieren! 
Selbst ESP im Auto muß schneller als eine Sekunde auf Gefahrensituationen reagieren. Und ein Auto ist bedeuten langsamer als ein Jet.
-
Urkel_ schrieb:
Wie kommt man auf eine solche Behauptung?? Dir ist bekannt das dies eine Düsenangetriebe Drohne ist!?!
Und selbst bei nur 950km/h (Turbo-Prop Antrieb) bedeutet, das die Drohne innerhalb einer Sekunde rund 260m sinkt oder steigt - Weg zurücklegt. Bei einem Landeanflug von 500km/h (was sehr niedrig ist, bei diesem Flügeln) sind das 130m in einer Sekunde!stimmt auch wieder. ich bin irrtümlicherweise von zu schnellen bewegungen irgendwelchen höhen/seitenruder ausgegangen, die bei solchen geschwindigkeiten ja nutzlos bzw. echt übel wären...
-
Real-Time-Java hat relativ wenig mit dem Standard-Java zu tun, das man so kennt. ...es gibt da keine 1-Sekunden-GC-Pausen.
Ich habe zwar keine Infos zu der RTJ-Realisierung, die die da selbst geschrieben haben, aber Sun schreibt zu seiner Referenz-Implementierung:http://java.sun.com/javase/technologies/realtime.jsp
Q: How fast is Java RTS? How do you measure Java RTS's performance?
Java RTS performance is measured in two ways: throughput performance for non-real-time logic, and maximum latency and jitter for hard real-time logic. (note: latency is defined as the average time it takes the system to respond to a higher priority interrupt; jitter is a measure of the variability of the latency number) For non-real-time logic this release of Java RTS performs up to 85% as fast as the equivalent non-real-time system on standard Java benchmarks.
For hard real-time logic this release of Java RTS, for our reference platform, has a maximum latency of 20 microseconds and a maximum jitter of 10 microseconds.
Wir sind da also etwa um einen Faktor 10^5 schneller als bisher angedacht wurde.
Mag sein, dass es noch schneller geht, aber andererseits reicht das vermutlich aus. Kein Mensch hat Reaktionszeiten im Bereich einiger 10 Mikrosekunden.Artchi schrieb:
Warum überhaupt Java wenn erst noch eine VM entwickelt werden mußte? Der Benefit erschliesst sich mir hier überhaupt nicht. Sehe nur Zeitaufwand (bekanntlich ist Zeit auch Geld). Hätte man nicht einfach einen (kostenlosen) C++ Compiler nehmen können? Ich wette, der Part den jetzt Java übernimmt, wäre mit C++ früher fertig geworden (und somit auch billiger).
Die werden schon nen Grund dafür gehabt haben.
Ich glaube nicht, dass es sinnvoll ist, denen ohne fundierte Informationen Idiotie zu unterstellen.
-
Ja, geiles Experten-Geblubber wieder mal, da kann man wirklich nur die Augen verdrehen.
TactX schrieb:
Die Frage ist also: was kann eine solche VM garantieren? Durch welche Einschränkungen hat man sich das erkauft?
Durch einen höheren Speicherverbrauch und/oder geringeren Durchsatz hat man das erreicht - wie seit 50 Jahren Software-Entwicklung.
Was genau garantiert die VM? Sie garantiert, dass das Auswerten des Flugsignals und die Berechnung der neuen Rudereinstellung innerhalb xyz Millisekunden abgeschlossen ist. Nicht einmal 3ms mehr, dafür ein andermal 5ms weniger. Immer unter xyz.Artchi schrieb:
Warum überhaupt Java wenn erst noch eine VM entwickelt werden mußte? Der Benefit erschliesst sich mir hier überhaupt nicht. Sehe nur Zeitaufwand (bekanntlich ist Zeit auch Geld). Hätte man nicht einfach einen (kostenlosen) C++ Compiler nehmen können? Ich wette, der Part den jetzt Java übernimmt, wäre mit C++ früher fertig geworden (und somit auch billiger).
Ja, dann wette mal. Wissen kannst es weder du noch ich. Weder wie aufwändig die Entwicklung der VM war, noch wie oft man diese VM wieder verwenden wird, noch welche Vor- und Nachteile sich daraus ergeben haben. In dem Artikel steht nichtmal, dass die VM nur für diesen Zweck entwickelt wurde, sieht eher so aus, als hätte man sich aus 50 vorhandenen für eine entschieden.
Man hätte auch so möglicherweise gar nicht dein geliebtes C++ verwendet. Gerade im militärischen Bereich benutzt man viel häufiger Sprachen wie ADA.
TactX schrieb:
100%ig. Ich könnte mir vorstellen, dass der Java-Part Sachen wie Kommunikation mit der Basis oder ähnliche Sachen übernimmt. Die Flugregelung usw., also die wirklich harten Echtzeitanforderungen, werden in einer anderen Sprache realisiert sein.
Artikel schrieb:
mit einer Steuerung, die zum Teil in Java implementiert ist
Jojo.
Und warum sollte Java-Code überhaupt eine schlechtere Reaktionszeit haben? Mit welcher logischen Begründung dauert ein Addieren von zwei Zahlen länger, wenn der Compiler den selben Code generiert? Hier wird nur gemutmaßt, von Leuten, die es offensichtlich nicht verkraften können, dass Java in einem amsonsten für Java eher untypischen Gebiet zum Einsatz kommt. Selbst wenn man Java generell mal eine schlechtere Performance unterstellt ist meistens immer noch der Durchsatz und nicht die Latenz gemeint.
-
Optimizer & Gregor 
-
...wobei der Java-Anteil hier i.d.T. eher gering zu sein scheint, wenn man folgender Behauptung von "barracuda_troll" glauben schenkt:
http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=10724622&forum_id=100184