JAVA schneller als C++ ? Stimmt das???



  • groovemaster schrieb:

    DEvent schrieb:

    x + y + z = e1 // c++
    w + x + y + z = e2 // java

    tolle 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.





  • 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:

    http://www.heise.de/newsticker/meldung/75012

    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



  • 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.

    Herrlich, und warum soll das nur eine VM und kein RTOS (wie z.B. QNX) auch leisten können? Hier stellst du wieder die Behauptung auf, das nur die VM das garantieren kann?



  • Artchi schrieb:

    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.

    Herrlich, und warum soll das nur eine VM und kein RTOS (wie z.B. QNX) auch leisten können? Hier stellst du wieder die Behauptung auf, das nur die VM das garantieren kann?

    Ich sehe nicht, dass er diese Behauptung aufstellt. ...zumindest habe ich da ein anderes Textverständnis. RTJ benötigt untendrunter ein RTOS. Ohne ein RTOS geht da gar nichts, das ist klar.



  • Artchi schrieb:

    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.

    Herrlich, und warum soll das nur eine VM und kein RTOS (wie z.B. QNX) auch leisten können? Hier stellst du wieder die Behauptung auf, das nur die VM das garantieren kann?

    Wie Gregor schon sagt, möchte ich diese Behauptung nicht aufstellen. Um so etwas zu garantieren, brauchst du einerseits ausreichend effiziente Implementierungen deiner Programmteile und andererseits einen Realtime-Scheduler. Dieser kann von einer JVM oder von einem OS bereitgestellt werden. Bei einem Projekt im embedded-Bereich kann es natürlich gut sein, dass die VM relativ viel von einem OS selbst implementiert (also die komplette Speicherverwaltung, Scheduling, ...), aber das muss natürlich keineswegs so sein.



  • Man koennt auch nen BS bauen (gibts da nich schon ansaetze ? ^^) was komplett auf die beduerfnisse von java zugeschnitten ist ^^ und eigentlich nur ne JAVA RT mit bisserl schnickschnack ist ....
    (GC als API vom Betriebssystem ... mir wird grad anders ^^)
    der naechste schritt waere, prozessoren zu bauen, die bestimmte in java haeufige Befehle beschleunigen ...

    wem wuerde es wundern wenn das ding um laengen schneller wuerd als wie c++ aufn standard system ^^

    Aber ehrlich, diesen aufwand fuer was ? um was zu beweissen ? oder um die entwicklunzgszeiten von programmen zu minimieren (was gescheite libs unter c++ ja auch koennen ) ???

    Der vergleich von c++ und java hinkt vorne und hinten ^^ Es gibt halt randbedingungen die man ned einfach ignorieren sollte.

    Vielleicht wird ja Java in zukunft auch mal schneller als c++, aber dann nur weil irgendwer keinen bock mehr hatte gescheite libs fuer c++ zu programmieren die performantechnisch auf das betroffene system zugeschnitten sind ^^

    Ciao ...


Anmelden zum Antworten