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.
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).
Est ce que Maple comme Matlab ne ferait pas ses calculs en 64 Bits même sur les architectures 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).
Est ce que Maple comme Matlab ne ferait pas ses calculs en 64 Bits
même sur les architectures 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).
Est ce que Maple comme Matlab ne ferait pas ses calculs en 64 Bits même sur les architectures 32 bits
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 :
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.
Tu commenceras à regarder mes codes sources avant de juger. Mon critère principal, c'est _justement_ la portabilité ! Et la portabilité, chez moi, ce n'est pas simplement la portabilité linux/i386 vers linux/amd64, ça englobe des architectures et OS beaucoup plus exotiques.
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.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
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.
Ce qui prouve que tu ne comprends strictement rien à la façon dont fonctionne un processeur (électroniquement parlant, je ne mets pas en doute tes capavcités de programmeur. Encore que j'attends de voir certains de tes codes, les miens étant disponibles sur le net). Ce n'est pas parce que c'est _possible_, parce que c'est _réalisable_, que c'est efficace. A ton avis, pourquoi crois-tu que certains processeurs demandent des alignements sévères ? Parce que les concepteurs sont des imbéciles, certainement...
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 ?
Non, relis _attentivement_. Je ne vais pas me répéter indéfiniement, avec toi, de toute façon, cela ne sert à rien.
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 <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.
Tu commenceras à regarder mes codes sources avant de juger. Mon
critère principal, c'est _justement_ la portabilité ! Et la
portabilité, chez moi, ce n'est pas simplement la portabilité
linux/i386 vers linux/amd64, ça englobe des architectures et OS
beaucoup plus exotiques.
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.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
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.
Ce qui prouve que tu ne comprends strictement rien à la façon dont
fonctionne un processeur (électroniquement parlant, je ne mets pas
en doute tes capavcités de programmeur. Encore que j'attends de voir
certains de tes codes, les miens étant disponibles sur le net).
Ce n'est pas parce que c'est _possible_, parce que c'est _réalisable_,
que c'est efficace. A ton avis, pourquoi crois-tu que certains
processeurs demandent des alignements sévères ? Parce que les
concepteurs sont des imbéciles, certainement...
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 ?
Non, relis _attentivement_. Je ne vais pas me répéter indéfiniement,
avec toi, de toute façon, cela ne sert à rien.
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 :
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.
Tu commenceras à regarder mes codes sources avant de juger. Mon critère principal, c'est _justement_ la portabilité ! Et la portabilité, chez moi, ce n'est pas simplement la portabilité linux/i386 vers linux/amd64, ça englobe des architectures et OS beaucoup plus exotiques.
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.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
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.
Ce qui prouve que tu ne comprends strictement rien à la façon dont fonctionne un processeur (électroniquement parlant, je ne mets pas en doute tes capavcités de programmeur. Encore que j'attends de voir certains de tes codes, les miens étant disponibles sur le net). Ce n'est pas parce que c'est _possible_, parce que c'est _réalisable_, que c'est efficace. A ton avis, pourquoi crois-tu que certains processeurs demandent des alignements sévères ? Parce que les concepteurs sont des imbéciles, certainement...
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 ?
Non, relis _attentivement_. Je ne vais pas me répéter indéfiniement, avec toi, de toute façon, cela ne sert à rien.
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 :
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est loin d'être négligeable.
JKB , dans le message <slrnfgk7g2.3at.knatschke@fermat.systella.fr>, a
écrit :
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du
natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est
loin d'être négligeable.
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est loin d'être négligeable.
Nicolas George
remy , dans le message <fed6ok$re8$, a écrit :
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
Pas tant que ça. Dans une journée, il y a plus de 2^32 microsecondes, par exemple.
remy , dans le message <fed6ok$re8$1@s1.news.oleane.net>, a écrit :
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
Pas tant que ça. Dans une journée, il y a plus de 2^32 microsecondes, par
exemple.
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
Pas tant que ça. Dans une journée, il y a plus de 2^32 microsecondes, par exemple.
Mihamina Rakotomandimby
remy wrote:
qui a besoin de valeurs plus grandes que 2^33-1 89934591 plus ou moins divisées par 2
Un logiciel qui voudra correctement afficher en arborescence et de manière recursive (dans le code) les troll de ce groupe. Une autre sorte de calcul, quoi.
remy wrote:
qui a besoin de valeurs plus grandes que
2^33-1 89934591 plus ou moins divisées par 2
Un logiciel qui voudra correctement afficher en arborescence et de
manière recursive (dans le code) les troll de ce groupe.
Une autre sorte de calcul, quoi.
qui a besoin de valeurs plus grandes que 2^33-1 89934591 plus ou moins divisées par 2
Un logiciel qui voudra correctement afficher en arborescence et de manière recursive (dans le code) les troll de ce groupe. Une autre sorte de calcul, quoi.
remy
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
Pas tant que ça. Dans une journée, il y a plus de 2^32 microsecondes, par exemple.
les pc on un horloge temps réel na
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
Pas tant que ça. Dans une journée, il y a plus de 2^32 microsecondes, par
exemple.
c'est assez vaseux comme raisonnement 2^32 c'est assez énorme comme valeur
Pas tant que ça. Dans une journée, il y a plus de 2^32 microsecondes, par exemple.
les pc on un horloge temps réel na
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 :
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est loin d'être négligeable.
Tu le fais exprès ! Ce n'est pas du tout ce que j'ai dit ! Je fait une fois sur 2**32 une addition 64 bits émulée en soft ! Le reste est une simple addition 32 bits.
Exemple en assembleur 6809 pour fixer les idées :
ET1: LDA #0 LDB #0 ET2: INCA BNZ ET2 INCB BRA ET2
Tu me colles une temporisation (ou mieux un gestionnaire de signal), tu me code ça en 32 bits sur l'architecture de ton choix, et je bouffe un balai (je te laisse choisir le modèle) s'il y a une différence de 30%, d'autant que la grande majorité du code sera dans la gestion des signaux pour avoir une horloge précise. Le reste, c'est de la sodomie de coléoptère. Mais il est vrai que tu es un spécialiste du genre.
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 <slrnfgk7g2.3at.knatschke@fermat.systella.fr>, a
écrit :
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du
natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est
loin d'être négligeable.
Tu le fais exprès ! Ce n'est pas du tout ce que j'ai dit ! Je fait
une fois sur 2**32 une addition 64 bits émulée en soft ! Le reste
est une simple addition 32 bits.
Exemple en assembleur 6809 pour fixer les idées :
ET1: LDA #0
LDB #0
ET2: INCA
BNZ ET2
INCB
BRA ET2
Tu me colles une temporisation (ou mieux un gestionnaire de signal),
tu me code ça en 32 bits sur l'architecture de ton choix, et je
bouffe un balai (je te laisse choisir le modèle) s'il y a une
différence de 30%, d'autant que la grande majorité du code sera dans
la gestion des signaux pour avoir une horloge précise. Le reste,
c'est de la sodomie de coléoptère. Mais il est vrai que tu es un
spécialiste du genre.
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 :
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est loin d'être négligeable.
Tu le fais exprès ! Ce n'est pas du tout ce que j'ai dit ! Je fait une fois sur 2**32 une addition 64 bits émulée en soft ! Le reste est une simple addition 32 bits.
Exemple en assembleur 6809 pour fixer les idées :
ET1: LDA #0 LDB #0 ET2: INCA BNZ ET2 INCB BRA ET2
Tu me colles une temporisation (ou mieux un gestionnaire de signal), tu me code ça en 32 bits sur l'architecture de ton choix, et je bouffe un balai (je te laisse choisir le modèle) s'il y a une différence de 30%, d'autant que la grande majorité du code sera dans la gestion des signaux pour avoir une horloge précise. Le reste, c'est de la sodomie de coléoptère. Mais il est vrai que tu es un spécialiste du genre.
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:
qui a besoin de valeurs plus grandes que 2^33-1 89934591 plus ou moins divisées par 2
Un logiciel qui voudra correctement afficher en arborescence et de manière recursive (dans le code) les troll de ce groupe. Une autre sorte de calcul, quoi.
donc une fois a la fin du calcul
remy wrote:
qui a besoin de valeurs plus grandes que
2^33-1 89934591 plus ou moins divisées par 2
Un logiciel qui voudra correctement afficher en arborescence et de
manière recursive (dans le code) les troll de ce groupe.
Une autre sorte de calcul, quoi.
qui a besoin de valeurs plus grandes que 2^33-1 89934591 plus ou moins divisées par 2
Un logiciel qui voudra correctement afficher en arborescence et de manière recursive (dans le code) les troll de ce groupe. Une autre sorte de calcul, quoi.
donc une fois a la fin du calcul
Nicolas George
JKB , dans le message , a écrit :
Tu commenceras à regarder mes codes sources avant de juger.
J'ai d'autres choses à faire. Tu avais sorti quelques énormités à l'époque.
Et la portabilité, chez moi, ce n'est pas simplement la portabilité linux/i386 vers linux/amd64, ça englobe des architectures et OS beaucoup plus exotiques.
Tu sous entends que ce n'est pas mon cas. C'est faux.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
Connue par qui ? Plus connue que perl ?
Ce qui prouve que tu ne comprends strictement rien à la façon dont fonctionne un processeur (électroniquement parlant, je ne mets pas en doute tes capavcités de programmeur. Encore que j'attends de voir certains de tes codes, les miens étant disponibles sur le net). Ce n'est pas parce que c'est _possible_, parce que c'est _réalisable_, que c'est efficace.
Tu brasses du vent, là. Montre-nous un code assembleur x86 où l'alignement des opcodes fait gagner de la vitesse.
Mais je soupçonne que tu vas avoir du mal, parce que si c'était le cas, icc le ferait.
A ton avis, pourquoi crois-tu que certains processeurs demandent des alignements sévères ?
Parce qu'ils ont fait des choix de conception différents. Pas moins bons, mais pas forcément meilleurs non plus.
Non, relis _attentivement_. Je ne vais pas me répéter indéfiniement, avec toi, de toute façon, cela ne sert à rien.
Alors je ré-essaie. Tu as dit que 2×SM71-75 vont nettement moins vite que 1×Ultra1-140. C'est bien ça ?
JKB , dans le message <slrnfgk9oe.3at.knatschke@fermat.systella.fr>, a
écrit :
Tu commenceras à regarder mes codes sources avant de juger.
J'ai d'autres choses à faire. Tu avais sorti quelques énormités à l'époque.
Et la
portabilité, chez moi, ce n'est pas simplement la portabilité
linux/i386 vers linux/amd64, ça englobe des architectures et OS
beaucoup plus exotiques.
Tu sous entends que ce n'est pas mon cas. C'est faux.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
Connue par qui ? Plus connue que perl ?
Ce qui prouve que tu ne comprends strictement rien à la façon dont
fonctionne un processeur (électroniquement parlant, je ne mets pas
en doute tes capavcités de programmeur. Encore que j'attends de voir
certains de tes codes, les miens étant disponibles sur le net).
Ce n'est pas parce que c'est _possible_, parce que c'est _réalisable_,
que c'est efficace.
Tu brasses du vent, là. Montre-nous un code assembleur x86 où l'alignement
des opcodes fait gagner de la vitesse.
Mais je soupçonne que tu vas avoir du mal, parce que si c'était le cas, icc
le ferait.
A ton avis, pourquoi crois-tu que certains
processeurs demandent des alignements sévères ?
Parce qu'ils ont fait des choix de conception différents. Pas moins bons,
mais pas forcément meilleurs non plus.
Non, relis _attentivement_. Je ne vais pas me répéter indéfiniement,
avec toi, de toute façon, cela ne sert à rien.
Alors je ré-essaie. Tu as dit que 2×SM71-75 vont nettement moins vite que
1×Ultra1-140. C'est bien ça ?
Tu commenceras à regarder mes codes sources avant de juger.
J'ai d'autres choses à faire. Tu avais sorti quelques énormités à l'époque.
Et la portabilité, chez moi, ce n'est pas simplement la portabilité linux/i386 vers linux/amd64, ça englobe des architectures et OS beaucoup plus exotiques.
Tu sous entends que ce n'est pas mon cas. C'est faux.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
Connue par qui ? Plus connue que perl ?
Ce qui prouve que tu ne comprends strictement rien à la façon dont fonctionne un processeur (électroniquement parlant, je ne mets pas en doute tes capavcités de programmeur. Encore que j'attends de voir certains de tes codes, les miens étant disponibles sur le net). Ce n'est pas parce que c'est _possible_, parce que c'est _réalisable_, que c'est efficace.
Tu brasses du vent, là. Montre-nous un code assembleur x86 où l'alignement des opcodes fait gagner de la vitesse.
Mais je soupçonne que tu vas avoir du mal, parce que si c'était le cas, icc le ferait.
A ton avis, pourquoi crois-tu que certains processeurs demandent des alignements sévères ?
Parce qu'ils ont fait des choix de conception différents. Pas moins bons, mais pas forcément meilleurs non plus.
Non, relis _attentivement_. Je ne vais pas me répéter indéfiniement, avec toi, de toute façon, cela ne sert à rien.
Alors je ré-essaie. Tu as dit que 2×SM71-75 vont nettement moins vite que 1×Ultra1-140. C'est bien ça ?
remy
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
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. Je viens de faire l'essai : pour de simples additions 64 bits, avoir du
natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est loin d'être négligeable.
Tu le fais exprès ! Ce n'est pas du tout ce que j'ai dit ! Je fait une fois sur 2**32 une addition 64 bits émulée en soft ! Le reste est une simple addition 32 bits.
Exemple en assembleur 6809 pour fixer les idées :
ET1: LDA #0 LDB #0 ET2: INCA BNZ ET2 INCB BRA ET2
ba meme pas un vrai 6800 petit joueur 6809 associer a 6850 ou 6821
Tu me colles une temporisation (ou mieux un gestionnaire de signal), tu me code ça en 32 bits sur l'architecture de ton choix, et je bouffe un balai (je te laisse choisir le modèle) s'il y a une différence de 30%, d'autant que la grande majorité du code sera dans la gestion des signaux pour avoir une horloge précise. Le reste, c'est de la sodomie de coléoptère. Mais il est vrai que tu es un spécialiste du genre.
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 <slrnfgk7g2.3at.knatschke@fermat.systella.fr>, a
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.
Je viens de faire l'essai : pour de simples additions 64 bits, avoir du
natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est
loin d'être négligeable.
Tu le fais exprès ! Ce n'est pas du tout ce que j'ai dit ! Je fait
une fois sur 2**32 une addition 64 bits émulée en soft ! Le reste
est une simple addition 32 bits.
Exemple en assembleur 6809 pour fixer les idées :
ET1: LDA #0
LDB #0
ET2: INCA
BNZ ET2
INCB
BRA ET2
ba meme pas un vrai 6800 petit joueur
6809 associer a 6850 ou 6821
Tu me colles une temporisation (ou mieux un gestionnaire de signal),
tu me code ça en 32 bits sur l'architecture de ton choix, et je
bouffe un balai (je te laisse choisir le modèle) s'il y a une
différence de 30%, d'autant que la grande majorité du code sera dans
la gestion des signaux pour avoir une horloge précise. Le reste,
c'est de la sodomie de coléoptère. Mais il est vrai que tu es un
spécialiste du genre.
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
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. Je viens de faire l'essai : pour de simples additions 64 bits, avoir du
natif fait gagner un tiers de vitesse. Si ces calculs sont fréquents, c'est loin d'être négligeable.
Tu le fais exprès ! Ce n'est pas du tout ce que j'ai dit ! Je fait une fois sur 2**32 une addition 64 bits émulée en soft ! Le reste est une simple addition 32 bits.
Exemple en assembleur 6809 pour fixer les idées :
ET1: LDA #0 LDB #0 ET2: INCA BNZ ET2 INCB BRA ET2
ba meme pas un vrai 6800 petit joueur 6809 associer a 6850 ou 6821
Tu me colles une temporisation (ou mieux un gestionnaire de signal), tu me code ça en 32 bits sur l'architecture de ton choix, et je bouffe un balai (je te laisse choisir le modèle) s'il y a une différence de 30%, d'autant que la grande majorité du code sera dans la gestion des signaux pour avoir une horloge précise. Le reste, c'est de la sodomie de coléoptère. Mais il est vrai que tu es un spécialiste du genre.
