j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et
les machines 64 bits, et, d'une manière général, sur les machines 64 bits.
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire
passer les registres du prcesseur de 32 à 64 bits. Ca peut sembler être
une Lapalissade, mais c'est bon de le préciser. Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme, c'est l'augmentation de
l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce
marketing ?
De plus, il faut en toute logique que les applications soit compilées
par un gcc en "mode 64bits" (?): ce mode "est il au point" ? Ne
change-t-il vraiment rien d'autre que quelques broutilles concernant
l'addressage ?
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup
d'applications Linux compatible 64bits ? Une liste existe-t-elle ?
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel
"compilé en mode 64 bits", et cela ralentit-il l'application ? Notez que
je préferrerais utiliser Debian (ma station de travail actuelle en 32
bits), mais qu'en est-il de l'avancement des distributions Linux par
rapport "au 64 bit" ?
Vous l'aurez compris,si je post ici et maintenant ce message, c'est pour
me décider à l'achat d'un futur et hypothètique ordinateur portable. Je
pensais me porter vers un Intel Core 2 Duo. Quelques remarques par
rapport à ce type de processeur ?
Pour finir, je tiens à préciser que je n'ai trouvé que des sujets (pas
tellement réjouissant) datant de 2004/2005/2006 sur internet, très peu
de (fin) 2007.
Donc, un 64 bits ne change rien à la donne à moins que... ... c'est incroyable: le 64 bit est l'étape suivante des processeurs.
Hum en effet incroyable. Ma question portait justement sur ce fait: est-ce que c'est une étape utile, ou non ? Car je ne vois pas trop l'utilité, à part comme dit plus tôt pour l'espace d'addressage.
Bienvenue dans le monde du marketing, les personnes ayant réellement besoin des avantages des machines 64bits les utilisant depuis bien longtemps, mais pas sur plate-forme x86... ;-)
C'est bien ce que je me disais :-)
N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une utilisation de "tout les jours" ?
Jerome Lambert wrote:
Mihamina Rakotomandimby wrote:
Nanar Duff > wrote:
Donc, un 64 bits ne change rien à la donne à moins que...
... c'est incroyable: le 64 bit est l'étape suivante des processeurs.
Hum en effet incroyable. Ma question portait justement sur ce fait:
est-ce que c'est une étape utile, ou non ? Car je ne vois pas trop
l'utilité, à part comme dit plus tôt pour l'espace d'addressage.
Bienvenue dans le monde du marketing, les personnes ayant réellement
besoin des avantages des machines 64bits les utilisant depuis bien
longtemps, mais pas sur plate-forme x86... ;-)
C'est bien ce que je me disais :-)
N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi
maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une
utilisation de "tout les jours" ?
Donc, un 64 bits ne change rien à la donne à moins que... ... c'est incroyable: le 64 bit est l'étape suivante des processeurs.
Hum en effet incroyable. Ma question portait justement sur ce fait: est-ce que c'est une étape utile, ou non ? Car je ne vois pas trop l'utilité, à part comme dit plus tôt pour l'espace d'addressage.
Bienvenue dans le monde du marketing, les personnes ayant réellement besoin des avantages des machines 64bits les utilisant depuis bien longtemps, mais pas sur plate-forme x86... ;-)
C'est bien ce que je me disais :-)
N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une utilisation de "tout les jours" ?
Miod Vallat
C'est plus rapide. Le reste est sans importance.
C'est justement ce que j'aimerais savoir. Décréter de dire que c'est plus rapide sans faire de benchmark avec des applications pour la plupart pas encore développé (pour x86 et pour une utilisation plus ou moins "bureautique" j'entends) c'est facile !
D'où ma question: en quoi les applications "optimisés" pour x86 64 bits serait plus rapide (à part comme dit plusieurs fois plus haut pour augmenter l'espace d'addressage) ?
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui suffit à rendre tout le code compilé avec un compilateur 64 bits plus rapide, même si c'est un mauvais compilateur.
Bien sûr, l'exécution de binaires 32 bits (flash, acrobat frigidaire, etc) ne profite en rien du processeur 64 bits.
C'est plus rapide. Le reste est sans importance.
C'est justement ce que j'aimerais savoir. Décréter de dire que c'est
plus rapide sans faire de benchmark avec des applications pour la
plupart pas encore développé (pour x86 et pour une utilisation plus ou
moins "bureautique" j'entends) c'est facile !
D'où ma question: en quoi les applications "optimisés" pour x86 64 bits
serait plus rapide (à part comme dit plusieurs fois plus haut pour
augmenter l'espace d'addressage) ?
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de
deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela
permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui
suffit à rendre tout le code compilé avec un compilateur 64 bits plus
rapide, même si c'est un mauvais compilateur.
Bien sûr, l'exécution de binaires 32 bits (flash, acrobat frigidaire,
etc) ne profite en rien du processeur 64 bits.
C'est justement ce que j'aimerais savoir. Décréter de dire que c'est plus rapide sans faire de benchmark avec des applications pour la plupart pas encore développé (pour x86 et pour une utilisation plus ou moins "bureautique" j'entends) c'est facile !
D'où ma question: en quoi les applications "optimisés" pour x86 64 bits serait plus rapide (à part comme dit plusieurs fois plus haut pour augmenter l'espace d'addressage) ?
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui suffit à rendre tout le code compilé avec un compilateur 64 bits plus rapide, même si c'est un mauvais compilateur.
Bien sûr, l'exécution de binaires 32 bits (flash, acrobat frigidaire, etc) ne profite en rien du processeur 64 bits.
Nanar Duff
Miod Vallat wrote:
N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une utilisation de "tout les jours" ?
C'est plus rapide. Le reste est sans importance.
C'est justement ce que j'aimerais savoir. Décréter de dire que c'est plus rapide sans faire de benchmark avec des applications pour la plupart pas encore développé (pour x86 et pour une utilisation plus ou moins "bureautique" j'entends) c'est facile !
D'où ma question: en quoi les applications "optimisés" pour x86 64 bits serait plus rapide (à part comme dit plusieurs fois plus haut pour augmenter l'espace d'addressage) ?
Miod Vallat wrote:
N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi
maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une
utilisation de "tout les jours" ?
C'est plus rapide. Le reste est sans importance.
C'est justement ce que j'aimerais savoir. Décréter de dire que c'est
plus rapide sans faire de benchmark avec des applications pour la
plupart pas encore développé (pour x86 et pour une utilisation plus ou
moins "bureautique" j'entends) c'est facile !
D'où ma question: en quoi les applications "optimisés" pour x86 64 bits
serait plus rapide (à part comme dit plusieurs fois plus haut pour
augmenter l'espace d'addressage) ?
N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une utilisation de "tout les jours" ?
C'est plus rapide. Le reste est sans importance.
C'est justement ce que j'aimerais savoir. Décréter de dire que c'est plus rapide sans faire de benchmark avec des applications pour la plupart pas encore développé (pour x86 et pour une utilisation plus ou moins "bureautique" j'entends) c'est facile !
D'où ma question: en quoi les applications "optimisés" pour x86 64 bits serait plus rapide (à part comme dit plusieurs fois plus haut pour augmenter l'espace d'addressage) ?
Michel Talon
Miod Vallat wrote:
C'est plus rapide. Le reste est sans importance.
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui suffit à rendre tout le code compilé avec un compilateur 64 bits plus rapide, même si c'est un mauvais compilateur.
Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod dise enfin que les prémisses du post initial étaient fausses, et qu'en mode 64 bits le processeur dispose de plus de registres, ce qui est important car le x86 manque cruellement de registres. A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un biproc est plus lent à cause des changements de contexte, il est clair que des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que les deux sortent du cache, la différence s'estompe rapidement.
(*) sur des machines avec bien moins de 4 Gigs de mémoire.
-- Michel Talon
Miod Vallat wrote:
C'est plus rapide. Le reste est sans importance.
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de
deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela
permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui
suffit à rendre tout le code compilé avec un compilateur 64 bits plus
rapide, même si c'est un mauvais compilateur.
Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod
dise enfin que les prémisses du post initial étaient fausses, et qu'en mode
64 bits le processeur dispose de plus de registres, ce qui est important
car le x86 manque cruellement de registres. A titre d'information, sur nos
machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui,
une augmentation de 100%) sur des calculs symboliques avec, par exemple
Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper
court aux arguments ridicules prétendant que le 64 bits ne sert qu'à
adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un
biproc est plus lent à cause des changements de contexte, il est clair que
des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est
pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y
tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a
une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que
les deux sortent du cache, la différence s'estompe rapidement.
(*) sur des machines avec bien moins de 4 Gigs de mémoire.
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui suffit à rendre tout le code compilé avec un compilateur 64 bits plus rapide, même si c'est un mauvais compilateur.
Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod dise enfin que les prémisses du post initial étaient fausses, et qu'en mode 64 bits le processeur dispose de plus de registres, ce qui est important car le x86 manque cruellement de registres. A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un biproc est plus lent à cause des changements de contexte, il est clair que des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que les deux sortent du cache, la différence s'estompe rapidement.
(*) sur des machines avec bien moins de 4 Gigs de mémoire.
-- Michel Talon
Emmanuel Florac
Le Sun, 07 Oct 2007 18:51:09 +0200, Nanar Duff a écrit :
j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et les machines 64 bits, et, d'une manière général, sur les machines 64 bits.
C'est intéressant si tu as besoin de beaucoup de RAM pour une application particulière (4Go maximum par processus en 32 bits), ou de beaucoup d'espace (16To par FS maximum en 32 bits). En terme de calcul pur, il est des cas où le 64 bits est plus rapide que le 32. En règle générale cependant, le 64 bits consomme plus de mémoire et est légèrement plus lent. Pour moi, le meilleur des deux mondes c'est un noyau 64 bits avec une distrib entièrement 32 bits ou presque. Le système entièrement 64 bits, c'est de la branlette.
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Sun, 07 Oct 2007 18:51:09 +0200, Nanar Duff a écrit :
j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et
les machines 64 bits, et, d'une manière général, sur les machines 64
bits.
C'est intéressant si tu as besoin de beaucoup de RAM pour une application
particulière (4Go maximum par processus en 32 bits), ou de beaucoup
d'espace (16To par FS maximum en 32 bits). En terme de calcul pur, il est
des cas où le 64 bits est plus rapide que le 32. En règle générale
cependant, le 64 bits consomme plus de mémoire et est légèrement plus
lent.
Pour moi, le meilleur des deux mondes c'est un noyau 64 bits avec une
distrib entièrement 32 bits ou presque. Le système entièrement 64 bits,
c'est de la branlette.
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Sun, 07 Oct 2007 18:51:09 +0200, Nanar Duff a écrit :
j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et les machines 64 bits, et, d'une manière général, sur les machines 64 bits.
C'est intéressant si tu as besoin de beaucoup de RAM pour une application particulière (4Go maximum par processus en 32 bits), ou de beaucoup d'espace (16To par FS maximum en 32 bits). En terme de calcul pur, il est des cas où le 64 bits est plus rapide que le 32. En règle générale cependant, le 64 bits consomme plus de mémoire et est légèrement plus lent. Pour moi, le meilleur des deux mondes c'est un noyau 64 bits avec une distrib entièrement 32 bits ou presque. Le système entièrement 64 bits, c'est de la branlette.
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Emmanuel Florac
Le Sun, 07 Oct 2007 21:38:04 +0200, Nanar Duff a écrit :
Ok :-) En parlant de ca, je serais bien curieux de savoir ce qui peut faire qu'une architecture soit plus "mauvaise' qu'une autre : est-ce comme les formats de compression audio, où la compression en mp3 est moins bonne que celle en vorbis car plus vieille (une architecture peut plus ou moin évoluer, non ?), ou y-a-t'il des raisons plus précise ?
En l'occurence, on est parti d'une architecture très limitée 8 bits (8080), pour en extrapoler une 16 bits (8086), qu'on a étendu avec un peu de protection mémoire (80286), puis on l'a encore étendue en 32 bits (80386), après quoi on a intégré le coprocesseur arithmétique (80486), avant de passer à un superscalaire sommaire (Pentium), puis à un vrai superscalaire RISC avec une "interface" CISC (Pentium Pro), auquel on a ajouté des estensions SIMD MMX (Pentium II, puis MMX2 avec le Pentium III), avant de le gonfler en 64 bits et en multicoeur.
En gros, si on faisait un parallèle "véhicule terrestre" on est parti d'une trottinette, on y a ajouté un moteur, puis deux roues, puis des phares, puis un siège, puis un autre, puis une cabine, puis un coffre, puis on a changé les roues pour des jantes alliages, puis on y a mis l'ABS et l'ESP, et aujourd'hui on a un truc qui ressemble à une voiture. Comme c'est le modèle que tout le monde a, le béotien s'imagine que c'est "comme ça que doit être une voiture". Le jour où il croise une vraie bonne bagnole, évidemment ça fait un choc.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Sun, 07 Oct 2007 21:38:04 +0200, Nanar Duff a écrit :
Ok :-) En parlant de ca, je serais bien curieux de savoir ce qui peut
faire qu'une architecture soit plus "mauvaise' qu'une autre : est-ce comme
les formats de compression audio, où la compression en mp3 est moins
bonne que celle en vorbis car plus vieille (une architecture peut plus ou
moin évoluer, non ?), ou y-a-t'il des raisons plus précise ?
En l'occurence, on est parti d'une architecture très limitée 8 bits
(8080), pour en extrapoler une 16 bits (8086), qu'on a étendu avec un peu
de protection mémoire (80286), puis on l'a encore étendue en 32 bits
(80386), après quoi on a intégré le coprocesseur arithmétique (80486),
avant de passer à un superscalaire sommaire (Pentium), puis à un vrai
superscalaire RISC avec une "interface" CISC (Pentium Pro), auquel on a
ajouté des estensions SIMD MMX (Pentium II, puis MMX2 avec le Pentium
III), avant de le gonfler en 64 bits et en multicoeur.
En gros, si on faisait un parallèle "véhicule terrestre" on est parti
d'une trottinette, on y a ajouté un moteur, puis deux roues, puis des
phares, puis un siège, puis un autre, puis une cabine, puis un coffre,
puis on a changé les roues pour des jantes alliages, puis on y a mis
l'ABS et l'ESP, et aujourd'hui on a un truc qui ressemble à une voiture.
Comme c'est le modèle que tout le monde a, le béotien s'imagine que
c'est "comme ça que doit être une voiture". Le jour où il croise une
vraie bonne bagnole, évidemment ça fait un choc.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Sun, 07 Oct 2007 21:38:04 +0200, Nanar Duff a écrit :
Ok :-) En parlant de ca, je serais bien curieux de savoir ce qui peut faire qu'une architecture soit plus "mauvaise' qu'une autre : est-ce comme les formats de compression audio, où la compression en mp3 est moins bonne que celle en vorbis car plus vieille (une architecture peut plus ou moin évoluer, non ?), ou y-a-t'il des raisons plus précise ?
En l'occurence, on est parti d'une architecture très limitée 8 bits (8080), pour en extrapoler une 16 bits (8086), qu'on a étendu avec un peu de protection mémoire (80286), puis on l'a encore étendue en 32 bits (80386), après quoi on a intégré le coprocesseur arithmétique (80486), avant de passer à un superscalaire sommaire (Pentium), puis à un vrai superscalaire RISC avec une "interface" CISC (Pentium Pro), auquel on a ajouté des estensions SIMD MMX (Pentium II, puis MMX2 avec le Pentium III), avant de le gonfler en 64 bits et en multicoeur.
En gros, si on faisait un parallèle "véhicule terrestre" on est parti d'une trottinette, on y a ajouté un moteur, puis deux roues, puis des phares, puis un siège, puis un autre, puis une cabine, puis un coffre, puis on a changé les roues pour des jantes alliages, puis on y a mis l'ABS et l'ESP, et aujourd'hui on a un truc qui ressemble à une voiture. Comme c'est le modèle que tout le monde a, le béotien s'imagine que c'est "comme ça que doit être une voiture". Le jour où il croise une vraie bonne bagnole, évidemment ça fait un choc.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Jérémy JUST
Le Sun, 7 Oct 2007 19:32:49 +0000 (UTC),
En pratique, presque toutes les applications libres maintenues depuis plusieurs années par une équipe de développeurs sont écrites suffisamment proprement pour être compilables partout.
s/partout/sur Linux sur i386/
Je parle d'après mon expérience sous Solaris sur UltraSparc III (avec compilateur Sun) et Linux sur G4 (avec GCC). Ça reste très conventionnel, mais ce n'est déjà plus du Linux/x86.
En pratique, il faut souvent retoucher les makefiles, et parfois utiliser GCC à la place du compilateur Sun, mais le code lui-même est portable.
-- Jérémy JUST
Le Sun, 7 Oct 2007 19:32:49 +0000 (UTC),
En pratique, presque toutes les applications libres maintenues
depuis plusieurs années par une équipe de développeurs sont écrites
suffisamment proprement pour être compilables partout.
s/partout/sur Linux sur i386/
Je parle d'après mon expérience sous Solaris sur UltraSparc III
(avec compilateur Sun) et Linux sur G4 (avec GCC). Ça reste très
conventionnel, mais ce n'est déjà plus du Linux/x86.
En pratique, il faut souvent retoucher les makefiles, et parfois
utiliser GCC à la place du compilateur Sun, mais le code lui-même est
portable.
En pratique, presque toutes les applications libres maintenues depuis plusieurs années par une équipe de développeurs sont écrites suffisamment proprement pour être compilables partout.
s/partout/sur Linux sur i386/
Je parle d'après mon expérience sous Solaris sur UltraSparc III (avec compilateur Sun) et Linux sur G4 (avec GCC). Ça reste très conventionnel, mais ce n'est déjà plus du Linux/x86.
En pratique, il faut souvent retoucher les makefiles, et parfois utiliser GCC à la place du compilateur Sun, mais le code lui-même est portable.
-- Jérémy JUST
Jérémy JUST
Le Sun, 07 Oct 2007 21:45:39 +0200,
Mais, on a dit plus haut que certains programme Sparc était "optimisé" pour les 64 bits.
Où as-tu lu ça?
Car si un programme "optimisé" pour 64 bit donne un binaire 32 bits où est l'utilité de la chose, qu'est ce que le programme fera sur une machine 64 bit qui ne fera pas (ou en plusieurs étapes) sur une machine 32 bits ?
Je n'ai jamais rencontré de programmes « optimisés pour les 64 bits ». J'ai juste vu des programmes propriétaires, distribués sous forme de binaires 64 bits, qui ne tournaient que sur la machine 64 bits pour laquelle ils étaient compilés. Mais j'imagine qu'on pouvait acheter la version 32 bits à côté.
Sinon, si ton programme utilise plus de 4 Go de RAM, effectivement, il ne pourra pas tourner sur une machine 32 bits. Mais ce n'est pas lié directement au programme.
Après, peut-être que le cas dont tu parles existe, hein. Mais je n'en ai jamais entendu parler.
-- Jérémy JUST
Le Sun, 07 Oct 2007 21:45:39 +0200,
Mais, on a dit plus haut que certains programme Sparc était
"optimisé" pour les 64 bits.
Où as-tu lu ça?
Car si un programme "optimisé" pour 64 bit donne un binaire 32 bits
où est l'utilité de la chose, qu'est ce que le programme fera sur une
machine 64 bit qui ne fera pas (ou en plusieurs étapes) sur une
machine 32 bits ?
Je n'ai jamais rencontré de programmes « optimisés pour les
64 bits ». J'ai juste vu des programmes propriétaires, distribués sous
forme de binaires 64 bits, qui ne tournaient que sur la machine 64 bits
pour laquelle ils étaient compilés.
Mais j'imagine qu'on pouvait acheter la version 32 bits à côté.
Sinon, si ton programme utilise plus de 4 Go de RAM, effectivement,
il ne pourra pas tourner sur une machine 32 bits. Mais ce n'est pas lié
directement au programme.
Après, peut-être que le cas dont tu parles existe, hein. Mais je n'en
ai jamais entendu parler.
Mais, on a dit plus haut que certains programme Sparc était "optimisé" pour les 64 bits.
Où as-tu lu ça?
Car si un programme "optimisé" pour 64 bit donne un binaire 32 bits où est l'utilité de la chose, qu'est ce que le programme fera sur une machine 64 bit qui ne fera pas (ou en plusieurs étapes) sur une machine 32 bits ?
Je n'ai jamais rencontré de programmes « optimisés pour les 64 bits ». J'ai juste vu des programmes propriétaires, distribués sous forme de binaires 64 bits, qui ne tournaient que sur la machine 64 bits pour laquelle ils étaient compilés. Mais j'imagine qu'on pouvait acheter la version 32 bits à côté.
Sinon, si ton programme utilise plus de 4 Go de RAM, effectivement, il ne pourra pas tourner sur une machine 32 bits. Mais ce n'est pas lié directement au programme.
Après, peut-être que le cas dont tu parles existe, hein. Mais je n'en ai jamais entendu parler.
-- Jérémy JUST
Nanar Duff >
Emmanuel Florac wrote:
Ok :-) En parlant de ca, je serais bien curieux de savoir ce qui peut faire qu'une architecture soit plus "mauvaise' qu'une autre : est-ce comme les formats de compression audio, où la compression en mp3 est moins bonne que celle en vorbis car plus vieille (une architecture peut plus ou moin évoluer, non ?), ou y-a-t'il des raisons plus précise ?
En l'occurence, on est parti d'une architecture très limitée 8 bits (8080), pour en extrapoler une 16 bits (8086), qu'on a étendu avec un peu de protection mémoire (80286), puis on l'a encore étendue en 32 bits (80386), après quoi on a intégré le coprocesseur arithmétique (80486), avant de passer à un superscalaire sommaire (Pentium), puis à un vrai superscalaire RISC avec une "interface" CISC (Pentium Pro), auquel on a ajouté des estensions SIMD MMX (Pentium II, puis MMX2 avec le Pentium III), avant de le gonfler en 64 bits et en multicoeur.
En gros, si on faisait un parallèle "véhicule terrestre" on est parti d'une trottinette, on y a ajouté un moteur, puis deux roues, puis des phares, puis un siège, puis un autre, puis une cabine, puis un coffre, puis on a changé les roues pour des jantes alliages, puis on y a mis l'ABS et l'ESP, et aujourd'hui on a un truc qui ressemble à une voiture. Comme c'est le modèle que tout le monde a, le béotien s'imagine que c'est "comme ça que doit être une voiture". Le jour où il croise une vraie bonne bagnole, évidemment ça fait un choc.
Merci de cette clair explication ;-)
Emmanuel Florac wrote:
Ok :-) En parlant de ca, je serais bien curieux de savoir ce qui peut
faire qu'une architecture soit plus "mauvaise' qu'une autre : est-ce comme
les formats de compression audio, où la compression en mp3 est moins
bonne que celle en vorbis car plus vieille (une architecture peut plus ou
moin évoluer, non ?), ou y-a-t'il des raisons plus précise ?
En l'occurence, on est parti d'une architecture très limitée 8 bits
(8080), pour en extrapoler une 16 bits (8086), qu'on a étendu avec un peu
de protection mémoire (80286), puis on l'a encore étendue en 32 bits
(80386), après quoi on a intégré le coprocesseur arithmétique (80486),
avant de passer à un superscalaire sommaire (Pentium), puis à un vrai
superscalaire RISC avec une "interface" CISC (Pentium Pro), auquel on a
ajouté des estensions SIMD MMX (Pentium II, puis MMX2 avec le Pentium
III), avant de le gonfler en 64 bits et en multicoeur.
En gros, si on faisait un parallèle "véhicule terrestre" on est parti
d'une trottinette, on y a ajouté un moteur, puis deux roues, puis des
phares, puis un siège, puis un autre, puis une cabine, puis un coffre,
puis on a changé les roues pour des jantes alliages, puis on y a mis
l'ABS et l'ESP, et aujourd'hui on a un truc qui ressemble à une voiture.
Comme c'est le modèle que tout le monde a, le béotien s'imagine que
c'est "comme ça que doit être une voiture". Le jour où il croise une
vraie bonne bagnole, évidemment ça fait un choc.
Ok :-) En parlant de ca, je serais bien curieux de savoir ce qui peut faire qu'une architecture soit plus "mauvaise' qu'une autre : est-ce comme les formats de compression audio, où la compression en mp3 est moins bonne que celle en vorbis car plus vieille (une architecture peut plus ou moin évoluer, non ?), ou y-a-t'il des raisons plus précise ?
En l'occurence, on est parti d'une architecture très limitée 8 bits (8080), pour en extrapoler une 16 bits (8086), qu'on a étendu avec un peu de protection mémoire (80286), puis on l'a encore étendue en 32 bits (80386), après quoi on a intégré le coprocesseur arithmétique (80486), avant de passer à un superscalaire sommaire (Pentium), puis à un vrai superscalaire RISC avec une "interface" CISC (Pentium Pro), auquel on a ajouté des estensions SIMD MMX (Pentium II, puis MMX2 avec le Pentium III), avant de le gonfler en 64 bits et en multicoeur.
En gros, si on faisait un parallèle "véhicule terrestre" on est parti d'une trottinette, on y a ajouté un moteur, puis deux roues, puis des phares, puis un siège, puis un autre, puis une cabine, puis un coffre, puis on a changé les roues pour des jantes alliages, puis on y a mis l'ABS et l'ESP, et aujourd'hui on a un truc qui ressemble à une voiture. Comme c'est le modèle que tout le monde a, le béotien s'imagine que c'est "comme ça que doit être une voiture". Le jour où il croise une vraie bonne bagnole, évidemment ça fait un choc.
Merci de cette clair explication ;-)
Nanar Duff >
Michel Talon wrote:
Miod Vallat wrote:
C'est plus rapide. Le reste est sans importance.
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui suffit à rendre tout le code compilé avec un compilateur 64 bits plus rapide, même si c'est un mauvais compilateur.
Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod dise enfin que les prémisses du post initial étaient fausses, et qu'en mode 64 bits le processeur dispose de plus de registres, ce qui est important car le x86 manque cruellement de registres. A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un biproc est plus lent à cause des changements de contexte, il est clair que des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que les deux sortent du cache, la différence s'estompe rapidement.
(*) sur des machines avec bien moins de 4 Gigs de mémoire.
Merci de cette réponse !
En effet j'avais pensé à la taille des registres mais pas au nombre... voila une information importante !
De plus j'aimerais dire pour ma défense que le but du post était justement de savoir à quoi sert le 64 bit A PART addresser 4GB de mémoire :-)
Je trouve quand même les chiffres que tu avances assez impressionnant : des calculs fait sous Maple 64 bits vont 2 fois plus vite qu'en 32 bits ?! Il devait s'agir de calculs de vrai bourrin ?!
Michel Talon wrote:
Miod Vallat wrote:
C'est plus rapide. Le reste est sans importance.
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de
deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela
permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui
suffit à rendre tout le code compilé avec un compilateur 64 bits plus
rapide, même si c'est un mauvais compilateur.
Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod
dise enfin que les prémisses du post initial étaient fausses, et qu'en mode
64 bits le processeur dispose de plus de registres, ce qui est important
car le x86 manque cruellement de registres. A titre d'information, sur nos
machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui,
une augmentation de 100%) sur des calculs symboliques avec, par exemple
Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper
court aux arguments ridicules prétendant que le 64 bits ne sert qu'à
adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un
biproc est plus lent à cause des changements de contexte, il est clair que
des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est
pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y
tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a
une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que
les deux sortent du cache, la différence s'estompe rapidement.
(*) sur des machines avec bien moins de 4 Gigs de mémoire.
Merci de cette réponse !
En effet j'avais pensé à la taille des registres mais pas au nombre...
voila une information importante !
De plus j'aimerais dire pour ma défense que le but du post était
justement de savoir à quoi sert le 64 bit A PART addresser 4GB de
mémoire :-)
Je trouve quand même les chiffres que tu avances assez impressionnant :
des calculs fait sous Maple 64 bits vont 2 fois plus vite qu'en 32 bits
?! Il devait s'agir de calculs de vrai bourrin ?!
Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui suffit à rendre tout le code compilé avec un compilateur 64 bits plus rapide, même si c'est un mauvais compilateur.
Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod dise enfin que les prémisses du post initial étaient fausses, et qu'en mode 64 bits le processeur dispose de plus de registres, ce qui est important car le x86 manque cruellement de registres. A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un biproc est plus lent à cause des changements de contexte, il est clair que des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que les deux sortent du cache, la différence s'estompe rapidement.
(*) sur des machines avec bien moins de 4 Gigs de mémoire.
Merci de cette réponse !
En effet j'avais pensé à la taille des registres mais pas au nombre... voila une information importante !
De plus j'aimerais dire pour ma défense que le but du post était justement de savoir à quoi sert le 64 bit A PART addresser 4GB de mémoire :-)
Je trouve quand même les chiffres que tu avances assez impressionnant : des calculs fait sous Maple 64 bits vont 2 fois plus vite qu'en 32 bits ?! Il devait s'agir de calculs de vrai bourrin ?!
