JAVA schneller als C++ ? Stimmt das???
-
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 ...
-
Hallo
Teilweise ganz witzig und teilweise ganz interessant.
Mich würde doch echt mal interessieren, was z. B TactX unter einem Echzeitsystem versteht....Egal, zu der Java-C++ Geschichte, ich überlege die ganze Zeit, wo ein JIT wirklich besser als ein C++Compiler sein kann. Also wo er die Lauzeit ausnutzen kann. Ich glaube kaum, dass es Compiler gibt, die spezial Befehle (z.B. MMX) irgendwelcher CPUs einfach für normal geschriebenen Code einsetzen können. Das kann auch der JIT nicht.
Angenommen, wir kompilieren ein Programm für genau ein System "offline" mit allen Optimiereungen. Wo kann da ein "online" Compiler noch was rauskitzeln.
Das System ist ja bekannt, aber welche Laufzeitinformationen kann der dann noch auswerten. Und das sollen natürlich welche sein, die nicht durch die CPU erledigt werden(können).Startvorgänge sollen einfach mal nicht berücksichtigt werden.
Ich fände das wirklich spannend, wenn das möglich wäre und wie das gemacht wird...
Bis dahin,
jenz
-
jenz2 schrieb:
Mich würde doch echt mal interessieren, was z. B TactX unter einem Echzeitsystem versteht....
Es muss in einer definierten Antwortzeit auf ein Ereignis reagieren. Das dürfte wohl die allgemeine Definition sein. Warum willst du das z.B. gerade von mir
wissen?Ist mir ehrlich gesagt scheissegal ob irgendwelche Javaianer glauben, dass Java für Echtzeitanwendungen geeignet ist. Auch sehe ich keinen Grund warum man ein Echtzeitsystem in Java realisieren sollte. Ich sehe keinen Vorteil von Java gegenüber den gängigen Methoden mit C, C++ und anderen Tools. Hier wurde auch keiner genannt. So what?
-
jenz2 schrieb:
Ich glaube kaum, dass es Compiler gibt, die spezial Befehle (z.B. MMX) irgendwelcher CPUs einfach für normal geschriebenen Code einsetzen können. Das kann auch der JIT nicht.
afaik kann das der Intel-Compiler für C++. Warum sollte es ein JIT-Compiler dann nicht auch können?
Angenommen, wir kompilieren ein Programm für genau ein System "offline" mit allen Optimiereungen. Wo kann da ein "online" Compiler noch was rauskitzeln.
Das System ist ja bekannt, aber welche Laufzeitinformationen kann der dann noch auswerten. Und das sollen natürlich welche sein, die nicht durch die CPU erledigt werden(können).Zum einen könnte die Menge an derzeitig zur Verfügung stehenden Ressourcen betrachtet werden. Viel spannender ist aber ein anderer Punkt. Wenn Du das mit C++ für genau ein System offline optimierst, dann wird das kaum zu schlagen sein. Mit JIT-Compiling könnte man das selbe aber auf allen System erreichen, ohne ganz viele verschiedene Programmversionen auszuliefern.
Startvorgänge sollen einfach mal nicht berücksichtigt werden.
Ich fände das wirklich spannend, wenn das möglich wäre und wie das gemacht wird...
Bis dahin,
jenz[/quote]
-
TactX schrieb:
Auch sehe ich keinen Grund warum man ein Echtzeitsystem in Java realisieren sollte. Ich sehe keinen Vorteil von Java gegenüber den gängigen Methoden mit C, C++ und anderen Tools.
na du weisst doch: in handgeschriebenen c und c++ codes können übelste bugs stecken, die gefahr für leib und leben bedeuten. da ist java durch z.b. laufzeitchecks besser geeignet oder ada, dessen output anschliessend durch nen c compiler gejagt wird...
-
Wer sagt denn, dass man handgeschriebenen Code nehmen muss?
-
Gregor schrieb:
Mag sein, dass es noch schneller geht, aber andererseits reicht das vermutlich aus. Kein Mensch hat Reaktionszeiten im Bereich einiger 10 Mikrosekunden.
Sorry, aber das ist einfach nur dämlich. Weil ein Mensch nicht schneller als 10ms reagieren kann, müssen es technische Systeme auch nicht können? lol?