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.
Tu as déjà fait des programmes qui ont à réagir à certains événements à des instants donnés ? On peut les voir. À défaut, tu saurais en faire ?
Si ce n'est pas le cas, je t'invite à ne pas t'exprimer sur des sujets techniques que tu ne comprends pas.
remy
les pc on un horloge temps réel na
Tu as déjà fait des programmes qui ont à réagir à certains événements à des instants donnés ? On peut les voir. À défaut, tu saurais en faire ?
Si ce n'est pas le cas, je t'invite à ne pas t'exprimer sur des sujets techniques que tu ne comprends pas. je t'adore repete apres moi micro timer "le registre "
les pc on un horloge temps réel na
Tu as déjà fait des programmes qui ont à réagir à certains événements à des
instants donnés ? On peut les voir. À défaut, tu saurais en faire ?
Si ce n'est pas le cas, je t'invite à ne pas t'exprimer sur des sujets
techniques que tu ne comprends pas.
je t'adore repete apres moi micro timer "le registre "
Tu as déjà fait des programmes qui ont à réagir à certains événements à des instants donnés ? On peut les voir. À défaut, tu saurais en faire ?
Si ce n'est pas le cas, je t'invite à ne pas t'exprimer sur des sujets techniques que tu ne comprends pas. je t'adore repete apres moi micro timer "le registre "
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 :
ET1: LDA #0 LDB #0 ET2: INCA BNZ ET2 INCB BRA ET2
Où as-tu vu que j'avais parlé d'une simple incrémentation ?
Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
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 <slrnfgka39.3at.knatschke@fermat.systella.fr>, a
écrit :
ET1: LDA #0
LDB #0
ET2: INCA
BNZ ET2
INCB
BRA ET2
Où as-tu vu que j'avais parlé d'une simple incrémentation ?
Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
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 :
ET1: LDA #0 LDB #0 ET2: INCA BNZ ET2 INCB BRA ET2
Où as-tu vu que j'avais parlé d'une simple incrémentation ?
Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
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 :
Où as-tu vu que j'avais parlé d'une simple incrémentation ? Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut te faire soigner, ou lire le man gettimeofday.
JKB , dans le message <slrnfgkb6l.3at.knatschke@fermat.systella.fr>, a
écrit :
Où as-tu vu que j'avais parlé d'une simple incrémentation ?
Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut
te faire soigner, ou lire le man gettimeofday.
Où as-tu vu que j'avais parlé d'une simple incrémentation ? Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut te faire soigner, ou lire le man gettimeofday.
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 commenceras à regarder mes codes sources avant de juger.
J'ai d'autres choses à faire. Tu avais sorti quelques énormités à l'époque.
Sors les moi que je rigoles.
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.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant de l'architecture i386/amd64.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
Connue par qui ? Plus connue que perl ?
Que vient foutre perl ici ?
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.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_ de la vitesse, simplement que si le processeur le permettait, cela éviterait d'en _perdre_. Ce n'est pas exactement la meme chose.
Mais je soupçonne que tu vas avoir du mal, parce que si c'était le cas, icc le ferait.
Je me contrefiche de ce que fait icc. icc fait ce qu'il a à faire avec ce qu'on lui donne. Ce n'est pas le problème. Le problème est que la taille des codes double grossièrement lorsqu'on double la taille des opérandes. Le fait de ne pas aligner la mémoire limite la casse et on obtient 30% de différence de taille selon mon expérience, 15% selon la tienne. Ce point se paie. Si ce n'est pas l'architecture qui impose l'alignement, l'alignement est de toute façon faite dans le processeur en interne, même si tu ne le vois pas, et cet alignement a un coût. Tu peux le prendre comme tu veux.
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.
Mais encore... Le non alignement est une bêtise monumentale héritée des 8088 (il n'y a aucune autre raison). Cela _pouvait_ se comprendre à l'époque. Aujourd'hui, on paie ce truc au prix fort, et ça va jusqu'à une consommation accrue du bidule puisqu'il y a toute une série de registres pour aligner les codes op en interne ! Sans compter le pipe-line qu'il a fallu chiader à l'extrème et complexifier pour qu'il ne se casse pas la gueule sur des codes op de différentes longueurs.
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 ?
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier du fait.
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 <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.
Sors les moi que je rigoles.
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.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant
de l'architecture i386/amd64.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
Connue par qui ? Plus connue que perl ?
Que vient foutre perl ici ?
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.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_
de la vitesse, simplement que si le processeur le permettait, cela
éviterait d'en _perdre_. Ce n'est pas exactement la meme chose.
Mais je soupçonne que tu vas avoir du mal, parce que si c'était le cas, icc
le ferait.
Je me contrefiche de ce que fait icc. icc fait ce qu'il a à faire
avec ce qu'on lui donne. Ce n'est pas le problème. Le problème est
que la taille des codes double grossièrement lorsqu'on double la
taille des opérandes. Le fait de ne pas aligner la mémoire limite la
casse et on obtient 30% de différence de taille selon mon
expérience, 15% selon la tienne. Ce point se paie. Si ce n'est pas
l'architecture qui impose l'alignement, l'alignement est de toute
façon faite dans le processeur en interne, même si tu ne le vois
pas, et cet alignement a un coût. Tu peux le prendre comme tu veux.
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.
Mais encore... Le non alignement est une bêtise monumentale héritée
des 8088 (il n'y a aucune autre raison). Cela _pouvait_ se
comprendre à l'époque. Aujourd'hui, on paie ce truc au prix fort, et
ça va jusqu'à une consommation accrue du bidule puisqu'il y a toute
une série de registres pour aligner les codes op en interne !
Sans compter le pipe-line qu'il a fallu chiader à l'extrème et
complexifier pour qu'il ne se casse pas la gueule sur des codes op
de différentes longueurs.
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 ?
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier
du fait.
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 commenceras à regarder mes codes sources avant de juger.
J'ai d'autres choses à faire. Tu avais sorti quelques énormités à l'époque.
Sors les moi que je rigoles.
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.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant de l'architecture i386/amd64.
Ouaips. Et moi, je mesure 30% sur une sortie de gcc _connue_.
Connue par qui ? Plus connue que perl ?
Que vient foutre perl ici ?
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.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_ de la vitesse, simplement que si le processeur le permettait, cela éviterait d'en _perdre_. Ce n'est pas exactement la meme chose.
Mais je soupçonne que tu vas avoir du mal, parce que si c'était le cas, icc le ferait.
Je me contrefiche de ce que fait icc. icc fait ce qu'il a à faire avec ce qu'on lui donne. Ce n'est pas le problème. Le problème est que la taille des codes double grossièrement lorsqu'on double la taille des opérandes. Le fait de ne pas aligner la mémoire limite la casse et on obtient 30% de différence de taille selon mon expérience, 15% selon la tienne. Ce point se paie. Si ce n'est pas l'architecture qui impose l'alignement, l'alignement est de toute façon faite dans le processeur en interne, même si tu ne le vois pas, et cet alignement a un coût. Tu peux le prendre comme tu veux.
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.
Mais encore... Le non alignement est une bêtise monumentale héritée des 8088 (il n'y a aucune autre raison). Cela _pouvait_ se comprendre à l'époque. Aujourd'hui, on paie ce truc au prix fort, et ça va jusqu'à une consommation accrue du bidule puisqu'il y a toute une série de registres pour aligner les codes op en interne ! Sans compter le pipe-line qu'il a fallu chiader à l'extrème et complexifier pour qu'il ne se casse pas la gueule sur des codes op de différentes longueurs.
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 ?
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier du fait.
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 :
Où as-tu vu que j'avais parlé d'une simple incrémentation ? Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut te faire soigner, ou lire le man gettimeofday.
Non, tu as parlé d'une horloge comptant les us, ni plus ni moins.
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 <slrnfgkb6l.3at.knatschke@fermat.systella.fr>, a
écrit :
Où as-tu vu que j'avais parlé d'une simple incrémentation ?
Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut
te faire soigner, ou lire le man gettimeofday.
Non, tu as parlé d'une horloge comptant les us, ni plus ni moins.
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 :
Où as-tu vu que j'avais parlé d'une simple incrémentation ? Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut te faire soigner, ou lire le man gettimeofday.
Non, tu as parlé d'une horloge comptant les us, ni plus ni moins.
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
Où as-tu vu que j'avais parlé d'une simple incrémentation ? Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut te faire soigner, ou lire le man gettimeofday. et moi je te dis horloge temps réel
si tu veux plus de precision je te reponds timer
si tu en veux plus je ne peux pas bicause quartz cela te va
remy
JKB , dans le message <slrnfgkb6l.3at.knatschke@fermat.systella.fr>, a
Où as-tu vu que j'avais parlé d'une simple incrémentation ?
Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut
te faire soigner, ou lire le man gettimeofday.
et moi je te dis horloge temps réel
si tu veux plus de precision je te reponds timer
si tu en veux plus je ne peux pas bicause quartz cela te va
Où as-tu vu que j'avais parlé d'une simple incrémentation ? Dans tes prémices ! Tu parles d'une horloge sur 32 bits ou 64 bits.
J'ai dit « calculs sur le temps ». Si tu y comprends « compteur », il faut te faire soigner, ou lire le man gettimeofday. et moi je te dis horloge temps réel
si tu veux plus de precision je te reponds timer
si tu en veux plus je ne peux pas bicause quartz cela te va
remy
Nicolas George
JKB , dans le message , a écrit :
Sors les moi que je rigoles.
J'ai autre chose à faire que fouiller google groups. Ça tournait autour du fait que le C ne permettrait pas d'écrire portablement.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant de l'architecture i386/amd64.
Quand la discussion porte précisément sur ces deux architectures, c'est la moindre des choses.
Que vient foutre perl ici ?
Ah, oui, j'avais pris vim comme exemple et pas perl comme j'en avais l'intention au début.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_ de la vitesse, simplement que si le processeur le permettait, cela éviterait d'en _perdre_. Ce n'est pas exactement la meme chose. <snip>
En d'autres termes, les gens chez intel et AMD sont des abrutis, tu sais tout mieux qu'eux.
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier du fait.
J'ai assez de ce petit jeu. Soit tu énonces clairement la comparaison que tu faisais, soit tu admets implicitement que tu as dit une connerie.
JKB , dans le message <slrnfgkbq0.3at.knatschke@fermat.systella.fr>, a
écrit :
Sors les moi que je rigoles.
J'ai autre chose à faire que fouiller google groups. Ça tournait autour du
fait que le C ne permettrait pas d'écrire portablement.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant
de l'architecture i386/amd64.
Quand la discussion porte précisément sur ces deux architectures, c'est la
moindre des choses.
Que vient foutre perl ici ?
Ah, oui, j'avais pris vim comme exemple et pas perl comme j'en avais
l'intention au début.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_
de la vitesse, simplement que si le processeur le permettait, cela
éviterait d'en _perdre_. Ce n'est pas exactement la meme chose.
<snip>
En d'autres termes, les gens chez intel et AMD sont des abrutis, tu sais
tout mieux qu'eux.
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier
du fait.
J'ai assez de ce petit jeu. Soit tu énonces clairement la comparaison que tu
faisais, soit tu admets implicitement que tu as dit une connerie.
J'ai autre chose à faire que fouiller google groups. Ça tournait autour du fait que le C ne permettrait pas d'écrire portablement.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant de l'architecture i386/amd64.
Quand la discussion porte précisément sur ces deux architectures, c'est la moindre des choses.
Que vient foutre perl ici ?
Ah, oui, j'avais pris vim comme exemple et pas perl comme j'en avais l'intention au début.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_ de la vitesse, simplement que si le processeur le permettait, cela éviterait d'en _perdre_. Ce n'est pas exactement la meme chose. <snip>
En d'autres termes, les gens chez intel et AMD sont des abrutis, tu sais tout mieux qu'eux.
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier du fait.
J'ai assez de ce petit jeu. Soit tu énonces clairement la comparaison que tu faisais, soit tu admets implicitement que tu as dit une connerie.
Nicolas George
JKB , dans le message , a écrit :
Non, tu as parlé d'une horloge comptant les us, ni plus ni moins.
Citation ?
JKB , dans le message <slrnfgkbrj.3at.knatschke@fermat.systella.fr>, a
écrit :
Non, tu as parlé d'une horloge comptant les us, ni plus ni moins.
