Java Native compilation

[B-Man]

Ik draai een multithreaded java app die 24/7 on-line is. Aangezien deze app alleen op linux draait (en op indentieke machines) ben ik aan het kijken naar native compilation en de (mogelijke) performancewinst.

mbravenboer: wat weet jij hierover?

Ook heb ik gelezen over Java-to-c translators. Geen info over performance.

Ik wil zoveel mogelijk uit de app halen als mogelijk is. Daarom ben ik aan het kijken of native compilation kan zorgen voor performancewinst of niet.

[mbravenboer]

Performance winst is over het algemeen niet zo groot. Vooral het geheugengebruik en de opstarttijd (dit hangt natuurlijk samen) verbeterd wel met native compilatie. Hotspot zorgt bij een langer lopend process zelf al voor native compilatie, dus voor server-side werk lijkt het mij eigenlijk minder zinvol.

Je kan GCJ eens proberen. Als je geen GUIs gebruikt schijnt dat wel aardig te functioneren .

[Alarmnummer]

Ik denk dat de voornaamste performance winst komt uit een goed ontwerp. Als je alles bv loopt te synchroniseren dan zal je programma (naar native code gecompileerd) ook langzaam zijn. Java heeft misschien op gui gebied een slechte naam, maar aan de server side dat de performance geloof ik niet veel onder voor c/c++.

En door de fantastische debugging faciliteiten/stack traces/ingebouwde beveiligingen in de taal, heb je ook de tijd om veel aandacht te geven aan je ontwerp. Ik zou dus helemaal afstappen van het idee van native code.

Ik weet wel dat er binnenkort ook een JET versie uitkomt voor linux. http://www.excelsior-usa.com/jetdlbeta.html
Hiermee kan je je java code (1.4beta3) naar native code compileren.

[mbravenboer]

Alarmnummer: Als je alles bv loopt te synchroniseren dan zal je programma (naar native code gecompileerd) ook langzaam zijn.

Synchronisatie was inderdaad altijd vrij duur. In de nieuwere VMs zijn de kosten van het in en uit gaan van monitoren wel drastisch afgenomen .

Uiteraard kost het aanmaken van onnodige monitoren nog steeds onnodig veel tijd. Ik zou dan ook altijd een splitsen in meerdere monitoren als dat mogelijk is. Synchronized in een methode-naam zetten is vaak te kort door de bocht. Als je aparte locks maakt voor de verschillende regio's die beveiligd moeten zijn krijg je kleinere monitoren en vaak ook meer multi-threading .

[Alarmnummer]

Op vrijdag 18 januari 2002 09:38 schreef mbravenboer het volgende:

[..]

Synchronisatie was inderdaad altijd vrij duur. In de nieuwere VMs zijn de kosten van het in en uit gaan van monitoren wel drastisch afgenomen .

Uiteraard kost het aanmaken van onnodige monitoren nog steeds onnodig veel tijd. Ik zou dan ook altijd een splitsen in meerdere monitoren als dat mogelijk is. Synchronized in een methode-naam zetten is vaak te kort door de bocht. Als je aparte locks maakt voor de verschillende regio's die beveiligd moeten zijn krijg je kleinere monitoren en vaak ook meer multi-threading .

Het diende ook als voorbeeld Wat ik ermee duidelijk wil maken is dat de meeste snelheids winst valt te halen uit een goed design(met de nadruk dit keer op performance) ipv naar native code compileren.

[Alarmnummer]

Maarja... als je het programma toch al klaar hebt je hoeft niets te herdesignen als je naar native code compileerd. En krijg misschien op een zeer eenvoudige manier een performance boost (wat ik mij eerlijk gezegd dus afvraag vanwege de kwaliteit van de huidige jre`s).

dit is trouwens wel een aardig artikel.
http://www.javalobby.org/fr/html/frm/javalobby/features/jpr/part4.html

[leuk_he]

zie eens

http://www.bearcave.com/software/java/comp_java.html

http://www.geocities.com/SiliconValley/Lakes/6686/java.html

Met andere woorden: gewoon eens wat tijd in steken of het voor jouw werkt en sneller is. (bepaalde dingen kunnen eigelijk niet goed gecompileerd worden).

Had er vandaag zelf ook net naar lopen zoeken.

[B-Man]

Bedankt voor de reacties.

Ik stelde de vraag omdat het me na het lezen van een aantal on-line artikelen niet duidelijk was wat er globaal over te zeggen is. De app heeft nog genoeg zaken die verder geoptimaliseerd kunnen worden. Het ontwerp is goed, de ontwikkeltijd was gelimiteerd door een budget. Ik ben nu (globaal) aan het kijken welke optimalisatie mogelijkheden er zijn buiten optimalisatie van de bestaande code.

Het gaat om een java server die veel e-mail verzend. Ik heb voor java gekozen vanwege de portabiliteit (ten tijde van het maken van het ontwerp werd er nog gesproken over het draaien op verschillende platformen), en gemak van onderhoud.

De app draait momenteel op Sun's JRE voor linux.