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.
Bien sûr, l'exécution de binaires 32 bits (flash, acrobat frigidaire, etc) ne profite en rien du processeur 64 bits.
Bien sur que non, pour exécuter ces binaires, n'importe quel instrument contondant est suffisant.
-- <ptilou> Mes partagaient, " Bougre de ma fatche" ...
Michel Billaud
Jérémy JUST writes:
Le grand public découvre ça maintenant, mais le fait de pouvoir faire tourner plusieurs processus en même temps doit dater des années 70 (ou au moins 80), avec les machines SMP.
Le debut des années 60, sans SMP.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Jérémy JUST <jeremy_just@netcourrier.com> writes:
Le grand public découvre ça maintenant, mais le fait de pouvoir faire
tourner plusieurs processus en même temps doit dater des années 70
(ou au moins 80), avec les machines SMP.
Le debut des années 60, sans SMP.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Le grand public découvre ça maintenant, mais le fait de pouvoir faire tourner plusieurs processus en même temps doit dater des années 70 (ou au moins 80), avec les machines SMP.
Le debut des années 60, sans SMP.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Nicolas George
Nanar Duff , dans le message <47090c23$0$16428$, a écrit :
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.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a aussi plus de registres généralistes.
Donc, le (seul ?) avantage du 64 bits pour les application ne demandant pas de calculs avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou 64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de 50 jours (il me semble que les vieux windows NT avaient un problème à ce niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin de mesurer le temps en dessous de la seconde, ce n'est pas rare.
c'est l'augmentation de l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce marketing ?
Si on considère que la plupart des machines vendues actuellement ont 1 Go de RAM minimum, donc on est très près de la limite de l'espace d'adressage. Si on se rappelle aussi que les OS modernes savent faire de la mémoire virtuelle et des fichiers mappés en mémoire, et que les disques durs font plusieurs centaines de giga-octets, c'est loin d'être négligeable.
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" ?
Oui.
Ne change-t-il vraiment rien d'autre que quelques broutilles concernant l'addressage ?
Si, ça change énormément. Du point de vue du compilateur, un Core 2 en 32 bits, c'est un 386 un peu plus rapide, avec quelques instructions en plus. Le compilateur peut faire l'effort d'utiliser ces instructions, mais une grande partie l'architecture du code produit reste quelque chose de compatible avec le 386.
C'est ce qu'on appelle l'ABI d'un système (couple système d'exploitation et architecture physique) : les conventions sur la manière dont les fonctions doivent se passer les arguments. Avec un Core 2 aujourd'hui, cette ABI reste compatible avec le 386.
C'est en particulier vrai pour les calculs sur les flottants : l'ABI de Linux en 32 bits utilise les registres du coprocesseur arithmétique 387. Un Core 2 a un système appelé SSE2 qui est plus pratique pour ça (en particulier parce qu'il peut échanger directement des registres avec le processeur, le 387 doit passer par la mémoire il me semble). Donc même si le compilateur peut, dans une fonction, utiliser SSE2 s'il sait que ça tournera sur un Core 2, dès qu'il y a des appels de fonctions, il doit passer par le 387.
À l'inverse, le Core 2 en 64 bits est un tout nouveau processeur (enfin, c'est l'AMD64 le nouveau, mais bon), qui n'est pas encombré de la compatibilité avec l'ancien. L'ABI a été conçue pour tirer parti directement de ses nouvelles possibilités.
D'autre part, comme la partie génération et optimisation du code du processeur dû être réécrite depuis le début pour le nouveau processeur, elle peut intégrer plus directement les nouvelles possibilités. Là encore, j'ai l'exemple d'un problème entre 387 et SSE2 : même sans appel de fonctions, où le calcul pourrait se faire entièrement avec SSE2, gcc va parfois passer par le 387 simplement parce qu'il n'a pas vu qu'il pouvait couper court. Du coup, le code produit est beaucoup plus lent en 32 bits qu'en 64 bits. En optimisant l'assembleur à la main, on arrive à les amener à égalité, mais gcc ne le voit pas.
L'un dans l'autre, une application gourmande en CPU va gagner peut-être 10% de vitesse à passer en 64 bits (test fait avec POV-Ray).
En revanche, l'occupation mémoire peut se trouver augmentée. Ce ne sera pas toujours le cas. En particulier, pour beaucoup de programmes, l'essentiel de la mémoire est pris par des données plates (typiquement, une image), qui n'est pas influencée. Mais avec des langages de haut niveau manipulant automatiquement des structures de données pleines de pointeurs, ça peut jouer.
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup d'applications Linux compatible 64bits ?
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre histoire.
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel "compilé en mode 64 bits",
Oui. Parfois un peu pénible, selon la distribution, pour les histoires de bibliothèques partagées, mais aucun problème de fond.
Il y a quelques rares cas de périphériques dont certaines fonctionnalités ne sont pas disponibles en émulation 32 bits, mais la plupart des applications ne touchent pas aux périphériques.
et cela ralentit-il l'application ?
Pas du tout.
Nanar Duff , dans le message <47090c23$0$16428$426a74cc@news.free.fr>, a
écrit :
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.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a
aussi plus de registres généralistes.
Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres
énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le
facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou
64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de
50 jours (il me semble que les vieux windows NT avaient un problème à ce
niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin
de mesurer le temps en dessous de la seconde, ce n'est pas rare.
c'est l'augmentation de
l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce
marketing ?
Si on considère que la plupart des machines vendues actuellement ont 1 Go de
RAM minimum, donc on est très près de la limite de l'espace d'adressage. Si
on se rappelle aussi que les OS modernes savent faire de la mémoire
virtuelle et des fichiers mappés en mémoire, et que les disques durs font
plusieurs centaines de giga-octets, c'est loin d'être négligeable.
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" ?
Oui.
Ne
change-t-il vraiment rien d'autre que quelques broutilles concernant
l'addressage ?
Si, ça change énormément. Du point de vue du compilateur, un Core 2 en
32 bits, c'est un 386 un peu plus rapide, avec quelques instructions en
plus. Le compilateur peut faire l'effort d'utiliser ces instructions, mais
une grande partie l'architecture du code produit reste quelque chose de
compatible avec le 386.
C'est ce qu'on appelle l'ABI d'un système (couple système d'exploitation et
architecture physique) : les conventions sur la manière dont les fonctions
doivent se passer les arguments. Avec un Core 2 aujourd'hui, cette ABI reste
compatible avec le 386.
C'est en particulier vrai pour les calculs sur les flottants : l'ABI de
Linux en 32 bits utilise les registres du coprocesseur arithmétique 387. Un
Core 2 a un système appelé SSE2 qui est plus pratique pour ça (en
particulier parce qu'il peut échanger directement des registres avec le
processeur, le 387 doit passer par la mémoire il me semble). Donc même si le
compilateur peut, dans une fonction, utiliser SSE2 s'il sait que ça tournera
sur un Core 2, dès qu'il y a des appels de fonctions, il doit passer par le
387.
À l'inverse, le Core 2 en 64 bits est un tout nouveau processeur (enfin,
c'est l'AMD64 le nouveau, mais bon), qui n'est pas encombré de la
compatibilité avec l'ancien. L'ABI a été conçue pour tirer parti directement
de ses nouvelles possibilités.
D'autre part, comme la partie génération et optimisation du code du
processeur dû être réécrite depuis le début pour le nouveau processeur, elle
peut intégrer plus directement les nouvelles possibilités. Là encore, j'ai
l'exemple d'un problème entre 387 et SSE2 : même sans appel de fonctions, où
le calcul pourrait se faire entièrement avec SSE2, gcc va parfois passer par
le 387 simplement parce qu'il n'a pas vu qu'il pouvait couper court. Du
coup, le code produit est beaucoup plus lent en 32 bits qu'en 64 bits. En
optimisant l'assembleur à la main, on arrive à les amener à égalité, mais
gcc ne le voit pas.
L'un dans l'autre, une application gourmande en CPU va gagner peut-être 10%
de vitesse à passer en 64 bits (test fait avec POV-Ray).
En revanche, l'occupation mémoire peut se trouver augmentée. Ce ne sera pas
toujours le cas. En particulier, pour beaucoup de programmes, l'essentiel de
la mémoire est pris par des données plates (typiquement, une image), qui
n'est pas influencée. Mais avec des langages de haut niveau manipulant
automatiquement des structures de données pleines de pointeurs, ça peut
jouer.
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup
d'applications Linux compatible 64bits ?
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à
ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même
semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un
dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre
histoire.
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel
"compilé en mode 64 bits",
Oui. Parfois un peu pénible, selon la distribution, pour les histoires de
bibliothèques partagées, mais aucun problème de fond.
Il y a quelques rares cas de périphériques dont certaines fonctionnalités ne
sont pas disponibles en émulation 32 bits, mais la plupart des applications
ne touchent pas aux périphériques.
Nanar Duff , dans le message <47090c23$0$16428$, a écrit :
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.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a aussi plus de registres généralistes.
Donc, le (seul ?) avantage du 64 bits pour les application ne demandant pas de calculs avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou 64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de 50 jours (il me semble que les vieux windows NT avaient un problème à ce niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin de mesurer le temps en dessous de la seconde, ce n'est pas rare.
c'est l'augmentation de l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce marketing ?
Si on considère que la plupart des machines vendues actuellement ont 1 Go de RAM minimum, donc on est très près de la limite de l'espace d'adressage. Si on se rappelle aussi que les OS modernes savent faire de la mémoire virtuelle et des fichiers mappés en mémoire, et que les disques durs font plusieurs centaines de giga-octets, c'est loin d'être négligeable.
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" ?
Oui.
Ne change-t-il vraiment rien d'autre que quelques broutilles concernant l'addressage ?
Si, ça change énormément. Du point de vue du compilateur, un Core 2 en 32 bits, c'est un 386 un peu plus rapide, avec quelques instructions en plus. Le compilateur peut faire l'effort d'utiliser ces instructions, mais une grande partie l'architecture du code produit reste quelque chose de compatible avec le 386.
C'est ce qu'on appelle l'ABI d'un système (couple système d'exploitation et architecture physique) : les conventions sur la manière dont les fonctions doivent se passer les arguments. Avec un Core 2 aujourd'hui, cette ABI reste compatible avec le 386.
C'est en particulier vrai pour les calculs sur les flottants : l'ABI de Linux en 32 bits utilise les registres du coprocesseur arithmétique 387. Un Core 2 a un système appelé SSE2 qui est plus pratique pour ça (en particulier parce qu'il peut échanger directement des registres avec le processeur, le 387 doit passer par la mémoire il me semble). Donc même si le compilateur peut, dans une fonction, utiliser SSE2 s'il sait que ça tournera sur un Core 2, dès qu'il y a des appels de fonctions, il doit passer par le 387.
À l'inverse, le Core 2 en 64 bits est un tout nouveau processeur (enfin, c'est l'AMD64 le nouveau, mais bon), qui n'est pas encombré de la compatibilité avec l'ancien. L'ABI a été conçue pour tirer parti directement de ses nouvelles possibilités.
D'autre part, comme la partie génération et optimisation du code du processeur dû être réécrite depuis le début pour le nouveau processeur, elle peut intégrer plus directement les nouvelles possibilités. Là encore, j'ai l'exemple d'un problème entre 387 et SSE2 : même sans appel de fonctions, où le calcul pourrait se faire entièrement avec SSE2, gcc va parfois passer par le 387 simplement parce qu'il n'a pas vu qu'il pouvait couper court. Du coup, le code produit est beaucoup plus lent en 32 bits qu'en 64 bits. En optimisant l'assembleur à la main, on arrive à les amener à égalité, mais gcc ne le voit pas.
L'un dans l'autre, une application gourmande en CPU va gagner peut-être 10% de vitesse à passer en 64 bits (test fait avec POV-Ray).
En revanche, l'occupation mémoire peut se trouver augmentée. Ce ne sera pas toujours le cas. En particulier, pour beaucoup de programmes, l'essentiel de la mémoire est pris par des données plates (typiquement, une image), qui n'est pas influencée. Mais avec des langages de haut niveau manipulant automatiquement des structures de données pleines de pointeurs, ça peut jouer.
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup d'applications Linux compatible 64bits ?
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre histoire.
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel "compilé en mode 64 bits",
Oui. Parfois un peu pénible, selon la distribution, pour les histoires de bibliothèques partagées, mais aucun problème de fond.
Il y a quelques rares cas de périphériques dont certaines fonctionnalités ne sont pas disponibles en émulation 32 bits, mais la plupart des applications ne touchent pas aux périphériques.
et cela ralentit-il l'application ?
Pas du tout.
Nicolas George
JKB , dans le message , a écrit :
C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un dernier fil, tu as essayé de nous dire que les tailles des exécutables 64 bits et 32 bits étaient les mêmes alors que je te prouvais que non... J'ai la flemme de chercher l'ID du message...
C'était avec moi, et je ne retrouve pas la discussion, mais il me semble bien que j'avais assez bien prouvé mon argument. D'ailleurs, c'est facile :
-rwxr-xr-x 1 root root 1391928 Aug 7 14:35 /lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 1335912 Aug 24 03:17 /mnt/32/lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 769368 Dec 11 2006 /bin/bash* -rwxr-xr-x 1 root root 677184 Dec 11 2006 /mnt/32/bin/bash* -rwxr-xr-x 1 root root 1587728 Aug 9 18:44 /usr/bin/vim.basic* -rwxr-xr-x 1 root root 1399348 Aug 9 17:59 /mnt/32/usr/bin/vim.basic*
Les binaires 64 bits sont plus gros, mais la différence est assez faible, moins de 15% alors que tu prétendais un facteur 2.
Compare pour rigoler une SS20 avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz)
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71.
JKB , dans le message <slrnfgjnfq.3at.knatschke@fermat.systella.fr>, a
écrit :
C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un
dernier fil, tu as essayé de nous dire que les tailles des exécutables
64 bits et 32 bits étaient les mêmes alors que je te prouvais que
non... J'ai la flemme de chercher l'ID du message...
C'était avec moi, et je ne retrouve pas la discussion, mais il me semble
bien que j'avais assez bien prouvé mon argument. D'ailleurs, c'est facile :
-rwxr-xr-x 1 root root 1391928 Aug 7 14:35 /lib/libc-2.6.1.so*
-rwxr-xr-x 1 root root 1335912 Aug 24 03:17 /mnt/32/lib/libc-2.6.1.so*
-rwxr-xr-x 1 root root 769368 Dec 11 2006 /bin/bash*
-rwxr-xr-x 1 root root 677184 Dec 11 2006 /mnt/32/bin/bash*
-rwxr-xr-x 1 root root 1587728 Aug 9 18:44 /usr/bin/vim.basic*
-rwxr-xr-x 1 root root 1399348 Aug 9 17:59 /mnt/32/usr/bin/vim.basic*
Les binaires 64 bits sont plus gros, mais la différence est assez faible,
moins de 15% alors que tu prétendais un facteur 2.
Compare pour rigoler une SS20
avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz)
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est
une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils
vont quand même nettement plus vite qu'un seul SM71.
C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un dernier fil, tu as essayé de nous dire que les tailles des exécutables 64 bits et 32 bits étaient les mêmes alors que je te prouvais que non... J'ai la flemme de chercher l'ID du message...
C'était avec moi, et je ne retrouve pas la discussion, mais il me semble bien que j'avais assez bien prouvé mon argument. D'ailleurs, c'est facile :
-rwxr-xr-x 1 root root 1391928 Aug 7 14:35 /lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 1335912 Aug 24 03:17 /mnt/32/lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 769368 Dec 11 2006 /bin/bash* -rwxr-xr-x 1 root root 677184 Dec 11 2006 /mnt/32/bin/bash* -rwxr-xr-x 1 root root 1587728 Aug 9 18:44 /usr/bin/vim.basic* -rwxr-xr-x 1 root root 1399348 Aug 9 17:59 /mnt/32/usr/bin/vim.basic*
Les binaires 64 bits sont plus gros, mais la différence est assez faible, moins de 15% alors que tu prétendais un facteur 2.
Compare pour rigoler une SS20 avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz)
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71.
Nicolas George
"Thierry B." , dans le message , a écrit :
Et l'espace d'adressage ? Il y a de cela très très longtemps, j'avais lu un article sur l'utilisation d'immenses espaces d'adressage par les bases de données, permettant une grande simplification du code, je crois que c'était des travaux de l'équipe Ingres.
En tout cas, quand j'ai essayé d'écrire un udffsck, j'aurais bien aimé pouvoir me permettre de mmaper les 300 Go du disque à vérifier et laisser l'OS derrière se débrouiller pour gérer ça.
"Thierry B." , dans le message <524pt4-r94.ln1@prout.stex>, a écrit :
Et l'espace d'adressage ? Il y a de cela très très longtemps, j'avais
lu un article sur l'utilisation d'immenses espaces d'adressage par
les bases de données, permettant une grande simplification du code,
je crois que c'était des travaux de l'équipe Ingres.
En tout cas, quand j'ai essayé d'écrire un udffsck, j'aurais bien aimé
pouvoir me permettre de mmaper les 300 Go du disque à vérifier et laisser
l'OS derrière se débrouiller pour gérer ça.
Et l'espace d'adressage ? Il y a de cela très très longtemps, j'avais lu un article sur l'utilisation d'immenses espaces d'adressage par les bases de données, permettant une grande simplification du code, je crois que c'était des travaux de l'équipe Ingres.
En tout cas, quand j'ai essayé d'écrire un udffsck, j'aurais bien aimé pouvoir me permettre de mmaper les 300 Go du disque à vérifier et laisser l'OS derrière se débrouiller pour gérer ça.
JKB
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
Nanar Duff , dans le message <47090c23$0$16428$, a écrit :
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.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a aussi plus de registres généralistes.
Donc, le (seul ?) avantage du 64 bits pour les application ne demandant pas de calculs avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou 64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de 50 jours (il me semble que les vieux windows NT avaient un problème à ce niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin de mesurer le temps en dessous de la seconde, ce n'est pas rare.
Ouaips, dans ce cas, l'application est mal codée. On utilise _deux_ compteurs pour passer sur 64 bits. En gros, si on a un problème, c'est qu'on n'y a _jamais_ pensé.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 08-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
Nanar Duff , dans le message <47090c23$0$16428$426a74cc@news.free.fr>, a
écrit :
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.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a
aussi plus de registres généralistes.
Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres
énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le
facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou
64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de
50 jours (il me semble que les vieux windows NT avaient un problème à ce
niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin
de mesurer le temps en dessous de la seconde, ce n'est pas rare.
Ouaips, dans ce cas, l'application est mal codée. On utilise _deux_
compteurs pour passer sur 64 bits. En gros, si on a un problème,
c'est qu'on n'y a _jamais_ pensé.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
Nanar Duff , dans le message <47090c23$0$16428$, a écrit :
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.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a aussi plus de registres généralistes.
Donc, le (seul ?) avantage du 64 bits pour les application ne demandant pas de calculs avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou 64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de 50 jours (il me semble que les vieux windows NT avaient un problème à ce niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin de mesurer le temps en dessous de la seconde, ce n'est pas rare.
Ouaips, dans ce cas, l'application est mal codée. On utilise _deux_ compteurs pour passer sur 64 bits. En gros, si on a un problème, c'est qu'on n'y a _jamais_ pensé.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un dernier fil, tu as essayé de nous dire que les tailles des exécutables 64 bits et 32 bits étaient les mêmes alors que je te prouvais que non... J'ai la flemme de chercher l'ID du message...
C'était avec moi, et je ne retrouve pas la discussion, mais il me semble bien que j'avais assez bien prouvé mon argument. D'ailleurs, c'est facile :
-rwxr-xr-x 1 root root 1391928 Aug 7 14:35 /lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 1335912 Aug 24 03:17 /mnt/32/lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 769368 Dec 11 2006 /bin/bash* -rwxr-xr-x 1 root root 677184 Dec 11 2006 /mnt/32/bin/bash* -rwxr-xr-x 1 root root 1587728 Aug 9 18:44 /usr/bin/vim.basic* -rwxr-xr-x 1 root root 1399348 Aug 9 17:59 /mnt/32/usr/bin/vim.basic*
Les binaires 64 bits sont plus gros, mais la différence est assez faible, moins de 15% alors que tu prétendais un facteur 2.
Tu prétendais moins à l'époque alors que je prétendais que pour les softs utilisant _vraiment_ les capacités mémoire adressables en 64 bits, cela doublaient à peu près la taille (j'ai des tas d'exemples, et d'autres types que moi se posent le problème. C'est même pour cela que sur les Sparc, toutes les applications qui n'ont pas besoin spécifiquement de 64 bits tournent en 32).
Compare pour rigoler une SS20 avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz)
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71.
Ce n'est pas ce que j'ai écrit, tu tronques mes propos. Je compare un processeur _unique_ tournant deux fois plus vite qu'un système à _deux_ processeurs deux fois plus lents dans une charge_ supérieure à deux_.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 08-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnfgjnfq.3at.knatschke@fermat.systella.fr>, a
écrit :
C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un
dernier fil, tu as essayé de nous dire que les tailles des exécutables
64 bits et 32 bits étaient les mêmes alors que je te prouvais que
non... J'ai la flemme de chercher l'ID du message...
C'était avec moi, et je ne retrouve pas la discussion, mais il me semble
bien que j'avais assez bien prouvé mon argument. D'ailleurs, c'est facile :
-rwxr-xr-x 1 root root 1391928 Aug 7 14:35 /lib/libc-2.6.1.so*
-rwxr-xr-x 1 root root 1335912 Aug 24 03:17 /mnt/32/lib/libc-2.6.1.so*
-rwxr-xr-x 1 root root 769368 Dec 11 2006 /bin/bash*
-rwxr-xr-x 1 root root 677184 Dec 11 2006 /mnt/32/bin/bash*
-rwxr-xr-x 1 root root 1587728 Aug 9 18:44 /usr/bin/vim.basic*
-rwxr-xr-x 1 root root 1399348 Aug 9 17:59 /mnt/32/usr/bin/vim.basic*
Les binaires 64 bits sont plus gros, mais la différence est assez faible,
moins de 15% alors que tu prétendais un facteur 2.
Tu prétendais moins à l'époque alors que je prétendais que pour les
softs utilisant _vraiment_ les capacités mémoire adressables en 64
bits, cela doublaient à peu près la taille (j'ai des tas d'exemples,
et d'autres types que moi se posent le problème. C'est même pour
cela que sur les Sparc, toutes les applications qui n'ont pas besoin
spécifiquement de 64 bits tournent en 32).
Compare pour rigoler une SS20
avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz)
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est
une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils
vont quand même nettement plus vite qu'un seul SM71.
Ce n'est pas ce que j'ai écrit, tu tronques mes propos. Je compare
un processeur _unique_ tournant deux fois plus vite qu'un système à
_deux_ processeurs deux fois plus lents dans une charge_ supérieure
à deux_.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un dernier fil, tu as essayé de nous dire que les tailles des exécutables 64 bits et 32 bits étaient les mêmes alors que je te prouvais que non... J'ai la flemme de chercher l'ID du message...
C'était avec moi, et je ne retrouve pas la discussion, mais il me semble bien que j'avais assez bien prouvé mon argument. D'ailleurs, c'est facile :
-rwxr-xr-x 1 root root 1391928 Aug 7 14:35 /lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 1335912 Aug 24 03:17 /mnt/32/lib/libc-2.6.1.so* -rwxr-xr-x 1 root root 769368 Dec 11 2006 /bin/bash* -rwxr-xr-x 1 root root 677184 Dec 11 2006 /mnt/32/bin/bash* -rwxr-xr-x 1 root root 1587728 Aug 9 18:44 /usr/bin/vim.basic* -rwxr-xr-x 1 root root 1399348 Aug 9 17:59 /mnt/32/usr/bin/vim.basic*
Les binaires 64 bits sont plus gros, mais la différence est assez faible, moins de 15% alors que tu prétendais un facteur 2.
Tu prétendais moins à l'époque alors que je prétendais que pour les softs utilisant _vraiment_ les capacités mémoire adressables en 64 bits, cela doublaient à peu près la taille (j'ai des tas d'exemples, et d'autres types que moi se posent le problème. C'est même pour cela que sur les Sparc, toutes les applications qui n'ont pas besoin spécifiquement de 64 bits tournent en 32).
Compare pour rigoler une SS20 avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz)
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71.
Ce n'est pas ce que j'ai écrit, tu tronques mes propos. Je compare un processeur _unique_ tournant deux fois plus vite qu'un système à _deux_ processeurs deux fois plus lents dans une charge_ supérieure à deux_.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
JKB , dans le message , a écrit :
(j'ai des tas d'exemples, et d'autres types que moi se posent le problème.
J'attends de les voir.
C'est même pour cela que sur les Sparc, toutes les applications qui n'ont pas besoin spécifiquement de 64 bits tournent en 32).
Et c'est non-pertinent pour une discussion portant sur les x86.
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71. Ce n'est pas ce que j'ai écrit
Je sais bien que ce n'est pas ce que tu as écrit, c'est précisément ce que je te reproche !
JKB , dans le message <slrnfgk1qo.3at.knatschke@fermat.systella.fr>, a
écrit :
(j'ai des tas d'exemples,
et d'autres types que moi se posent le problème.
J'attends de les voir.
C'est même pour
cela que sur les Sparc, toutes les applications qui n'ont pas besoin
spécifiquement de 64 bits tournent en 32).
Et c'est non-pertinent pour une discussion portant sur les x86.
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est
une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils
vont quand même nettement plus vite qu'un seul SM71.
Ce n'est pas ce que j'ai écrit
Je sais bien que ce n'est pas ce que tu as écrit, c'est précisément ce que
je te reproche !
(j'ai des tas d'exemples, et d'autres types que moi se posent le problème.
J'attends de les voir.
C'est même pour cela que sur les Sparc, toutes les applications qui n'ont pas besoin spécifiquement de 64 bits tournent en 32).
Et c'est non-pertinent pour une discussion portant sur les x86.
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71. Ce n'est pas ce que j'ai écrit
Je sais bien que ce n'est pas ce que tu as écrit, c'est précisément ce que je te reproche !
Nicolas George
JKB , dans le message , a écrit :
Ouaips, dans ce cas, l'application est mal codée. On utilise _deux_ compteurs pour passer sur 64 bits. En gros, si on a un problème, c'est qu'on n'y a _jamais_ pensé.
Faire du pseudo-64 bits avec des opérations 32 bits, donc. C'est forcément plus lent et plus coûteux que du 64 bits natif.
JKB , dans le message <slrnfgk1ko.3at.knatschke@fermat.systella.fr>, a
écrit :
Ouaips, dans ce cas, l'application est mal codée. On utilise _deux_
compteurs pour passer sur 64 bits. En gros, si on a un problème,
c'est qu'on n'y a _jamais_ pensé.
Faire du pseudo-64 bits avec des opérations 32 bits, donc. C'est forcément
plus lent et plus coûteux que du 64 bits natif.
Ouaips, dans ce cas, l'application est mal codée. On utilise _deux_ compteurs pour passer sur 64 bits. En gros, si on a un problème, c'est qu'on n'y a _jamais_ pensé.
Faire du pseudo-64 bits avec des opérations 32 bits, donc. C'est forcément plus lent et plus coûteux que du 64 bits natif.
JKB
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
(j'ai des tas d'exemples, et d'autres types que moi se posent le problème.
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits. Ça va mieux ?
C'est même pour cela que sur les Sparc, toutes les applications qui n'ont pas besoin spécifiquement de 64 bits tournent en 32).
Et c'est non-pertinent pour une discussion portant sur les x86.
Tu coupes encore.
Maintenant, pour rigoler, j'ai fait le même test avec amd64 et i386 : fermat:[~/gopher/rpl2/build-i386/src] > ls -l rpl -rwxr-xr-x 1 bertrand bertrand 3935613 2007-10-03 22:21 rpl fermat:[~/gopher/rpl2/build-amd64/src] > ls -l rpl -rwxr-xr-x 1 bertrand bertrand 5645495 2007-10-03 22:21 rpl
ce qui fait une différence de plus de 15%. Le compilo utilisé est ici gcc-4.1.2.
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71. Ce n'est pas ce que j'ai écrit
Je sais bien que ce n'est pas ce que tu as écrit, c'est précisément ce que je te reproche !
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 08-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnfgk1qo.3at.knatschke@fermat.systella.fr>, a
écrit :
(j'ai des tas d'exemples,
et d'autres types que moi se posent le problème.
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une
histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits.
Ça va mieux ?
C'est même pour
cela que sur les Sparc, toutes les applications qui n'ont pas besoin
spécifiquement de 64 bits tournent en 32).
Et c'est non-pertinent pour une discussion portant sur les x86.
Tu coupes encore.
Maintenant, pour rigoler, j'ai fait le même test avec amd64 et i386 :
fermat:[~/gopher/rpl2/build-i386/src] > ls -l rpl
-rwxr-xr-x 1 bertrand bertrand 3935613 2007-10-03 22:21 rpl
fermat:[~/gopher/rpl2/build-amd64/src] > ls -l rpl
-rwxr-xr-x 1 bertrand bertrand 5645495 2007-10-03 22:21 rpl
ce qui fait une différence de plus de 15%. Le compilo utilisé est
ici gcc-4.1.2.
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est
une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils
vont quand même nettement plus vite qu'un seul SM71.
Ce n'est pas ce que j'ai écrit
Je sais bien que ce n'est pas ce que tu as écrit, c'est précisément ce que
je te reproche !
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits. Ça va mieux ?
C'est même pour cela que sur les Sparc, toutes les applications qui n'ont pas besoin spécifiquement de 64 bits tournent en 32).
Et c'est non-pertinent pour une discussion portant sur les x86.
Tu coupes encore.
Maintenant, pour rigoler, j'ai fait le même test avec amd64 et i386 : fermat:[~/gopher/rpl2/build-i386/src] > ls -l rpl -rwxr-xr-x 1 bertrand bertrand 3935613 2007-10-03 22:21 rpl fermat:[~/gopher/rpl2/build-amd64/src] > ls -l rpl -rwxr-xr-x 1 bertrand bertrand 5645495 2007-10-03 22:21 rpl
ce qui fait une différence de plus de 15%. Le compilo utilisé est ici gcc-4.1.2.
Qu'un SMP ne rivalise pas avec un processeur deux fois plus rapide, c'est une évidence, personne n'a prétendu le contraire. Mais tes deux SM71, ils vont quand même nettement plus vite qu'un seul SM71. Ce n'est pas ce que j'ai écrit
Je sais bien que ce n'est pas ce que tu as écrit, c'est précisément ce que je te reproche !
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
