Java et architecture 64 bits

Java et architecture 64 bits - Java - Programmation

Marsh Posté le 10-08-2003 à 00:23:25    

(message pas trolleux, mais on pourrait le croire)
 
depusi toujours on me prends la tête "Java, code once, run everywhere" et des "t'en a pas marre de coder que ça marche pas partout"
 
et là je tombe la dessus
 
http://www.sun.com/smi/Press/sunfl [...] 805.9.html
 
 

Citation :

Sun is allowing companies to migrate their current Java applications from a 32-bit to 64-bit computing platform with little or no changes to the code

 
 
l'article n'est pas clair mais ça pue...
 
le C fonctionne partout de la même façon depuis 20ans, des derniers ordinateurs à votre programmeur de machine à laver...

Reply

Marsh Posté le 10-08-2003 à 00:23:25   

Reply

Marsh Posté le 10-08-2003 à 05:30:51    

en JAVA, un int c'est toujours 32bits et un long c'est toujours 64bits. Si la JVM tourne sur une machine 32bits (comme nos PC), elle doit "émuler" les long grâce à plusieurs int. Sur une machine 64bits (comme l'Opteron), les long sont gérés nativement par le CPU. L'autre différence est évidement le support de plus de 4Go. En java, les changements se trouvent dans la JVM, normalement tout programme doit tourner correctement sur une machine 32 ou 64bits.
 
 
En C, la taille des int et long dépend de l'architecture, par exemple, sur nos PC, un int est en 32bits, mais un long est aussi 32bits, pour avoir de plus grands chiffres, il faut utiliser des librairies spéciales. Les pointeurs sont aussi en 32bits.
 
Lors du passage en 64bits, les pointeurs passent en 64bits et les int restent en 32bits, donc partout où on avait fait des conversions int<->pointeurs, ca devient foireux. Pour ce qui est des long, ça dépend, sous Windows avec VisualStudio, il me semble que les long restent 32bits, mais il y a des long long qui sont en 64bits. Sous Linux, il me semble que les long passent en 64bits.
 
C'est à cause de ces changements qu'en C(++) le passage d'une architecture 32bits à 64bits demande plus que de juste recompiler.
 
Et je ne te parle même pas des 286, sur lesquels les int devaient sans doute être 16bits...


Message édité par deltaden le 10-08-2003 à 05:31:39
Reply

Marsh Posté le 10-08-2003 à 06:58:30    

pourtant cette article dit clairement le contraire !

Reply

Marsh Posté le 10-08-2003 à 11:27:24    

C clair que c'est chelou ce truc... Normalement, l'utilisation de la bonne VM devrait suffir :??:
 
Peut-être par contre parlent-il au niveau de l'optimisation ? (et encore, normalement la VM doit être capable de prendre les bonnes décisions toute seule...)
 
En Java, y'a des pointeurs avec une gestion à chier comme en C ou pas ? (parceque si oui, c'est très certainement à ce niveau que ça part en sucette, mais ça apprendra aux développeur à coder proprement)

Reply

Marsh Posté le 10-08-2003 à 12:09:54    

Citation :

SAN FRANCISCO -- LinuxWorld Conference & Expo -- August 5, 2003 -- Sun Microsystems, Inc. (Nasdaq: SUNW) today announced it has teamed with AMD to provide native Java technology support for the 64-bit AMD Opteron processor. By supporting the 64-bit Linux and Windows platforms on the AMD Opteron processor, Sun is allowing companies to migrate their current Java applications from a 32-bit to 64-bit computing platform with little or no changes to the code, as well as enabling the development and deployment of new Java applications and Web services. Sun expects to make the 64-bit Linux and Windows ports to AMD Opteron available with the release of the Java 2 Platform, Standard Edition (J2SE) v 1.5 in summer of 2004. Blackdown, a J2SE licensee, also contributed technology to the development of these ports.


 
Si tu lis bien, tu verras qu'il est dit qu'en s'associant avec AMD pour développer une JVM 64 bits pour windows et linux, Sun permet aux entreprises de faire tourner leurs applis java sur les plateformes 64 bit AMD... C'est bien la JVM qui change, pas les applis.

Reply

Marsh Posté le 10-08-2003 à 12:12:18    

R3g a écrit :

Citation :

SAN FRANCISCO -- LinuxWorld Conference & Expo -- August 5, 2003 -- Sun Microsystems, Inc. (Nasdaq: SUNW) today announced it has teamed with AMD to provide native Java technology support for the 64-bit AMD Opteron processor. By supporting the 64-bit Linux and Windows platforms on the AMD Opteron processor, Sun is allowing companies to migrate their current Java applications from a 32-bit to 64-bit computing platform with little or no changes to the code, as well as enabling the development and deployment of new Java applications and Web services. Sun expects to make the 64-bit Linux and Windows ports to AMD Opteron available with the release of the Java 2 Platform, Standard Edition (J2SE) v 1.5 in summer of 2004. Blackdown, a J2SE licensee, also contributed technology to the development of these ports.


 
Si tu lis bien, tu verras qu'il est dit qu'en s'associant avec AMD pour développer une JVM 64 bits pour windows et linux, Sun permet aux entreprises de faire tourner leurs applis java sur les plateformes 64 bit AMD... C'est bien la JVM qui change, pas les applis.


Non, ils parlent bien dans la phrase quotée du code de l'appli, pas de la JVM.

Reply

Marsh Posté le 10-08-2003 à 12:58:37    

Oui mais il disent bien "avec peu ou pas de changements au code". Evidemment, c'est le "peu" qui est suspect, mais je pense que c'est surtout une formule de prudence pour ne pas se faire reprocher les quelques cas tres particuliers qui pourraient nécessiter une modif du code.

Reply

Marsh Posté le 10-08-2003 à 13:02:45    

ben oui, mais ça veut bien dire ce que ça veut dire. je suis désolé, la plus part des appli 32bits à peu ou pas de changements touneront aussi sur des architectures 64bits.

Reply

Marsh Posté le 10-08-2003 à 13:05:15    

Taz a écrit :

ben oui, mais ça veut bien dire ce que ça veut dire. je suis désolé, la plus part des appli 32bits à peu ou pas de changements touneront aussi sur des architectures 64bits.


En C/C++ tu veux dire ? Ben ouais, à condition de pas avoir fait nimp avec les pointeurs comme disait deltaden. Et puis il faudra les recompiler  :kaola: En java, sauf cas très particulier, ca reste "compile once, run everywhere"

Reply

Marsh Posté le 10-08-2003 à 13:06:54    

ben le cas particulier devrait pas exister. ce que tu reproches au C/C++, ben Java a apparemment exactement le même problème. donc en java aussi faudra recompiler.

Reply

Marsh Posté le 10-08-2003 à 13:06:54   

Reply

Marsh Posté le 10-08-2003 à 13:51:34    

De toute façon, le C# c'est encore mieu y'a pas besoin de modifier une ligne :D
 
Et on peut choisir si on veut des int16, int32 ou int64... Que demande le peuple ? :D


Message édité par MagicBuzz le 10-08-2003 à 13:52:13
Reply

Marsh Posté le 10-08-2003 à 13:52:34    

MagicBuzz a écrit :

De toute façon, le C# c'est encore mieu y'a pas besoin de modifier une ligne :D

et c'est le premir langage portable qui marche que sur une seule plateforme  [:xp1700]

Reply

Marsh Posté le 10-08-2003 à 13:57:13    

en tout cas, moi qui déjà avait du mal avec Java, là je crois que c'est ce qui va faire pencher la balance...

Reply

Marsh Posté le 10-08-2003 à 13:57:15    

Taz a écrit :

et c'est le premir langage portable qui marche que sur une seule plateforme  [:xp1700]  


Mais nan, y'a des framework pour x-like depuis le temps. Ils sont pas forcément finalisés, mais déjà exploitable :p
 
M$ l'a indiqué depuis le départ : ils ont écrit le langage et ses spécifications dans l'optique du multiplateforme, mais n'assurent les développement que sous Windows. Après, si personne n'a envie d'écrire un framework pour tel ou tel OS, bah M$ n'y peut pas forcément grand chose : ils ont posé les règles dès le départ.

Reply

Marsh Posté le 10-08-2003 à 13:58:27    

et on tout breveté à fond, engagé des centaines d'avocats pour chercher des poux à Monon.Net ... enfin bon, là n'est pas le sujet.

Reply

Marsh Posté le 10-08-2003 à 14:01:20    

Taz a écrit :

et on tout breveté à fond, engagé des centaines d'avocats pour chercher des poux à Monon.Net ... enfin bon, là n'est pas le sujet.  


Bah ils ont breveté pour s'assuer, comme Sun l'a fait avec Java, que personne ne va décider "tiens, cette fonction elle serait mieu comme ça, et pis tiens, je vais rajouter celle là, et maintenant c'est plus portable".
Pourquoi M$ a perdu son procès contre Sun quand ils ont fait ce genre de bidouilles avec VJ++, c'est tout simplement parceque Sun a lui aussi déposé un brevet pour chaque ligne de spec.

Reply

Marsh Posté le 10-08-2003 à 14:02:58    

tout ça puxor
 
perl et python sont libres, sur VM et n'ont pas tout ce genre de problème à la con

Reply

Marsh Posté le 10-08-2003 à 14:36:27    

Taz a écrit :

ben le cas particulier devrait pas exister. ce que tu reproches au C/C++, ben Java a apparemment exactement le même problème. donc en java aussi faudra recompiler.


Il ne faudra PAS recompiler, les changements sont uniquement présents dans la JVM!
Quand tu compile ton prog java, il va utiliser des entiers 32 ou 64bits, ensuite, c'est lorsque la JVM compile le bytecode en langage machine qu'elle agit différement pour les long, ce n'est absolument pas le problème du prog java. Même chose pour les pointeurs, le bytecode, il sait même pas ce que c'est des pointeurs, c'est enore une fois le problème de la JVM.
 
Tous les programmes sont sensés marché directement, sans recompilation, d'ailleurs, c'est déjà le cas quand on fait tourner des progs java sur des machines 64bits actuelles (Sparc sous Solaris,...).
Comme l'a dis R3g, le "peu" est juste une formule de prudence, car il peut y avoir des cas spécifiques (comme l'utilisation de JNI mais ce n'est plus de la faute de Java...)
 
Pour ce qui est du C(++), il faudra recompiler, et il peut y avoir des problèmes si ce n'a pas été codé correctement.

Reply

Marsh Posté le 10-08-2003 à 14:37:31    

Taz a écrit :

Citation :

Sun is allowing companies to migrate their current Java applications from a 32-bit to 64-bit computing platform with little or no changes to the code

 

[:quoted]
je pense pas qu'on parle de JNI là


Message édité par Taz le 10-08-2003 à 14:40:08
Reply

Marsh Posté le 10-08-2003 à 14:44:29    

peut-être pas, mais de toute façon, je suis sûr qu'il s'agit du formule de prudence, on ne sait jamais ce qui peut arriver.

Reply

Marsh Posté le 10-08-2003 à 14:48:42    

deltaden a écrit :

peut-être pas, mais de toute façon, je suis sûr qu'il s'agit du formule de prudence, on ne sait jamais ce qui peut arriver.
 

ben je croyais que le coup de la VM, c'était justement de prévoir ce jamais. si y a des implémentations de la VM qui suivent pas les critères de la VM...

Reply

Marsh Posté le 10-08-2003 à 14:57:47    

Taz a écrit :

ben je croyais que le coup de la VM, c'était justement de prévoir ce jamais. si y a des implémentations de la VM qui suivent pas les critères de la VM...


he bien considère que ça prévoir ce jamais, il s'agit d'une annonce du département marketing, pas d'une interview d'un ingénieur qui s'y connait...
 
Je te signale que en C(++), il faut aussi attendre que les libs utilisées soient également portées, débuggées, validées, ensuite on peut seulement suivre le même cheminement pour ses propres programmes...

Reply

Marsh Posté le 10-08-2003 à 16:40:16    

dans le cas du passage du 64 bits au 32 bits y a quand même des petites différence.
 
exemple :  

Citation :


long a;
long b =2;
a = b;


sur une plateforme 64 bits, l'affectation est atomique. Sur une plateforme 32 bits, il faut entourer cette opération d'un bloc sycnhronized car elle ne l'est pas ...
 
Pour ce cas là, le passage de 32 à 64 ne pose pas de problème (dans l'autre sens ca en poserait bcp, ou par exemple passage de 32-> 16 [:totoz]), mais c'est peutr être pour ce genre de cas qi'il peux y avoir des trucs foireux


Message édité par benou le 10-08-2003 à 16:40:43

---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 16:45:00    

euh on a pas du suivre le meme cours sur l'atomicité...
 
en tout cas, ça n'entraine pas de changement dans ton code

Reply

Marsh Posté le 10-08-2003 à 19:10:45    

benou a écrit :

dans le cas du passage du 64 bits au 32 bits y a quand même des petites différence.
 
exemple :  

Citation :


long a;
long b =2;
a = b;


sur une plateforme 64 bits, l'affectation est atomique. Sur une plateforme 32 bits, il faut entourer cette opération d'un bloc sycnhronized car elle ne l'est pas ...


Mmm.. tu es sur de ça ? j'aurais pensé que ce genre de chose était géré par la jvm justement ; que du point de vue de ton programme, une telle affectation était toujours atomique, quelque soit le type concerné.

Reply

Marsh Posté le 10-08-2003 à 19:19:55    

R3g a écrit :


Mmm.. tu es sur de ça ? j'aurais pensé que ce genre de chose était géré par la jvm justement ; que du point de vue de ton programme, une telle affectation était toujours atomique, quelque soit le type concerné.


ouais ouais je suis sûr ... 2 sec, je cherche la référence ...
on a déjà eu tout un débat la dessus au boulot ! :D
 
edit : http://java.sun.com/docs/books/jls [...] html#28733


Message édité par benou le 10-08-2003 à 19:21:44

---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 19:22:02    

Taz a écrit :

euh on a pas du suivre le meme cours sur l'atomicité...


qu'est ce que tu veux dire ?


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 19:29:05    

benou a écrit :


qu'est ce que tu veux dire ?

en java, je sais pas, mais c'est loin d'être atomique niveau processeur

Reply

Marsh Posté le 10-08-2003 à 19:42:48    

Taz a écrit :

en java, je sais pas, mais c'est loin d'être atomique niveau processeur


une écriture d'une valeur de 32 bits ? pkoi ce serait pas atomique ?
 
je te parle pas de l'affectation en elle même (parce qu'il y a aussi la partie lecture), mais juste de l'écriture...
 
je disais que c'était atomique parce que tu risque pas ed te retrouver avec une valeur foireurse (genre moitié d'un int au début et moitié d'un autre int à la fin).
 
pareil pour l'affectation d'objet : si l'affectation (je parle juste de la copie des adresse mémoires là) n'était pas atomique, ca voudrais dire qu'on pourrais se retrouver avec des adresses foireuses ... ce qui ne peux pas arrivé sur ne archi 32 bits puisque l'écriture d'un bloc de 32 bits se fait en 1 fois.


Message édité par benou le 10-08-2003 à 19:43:08

---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 19:44:40    

ben oui mais y a pas que ça! c'est pas que l'ecriture, y a toutes les opérations avec les registres et la mémoire...  
 
enfin bon, fini la digression

Reply

Marsh Posté le 10-08-2003 à 19:47:28    

donc toi tu me dis que quand tu fais o1 = o2, dans une apli multithreadé, tu peux te retrouver avec une un peu n'importe quoi dans o1 si on était en train de faire o1 = o3 au même moment dans un autre thread.
(sachant que o1 et o2 sont des objets)
 
pour moi, on aura o1 vaudra soit o2, soit o3 ... c'est ca que je voulais dire par atomicité de l'affectation ... tu crois que c'est pas le cas ?


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 19:51:30    

peut etre pas n'importe quoi mais en tout cas je pense que c'est n'est pas prévisible lequel ça sera. sinon ça serait trop facile :D

Reply

Marsh Posté le 10-08-2003 à 20:03:41    

MagicBuzz a écrit :


M$ l'a indiqué depuis le départ : ils ont écrit le langage et ses spécifications dans l'optique du multiplateforme, mais n'assurent les développement que sous Windows. Après, si personne n'a envie d'écrire un framework pour tel ou tel OS, bah M$ n'y peut pas forcément grand chose : ils ont posé les règles dès le départ.


 
Faut vraiment etre credule pour croire Microsoft de si bon coeur et que .NET est un framework multiplateforme puisque ca tourne que sous Windows.
Je te rappelle que Microsoft ne file pas les sources donc tu es oblige de tout redevelopper gratos pour ta plateforme et d'etre a la botte de MS puisque c'est eux qui decident comment les API evoluent (que l'on ne me parle pas de la pseudo standardisation). Etre a la botte de MS j'en connais pas beaucoup que ca fait juir...
 
Depuis le depart ils savent qu'il n'y aura pas d'implementation a la hauteur, c'est tres bien ca permet de concerver le monopole et en plus ca permet de convertir quelques personnes qui pensent que c'est un framework ouvert et multiplateforme.
 
edit - j'avais pas lu ce monument:

MagicBuzz a écrit :


Bah ils ont breveté pour s'assuer, comme Sun l'a fait avec Java, que personne ne va décider "tiens, cette fonction elle serait mieu comme ça, et pis tiens, je vais rajouter celle là, et maintenant c'est plus portable".
Pourquoi M$ a perdu son procès contre Sun quand ils ont fait ce genre de bidouilles avec VJ++, c'est tout simplement parceque Sun a lui aussi déposé un brevet pour chaque ligne de spec.


Assurer quoi ? c'est pour mieux niker ceux qui deviendraient trop genants tout simplement :D
Je suis curieux de savoir quels brevets Sun a utiliser lors du proces contre Microsoft. Apparemment tu as l'air vachement renseigne et tu vas nous sortir les liens de ce que tu avances.


Message édité par tanguy le 10-08-2003 à 20:14:07
Reply

Marsh Posté le 10-08-2003 à 20:14:07    

benou a écrit :


ouais ouais je suis sûr ... 2 sec, je cherche la référence ...
on a déjà eu tout un débat la dessus au boulot ! :D
 
edit : http://java.sun.com/docs/books/jls [...] html#28733


 :jap: merci, je le note.

Reply

Marsh Posté le 10-08-2003 à 20:18:00    

Taz a écrit :

peut etre pas n'importe quoi mais en tout cas je pense que c'est n'est pas prévisible lequel ça sera. sinon ça serait trop facile :D  


que ce soit pas prévisible ca ok, c'est pas bien grave. Ce qui est important c'est que ca n'écrive pas la moitié des deux. C'est ca que je veux dire quand je dis que l'écriture n'est pas atomique.
 
Pour un long, par example, c'est pas garntit !


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 20:20:59    

R3g a écrit :


 :jap: merci, je le note.


ouais c'est très peu connu et pourtant c'est vachement important !!
 
ca doit être la cause de pas mal de bug ! imagine : à chaque fois que tu fais une copie de long ou de double dans une appli multithreadée et que tu oublies de synchronizer cette copie, potentiellement, ca peut complétement foirer sa valeur !!


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 20:23:21    

oui mais bon, en mutli-thread, le moindre oubli de synchronisation est dramatique.

Reply

Marsh Posté le 10-08-2003 à 20:26:44    

Taz a écrit :

oui mais bon, en mutli-thread, le moindre oubli de synchronisation est dramatique.


bha oui bien sûr ...
 
c'est pour ca que comme ce truc est très peu connu, à mon avis ca doit pas être rare de faire des bigs là dessus : c'est loin d'être évident qu'il faut synchronizer une ligne du style a=b; :/
 
mais c'est marrant ta remarque : on dirait que les applis multi-threadées te font très peur ... en Java ca se fait assez facilement...


Message édité par benou le 10-08-2003 à 20:27:28

---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-08-2003 à 20:28:17    

benou a écrit :


bha oui bien sûr ...
 
c'est pour ca que comme ce truc est très peu connu, à mon avis ca doit pas être rare de faire des bigs là dessus : c'est loin d'être évident qu'il faut synchronizer une ligne du style a=b; :/
 
mais c'est marrant ta remarque : on dirait que les applis multi-threadées te font très peur ... en Java ca se fait assez facilement...

ta mère t'as jamais appris manipulation varaible partagée -> mutex ?  :o


Message édité par Taz le 10-08-2003 à 20:28:39
Reply

Marsh Posté le 10-08-2003 à 20:29:33    

Taz a écrit :

ta mère t'as jamais appris manipulation varaible partagée -> mutex ?  :o  


ton père t'as jamais dis que c'était pas nécessaire si l'opération était atomique ?  :sarcastic:


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed