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 :
Tu coupes encore. Il manque encore une hypothèse.
Bien sûr.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Essentiellement parce que les questions d'architectures sont rarement pertinentes.
Tiens donc...
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité.
Il y a eu largement le temps pour faire évoluer ça, mais de toute évidence ça n'a pas paru nécessaire à qui de droit.
Tu prouves encore une fois que tu ne sais pas comment fonctionne électroniquement un processeur. Soit on garde des adressages non alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_ été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le résultat).
Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Non, justement. Du code plus compact, ça veut aussi dire du code qui tient mieux dans les caches. Avec les multiplicateurs énormes entre la mémoire et le processeur, ça joue énormément.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche d'avoir 4 Mo de cache synchrone par coeur de processeur.
Maintenant, si les processeurs i386 et dérivés sont si complexes et chauffent autant, c'est justement parce qu'il y a à l'intérieur des tas de petites trucs comme cela pour raisons de compatibilité (réalignement des mémoire, bourrage des pipe-lines pour ne pas les casser en raison d'OP codes de tailles différentes et j'en passe !). Regarde un peu les différences entre un ev6 et un amd64, entre un power5 et un amd64, entre un T1 et un amd64. Tu apprendras des choses. Mais pour toi, les gens d'IBM, de feue Digital et les concepteurs des sparcs sont des imbéciles.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales.
Comment définis-tu ces « puissance de calcul égales » ?
Comme tout le monde, un ordre de calcul sur le temps d'exécution. Fin de la disussion pour ma part.
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 <slrnfgkdlh.3at.knatschke@fermat.systella.fr>, a
écrit :
Tu coupes encore. Il manque encore une hypothèse.
Bien sûr.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Essentiellement parce que les questions d'architectures sont rarement
pertinentes.
Tiens donc...
Non, je dis simplement qu'on traîne un truc idiot pour raison de
compatibilité et qu'on paie cette compatibilité.
Il y a eu largement le temps pour faire évoluer ça, mais de toute évidence
ça n'a pas paru nécessaire à qui de droit.
Tu prouves encore une fois que tu ne sais pas comment fonctionne
électroniquement un processeur. Soit on garde des adressages non
alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_
été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le
résultat).
Et qu'en cela le
fait de dire que le code obtenu n'est pas deux fois plus gros est
une argutie.
Non, justement. Du code plus compact, ça veut aussi dire du code qui tient
mieux dans les caches. Avec les multiplicateurs énormes entre la mémoire et
le processeur, ça joue énormément.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très
souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche
d'avoir 4 Mo de cache synchrone par coeur de processeur.
Maintenant, si les processeurs i386 et dérivés sont si complexes et
chauffent autant, c'est justement parce qu'il y a à l'intérieur des
tas de petites trucs comme cela pour raisons de compatibilité
(réalignement des mémoire, bourrage des pipe-lines pour ne pas les
casser en raison d'OP codes de tailles différentes et j'en passe !).
Regarde un peu les différences entre un ev6 et un amd64, entre un
power5 et un amd64, entre un T1 et un amd64. Tu apprendras des
choses. Mais pour toi, les gens d'IBM, de feue Digital et les
concepteurs des sparcs sont des imbéciles.
Mon énoncé était très clair. Sur une machine de calcul faisant
tourner de quatre à six threads _simultanément_, une SS20 avec 2
SM71 est bien plus lente qu'une U1E/140, machines qui sont de
puissance de calcul par ailleurs égales.
Comment définis-tu ces « puissance de calcul égales » ?
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Fin de la disussion pour ma part.
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 :
Tu coupes encore. Il manque encore une hypothèse.
Bien sûr.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Essentiellement parce que les questions d'architectures sont rarement pertinentes.
Tiens donc...
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité.
Il y a eu largement le temps pour faire évoluer ça, mais de toute évidence ça n'a pas paru nécessaire à qui de droit.
Tu prouves encore une fois que tu ne sais pas comment fonctionne électroniquement un processeur. Soit on garde des adressages non alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_ été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le résultat).
Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Non, justement. Du code plus compact, ça veut aussi dire du code qui tient mieux dans les caches. Avec les multiplicateurs énormes entre la mémoire et le processeur, ça joue énormément.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche d'avoir 4 Mo de cache synchrone par coeur de processeur.
Maintenant, si les processeurs i386 et dérivés sont si complexes et chauffent autant, c'est justement parce qu'il y a à l'intérieur des tas de petites trucs comme cela pour raisons de compatibilité (réalignement des mémoire, bourrage des pipe-lines pour ne pas les casser en raison d'OP codes de tailles différentes et j'en passe !). Regarde un peu les différences entre un ev6 et un amd64, entre un power5 et un amd64, entre un T1 et un amd64. Tu apprendras des choses. Mais pour toi, les gens d'IBM, de feue Digital et les concepteurs des sparcs sont des imbéciles.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales.
Comment définis-tu ces « puissance de calcul égales » ?
Comme tout le monde, un ordre de calcul sur le temps d'exécution. Fin de la disussion pour ma part.
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
remy wrote:
et moi je te dis horloge temps réel Et toi tu ne sais pas de quoi tu parles.
peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
Penche toi vers l'avant, que je t'explique à ma façon.
tu peut revée vieil obsédé
remy
remy wrote:
et moi je te dis horloge temps réel
Et toi tu ne sais pas de quoi tu parles.
peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
Penche toi vers l'avant, que je t'explique à ma façon.
et moi je te dis horloge temps réel Et toi tu ne sais pas de quoi tu parles.
peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
Penche toi vers l'avant, que je t'explique à ma façon.
tu peut revée vieil obsédé
remy
Nicolas George
JKB , dans le message , a écrit :
Tu prouves encore une fois que tu ne sais pas comment fonctionne électroniquement un processeur.
J'en ai une assez bonne idée, au contraire.
Soit on garde des adressages non alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_ été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le résultat).
Il y a également la possibilité de tolérer les accès non-alignés, tout en étant plus rapide pour les accès alignés. C'est ce qui est fait pour les accès mémoire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche d'avoir 4 Mo de cache synchrone par coeur de processeur.
Et alors ?
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Mais tu viens de dire que l'une allait nettement plus vite que l'autre sur un certain calcul, justement. Il faudrait voir à ne pas trop te contredire.
JKB , dans le message <slrnfgkfke.3at.knatschke@fermat.systella.fr>, a
écrit :
Tu prouves encore une fois que tu ne sais pas comment fonctionne
électroniquement un processeur.
J'en ai une assez bonne idée, au contraire.
Soit on garde des adressages non
alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_
été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le
résultat).
Il y a également la possibilité de tolérer les accès non-alignés, tout en
étant plus rapide pour les accès alignés. C'est ce qui est fait pour les
accès mémoire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité
récemment, et ils n'ont manifestement pas jugé utilise de changer les
opcodes pour la peine.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très
souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche
d'avoir 4 Mo de cache synchrone par coeur de processeur.
Et alors ?
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Mais tu viens de dire que l'une allait nettement plus vite que l'autre sur
un certain calcul, justement. Il faudrait voir à ne pas trop te contredire.
Tu prouves encore une fois que tu ne sais pas comment fonctionne électroniquement un processeur.
J'en ai une assez bonne idée, au contraire.
Soit on garde des adressages non alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_ été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le résultat).
Il y a également la possibilité de tolérer les accès non-alignés, tout en étant plus rapide pour les accès alignés. C'est ce qui est fait pour les accès mémoire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche d'avoir 4 Mo de cache synchrone par coeur de processeur.
Et alors ?
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Mais tu viens de dire que l'une allait nettement plus vite que l'autre sur un certain calcul, justement. Il faudrait voir à ne pas trop te contredire.
Nicolas George
remy , dans le message <fedejt$url$, a écrit :
le monsieur te parle de calcul symbolique
Oui, moi aussi.
qui se résume à de la gestion de mémoire
Non.
tiens j'ai trouvé un lien pour toi votre majesté http://fr.wikipedia.org/wiki/RDTSC
Je connais, et tu ne sais toujours pas de quoi tu parles.
remy , dans le message <fedejt$url$1@s1.news.oleane.net>, a écrit :
le monsieur te parle de calcul symbolique
Oui, moi aussi.
qui se résume à de la gestion de mémoire
Non.
tiens j'ai trouvé un lien pour toi votre majesté
http://fr.wikipedia.org/wiki/RDTSC
Je connais, et tu ne sais toujours pas de quoi tu parles.
tiens j'ai trouvé un lien pour toi votre majesté http://fr.wikipedia.org/wiki/RDTSC
Je connais, et tu ne sais toujours pas de quoi tu parles.
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 :
Tu prouves encore une fois que tu ne sais pas comment fonctionne électroniquement un processeur.
J'en ai une assez bonne idée, au contraire.
Tu montres pourtant le contraire.
Soit on garde des adressages non alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_ été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le résultat).
Il y a également la possibilité de tolérer les accès non-alignés, tout en étant plus rapide pour les accès alignés. C'est ce qui est fait pour les accès mémoire.
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est différent. Si tu ne vois pas la différence, retourne à tes bouquins ! L'adressage de la prochaine instruction et l'adressage de données est différent et n'obéit pas aux mêmes règles !
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine.
C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes pour raisons de compatibilité quitte à bricoler autour de ces OP codes.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche d'avoir 4 Mo de cache synchrone par coeur de processeur.
Et alors ?
Et alors ? ton argument de code qui ne tient pas en cache ne tient pas la route.
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Mais tu viens de dire que l'une allait nettement plus vite que l'autre sur un certain calcul, justement. Il faudrait voir à ne pas trop te contredire.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne pas tout déformer.
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 <slrnfgkfke.3at.knatschke@fermat.systella.fr>, a
écrit :
Tu prouves encore une fois que tu ne sais pas comment fonctionne
électroniquement un processeur.
J'en ai une assez bonne idée, au contraire.
Tu montres pourtant le contraire.
Soit on garde des adressages non
alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_
été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le
résultat).
Il y a également la possibilité de tolérer les accès non-alignés, tout en
étant plus rapide pour les accès alignés. C'est ce qui est fait pour les
accès mémoire.
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est
différent. Si tu ne vois pas la différence, retourne à tes bouquins
! L'adressage de la prochaine instruction et l'adressage de données
est différent et n'obéit pas aux mêmes règles !
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité
récemment, et ils n'ont manifestement pas jugé utilise de changer les
opcodes pour la peine.
C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP
codes.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très
souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche
d'avoir 4 Mo de cache synchrone par coeur de processeur.
Et alors ?
Et alors ? ton argument de code qui ne tient pas en cache
ne tient pas la route.
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Mais tu viens de dire que l'une allait nettement plus vite que l'autre sur
un certain calcul, justement. Il faudrait voir à ne pas trop te contredire.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour
des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne
pas tout déformer.
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 :
Tu prouves encore une fois que tu ne sais pas comment fonctionne électroniquement un processeur.
J'en ai une assez bonne idée, au contraire.
Tu montres pourtant le contraire.
Soit on garde des adressages non alignés, soit casse la compatibilité ascendante, ce uqi n'a _jamais_ été le choix chez Intel (au moins jusqu'à l'IA64 et on a vu le résultat).
Il y a également la possibilité de tolérer les accès non-alignés, tout en étant plus rapide pour les accès alignés. C'est ce qui est fait pour les accès mémoire.
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est différent. Si tu ne vois pas la différence, retourne à tes bouquins ! L'adressage de la prochaine instruction et l'adressage de données est différent et n'obéit pas aux mêmes règles !
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine.
C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes pour raisons de compatibilité quitte à bricoler autour de ces OP codes.
Alors là, je m'incline. Dis, sur des architectures 64bits, j'ai très souvent entre 4 et 8 Mo de cache. Aujourd'hui, rien ne nous empêche d'avoir 4 Mo de cache synchrone par coeur de processeur.
Et alors ?
Et alors ? ton argument de code qui ne tient pas en cache ne tient pas la route.
Comme tout le monde, un ordre de calcul sur le temps d'exécution.
Mais tu viens de dire que l'une allait nettement plus vite que l'autre sur un certain calcul, justement. Il faudrait voir à ne pas trop te contredire.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne pas tout déformer.
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
le monsieur te parle de calcul symbolique
Oui, moi aussi.
qui se résume à de la gestion de mémoire
Non.
tiens j'ai trouvé un lien pour toi votre majesté http://fr.wikipedia.org/wiki/RDTSC
Je connais, et tu ne sais toujours pas de quoi tu parles.
ah bien merde alors et au faite l'on parle de quoi ? d'alu ,de registre ,de timer ,de pipe-line, de quoi
le monsieur te parle de calcul symbolique
Oui, moi aussi.
qui se résume à de la gestion de mémoire
Non.
tiens j'ai trouvé un lien pour toi votre majesté
http://fr.wikipedia.org/wiki/RDTSC
Je connais, et tu ne sais toujours pas de quoi tu parles.
ah bien merde alors et au faite l'on parle de quoi ?
d'alu ,de registre ,de timer ,de pipe-line, de quoi
ah bien merde alors et au faite l'on parle de quoi ? d'alu ,de registre ,de timer ,de pipe-line, de quoi
On parle de vrais programmes qui font des choses. Si un jour tu sais manier poll() et gettimeofday(), peut-être que tu comprendras.
Nicolas George
JKB , dans le message , a écrit :
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est différent. Si tu ne vois pas la différence, retourne à tes bouquins ! L'adressage de la prochaine instruction et l'adressage de données est différent et n'obéit pas aux mêmes règles !
Oui. Et même, tu point de vue de l'alignement, c'est infiniment plus facile de gérer des opcodes non alignés que pour les accès mémoire aléatoire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine. C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP codes.
Youhoud ? Il n'y a pas compatibilité, ici.
Et alors ? ton argument de code qui ne tient pas en cache ne tient pas la route.
Il n'y a pas que le code, dans le cache.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne pas tout déformer.
Ce que j'essaie de te faire comprendre, c'est que ta notion de « même puissance » ne veut strictement rien dire. Deux machines qui vont à la même vitesse pour tous les calculs ont la même puissance, mais pour certains une machine va moins vite, ce n'est plus le cas.
JKB , dans le message <slrnfgkh0b.3at.knatschke@fermat.systella.fr>, a
écrit :
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est
différent. Si tu ne vois pas la différence, retourne à tes bouquins
! L'adressage de la prochaine instruction et l'adressage de données
est différent et n'obéit pas aux mêmes règles !
Oui. Et même, tu point de vue de l'alignement, c'est infiniment plus facile
de gérer des opcodes non alignés que pour les accès mémoire aléatoire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité
récemment, et ils n'ont manifestement pas jugé utilise de changer les
opcodes pour la peine.
C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP
codes.
Youhoud ? Il n'y a pas compatibilité, ici.
Et alors ? ton argument de code qui ne tient pas en cache
ne tient pas la route.
Il n'y a pas que le code, dans le cache.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour
des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne
pas tout déformer.
Ce que j'essaie de te faire comprendre, c'est que ta notion de « même
puissance » ne veut strictement rien dire. Deux machines qui vont à la même
vitesse pour tous les calculs ont la même puissance, mais pour certains une
machine va moins vite, ce n'est plus le cas.
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est différent. Si tu ne vois pas la différence, retourne à tes bouquins ! L'adressage de la prochaine instruction et l'adressage de données est différent et n'obéit pas aux mêmes règles !
Oui. Et même, tu point de vue de l'alignement, c'est infiniment plus facile de gérer des opcodes non alignés que pour les accès mémoire aléatoire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine. C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP codes.
Youhoud ? Il n'y a pas compatibilité, ici.
Et alors ? ton argument de code qui ne tient pas en cache ne tient pas la route.
Il n'y a pas que le code, dans le cache.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne pas tout déformer.
Ce que j'essaie de te faire comprendre, c'est que ta notion de « même puissance » ne veut strictement rien dire. Deux machines qui vont à la même vitesse pour tous les calculs ont la même puissance, mais pour certains une machine va moins vite, ce n'est plus le cas.
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 :
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est différent. Si tu ne vois pas la différence, retourne à tes bouquins ! L'adressage de la prochaine instruction et l'adressage de données est différent et n'obéit pas aux mêmes règles !
Oui. Et même, tu point de vue de l'alignement, c'est infiniment plus facile de gérer des opcodes non alignés que pour les accès mémoire aléatoire.
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)... Tes connaissances de machines séquentielles me font sourire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine. C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP codes.
Youhoud ? Il n'y a pas compatibilité, ici.
Ah bon ? De quoi parles-tu dans ce cas ?
Et alors ? ton argument de code qui ne tient pas en cache ne tient pas la route.
Il n'y a pas que le code, dans le cache.
Au niveau processeur, si. Les caches sont _séparés_.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne pas tout déformer.
Ce que j'essaie de te faire comprendre, c'est que ta notion de « même puissance » ne veut strictement rien dire. Deux machines qui vont à la même vitesse pour tous les calculs ont la même puissance, mais pour certains une machine va moins vite, ce n'est plus le cas.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas moi.
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 <slrnfgkh0b.3at.knatschke@fermat.systella.fr>, a
écrit :
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est
différent. Si tu ne vois pas la différence, retourne à tes bouquins
! L'adressage de la prochaine instruction et l'adressage de données
est différent et n'obéit pas aux mêmes règles !
Oui. Et même, tu point de vue de l'alignement, c'est infiniment plus facile
de gérer des opcodes non alignés que pour les accès mémoire aléatoire.
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)...
Tes connaissances de machines séquentielles me font sourire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité
récemment, et ils n'ont manifestement pas jugé utilise de changer les
opcodes pour la peine.
C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP
codes.
Youhoud ? Il n'y a pas compatibilité, ici.
Ah bon ? De quoi parles-tu dans ce cas ?
Et alors ? ton argument de code qui ne tient pas en cache
ne tient pas la route.
Il n'y a pas que le code, dans le cache.
Au niveau processeur, si. Les caches sont _séparés_.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour
des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne
pas tout déformer.
Ce que j'essaie de te faire comprendre, c'est que ta notion de « même
puissance » ne veut strictement rien dire. Deux machines qui vont à la même
vitesse pour tous les calculs ont la même puissance, mais pour certains une
machine va moins vite, ce n'est plus le cas.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas
moi.
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 :
Mais on s'en fout. On parle d'accès mémoire pour des OP codes, c'est différent. Si tu ne vois pas la différence, retourne à tes bouquins ! L'adressage de la prochaine instruction et l'adressage de données est différent et n'obéit pas aux mêmes règles !
Oui. Et même, tu point de vue de l'alignement, c'est infiniment plus facile de gérer des opcodes non alignés que pour les accès mémoire aléatoire.
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)... Tes connaissances de machines séquentielles me font sourire.
Accessoirement, il y a vaguement eu une grosse rupture de compatibilité récemment, et ils n'ont manifestement pas jugé utilise de changer les opcodes pour la peine. C'est bien ce que j'essaie de t'expliquer. On garde ces OP codes
pour raisons de compatibilité quitte à bricoler autour de ces OP codes.
Youhoud ? Il n'y a pas compatibilité, ici.
Ah bon ? De quoi parles-tu dans ce cas ?
Et alors ? ton argument de code qui ne tient pas en cache ne tient pas la route.
Il n'y a pas que le code, dans le cache.
Au niveau processeur, si. Les caches sont _séparés_.
Je n'ai jamais marqué pour _un certain calcul_. J'ai indiqué pour des calculs provoquant une charge entre 4 et 6. Faudrait voir à ne pas tout déformer.
Ce que j'essaie de te faire comprendre, c'est que ta notion de « même puissance » ne veut strictement rien dire. Deux machines qui vont à la même vitesse pour tous les calculs ont la même puissance, mais pour certains une machine va moins vite, ce n'est plus le cas.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas moi.
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
ah bien merde alors et au faite l'on parle de quoi ? d'alu ,de registre ,de timer ,de pipe-line, de quoi
On parle de vrais programmes qui font des choses. Si un jour tu sais manier poll() et gettimeofday(), peut-être que tu comprendras.
suis désolé mais les appels system je ne les connais pas tous se qui serait intéressant c'est de voir se qu'il y a derrière
juste histoire de voir le rapport avec les 64 bits et entre nous il y a peu de chance que cela soit un registre "classique" mais bon s'est toi qui a raison hein
remy
ah bien merde alors et au faite l'on parle de quoi ?
d'alu ,de registre ,de timer ,de pipe-line, de quoi
On parle de vrais programmes qui font des choses. Si un jour tu sais manier
poll() et gettimeofday(), peut-être que tu comprendras.
suis désolé mais les appels system je ne les connais pas tous
se qui serait intéressant c'est de voir se qu'il y a derrière
juste histoire de voir le rapport avec les 64 bits
et entre nous il y a peu de chance que cela soit un
registre "classique" mais bon s'est toi qui a raison hein
ah bien merde alors et au faite l'on parle de quoi ? d'alu ,de registre ,de timer ,de pipe-line, de quoi
On parle de vrais programmes qui font des choses. Si un jour tu sais manier poll() et gettimeofday(), peut-être que tu comprendras.
suis désolé mais les appels system je ne les connais pas tous se qui serait intéressant c'est de voir se qu'il y a derrière
juste histoire de voir le rapport avec les 64 bits et entre nous il y a peu de chance que cela soit un registre "classique" mais bon s'est toi qui a raison hein
