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.
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 :
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.
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
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 <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.
Je n'ai jamais dit de compter en 64 bits, c'est _ton_
interprétation. Je te laisse méditer.
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 :
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.
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
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 ?
Quelle architecture ?
Et c'est non-pertinent pour une discussion portant sur les x86. Tu coupes encore.
Qu'est-ce que je suis censé couper ? Il était question de la taille des binaires entre x86 et x86_64, pas de la taille des binaires entre 32 et 64 bits sur d'autres architectures.
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.
Ça fait un exemple. Tu en as d'autres, dans d'autres registres ?
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
Je t'invite toi aussi à me relire attentivement. Qu'un processeur à vitesse 2x aille plus vite que deux processeurs à vitesse x, c'est une évidence pour tout le monde. Alors pourquoi sors-tu cet exemple ?
JKB , dans le message <slrnfgk3ga.3at.knatschke@fermat.systella.fr>, a
écrit :
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une
histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits.
Ça va mieux ?
Quelle architecture ?
Et c'est non-pertinent pour une discussion portant sur les x86.
Tu coupes encore.
Qu'est-ce que je suis censé couper ? Il était question de la taille des
binaires entre x86 et x86_64, pas de la taille des binaires entre 32 et
64 bits sur d'autres architectures.
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.
Ça fait un exemple. Tu en as d'autres, dans d'autres registres ?
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
Je t'invite toi aussi à me relire attentivement. Qu'un processeur à vitesse
2x aille plus vite que deux processeurs à vitesse x, c'est une évidence pour
tout le monde. Alors pourquoi sors-tu cet exemple ?
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits. Ça va mieux ?
Quelle architecture ?
Et c'est non-pertinent pour une discussion portant sur les x86. Tu coupes encore.
Qu'est-ce que je suis censé couper ? Il était question de la taille des binaires entre x86 et x86_64, pas de la taille des binaires entre 32 et 64 bits sur d'autres architectures.
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.
Ça fait un exemple. Tu en as d'autres, dans d'autres registres ?
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
Je t'invite toi aussi à me relire attentivement. Qu'un processeur à vitesse 2x aille plus vite que deux processeurs à vitesse x, c'est une évidence pour tout le monde. Alors pourquoi sors-tu cet exemple ?
Nicolas George
JKB , dans le message , a écrit :
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs 32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
JKB , dans le message <slrnfgk3jm.3at.knatschke@fermat.systella.fr>, a
écrit :
Je n'ai jamais dit de compter en 64 bits, c'est _ton_
interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs
32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits. Ça va mieux ?
Quelle architecture ?
sparc, et alors, je t'ai refilé le même exemple avec i386 et amd64.
Et c'est non-pertinent pour une discussion portant sur les x86. Tu coupes encore.
Qu'est-ce que je suis censé couper ? Il était question de la taille des binaires entre x86 et x86_64, pas de la taille des binaires entre 32 et 64 bits sur d'autres architectures.
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.
Ça fait un exemple. Tu en as d'autres, dans d'autres registres ?
Oui, mais je ne vois pas pourquoi les mettre ici vu que de toute façon, tu ne veux voir que ce que tu veux.
Je te rappelle tes positions : il y a deux mois, un binaire i386 était à peine plus petit qu'un amd64. Aujourd'hui, on est à 15% de différence, moi, je mesure peu ou prou 30% (sans compter les problèmes d'alignement qui grèvent les performances). Remarque, je n'ai pas regardé l'espace occupé par le code en question (qui peut être différent en fonction des loaders sur les différentes architectures). Bref, tu n'es pas très cohérent.
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
Je t'invite toi aussi à me relire attentivement. Qu'un processeur à vitesse 2x aille plus vite que deux processeurs à vitesse x, c'est une évidence pour tout le monde. Alors pourquoi sors-tu cet exemple ?
Parce que je parle d'une machine avec une charge conséquente, ce qui fait que sans l'overhead apportée par la gestion des _deux_ processeurs, on devrait avoir à peu de choses près les mêmes performances. Je te rappelle qu'on était en train de discuter des pertes de performances apportées par le SMP.
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 <slrnfgk3ga.3at.knatschke@fermat.systella.fr>, a
écrit :
gcc-4.2.1, gfortran correspondant. La _seule_ différence est une
histoire de compilation : rpl32 -> 32 bits, rpl64 -> 64 bits.
Ça va mieux ?
Quelle architecture ?
sparc, et alors, je t'ai refilé le même exemple avec i386 et amd64.
Et c'est non-pertinent pour une discussion portant sur les x86.
Tu coupes encore.
Qu'est-ce que je suis censé couper ? Il était question de la taille des
binaires entre x86 et x86_64, pas de la taille des binaires entre 32 et
64 bits sur d'autres architectures.
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.
Ça fait un exemple. Tu en as d'autres, dans d'autres registres ?
Oui, mais je ne vois pas pourquoi les mettre ici vu que de toute
façon, tu ne veux voir que ce que tu veux.
Je te rappelle tes positions : il y a deux mois, un binaire i386
était à peine plus petit qu'un amd64. Aujourd'hui, on est à 15% de
différence, moi, je mesure peu ou prou 30% (sans compter les
problèmes d'alignement qui grèvent les performances). Remarque, je
n'ai pas regardé l'espace occupé par le code en question (qui peut
être différent en fonction des loaders sur les différentes
architectures). Bref, tu n'es pas très cohérent.
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
Je t'invite toi aussi à me relire attentivement. Qu'un processeur à vitesse
2x aille plus vite que deux processeurs à vitesse x, c'est une évidence pour
tout le monde. Alors pourquoi sors-tu cet exemple ?
Parce que je parle d'une machine avec une charge conséquente, ce qui
fait que sans l'overhead apportée par la gestion des _deux_
processeurs, on devrait avoir à peu de choses près les mêmes
performances. Je te rappelle qu'on était en train de discuter des
pertes de performances apportées par le SMP.
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 ?
Quelle architecture ?
sparc, et alors, je t'ai refilé le même exemple avec i386 et amd64.
Et c'est non-pertinent pour une discussion portant sur les x86. Tu coupes encore.
Qu'est-ce que je suis censé couper ? Il était question de la taille des binaires entre x86 et x86_64, pas de la taille des binaires entre 32 et 64 bits sur d'autres architectures.
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.
Ça fait un exemple. Tu en as d'autres, dans d'autres registres ?
Oui, mais je ne vois pas pourquoi les mettre ici vu que de toute façon, tu ne veux voir que ce que tu veux.
Je te rappelle tes positions : il y a deux mois, un binaire i386 était à peine plus petit qu'un amd64. Aujourd'hui, on est à 15% de différence, moi, je mesure peu ou prou 30% (sans compter les problèmes d'alignement qui grèvent les performances). Remarque, je n'ai pas regardé l'espace occupé par le code en question (qui peut être différent en fonction des loaders sur les différentes architectures). Bref, tu n'es pas très cohérent.
Relis-moi attentivement. Cela t'éviteras de raconter des conneries.
Je t'invite toi aussi à me relire attentivement. Qu'un processeur à vitesse 2x aille plus vite que deux processeurs à vitesse x, c'est une évidence pour tout le monde. Alors pourquoi sors-tu cet exemple ?
Parce que je parle d'une machine avec une charge conséquente, ce qui fait que sans l'overhead apportée par la gestion des _deux_ processeurs, on devrait avoir à peu de choses près les mêmes performances. Je te rappelle qu'on était en train de discuter des pertes de performances apportées par le SMP.
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 :
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs 32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
Tu veux absolument compter en milliseconde (c'est ton choix). Personnellement, je préfère les horloges externes et les signaux. Admettons. Personnellement, je remplace deux additions 32 bits par une addition 32 bits et une comparaison à zéro avec saut, ce qui ne rajoute quasiment rien comme surcharge en ne faisant deux additions que tous les 50 jours.
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 <slrnfgk3jm.3at.knatschke@fermat.systella.fr>, a
écrit :
Je n'ai jamais dit de compter en 64 bits, c'est _ton_
interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs
32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
Tu veux absolument compter en milliseconde (c'est ton choix).
Personnellement, je préfère les horloges externes et les signaux.
Admettons. Personnellement, je remplace deux additions 32 bits par
une addition 32 bits et une comparaison à zéro avec saut, ce qui
ne rajoute quasiment rien comme surcharge en ne faisant deux
additions que tous les 50 jours.
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 :
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs 32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
Tu veux absolument compter en milliseconde (c'est ton choix). Personnellement, je préfère les horloges externes et les signaux. Admettons. Personnellement, je remplace deux additions 32 bits par une addition 32 bits et une comparaison à zéro avec saut, ce qui ne rajoute quasiment rien comme surcharge en ne faisant deux additions que tous les 50 jours.
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.
remy
JKB , dans le message , a
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs 32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur que le reste soit rempli de zéro je m'en fous dans le cas d'un 64 bits
la différence doit être du côté du nombre de mnemonique
une instruction 64 = 2 instructions 32 en gros et qui vont bien sinon pipeau
et je fais l'impasse sur la largeur du bus cpu /mémoire
mais bon je ne suis plus vraiment à jour côté hard si il y a un spécialiste dans la salle je suis preneur
remy
Philippe.Weill
Michel Talon wrote:
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.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces calculs en 64 bits même sur les machines 32 bits
Michel Talon wrote:
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.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces
calculs en 64 bits même sur les machines 32 bits
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.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces calculs en 64 bits même sur les machines 32 bits
Nicolas George
JKB , dans le message , a écrit :
Oui, mais je ne vois pas pourquoi les mettre ici vu que de toute façon, tu ne veux voir que ce que tu veux.
Je vois ce que j'ai sur mon système, et tu m'excuseras, mais je pense que bash, la libc ou perl, ça me semble statistiquement plus significatif qu'un programme sorti d'on ne sait où.
D'autant plus qu'il me semble me rappeler quelques sorties de ta part concernant la portabilité qui laissent supposer que tu emploies des tournures assez crades.
Je te rappelle tes positions : il y a deux mois, un binaire i386 était à peine plus petit qu'un amd64. Aujourd'hui, on est à 15% de différence,
Quinze pourcents, dans ce domaine, c'est faible.
sans compter les problèmes d'alignement qui grèvent les performances
Je te l'ai déjà dit à l'époque, je te le redis maintenant : les opcodes pas alignés, c'est le mode de fonctionnement _normal_ d'un x86, et ça ne grève absolument pas les performances.
Parce que je parle d'une machine avec une charge conséquente, ce qui fait que sans l'overhead apportée par la gestion des _deux_ processeurs, on devrait avoir à peu de choses près les mêmes performances. Je te rappelle qu'on était en train de discuter des pertes de performances apportées par le SMP.
J'ai peur de te comprendre, là.
Tu dis que un SM71 75 MHz devrait être aussi rapide qu'un Ultra1 140 MHz, mais que deux SM71 75 MHz sont bien plus lent ?
C'est vraiment ça que tu prétends ?
JKB , dans le message <slrnfgk7a7.3at.knatschke@fermat.systella.fr>, a
écrit :
Oui, mais je ne vois pas pourquoi les mettre ici vu que de toute
façon, tu ne veux voir que ce que tu veux.
Je vois ce que j'ai sur mon système, et tu m'excuseras, mais je pense que
bash, la libc ou perl, ça me semble statistiquement plus significatif qu'un
programme sorti d'on ne sait où.
D'autant plus qu'il me semble me rappeler quelques sorties de ta part
concernant la portabilité qui laissent supposer que tu emploies des
tournures assez crades.
Je te rappelle tes positions : il y a deux mois, un binaire i386
était à peine plus petit qu'un amd64. Aujourd'hui, on est à 15% de
différence,
Quinze pourcents, dans ce domaine, c'est faible.
sans compter les
problèmes d'alignement qui grèvent les performances
Je te l'ai déjà dit à l'époque, je te le redis maintenant : les opcodes pas
alignés, c'est le mode de fonctionnement _normal_ d'un x86, et ça ne grève
absolument pas les performances.
Parce que je parle d'une machine avec une charge conséquente, ce qui
fait que sans l'overhead apportée par la gestion des _deux_
processeurs, on devrait avoir à peu de choses près les mêmes
performances. Je te rappelle qu'on était en train de discuter des
pertes de performances apportées par le SMP.
J'ai peur de te comprendre, là.
Tu dis que un SM71 75 MHz devrait être aussi rapide qu'un Ultra1 140 MHz,
mais que deux SM71 75 MHz sont bien plus lent ?
Oui, mais je ne vois pas pourquoi les mettre ici vu que de toute façon, tu ne veux voir que ce que tu veux.
Je vois ce que j'ai sur mon système, et tu m'excuseras, mais je pense que bash, la libc ou perl, ça me semble statistiquement plus significatif qu'un programme sorti d'on ne sait où.
D'autant plus qu'il me semble me rappeler quelques sorties de ta part concernant la portabilité qui laissent supposer que tu emploies des tournures assez crades.
Je te rappelle tes positions : il y a deux mois, un binaire i386 était à peine plus petit qu'un amd64. Aujourd'hui, on est à 15% de différence,
Quinze pourcents, dans ce domaine, c'est faible.
sans compter les problèmes d'alignement qui grèvent les performances
Je te l'ai déjà dit à l'époque, je te le redis maintenant : les opcodes pas alignés, c'est le mode de fonctionnement _normal_ d'un x86, et ça ne grève absolument pas les performances.
Parce que je parle d'une machine avec une charge conséquente, ce qui fait que sans l'overhead apportée par la gestion des _deux_ processeurs, on devrait avoir à peu de choses près les mêmes performances. Je te rappelle qu'on était en train de discuter des pertes de performances apportées par le SMP.
J'ai peur de te comprendre, là.
Tu dis que un SM71 75 MHz devrait être aussi rapide qu'un Ultra1 140 MHz, mais que deux SM71 75 MHz sont bien plus lent ?
C'est vraiment ça que tu prétends ?
remy
JKB , dans le message , a
Je n'ai jamais dit de compter en 64 bits, c'est _ton_ interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs 32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur que le reste soit rempli de zéro je m'en fous dans le cas d'un 64 bits
la différence doit être du côté du nombre de mnemonique
une instruction 64 = 2 instructions 32 en gros et qui vont bien sinon pipeau
et je fais l'impasse sur la largeur du bus cpu /mémoire
mais bon je ne suis plus vraiment à jour côté hard si il y a un spécialiste dans la salle je suis preneur
http://fr.wikipedia.org/wiki/AMD64#Architecture
meun ils ont juste introduits plusieurs jeux d'instruction sse sse2 sse3 du gâchis de techno ma ptite dame donc le plus est vraiment du cote du nb de registres et des entiers /flottant sur 64 bits donc pour les applis vraiment spécialisées dans le calcul le reste ...
<troll_on>
qui a besoin de valeurs plus grandes que 2^33-1 89934591 plus ou moins divisées par 2
remy
JKB , dans le message <slrnfgk3jm.3at.knatschke@fermat.systella.fr>, a
Je n'ai jamais dit de compter en 64 bits, c'est _ton_
interprétation. Je te laisse méditer.
Quelle que soit la manière dont tu fais le calcul, manipuler deux valeurs
32 bits plutôt qu'une seule 64 bits sera toujours moins efficace.
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
que le reste soit rempli de zéro je m'en fous dans le cas d'un 64 bits
la différence doit être du côté du nombre de mnemonique
une instruction 64 = 2 instructions 32 en gros et qui vont bien
sinon pipeau
et je fais l'impasse sur la largeur du bus cpu /mémoire
mais bon je ne suis plus vraiment à jour côté hard
si il y a un spécialiste dans la salle je suis preneur
http://fr.wikipedia.org/wiki/AMD64#Architecture
meun ils ont juste introduits plusieurs jeux d'instruction
sse sse2 sse3 du gâchis de techno ma ptite dame
donc le plus est vraiment du cote du nb de registres
et des entiers /flottant sur 64 bits donc pour les applis vraiment
spécialisées dans le calcul le reste ...
<troll_on>
qui a besoin de valeurs plus grandes que
2^33-1 89934591 plus ou moins divisées par 2
une instruction 64 = 2 instructions 32 en gros et qui vont bien sinon pipeau
et je fais l'impasse sur la largeur du bus cpu /mémoire
mais bon je ne suis plus vraiment à jour côté hard si il y a un spécialiste dans la salle je suis preneur
http://fr.wikipedia.org/wiki/AMD64#Architecture
meun ils ont juste introduits plusieurs jeux d'instruction sse sse2 sse3 du gâchis de techno ma ptite dame donc le plus est vraiment du cote du nb de registres et des entiers /flottant sur 64 bits donc pour les applis vraiment spécialisées dans le calcul le reste ...
<troll_on>
qui a besoin de valeurs plus grandes que 2^33-1 89934591 plus ou moins divisées par 2
