64 Bit Java Anwendungen - Allgemeiner Thread

[pocketom]

Wenn man in der SuFu versucht etwas zu "64 Bit" zu finden, so könnte man meinen die Boardsuche ist kaputt. Keine Ergebnisse hierzu. Da ich sicher nicht der Einzige sein dürfte der sich Gedanken über den Einsatz von Java in leistungsfähigen 64 Bit Umgebungen macht, eröffne ich mal einen allgemeinen Thread zu diesem Thema.


Zum Einstieg fällt mir dazu mal folgendes ein:




ALLGEMEIN

Was ist grundsätzlich anders unter 64 Bit, was muss generell beachtet werden?

Vorteile - Nachteile JAVA 32 Bit vs. JAVA 64 Bit?

Müssen (oder sollten) 64 Bit Programme mit einem 64 Bit JDK erstellt werden?


SPEZIELLER

Was ist bei der Entwicklung von reinen 64 Bit Anwendungen im Gegensatz zur Entwicklung für 32 Bit Systeme besonders hervorzuheben?

Wie nutzt man 64 Bit auch wirklich aus, wie kann man die Performance gegenüber 32 Bit effektiv erhöhen (z.B. Stichwort Datentypen)?

Welche konkreten Änderungen ergeben sich aus Sicht des Codes (gibt es spezielle optimierte Klassen, Bibliotheken für 64 Bit)?



Des weiteren soll dieser Thread dazu dienen um allgemeine Tipps, Tricks und HowTos zum Thema zu sammeln.





Vieleicht noch kurz zu meinem Hintergrund: Seit einigen Tagen haben wir in der Firma eine "Mörderkiste" mit 2 Quadcore 64Bit Intel Prozessoren, 16 GB RAM und pfeilschnellen Festplatten. Nun möchte ich mit meinen Java Anwendungen (Bioinformatik) aus der Kiste natürlich alles rausholen ;-)

 

[HLX]

Unter diesem Link findest du umfangreiche Informationen zum Thema.

 

[tuxedo]

Siehe auch: http://www.java-forum.org/de/topic56471_java-64-bit.html

 

[Guest]

HI, die beiden Quellen kannte ich schon. Die Infos auf Sun sind denke ich auch nicht mehr ganz aktuell, mittlerweile gibts ja auch SE 6.0 in 64 Bit. Hat irgendwer damit Erfahrung? Ich habe das jdk6u2 mal auf der Kiste unter RedHat installiert. Hat irgendwer hier damit schon Erfahrung?
Es scheint zu laufen "java -version" zeigt mir zumindest die aktuelle Version an. Nur meine Programme laufen damit noch nicht. Muss ich die mit dem 64 Bit JDK neu erstellen? Sind noch mit der 32 Bit Variante von SE 6u2 kompiliert...

Kennt irgendwer noch gute Quellen? Mich würden Infos zu elementaren Veränderungen interessieren, z.B. sollen sich elementare Datentypen geändert haben...

 

[pocketom]

Das hier scheint nützlich zu sein:

Porting to 64-bit GNU/Linux Systems

 

[Guest]

Das hier scheint nützlich zu sein:

Porting to 64-bit GNU/Linux Systems

Und inwiefern hat dies eine Relevanz zu Java? Deine Programme, die mit dem 32-Bit Java Compiler erstellt wurden,
laufen auch bei einer 64 Bit VM.

 

[pocketom]

Und inwiefern hat dies eine Relevanz zu Java? Deine Programme, die mit dem 32-Bit Java Compiler erstellt wurden, laufen auch bei einer 64 Bit VM.

Das ist falsch. Siehe Will 32-bit native code work with a 64-bit VMs?

Aus eigener Erfahrung kann ich bestätigen das es nicht funktioniert. 32 Bit Java Anwendungen können natürlich auf einem 64 Bit System mit einer 32 Bit VM ausgeführt werden. Für kleine Programme kann das sicherlich ok sein, für speicher- und rechenintensive Anwednungen aber herzlich sinnfrei (siehe meinen Anwengungszweck!).

Bitte beachten, der Titel dieses Threads heißt nicht "Wie mache ich es mir unter 64 Bit besonders leicht?"... Hier geht es darum 64 Bit zu NUTZEN und nicht 32 Bit anzuwenden ;-)

 

[Guest]

@pocketom
Du hast bis zu deiner letzten Antwort mit keinem Wort JNI genannt, daher bin ich davon ausgegangen, dass es dir
um reine Java-Anwendungen geht (also nur Bytecode). Wie auch immer, viel Spass mit dem neuen Spielzeug.

 

[pocketom]

SWT halt... :shock:

Was aber mittlerweile garnicht mehr so das Problem ist, die Anforderungen an die GUI sind nicht hoch.

Mittlerweile läuft das Programm unter 64, Aufwand der Umstellung war moderat. Das wertvollste was ich bis jetzt so erkennen kann, ist bis jetzt das man plötzlich viel mehr Speicher adressieren kann. Auslagern ade. Kann man ungefähr sagen wieviele Objekte man gleichzeitig im Speicher halten kann (für den Fall man hätte einen riesigen Hauptspeicher von sagen wir 512 TB)?

 

[Guest]

SWT halt... :shock:

Seit dem M1-Release von Eclipse 3.4 ist SWT komplett auf 64 Bit portiert (siehe http://www.eclipse.org/swt/R3_4/plan.html).
Auf der Seite des SWT Projekts stehen auch die aktuellen Versionen zur Verfügung. Läuft super unter Vista x64. :applaus:

Mittlerweile läuft das Programm unter 64, Aufwand der Umstellung war moderat. Das wertvollste was ich bis jetzt so erkennen kann, ist bis jetzt das man plötzlich viel mehr Speicher adressieren kann. Auslagern ade. Kann man ungefähr sagen wieviele Objekte man gleichzeitig im Speicher halten kann (für den Fall man hätte einen riesigen Hauptspeicher von sagen wir 512 TB)?

Ist das der neue Aldi-PC? :lol:
Du hast ein richtiges Luxusproblem. Was ist das für ein Schrank, den du da zum Spielen hast? Deep Thought? :bae:

 

[pocketom]

Das war eigentlich eher eine theoretische Frage... ;-) Wo ist die Grenze für die Anzahl der Objekte ca., mal angenommen man aht unendlich viel Hauptspeicher? Gibts überhaupt eine?

 

[AlArenal]

Das war eigentlich eher eine theoretische Frage... ;-) Wo ist die Grenze für die Anzahl der Objekte ca., mal angenommen man aht unendlich viel Hauptspeicher? Gibts überhaupt eine?

Wenn der Rechner unendlich viel Speicher hat, kann ih auch annehmen, dass darauf eine unendlich weit entwickelte VM läuft, die dann selbstverständlich auch unendlich viele Objekte unterstützt.

Dummerweise sind dererlei Gedankenspiele auch unendlich nutzlos

 

[pocketom]

Theoretischen Fragen sind in keinster Weise nutzlos. Wir müssen uns Gedanken darüber machen ob wir mit Java auch morgen noch gut bedient sind. Wenn der Hauptspeicher ausgeht dann erweitern wir den einfach. Wenn die VM aber eh nicht genügend Objekte zulässt um den dann auszunutzen, ist eine Speichererweiterung eventuell sinnlos.

 

[Guest]

Theoretischen Fragen sind in keinster Weise nutzlos. Wir müssen uns Gedanken darüber machen ob wir mit Java auch morgen noch gut bedient sind. Wenn der Hauptspeicher ausgeht dann erweitern wir den einfach. Wenn die VM aber eh nicht genügend Objekte zulässt um den dann auszunutzen, ist eine Speichererweiterung eventuell sinnlos.

Solange keiner auf die Idee kommt, Pointer und Pointerarithmetik in den Sprachumfang von Java aufzunehmen,
dürfte es keine Probleme geben, den referenzierbaren Adressraum innerhalb der VM mit jeder Prozessorgeneration
zu erhöhen. Bestehender Bytecode wird davon kaum berührt.

 

[Leroy42]

Wenn der Rechner unendlich viel Speicher hat, kann ih auch annehmen, dass darauf eine unendlich weit entwickelte VM läuft, die dann selbstverständlich auch unendlich viele Objekte unterstützt.

Aber nur abzählbar unendlich viele! :meld:

Irgendwie schade...

 

[AlArenal]

Theoretischen Fragen sind in keinster Weise nutzlos. Wir müssen uns Gedanken darüber machen ob wir mit Java auch morgen noch gut bedient sind. Wenn der Hauptspeicher ausgeht dann erweitern wir den einfach. Wenn die VM aber eh nicht genügend Objekte zulässt um den dann auszunutzen, ist eine Speichererweiterung eventuell sinnlos.

Ja, ich bin sicher auf solche Ideen kommt bei Sun niemand, da deren Server ja bekanntlich dem Gates-Credo "640 KB sind genug" folgen. Mir schlottern schon die Knie...

 

[hupfdule]

Theoretischen Fragen sind in keinster Weise nutzlos. Wir müssen uns Gedanken darüber machen ob wir mit Java auch morgen noch gut bedient sind.

Kommt darauf an, was du unter "morgen" verstehst. In fünf Jahren? In fünfzig Jahren?
Im ersten Fall würde ich klar sagen "Ja". Insbesondere, da es in fünf Jahren wieder aktuellere VMs gibt, die deinen Code von heute (zumindest im Idealfall) auch noch ausführen können.
Im zweiten Fall würde ich klar "Nein" sagen. Du wirst in fünfzig Jahren mit nichts mehr glücklich sein, was du heute benutzt hast. Dafür sind die Entwicklungsschritte in der Computertechnik zu groß und zu schlecht vorherzusagen.

Wohlgemerkt, ich beziehe mich hier auf reines Java! Wenn du da noch JNI reinpfuschst, ist meine Aussage bezüglich der nächsten fünf Jahre mit Vorsicht zu genießen. ;-)

 

[pocketom]

Mit morgen meine ich eher 2 statt 5 Jahre...

Um die Frage also nochmal auf den Punkt zu bringen: Ist ein Limit bzgl. der Anzahl konkurrenter Objekte im Speicher bekannt? Wenn ja, wo liegt das in etwa?

 

[tuxedo]

AFAIK ist die Anzahl nur durch den zur verfügung stehenden Speicher selbst begrenzt (alles andere wäre ja auch irgendwie stumpfsinnig, oder??): Mehr zugesicherter Speicher -> mehr mögliche Objekte im Speicher

Korrigiert mich wenn ich falsch liege ...

- Alex

 

[pocketom]

Danke Alex, nicht mehr und nicht weniger wollte ich hören.

 

[tuxedo]

Wie gesagt, ich könnte mich auch irren. Aber rational betrachtet wäre alles andere IMHO stumpfsinnig.

- Alex

 

[Guest]

@pocketom:
ich habs mit eclipse auch mal unter 64bit versucht. hast du mittlerweile packages gefunden die besonders für 64 bit optimiert wurden?
mich würde auch sehr interessieren wie man 64 mit java richtig ausreizen kann. ich benchmarke gerade mit algorithmen für np-harte probleme (traveling-salesman). leider kann ich keinen signifikanten laufzeitunterschied zwischen 32 und 64 feststellen. beide male laufengelassen auf dem selbem rechner - ein core2duo - ohne das programm zu verändern - einmal mit 32bit redhat und mit 64bit redhat OS - beide mit jre1.6.02(_64) - es läuft unter 64 bit gradmal ganze 0,5% schneller?

wer kann hier gute (allgemeine) tuning tips für java64 geben oder kennt gute links?


v.g. martin

 

[tuxedo]

Solange du keine JVM benutzt die für 64Bit gemacht ist und drunter ein OS liegt das für 64 Bit gemacht ist und drunter auch ein 64Bit Prozessor sitzt, wird sich da auch nix tun.

- Alex

 

[pocketom]

Hast du dein Programm denn auch für 64 Bit nochmal neu kompiliert?

 

[pocketom]

Hast du mal getestet ob es auch wirklich unter der 64 Bit VM läuft, oder ob die 32 Bit Standard unter deinem 64 Bit OS ausgeführt wird? Das geht nämlich auch...

 

[tuxedo]

Kleine zwischenfrage:

Wie verhält es sich, wenn ich ein mit einem 64Bit JDK compiliertes Programm mit einer 32Bit JRE auf einem 64Bit System ausführen will? Und die gleiche Frage mit einer 32Bit JRE auf einem 32Bit System ...(System=CPU+OS)...

Hab kein 64Bit System da um's zu testen...

- Alex

 

[Guest]

tschuldigung, aber eigentlich habe ich mich doch ganz klar ausgedrückt? :autsch:


intel core2duo -> sind wie man wissen sollte sind core2 alles 64bit prozis
64bit redhat OS -> was hast du daran nicht verstanden?
jre1.6.02(_64) -> eigentlich doch auch logisch - einmal 32bit(jre1.6.02 natürlich unter 32bit redhat )
- einmal 64bit(jre1.6.02_64 natürlich unter 64bit redhat, wie auch sonst...)

das programm wurde natürlich mit der 64bit eclipse version neu kompiliert (lief anders auch garnicht...). natürlich läuft auch die 1.6.02_64 VM. jetzt alle klarheiten beseitigt? gruß martin



PS: einigen wir uns bitte darauf dass wenn von 64bit gesprochen wird immer vorrausgesetzt wird das ein 64bit prozessor, ein 64bit OS und eine 64 Bit VM verwendet wird. alles andere ist doch schwachsinn!

 

[byte]

intel core2duo -> sind wie man wissen sollte sind core2 alles 64bit prozis

falsch.

 

[tuxedo]

Kleine Randbemerkung:

Allein der Fakt dass ein 64Bit System 32Bit mehr hat als ein 32Bit System, machen das ganze nicht zwingend schneller. Die Bits sind ja in erster Linie für die Adressierung zuständig. Und wenn man nur (übrwiegend) Features nutzt die mit 32Bit komplett adressiert werden können, hat ein 64Bit System keine wirklichen Vorteile.

 

[tuxedo]

intel core2duo -> sind wie man wissen sollte sind core2 alles 64bit prozis

falsch.

Prima. Ein Wort das frei im Raum steht. Aussage gegen Aussage. Kann einer von euch das belegen? (*selbst nicht informiert bin*)

 

[byte]

intel core2duo -> sind wie man wissen sollte sind core2 alles 64bit prozis

falsch.

Prima. Ein Wort das frei im Raum steht. Aussage gegen Aussage. Kann einer von euch das belegen? (*selbst nicht informiert bin*)

Ich habe einen 32bit Intel Duo Core in meinem Notebook. Reicht das?

ich benchmarke gerade mit algorithmen für np-harte probleme (traveling-salesman). leider kann ich keinen signifikanten laufzeitunterschied zwischen 32 und 64 feststellen. beide male laufengelassen auf dem selbem rechner - ein core2duo - ohne das programm zu verändern - einmal mit 32bit redhat und mit 64bit redhat OS - beide mit jre1.6.02(_64) - es läuft unter 64 bit gradmal ganze 0,5% schneller?

wer kann hier gute (allgemeine) tuning tips für java64 geben oder kennt gute links?

wie kommst du darauf, dass 64bit schneller ist als 32bit?

 

[tuxedo]

intel core2duo -> sind wie man wissen sollte sind core2 alles 64bit prozis

falsch.

Prima. Ein Wort das frei im Raum steht. Aussage gegen Aussage. Kann einer von euch das belegen? (*selbst nicht informiert bin*)

Ich habe einen 32bit Intel Duo Core in meinem Notebook. Reicht das?

Naja, bin da auch kein Experte, bzw. bin da nicht auf dem laufenden. Aber meine "schnell-recherche" hat bis jetzt nur Core2Duo CPUs zu trage gebracht mit 64Bit Befehlssatz ... Und überall konnte ich bisher nur lesen dass diese CPU-Familie zur 64Bit-CPU-Familie gehört.

Wie ist denn die genaue Bezeichnung der CPU (Diese seltsame Intel-Nummer)?

- Alex

 

[Guest]

Leute, ihr könnt nicht gescheit lesen glaub ich.

ich habe core2duo geschrieben, und nicht "ich besitze einen INTEL UR CORE OHNE 2 UND OHNE DUO" schon im ersten posting. in der erklärung steht auch ganz klar core 2! alle core 2 sind definitiv 64bit prozessoren!
de.wikipedia.org/wiki/Core_2 auch bei intel selbst nachzulesen...

 

[tuxedo]

Was hat denn "2" mit "64" zu tun? Es gibt offensichtlich einen Dual-Core der 32bit nutzt..

The Core brand refers to Intel's 32-bit mobile dual-core x86 CPUs that derived from the Pentium M branded processors...
The Core brand was launched on January 5, 2006 by the release of the 32-bit Yonah core CPU - Intel's first dual-core mobile (low-power) processor. ....

Und lesen können wir schon. Nur gings gerade nicht um DEINE Cpu, sondern um deine Aussage, alle Intel Doppel-Kern CPUs wären 64 Bit CPUs.
Und da hattest du offensichtlich schlicht und ergreifend Unrecht (vorrausgesetzt byto hat recht, Wikipedia ist glaubwürdig und ich hab den Text korrekt interpretiert).


- Alex

[update]
ich nehme alles zurück und behaupte das gegenteil... verwirrende sache mit dem core-duo und core-2-duo ...

 

[byte]

Leute, ihr könnt nicht gescheit lesen glaub ich.

Doch, aber es war in diesem Fall einfach Unwissenheit meinerseits bzgl. des Unterschieds zwischen Duo Core und Core2 Duo. Ich entschuldige mich vielmals für diesen Fauxpas und gelobe Besserung.

Die Intel-Core-Duo-Serie ist eine Familie von 32-Bit-Mikroprozessoren für Computer.
...
Die Intel-Core-2-Duo-Serie für Desktop-Computer ist eine Familie von 64-Bit-Mikroprozessoren für Computer.

 

[Guest]

alex0801 hat folgendes geschrieben

Was hat denn "2" mit "64" zu tun?

Sag mal wie deutlich muss ich denn noch werden?
Wie byto jetzt auch schon erkannt hat, genau diese 2 hat verdammt viel mit 64 zu tun.... tut mir leid wenn ichs dir also nochmal sagen muss: WER LESEN KANN IST KLAR IM VORTEIL!

<stupide wiederholung begin>de.wikipedia.org/wiki/Core_2 </stupide wiederholung end>>

alex0801 hat folgendes geschrieben

...um deine Aussage, alle Intel Doppel-Kern CPUs wären 64 Bit CPUs.

wo hab ich diese ausssage bitteschön gemacht?

 

[tuxedo]

@Gast, nunmal nicht ausfällig werden.

Du hättest ja gleich aufdecken können dass core-duo und core-2-duo zwei paar Schuhe sind.

Einfach Fett 2 hinschreiben hilft ja nur denen die den "Trick" kennen. Bei allen anderen stiftet's massive verwirrung, wie wir jetzt unschwer erkennen konnten.

BTW: ich hatte meinen Post schon "geupdatet". Aber da war ich entweder zu schnell oder du zu langsam.

- Alex

 

[pocketom]

Danke das ihr meinen Thread so wunderbar zerrupft habt. Nun nachdem jeder mal kurz seine hohes Qualifikationsniveau hat durchblicken lassen liest es sich ja erst so richtig toll. Darauf haben Informationssuchende gewartet. Kann sich irgendwer von Euch überhaupt noch erinnern worums hier eigentlich gehen sollte, bzw. hat Euch das überhaupt jemals interessiert? Ich glaube nicht. Nochmal vielen Dank für Eure Bemühungen. :roll:

@admins
von mir aus könnt ihr den Thread schliessen, ich mache bei Gelegenheit eh nochmal einen neuen auf.

 

[AlArenal]

Don't like it? Don't read it!