C++ oder Java

Naja, der Vergleich OpenGL zu DirectX hinkt aber schon ein Wenig. Das ist etwa wie Notepad zu Office. Die meisten Leute sehen leider bei DirectX nur das augenscheinliche - die Grafik, dabei ist es VIEL mehr.

Das soll aber keine Kritik an OpenGL sein; das macht seine Sache sehr gut, soweit ich weiß. Ist schon ziemlich lange her, dass ich mich damit beschäftigt habe.

Halloechen,

the ubm schrieb:

Java ist wegen dem ManagedCode definitiv langsamer

Zum Vergrößern anklicken....

Nö, isses nicht - dank JIT. Wie gesagt, frueher war die Aussage sicher mal richtig.

Gruss, FFNB.

Du verwechselt da etwas.
Bei Java hast du Bytecode, bei C++ Maschinencode.
Das JavaRuntime-Enviroment erzeugt zur Laufzeit den für das jeweilige System notwendigen Maschinencode, der dann gecacht werden kann.
Dieser erzeugte Maschinencode kann gecacht werden, sodass die notwendige Kompilierung zur Laufzeit entfallen kann. Das Problem der Indexprüfung bleibt aber bestehen, da führt kein Weg dran vorbei.

http://www.zdnet.de/sicherheits_ana...s_ist_besiegelt_story-39001544-41003020-4.htm
Hier ist das ganze auch nochmal sehr schön erklärt.

Halloechen,

das liegt aber nicht an Java sondern am Compiler. Nimmst Du den GNU Compiler kannst Du den auch unmanaged code erzeugen lassen.

Aber in der Regel bringt das kaum Geschwindigkeitszuwachs - ist halt abhaengig davon, was man macht.

Gruss, FFNB.

Java Code ist immer managed und managed Code ist langsamer.
Der Microsoft Compiler erzeugt auch standarmäßig unmanaged Code.

Von Managed Code spricht man eigentlich nur bei .NET. Welchen Code der C/C++-Compiler vom Microsoft erzeugt hängt vom ausgewählten Projekt ab. Default gibt's da keinen.

Java wird in Bytecode kompiliert, der dann von einer Virtuellen Maschine ausgeführt wird. Das Ausführen des Bytecodes ist natürlich langsamer als Maschinencode. Mit der Entwicklung der JIT-Compiler wird dieser Nachteil aber zum Großteil aufgehoben. Der JIT kompiliert zur Laufzeit den Bytecode in Maschinencode, so daß dieser unter Umständen sogar schneller ist als der Maschinencode eines C++-Programms, da dieser das Laufzeitverhalten in seine Optimierungen miteinbeziehen kann.

Natürlich ist Maschinencode ohne Indexüberprüfung schneller als mit. Allerdings spielen die paar Taktzyklen in 99,99% aller Programme absolut keine Rolle. Außer man betreibt Numbercrunching mit Millionen von Rechenoperationen pro Sekunde.

Von Managed Code spricht man eigentlich nur bei .NET. Welchen Code der C/C++-Compiler vom Microsoft erzeugt hängt vom ausgewählten Projekt ab. Default gibt's da keinen.

Zum Vergrößern anklicken....

Falsch. Managed bedeutet unter anderem, dass es einen Garbage Collektor gibt und somit keine Speicherlecks entstehen können.

Allerdings spielen die paar Taktzyklen in 99,99% aller Programme absolut keine Rolle.

Zum Vergrößern anklicken....

Global spielt das eine enorme Rolle, da hierdurch ein viel höherer Stromverbrauch zu stande kommt. Bei Laptops merkt man es dann direkt an verringerter Akkulaufzeit.

the ubm schrieb:

...Das Problem der Indexprüfung bleibt aber bestehen, da führt kein Weg dran vorbei....

Zum Vergrößern anklicken....

Der vorhin erwaehnte GNU-Compiler kann mit der Option "--no-bounds-check" diese Pruefung unterbinden. Von daher ist "da fuehrt kein Weg dran vorbei." so nicht richtig.

the ubm schrieb:

Java Code ist immer managed und managed Code ist langsamer.

Zum Vergrößern anklicken....

Das Code, welcher in einer VM laeuft, als Managed bezeichnet wird, hab ich ja nun eingesehen. Aber wie kommst Du darauf, dass managed Code grundsaetzlich langsamer sein soll? Die Indexpruefung kann man ja nun schonmal aussen vor lassen, da abschaltbar. Managed muss ja nicht zwingend overhead bedeuten, welcher verlangsamt sondern kann auch optimierungspotential bergen.

Vielleicht sollten wir mal ein Apfelmaennchen bauen. Du in C und ich in Java und dann "benchen" wir mal um die Wette.

Gruss, FFNB.

PS: Nein, dass soll kein "rumgeflame" werden, mich interessiert wirklich wie Du darauf kommst.

Der vorhin erwaehnte GNU-Compiler kann mit der Option "--no-bounds-check" diese Pruefung unterbinden. Von daher ist "da fuehrt kein Weg dran vorbei." so nicht richtig.

Zum Vergrößern anklicken....

Der GNU Compiler erzeugt doch C Code. Java Code nur der Compiler von Sun oder irre ich?

Und wie gesagt da ist dann noch das Problem bei der Vererbung und dem Überschreiben von Methoden. Bei Java muss immer in einer Tabelle nachgeschaut werden, welche Methode mit dem selben Namen zum Einsatz kommen soll (Polymorphismus). Bei C++ geschieht das nur, wenn die Methoden explizit als virtual und damit als überschreibbar deklariert wurden.

the ubm schrieb:

Der GNU Compiler erzeugt doch C Code. Java Code nur der Compiler von Sun oder irre ich?

Zum Vergrößern anklicken....

GNU gibts doch für Java auch, heißt dann GCJ (statt gcc oder g++).

The GNU Compiler for the JavaTM Programming Language

Zum Vergrößern anklicken....

Ok danke. Wieder was dazugelernt.
Es ist tatsächlich möglich die Überprüfung der Indizes zu deaktivieren.

Ein gewisser Overhead muss aber weiterhin existieren, da sonst der Ausdruck "array.length" welcher die Größe des Arrays zurückliefert nicht funktionieren würde.