Adobe et le 64 bits : Vista d'abord, Mac OS ensuite

megadub a écrit:

v_atekor a écrit:

Franck : en fait le problème est d'adresser 4Go **en un bloc** Je crois que la précision est importante pour certains. [il y a un registre adhoc de plus de 32 bits pour gérer plus sur tout les procs 32 bits ... ]

en effet :jap:

Je n'oublie pas PAE, mais PAE ne permet pas à une appli 32bits d'utiliser plus de 4Go, ça permet juste au système de gérer plus de 4Go au total.

Franck a écrit:
> c'est oublié le PAE qui montre des perfs normal... c'est à dire que tu as les mêmes perfs quand tu consommes 1.5Go sur les 2Go installés ou 7.5Go sur les 8 installés avec le PAE

Je n'oublie pas PAE, mais PAE ne permet pas à une appli 32bits d'utiliser plus de 4Go, ça permet juste au système de gérer plus de 4Go au total.

v_atekor a écrit:
@kpouer : les entiers au niveau de l'OS sont défini par des U32, donc ça restera des 32 bits, quelque soit le processeur. (Linux, et iso C
... )
Seul le void * change de taille (les adresses ...)

Ca fait beaucoup, mais ce n'est pas non plus catastrophique.

Ca me parrait pas si simple,

In most programming environments on 32-bit machines, pointers, "int" types, and "long" types are all 32 bits wide.

However, in many programming environments on 64-bit machines, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide.

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers).

Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types.

v_atekor a écrit:

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers).

Le standard ...

Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types.

.... et Microsoft, qui a laissé ses long int en int 32 au mépris du reste du monde ... Arf ... On ne les changera pas!

---

(Note que ce sont les long int et non les int qui sont affectés par ce changement )

catseye a écrit:

v_atekor a écrit:

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers).

Le standard ...

Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types.

.... et Microsoft, qui a laissé ses long int en int 32 au mépris du reste du monde ... Arf ... On ne les changera pas!

---

(Note que ce sont les long int et non les int qui sont affectés par ce changement )

D'ou l'interet d'utiliser des macro chez Microsoft ...
CHAR au lieu de char
LONG au lieu de long
UINT au lieu de unsigned int
et surtout dans notre cas :
LONGLONG
ULONGLONG ...

Franck a écrit:
Il est très probable qu'en mémoire, les données soient alignées sur 64 bits et non plus sur 32 pour accélérer les accès, quelquesoit leur taille initiale (donc que ce soit un short, un int, un long...un tableau de strings...l'adresse de début de l'élément sera un multiple de 64bits) ce qui fait qu'un programme utilisera en tout plus de mémoire.

gentoux a écrit:

catseye a écrit:

v_atekor a écrit:

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers).

Le standard ...

Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types.

.... et Microsoft, qui a laissé ses long int en int 32 au mépris du reste du monde ... Arf ... On ne les changera pas!

---

(Note que ce sont les long int et non les int qui sont affectés par ce changement )

D'ou l'interet d'utiliser des macro chez Microsoft ...
CHAR au lieu de char
LONG au lieu de long
UINT au lieu de unsigned int
et surtout dans notre cas :
LONGLONG
ULONGLONG ...

Moi je lis LON-GLONG, ils sont pas possibles chez microsoft, on les aime pas.

Franck a écrit:
Il est très probable qu'en mémoire, les données soient alignées sur 64 bits et non plus sur 32 pour accélérer les accès, quelquesoit leur taille initiale (donc que ce soit un short, un int, un long...un tableau de strings...l'adresse de début de l'élément sera un multiple de 64bits) ce qui fait qu'un programme utilisera en tout plus de mémoire.

Pour avoir fait un peu d'IPP dans le passé, je me souviens que le format des images c'est RGBA-RGBA-RGBA-RGBA.... (non aligné). C'est que SSE c'est quand même puissant.

Digital Still Camera a écrit:
lol
tous les mac os leopard peuvent exécuter du 64 bits, alors qu'une infime partie des windws vista peuvent.

Franck a écrit:
> Une infime partie des machines Windows c'est deja 5 fois plus que de Mac qui peuvent faire tourner Leopard ...

Ça mériterait d'être chiffré.

Franck a écrit:
> Ensuite bon trouver des XP64 ou des Vista64 en entreprise, c'est pas tres comlique, y en a pas mal, bien plus que de Mac...

C'est justement de ça dont on parle. Estimer les PdM de XP64 ou Vista 64 par rapport à Leopard " de base", sachant qu'une bonne partie des 10.5 vendus tourneront sur une machine 64 bits, les G3, G4 et core duo premiers du nom étant très limités dans le parc.

catseye a écrit:

Franck a écrit:
> Une infime partie des machines Windows c'est deja 5 fois plus que de Mac qui peuvent faire tourner Leopard ...

Ça mériterait d'être chiffré.

J'ai du mal a croire qu'il se vendrait autant de Mac avec CPU Intel 64 bits sous Leopard (ou upgradable en Leopard) comparativement au monde PC (qui est 64 bits depuis le Athlon64 premier du nom), si on s'en refere deja au pdm globles ca me parait assez loufoque ...
Ensuite bon trouver des XP64 ou des Vista64 en entreprise, c'est pas tres comlique, y en a pas mal, bien plus que de Mac...

catseye a écrit:

Franck a écrit:
> Ensuite bon trouver des XP64 ou des Vista64 en entreprise, c'est pas tres comlique, y en a pas mal, bien plus que de Mac...

C'est justement de ça dont on parle. Estimer les PdM de XP64 ou Vista 64 par rapport à Leopard " de base", sachant qu'une bonne partie des 10.5 vendus tourneront sur une machine 64 bits, les G3, G4 et core duo premiers du nom étant très limités dans le parc.

C'est assez difficile a evaluer... si je regarde chez moi, y a 5% de XP64, 25% de Vista64, mais vu qu'on est dans la R&D, ca compte pas trop ... forcement on a tous les derniers trucs...