JAVA schneller als C++ ? Stimmt das???
-
nur weil man hingewiesen wird, dass das programm wegen eines indizierungsoverflows oder nullpointer-exception tod ist, statt dass es einfach abranzt, ist das system nicht grundsätzlich sicherer.
Also du sagst jetzt das System ist unsicherer, wenn der Compiler darauf hinweist das das Programm unsicher ist, anstatt das es beim 10003293 Ausführen bei Vollmond irgendeinen komischen Laufzeitfehler wirft und abkratzt ?
-
DEvent schrieb:
aus diesem grund sollte code unoptimiert möglichst als source direkt auf nativen microcode compilert werden.
Aha
und wozu die ganzen Freaks mit ihren ach so tollen C++ super duper micro bit-shift, mem-align optimierungen?was haben die dinge miteinander zu tun?
ob eein programmierer dem compiler einen hint gibt und wenn er es überschauen kann eine optimierung macht die dem compiler den code besser presentieren, oder ob ein compiler den code optimiert ohne zu wissen wie der nachfolgende compiler ihn bräuchte, sind doch zwei verschiedene dinge.
-
rapso schrieb:
DEvent schrieb:
aus diesem grund sollte code unoptimiert möglichst als source direkt auf nativen microcode compilert werden.
Aha
und wozu die ganzen Freaks mit ihren ach so tollen C++ super duper micro bit-shift, mem-align optimierungen?was haben die dinge miteinander zu tun?
ob eein programmierer dem compiler einen hint gibt und wenn er es überschauen kann eine optimierung macht die dem compiler den code besser presentieren, oder ob ein compiler den code optimiert ohne zu wissen wie der nachfolgende compiler ihn bräuchte, sind doch zwei verschiedene dinge.
Ah jetzt habs ich verstanden. Sry zock nebenbei WoW.
Aber das spricht eben für die JIT.
Ein C++ Programmierer muss für jedes System Implementationen anbieten, die eben diese Feinheiten haben. Der JIT macht das für den Programmierer und das für jedes System automatisch.
-
justchris schrieb:
warum werden dann z.B in JAVA oder C#(die VM dort hat doch auch JIT-C oder?) nicht performante Anwendungen geschrieben?
Was verstehst Du unter einer "performanten Anwendung"?
-
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...