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

*rofl*

DEvent

Jester schrieb:

DEvent schrieb:

Ausserdem ist die JIT Compelierung in O(n) also in konstanter Zeit, also völlig und total vernachlässigbar.

Ja was denn nun? O(n) oder konstant?

Ahh stimmt. Ich meinte linear. Linearer Zeitaufwand ist aber genauso vernachlässigbar.

P = NP!!!!!!!!!!!!!!!!111111111111111 (O(n!) ist vernachlässigbar)

DEvent

Die Mods sollten den Thread in die FAQ reinstellen

net 0

DEvent schrieb:

Die Mods sollten den Thread in die FAQ reinstellen

java vs. c++ threads gibts doch viele hier und immer füllen sie mehrere seiten...

Gregor

@rapso: Ok, habe deinen Beitrag vorhin wohl etwas falsch interpretiert. Mit deiner Erklärung bin ich mehr oder weniger einverstanden.

Bei den aufgelisteten Sprachen gibt es sicherlich auch noch ne ganze Menge anderes Zeug drin, keine Frage. Allerdings sind auch einige interessante Sprachen/Compiler enthalten, die Bytecode produzieren.

Man braucht aber letztendlich sowieso nur ganz wenige Sprachen. Ich habe noch nie etwas anderes als Java verwendet, um Code für die JVM zu produzieren. Nicht weil es nichts anderes gäbe, sondern weil der diesbezügliche Bedarf einfach nicht da ist. Interessant könnten zum Beispiel Sprachen wie "Groovy" sein. Auch irgendwelche Javavarianten von Prolog oder Lisp könnten für mich irgendwann interessant werden. Aber die meisten Sprachen bieten eigentlich nichts, was mich dazu bringen würde, sie in diesem Umfeld einzusetzen.

Ich will mich ja als C++ Neuling nicht großartig in das Fachgespräch einmischen, aber wenn der JIT Compiler ähnlich performant oder sogar schneller als eine C oder C++ Implementierung ist, warum werden dann z.B in JAVA oder C#(die VM dort hat doch auch JIT-C oder?) nicht performante Anwendungen geschrieben?

rapso

Optimizer schrieb:

also beispielsweise for( int i; i < array.length; ++i ); Warum sollte er jetzt nicht für den Prozessor geeigneten Code generieren können?

schönes beispiel, ich erweiter es ein wenig um es dir verständlich zu machen was für informationen verloren gehen. also, lass uns annehmen, dass in dieser schleife alle werte des arrays aufeinander addiert werden. ala

int array[] = new int[256];
.
.
.
int Sum=0;
for(int a=0;a<array.len;++a)
  Sum+=array[a];
return Sum;

hat natürlich ein wenig overhead das ganze, das summieren hat den allerwenigsten einfluss auf die ausführungsgeschwindigkeit. sowas sollte ein compiler dann also optimieren indem er die schleife ausrollt. z.b.

Sum+=array[a++];
Sum+=array[a++];
...

ich hab zwar schon ewig nicht mehr java-bytecode-assembler gecodet, aber in pseudocode dürfte dabei etwas wie

bipush 0 //a auf stack legen
load array //pointer vom aktuellen array laden

iaload //erstes arrayelement auf stack schreiben und auf stsack legen
... hier verrechnet er nun Sum mit dem stackelement
iinc 1,1 //addiert auf a eins drauf
iaload //zweites arrayelement auf stack schreiben und auf stsack legen
usw...

als assembler wird er also eine var vom array laden, dann aufsummieren und dann a inkrementieren. das ist auf einer ARM-cpu super, dürfte in 2instructions pro schleifendurchlauf resultieren, schneller geht es nicht. auf x86 generiert er ebenfalls diese instruktionen, leider ist es sehr langsam, weil die ladefunktion immer auf das resultat vom increment warten muss, der richtige weg wäre gewesen mit konstanten zu indizieren (das wiederrum geht auf arm nicht und würde emuliert werden).

man kann natürlich versuchen für diesen trivialfall eine optimierung einzubauen, ist wahrscheinlich auch in den JIT für die verschiedenen plattformen drinne, vermutlich sogar mit SIMD-optimierungen. aber wie gesagt, das ist ein trivialfall der in den ersten JIT nicht erkannt wurde und man mit bytecode-assembler ein javaprogramm trotz JIT noch locker doppelt so schnell bekommen konnte. bei komplexeren beispielen kann der JIT leider nicht hellsehen was die absicht im source war.

Optimizer schrieb:

...

Dabei gehst du davon aus, dass wegen des Bytecodes Informationsverlust auftritt. Daran glaube ich noch nicht und es würde mich interessieren, auf welche Informationen du dich dabei beziehst.

s.o., informationen sind meine erfahrungen mit bytecompilern wie java, cg usw.

Optimizer schrieb:

Amsonsten hat der JIT-Compiler eindeutig mehr Informationen/Quellen zur Verfügung, denn er hat den ganzen Source, der am Ende auf dem Computer vom Benutzer läuft, zur Verfügung und kann damit leichter modulübergreifend optimieren. Er kennt beispielsweise die Größe von fremden Objekten im Speicher und kann beim Zugriff auf Felder die Adresse ausrechnen.

1. das ist leider naiver glaube, dass das performancerelavant ist. das verrechnen einer adresse passiert bei x86 aufgrund der adressierungsmodi meist kostenlos (0 performance relevanz).
2. in den allermeisten fällen ist es nicht möglich die absolute adresse zu errechnen, weil man sonst für jeden datenbereich den eigenen code bräuchte der auf diesen datenbereich optimiert ist (das wäre weit aus langsammer), aus diesem grund gibt es weiterhin indirektion über pointer.

Nimm als Gegensatz mal COM, ein Objektmodell, dass es erlaubt, Klassenbibliotheken zur Laufzeit hinzuzulinken. Du kriegst in deiner Anwendung immer eine Indirektion (IDirect3DDevice9**) rein und ein einfacher getter kann auch nicht geinlined werden. Wenn du deine Klasse von einer COM-Klasse ableitest, besteht eine richtig physische Barriere zwischen den Membern der abgeleiteten Klassen und denen der Basisklasse.

ja, COM ist ein echt unschönes interface, hat aber nichts mit eine sprache zu tun, auch java muss über die JVM auf externe bibliotheken zugreifen, ansonsten gebe es nichtmal ein println.
das hat aber nicht wirklich viel damit zu tun, dass man beim compilieren mit c++ meist alle sourcen von den verwendeten libs hat so wie bei java der JIT die sourcen der libs hat. nur sehr selten hat man wirklich externe libs/dlls, wenn man eine applikation mit mehreren hundert klassen hat, sind vielleicht 5DLLs dabei die keine performancekritischen schnittstellen haben, wenn es nicht absolut nötig ist (z.b. spiel zu d3d9.dll)

Jetzt überleg mal, was ein JIT-Compiler im Vergleich dazu machen kann. Er erhält den Bytecode der Basisklasse und der abeleiteten Klassen.

wie gesagt, zumeist hat man alle sourcen der libs die man verwendet, nein nicht nur bei linux, auch wenn man kommerzielle libs verwendet z.b. unreal engine3, bekommt man die vollen sourcen und der c++ compiler kann direkt auf das native format compilieren ohne zwischendurch informationen zu verlieren.

Optimizer schrieb:

...

Ich beziehe mich dabei auf Informationen, die nicht notwendigerweise bei jedem Programmstart gleich sind. Beispielsweise linke ich eine DLL hinzu, dort drin befindet sich die Konstante FOOBAR. Ich kann dir mit Sicherheit garantieren, dass jedes Vorkommen dieser Variable vom JIT mit dem Wert ersetzt wird. Bei einem fertig compiliertem Programm steht dagegen schon fest in deinem Code "rechne Basisadresse + offset" und lies den Wert der Variablen aus". Im Grunde ist es hier das selbe wie mit dem Inlinen von Methoden, die sich in DLLs befinden.

das hängt mit der unterschiedlichen definition von "konstante" ab und überlebt keinen direkten performancevergleich.
eine konstante von java ist mit einem enum bzw #define von c++ vergleichbar, nicht jedoch mit einer const. aus diesem grund hast du nach dem kompilieren die gleichen optimierungen wie bei java.
eine c/c++ const ist als const anders definiert. bei z.b. einer static const ist die adresse immer gleich für die ganze app, je nach OS kannst du dann diese const zur laufzeit auch noch umstellen (bei windows kann man meines wissens nach mit ein paar undokumentierten api-calls das segment in dem die const liegt write-able machen und überschreiben).

Bei .Net gibt so genannte Application Domains. Vereinfach ausgedrückt erlauben die, ein anderes Programm im selben Betriebssystem-Prozess zu starten, mit der gleichen vollständigen Isolierung der Zustände, aber mit geteilten Resourcen, z.B. bereits JIT-compilierter Code und natürlich nur einmaliger VM-Overhead.

ich bezog mich hier auf java, aber auch da wäre es sicherlich möglich beim verknüpfen von OS und JVM sowas zu integrieren, gibt es auf dem SunOS meines wissens nach auch bei der serverversion der JVM.

Es gibt viele tolle Möglichkeiten, aber die Win32-Altlasten machen bei vielen Dingen noch einen Strich durch die Rechnung. Es ist beispielsweise reichlich unnötig, einen VM-Prozess vom BS-Speicherschutz überwachen zu lassen, wenn man schon garantieren kann, dass keine access violations auftreten. Die Praxis sieht für solche Systeme halt noch eher schlecht aus.

tjo, aber da der speicherschutz von der hardware 4free ist, who cares?

Optimizer schrieb:

Natürlich geht nie in jeder Sprache alles, sonst wäre der Sinn von mehreren Sprachen irgendwie weg. Man hat immer nur eine gemeinsame Untermenge an Features zur Verfügung, nicht alle Features stehen jeder Sprache offen.

nicht nur unterschiedliche features, sondern auch auslegungen und java wurde nicht für performance ausgelegt, no no und c++ nicht für write once, run everywhere.

Optimizer schrieb:

es ist aus meiner sicht der schlechtere weg. der c++ compiler hat alle sourcen meistens zur verfügung um daraus das beste binary zu generieren. DLLs und andere module sind meist komplett abgeschlossene bereiche mit schnittstellen, die nicht performancekritisch sind.

Dem widerspreche ich. Ich möchte nicht darauf verzichten, von Bibliotheksklassen abzuleiten und Methoden zu ergänzen oder zu redefinieren. All das wäre reichlich inperformant, wenn die Klassen aus irgendwelchen DLLs kommen. Oder stell dir mal vor std::map<> käme aus einer DLL! "Nicht performancekritisch" ist ein statisches System nur, wenn du bereit bist, auf bestimmte Features zu verzichten.

wie ich schon sagte, meistens hat man alle sourcen zu verfügung. ein modul/eine lib ist keine aussage darüber, dass es physikalisch getrennt ist. ich kann mir die boost dazucompilieren oder die nebulaengine und irgens wird festgelegt, dass die in seperaten dlls sein müssen. somit bleib ich dabei, dass dlls nur komplett abgetrennte bereiche darstellen und meistens nicht performancekritische schnittstellen haben (ausnahmen sind nunmal dinge wie z.b. d3d9).

Optimizer schrieb:

Alles was performancekritisch ist, ist meistens in einem binary für sich und es wurde aus dem source direkt ins binary optimiert. bei java wird meines wissens nach jede klasse zu einem bytecode-objekt und danach erst mit JIT zusammengefasst, an der stelle des byte-objekts ist bei c++ hingegen schon jede optimierung gelaufen und würde selbst mit einem JIT nichts mehr reissen können.

Jede mögliche Optimierung ist gelaufen. Und was ist schlecht daran, wenn erst der JIT optimiert?

wenn du dich ein wenig mehr mit compilern beschäftigst, siehst du dass es viel einfacher ist code zu optimieren der unoptimiert ist, als optimierten source/bytecode. das trifft z.b. auch auf shadercompiler zu und wird von den herstellen explizit gesagt, dass man z.b. beim compilieren von cg zu glsl unopptimierten code machen soll, weil dann die compiler mehr ihr eigenes potential ausspielen können.
ein compiler kann z.b. eine normalisierungs eines vectors vornehmen. vielleicht kann er sogar so intelligent sein und zwei vectoren mit nur einer reciproken berechnung normalisieren
pseudocode

vec V1, V2;
...
float L1=V1.Len();
float L2=V2.Len();
float iL=1.f/(L1*L2);
V1*=iL*L2;
V2*=iL*L1;

dieser code ist vermutlich schneller als wenn er zwei divisionen hätte... oder? leider würde der nächste compiler der drüber geht nicht mehr den sinn dieses codes erkennen. also dass man v1.normalize(); machen möchte. falls nun die cpu ne optimierung hat für ein superschnelles normalize, würde dieses potential nicht ausgenutzt werden.

aus diesem grund sollte code unoptimiert möglichst als source direkt auf nativen microcode compilert werden.
ist in etwa so wie beim packen. gibst du einem guten packer rohdaten, generiert er dir zumeist bessere final-packergebnisse, als wenn du ihm die schon vorgepackt von anderer software gibst.

Optimizer schrieb:

java wurde nicht entwickelt um
1. schnell zu sein und ne performancekrone zu erhalten (im gegenteil, wurde anfangs nur mit interpretern ausgeliefert und mußte später JITs erhalten, damit es nicht 10x langsammer läuft als andere sprachen, nachdem MS für j++ soeinen erstellte)

Das ist auch genau der Grund, warum die Praxis für Java schlechter aussieht. Aber ich bin mal gespannt, wie .Net Programme in Zukunft laufen werden. Ich bin überzeugt, dass das Konzept eines Zwischencodes überlegen ist. Dabei muss man Sprachen und Reife der Compiler außer Acht lassen. Schon jetzt ist ein C++/CLI Programm mit JIT-Compilierung kaum langsamer als das gleiche C++ Programm.

[/quote]
ich kenne viele beispiele, dass es dem nicht so ist. ich kenne z.b. einen sehr guten programmierer der auf .net schwört und raytracer an der uni in utah schreibt. trotz seines wirklich guten wissens und könnens der sprache und der materie waren die raytracer der meisten anderen die in c/c++ programmiert wurden im schnitt ca 4mal schneller (laut seiner aussage), aber es stört ihn nicht wirklich, da sein tracer sehr gut designed und erweiterbar ist, deswegen hat er gegen ende sehr viel weniger zeit mit programmieren verbringen müssen als die anderen (dafür aber sehr viel mehr gewartet bis sein tracer fertig ist).
und ich hab sehr viele andere beispiele die das selbe sagen.

rapso

DEvent schrieb:

Was hat das mit Java zu tun ? Rechnet Java falsch oder rundet es falsch ?

das war nur ein _beispiel_ dafür, dass sehr kleine ursachen große schäden verursachen können.

Ich würde sagen daduch, das man die Speicherverwaltung Profis überlässt, die Tagein Tagaus nichts anderes machen als den GC zu optimieren, sorgt man dafür das die Software sicherer ist.
Ein C++ Programmierer muss sich sorgen machen über die normale Implementation der Algorithmen und um die Speicherverwaltung. Bei Java und C# hat man es getrennt: Ein Spezialist arbeitet an der Speicherverwaltung, ein anderer an den Algorithmen.
Ausserdem ist es durch den wegfall der Zeiger eher sicherer :p

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.

DEvent

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?

rapso

Gregor schrieb:

Man braucht aber letztendlich sowieso nur ganz wenige Sprachen.

ich eben auch, ich nutze das, was das ziel am besten erfüllt.
engines mit c++, serverprogramme mit java, applets mit java, spiele mit lua/anderescriptsprachen.

wozu sollte man da versuchen auf biegen und brechen was anderes zu nehmen? wenn ich kein java könnte, würd ich server mti c und applets mit flash schreiben. ich weiß echt nicht wozu man immmer java/c# als schneller oder genausoschnell debatieren muss. nur weil es marketingheinis rausposaunen? es streitet sich doch auch niemand dauernd ddrüber ob c oder java platformunabhängiger ist. wozu dann dauernd wegen performance?

DEvent

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 ?

rapso

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.

DEvent

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.

Gregor

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"?

Gregor

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.

groovemaster

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

DEvent

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.

Jester

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.