JNode = Java = langsam

[iGi]

> Jein, du vergisst, das Sun Java oft schon viel
> früher zu native code wechselt als man denkt. Z.B.
> image io, zip file, und ähnliches sind oft schon
> sehr früh in native code geschrieben. Da haben wir
> 100% Java Code und somit (hoffentlich ;)) einen
> Vorteil.
Das verstehe ich nicht. Wie bekommt Ihr denn euren Javacode so optimiert und compiliert, daß er schneller als nativer code von Sun läuft? Meinst Du, weil der native Code von sun einfach schlechter programmiert ist?
Sorry, wenn ich was verpeile, aber hatte länger nichts mit Java zu tun...

[MeineMeinung]

Peda schrieb:
-------------------------------------------------------

> Bzgl des "Java = langsam" geb ich dem vorposter im
> Moment noch Recht. Wir besitzen zwar bereits
> keinen Interpreter mehr sondern kompilieren alles
> per JIT beim ersten ausführen, jedoch ist dieser
> Compiler noch etwas "dumm". Für die nächste
> Version ist jedoch geplant jikes zu integrieren,
> was JNode massive beschleunigen wird. Ich denke
> das "Java = langsam" wird in Zukunft kein Argument
> mehr gegen Java/JNode sein, höchstens der erhöhte
> Speicherverbrauch.

Ich weiß ja nicht für welche Zielgruppe JNode Entwickelt wird. Bei normalen Arbeitsprogrammen reicht die Geschwindigkeit i.d.R. aus. Vor allem bei modernen PCs.

Es gibt genügend kleine Firmen, welche nur einen Webbrowser und Ihre Kaufmännische Software benötigen. Dazu dann noch OpenOffice. Alle Rechner sind über DHCP angeschlossen.

Wenn ein Rechner ausfällt, dann stellt man halt ggf. einen neuen Rechner hin und spielt ein neues Image auf die Platte. Falls man bei so einem Rechner überhaupt noch eine Platte einbaut ....

Ich wäre begeistert wenn JNode irgendwann mal den Grundstein für diesen Anwendungsfall legen könnte.

[Peda]

iGi schrieb:
-------------------------------------------------------
> > Jein, du vergisst, das Sun Java oft schon
> viel
> früher zu native code wechselt als man
> denkt. Z.B.
> image io, zip file, und ähnliches
> sind oft schon
> sehr früh in native code
> geschrieben. Da haben wir
> 100% Java Code und
> somit (hoffentlich ;)) einen
> Vorteil.
> Das verstehe ich nicht. Wie bekommt Ihr denn euren
> Javacode so optimiert und compiliert, daß er
> schneller als nativer code von Sun läuft? Meinst
> Du, weil der native Code von sun einfach
> schlechter programmiert ist?
> Sorry, wenn ich was verpeile, aber hatte länger
> nichts mit Java zu tun...
>

Also im Moment ist er eher viiieeeel langsamer als Sun ;)
Es geht also erst mal nur um die Theorie (bzw jikes, sobald fertig integriert :)). Jeder JNI Aufruf kostet einfach extra Zeit und man braucht dann im native code z.B. auch extra Code um dem gc über Objekte und Referenzen zu informieren. Da hast du einfach einen extremen Overhead. Des weiteren wurde der native code ahead-of-time kompiliert, der Java code per JIT. D.h. da erwarten wir auch einen Vorteil. Man kann über allen Code Statistiken anlegen, branch prediction ausnutzen,... Es gibt da eine Menge Seiten die die Vorteile eines JITs gegenüber AOT Compilern erklären, will ich hier jetzt nicht nochmal alles ausführen ;) Auf jeden Fall können wir diesen JIT Vorteil dann auf das komplette System anwenden, nicht wie bei Sun, wo ab dem JNI Aufruf einfach Schluss ist.

Ob der JIT dann wirklich besseren Code als der native code von Sun erzeugt ist nochmal eine andere Frage.. ich bin davon fest überzeugt :) Wir werden es aber sehen, sobald der optimierende Compiler erst mal läuft :)

Peter

[Tropper]

Peda schrieb:
-------------------------------------------------------
> Also im Moment ist er eher viiieeeel langsamer als
> Sun ;)
> Es geht also erst mal nur um die Theorie (bzw
> jikes, sobald fertig integriert :)). Jeder JNI
> Aufruf kostet einfach extra Zeit und man braucht
> dann im native code z.B. auch extra Code um dem gc
> über Objekte und Referenzen zu informieren. Da
> hast du einfach einen extremen Overhead. Des
> weiteren wurde der native code ahead-of-time
> kompiliert, der Java code per JIT. D.h. da
> erwarten wir auch einen Vorteil. Man kann über
> allen Code Statistiken anlegen, branch prediction
> ausnutzen,... Es gibt da eine Menge Seiten die die
> Vorteile eines JITs gegenüber AOT Compilern
> erklären, will ich hier jetzt nicht nochmal alles
> ausführen ;) Auf jeden Fall können wir diesen JIT
> Vorteil dann auf das komplette System anwenden,
> nicht wie bei Sun, wo ab dem JNI Aufruf einfach
> Schluss ist.

Also irgendwie blick ich bei euch nicht mehr durch. Ich hab mich gestern schon die ganze Zeit gefragt warum Du die ganze Zeit von jikes redest.

Also gestern hast Du gesagt das das komplette Programm beim Start kompiliert wird und nicht wie bei Sun die hotspots. Demnäch hätte ihr aber kein JIT Compiler sondern auch einen AOT Compiler am Werk. Zusätzlich hätte jikes damit nichts am Hut; jikes kompiliert java Sourcecode in Bytecode und nicht in Native-Code.

Irgendwie verwirren mich deine Aussagen hier...

Tropper

[Peda]

Tropper schrieb:
-------------------------------------------------------
> Peda schrieb:
> --------------------------------------------------
> -----
> > Also im Moment ist er eher viiieeeel
> langsamer als
> Sun ;)
> Es geht also erst
> mal nur um die Theorie (bzw
> jikes, sobald
> fertig integriert :)). Jeder JNI
> Aufruf
> kostet einfach extra Zeit und man braucht
>
> dann im native code z.B. auch extra Code um dem
> gc
> über Objekte und Referenzen zu
> informieren. Da
> hast du einfach einen
> extremen Overhead. Des
> weiteren wurde der
> native code ahead-of-time
> kompiliert, der
> Java code per JIT. D.h. da
> erwarten wir auch
> einen Vorteil. Man kann über
> allen Code
> Statistiken anlegen, branch prediction
>
> ausnutzen,... Es gibt da eine Menge Seiten die
> die
> Vorteile eines JITs gegenüber AOT
> Compilern
> erklären, will ich hier jetzt nicht
> nochmal alles
> ausführen ;) Auf jeden Fall
> können wir diesen JIT
> Vorteil dann auf das
> komplette System anwenden,
> nicht wie bei Sun,
> wo ab dem JNI Aufruf einfach
> Schluss ist.
>
> Also irgendwie blick ich bei euch nicht mehr
> durch. Ich hab mich gestern schon die ganze Zeit
> gefragt warum Du die ganze Zeit von jikes redest.
>
> Also gestern hast Du gesagt das das komplette
> Programm beim Start kompiliert wird und nicht wie
> bei Sun die hotspots. Demnäch hätte ihr aber kein
> JIT Compiler sondern auch einen AOT Compiler am
> Werk. Zusätzlich hätte jikes damit nichts am Hut;
> jikes kompiliert java Sourcecode in Bytecode und
> nicht in Native-Code.
>
> Irgendwie verwirren mich deine Aussagen hier...

Hehe ok. Also als erstes mal, kann man unseren Compiler natürlich auch als AOT Compiler betrachten, jedoch können und werden wir, sobald es die Statistiken verlangen Code rekompilieren. Deshalb spreche ich von JIT. Gedacht ist das ganze so: Alles wird per primitiv compiler kompiliert, damit es schnell geht, die HotSpots werden dann zu gegebener Zeit nochmal optimiert kompiliert ;)

Zu Jikes, sorry, ich vereinfache das. Ich rede nicht vom jikes compiler sondern von Jikes-rvm ;) Jikes-rvm besteht aus einer VM, verschiedenen optimierenden JITs, mmtk (memory management toolkit, also Allocator und GCs) und Scheduler. Wenn ich also Jikes sage mein ich Jikes-rvm ;)

Ich hoffe nun ist alles klar :)

Peter

[knopkin]

Peda schrieb:
-------------------------------------------------------
> >
> Und wie im Artikel richtig steht, liefern wir
> einen vmx file mit aus, so dass man JNode sehr
> einfach mal im kostenlosen vmware-player testen
> kann. Ihr seid also alle herzlich eingeladen zu
> testen ;)
>
> Peter
>

Hi,

ich finde auf der seite die 0.2.4er Version nicht zum downloaden!

Ist Sie noch irgendwo versteckt?

Gruß
Knopkin

[Tropper]

knopkin schrieb:
-------------------------------------------------------
> ich finde auf der seite die 0.2.4er Version nicht
> zum downloaden!
>
> Ist Sie noch irgendwo versteckt?
>

Oben rechts auf "Latest Release" clicken. Dann landest du auf:
http://www.jnode.org/node/892

Da findest Du dann die downloads.

Tropper