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.
sur le meme ordi ? avec un code compiler pour du 32 bit et le meme programme compiler pour du 64 bit avec le meme calcul
Oui, le même ordi, sur lequel est installé le maple 32 bits et le maple
64 bits, et le même calcul.
ils ont du faire des progrès dans l'optimisation du code compilé ou des algos
dit différemment il y a un truc qui m'échappe c'est pas très logique vu qu'il n'y a pratiquement pas d'optimisation des mnemoniques dixit wikipedia et que ta taille de mémoire n'utilise pas le 64 bits
il y a comme un truc
remy
remy <remy@fctpas.fr> wrote:
sur le meme ordi ?
avec un code compiler pour du 32 bit et le meme programme
compiler pour du 64 bit avec le meme calcul
Oui, le même ordi, sur lequel est installé le maple 32 bits et le maple
64 bits, et le même calcul.
ils ont du faire des progrès dans l'optimisation du code compilé
ou des algos
dit différemment il y a un truc qui m'échappe c'est pas très logique
vu qu'il n'y a pratiquement pas d'optimisation des mnemoniques
dixit wikipedia et que ta taille de mémoire n'utilise pas le
64 bits
sur le meme ordi ? avec un code compiler pour du 32 bit et le meme programme compiler pour du 64 bit avec le meme calcul
Oui, le même ordi, sur lequel est installé le maple 32 bits et le maple
64 bits, et le même calcul.
ils ont du faire des progrès dans l'optimisation du code compilé ou des algos
dit différemment il y a un truc qui m'échappe c'est pas très logique vu qu'il n'y a pratiquement pas d'optimisation des mnemoniques dixit wikipedia et que ta taille de mémoire n'utilise pas le 64 bits
il y a comme un truc
remy
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 :
Si. Il y a une raison fondamentale qui t'échapppe.
Je t'écoute...
Non. Puisque tu connais parfaitement le fonctionnement interne des processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Et alors ? On peut _toujours_ doubler sa taille, même s'il est petit, et ton argument tombe de lui-même.
Doubler la taille, ça coûte aussi.
Moins que se palucher un décodeur _beaucoup_ plus complexe.
L'argument est simple. À puissance de calcul équivalente, une machine bipro est plus mauvaise qu'une monopro
Très bien. Eh bien je dis : si elle est plus mauvaise, c'est qu'elle n'a pas la même « puissance de calcul », pour toute définition vaguement pertinente de ce terme.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5% près la même puissance de calcul. La différence se fait dès qu'on accède à la mémoire en raison des temps d'attente.
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 <slrnfgkjg9.3at.knatschke@fermat.systella.fr>, a
écrit :
Si. Il y a une raison fondamentale qui t'échapppe.
Je t'écoute...
Non. Puisque tu connais parfaitement le fonctionnement interne des
processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Et alors ? On peut _toujours_ doubler sa taille, même s'il est
petit, et ton argument tombe de lui-même.
Doubler la taille, ça coûte aussi.
Moins que se palucher un décodeur _beaucoup_ plus complexe.
L'argument est simple. À puissance de calcul équivalente, une
machine bipro est plus mauvaise qu'une monopro
Très bien. Eh bien je dis : si elle est plus mauvaise, c'est qu'elle n'a pas
la même « puissance de calcul », pour toute définition vaguement pertinente
de ce terme.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5%
près la même puissance de calcul. La différence se fait dès qu'on
accède à la mémoire en raison des temps d'attente.
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 :
Si. Il y a une raison fondamentale qui t'échapppe.
Je t'écoute...
Non. Puisque tu connais parfaitement le fonctionnement interne des processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Et alors ? On peut _toujours_ doubler sa taille, même s'il est petit, et ton argument tombe de lui-même.
Doubler la taille, ça coûte aussi.
Moins que se palucher un décodeur _beaucoup_ plus complexe.
L'argument est simple. À puissance de calcul équivalente, une machine bipro est plus mauvaise qu'une monopro
Très bien. Eh bien je dis : si elle est plus mauvaise, c'est qu'elle n'a pas la même « puissance de calcul », pour toute définition vaguement pertinente de ce terme.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5% près la même puissance de calcul. La différence se fait dès qu'on accède à la mémoire en raison des temps d'attente.
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
mais oui mais oui tu vient de dire une connerie
Non.
si re lit le lien l'info elle et ou pour gettimeofday()
mais oui mais oui tu vient de dire une connerie
Non.
si re lit le lien l'info elle et ou pour gettimeofday()
si re lit le lien l'info elle et ou pour gettimeofday()
Nanar Duff >
Nicolas George wrote:
Nanar Duff , dans le message <47090c23$0$16428$, a
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire passer les registres du prcesseur de 32 à 64 bits.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a aussi plus de registres généralistes.
Donc, le (seul ?) avantage du 64 bits pour les application ne demandant pas de calculs avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou 64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de 50 jours (il me semble que les vieux windows NT avaient un problème à ce niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin de mesurer le temps en dessous de la seconde, ce n'est pas rare.
c'est l'augmentation de l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce marketing ?
Si on considère que la plupart des machines vendues actuellement ont 1 Go de RAM minimum, donc on est très près de la limite de l'espace d'adressage. Si on se rappelle aussi que les OS modernes savent faire de la mémoire virtuelle et des fichiers mappés en mémoire, et que les disques durs font plusieurs centaines de giga-octets, c'est loin d'être négligeable.
De plus, il faut en toute logique que les applications soit compilées par un gcc en "mode 64bits" (?): ce mode "est il au point" ?
Oui.
Ne change-t-il vraiment rien d'autre que quelques broutilles concernant l'addressage ?
Si, ça change énormément. Du point de vue du compilateur, un Core 2 en 32 bits, c'est un 386 un peu plus rapide, avec quelques instructions en plus. Le compilateur peut faire l'effort d'utiliser ces instructions, mais une grande partie l'architecture du code produit reste quelque chose de compatible avec le 386.
C'est ce qu'on appelle l'ABI d'un système (couple système d'exploitation et architecture physique) : les conventions sur la manière dont les fonctions doivent se passer les arguments. Avec un Core 2 aujourd'hui, cette ABI reste compatible avec le 386.
C'est en particulier vrai pour les calculs sur les flottants : l'ABI de Linux en 32 bits utilise les registres du coprocesseur arithmétique 387. Un Core 2 a un système appelé SSE2 qui est plus pratique pour ça (en particulier parce qu'il peut échanger directement des registres avec le processeur, le 387 doit passer par la mémoire il me semble). Donc même si le compilateur peut, dans une fonction, utiliser SSE2 s'il sait que ça tournera sur un Core 2, dès qu'il y a des appels de fonctions, il doit passer par le 387.
À l'inverse, le Core 2 en 64 bits est un tout nouveau processeur (enfin, c'est l'AMD64 le nouveau, mais bon), qui n'est pas encombré de la compatibilité avec l'ancien. L'ABI a été conçue pour tirer parti directement de ses nouvelles possibilités.
D'autre part, comme la partie génération et optimisation du code du processeur dû être réécrite depuis le début pour le nouveau processeur, elle peut intégrer plus directement les nouvelles possibilités. Là encore, j'ai l'exemple d'un problème entre 387 et SSE2 : même sans appel de fonctions, où le calcul pourrait se faire entièrement avec SSE2, gcc va parfois passer par le 387 simplement parce qu'il n'a pas vu qu'il pouvait couper court. Du coup, le code produit est beaucoup plus lent en 32 bits qu'en 64 bits. En optimisant l'assembleur à la main, on arrive à les amener à égalité, mais gcc ne le voit pas.
L'un dans l'autre, une application gourmande en CPU va gagner peut-être 10% de vitesse à passer en 64 bits (test fait avec POV-Ray).
En revanche, l'occupation mémoire peut se trouver augmentée. Ce ne sera pas toujours le cas. En particulier, pour beaucoup de programmes, l'essentiel de la mémoire est pris par des données plates (typiquement, une image), qui n'est pas influencée. Mais avec des langages de haut niveau manipulant automatiquement des structures de données pleines de pointeurs, ça peut jouer.
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup d'applications Linux compatible 64bits ?
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre histoire.
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel "compilé en mode 64 bits",
Oui. Parfois un peu pénible, selon la distribution, pour les histoires de bibliothèques partagées, mais aucun problème de fond.
Il y a quelques rares cas de périphériques dont certaines fonctionnalités ne sont pas disponibles en émulation 32 bits, mais la plupart des applications ne touchent pas aux périphériques.
et cela ralentit-il l'application ?
Pas du tout.
Merci de cette réponse :-)
Nicolas George wrote:
Nanar Duff , dans le message <47090c23$0$16428$426a74cc@news.free.fr>, a
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire
passer les registres du prcesseur de 32 à 64 bits.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a
aussi plus de registres généralistes.
Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres
énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le
facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou
64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de
50 jours (il me semble que les vieux windows NT avaient un problème à ce
niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin
de mesurer le temps en dessous de la seconde, ce n'est pas rare.
c'est l'augmentation de
l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce
marketing ?
Si on considère que la plupart des machines vendues actuellement ont 1 Go de
RAM minimum, donc on est très près de la limite de l'espace d'adressage. Si
on se rappelle aussi que les OS modernes savent faire de la mémoire
virtuelle et des fichiers mappés en mémoire, et que les disques durs font
plusieurs centaines de giga-octets, c'est loin d'être négligeable.
De plus, il faut en toute logique que les applications soit compilées
par un gcc en "mode 64bits" (?): ce mode "est il au point" ?
Oui.
Ne
change-t-il vraiment rien d'autre que quelques broutilles concernant
l'addressage ?
Si, ça change énormément. Du point de vue du compilateur, un Core 2 en
32 bits, c'est un 386 un peu plus rapide, avec quelques instructions en
plus. Le compilateur peut faire l'effort d'utiliser ces instructions, mais
une grande partie l'architecture du code produit reste quelque chose de
compatible avec le 386.
C'est ce qu'on appelle l'ABI d'un système (couple système d'exploitation et
architecture physique) : les conventions sur la manière dont les fonctions
doivent se passer les arguments. Avec un Core 2 aujourd'hui, cette ABI reste
compatible avec le 386.
C'est en particulier vrai pour les calculs sur les flottants : l'ABI de
Linux en 32 bits utilise les registres du coprocesseur arithmétique 387. Un
Core 2 a un système appelé SSE2 qui est plus pratique pour ça (en
particulier parce qu'il peut échanger directement des registres avec le
processeur, le 387 doit passer par la mémoire il me semble). Donc même si le
compilateur peut, dans une fonction, utiliser SSE2 s'il sait que ça tournera
sur un Core 2, dès qu'il y a des appels de fonctions, il doit passer par le
387.
À l'inverse, le Core 2 en 64 bits est un tout nouveau processeur (enfin,
c'est l'AMD64 le nouveau, mais bon), qui n'est pas encombré de la
compatibilité avec l'ancien. L'ABI a été conçue pour tirer parti directement
de ses nouvelles possibilités.
D'autre part, comme la partie génération et optimisation du code du
processeur dû être réécrite depuis le début pour le nouveau processeur, elle
peut intégrer plus directement les nouvelles possibilités. Là encore, j'ai
l'exemple d'un problème entre 387 et SSE2 : même sans appel de fonctions, où
le calcul pourrait se faire entièrement avec SSE2, gcc va parfois passer par
le 387 simplement parce qu'il n'a pas vu qu'il pouvait couper court. Du
coup, le code produit est beaucoup plus lent en 32 bits qu'en 64 bits. En
optimisant l'assembleur à la main, on arrive à les amener à égalité, mais
gcc ne le voit pas.
L'un dans l'autre, une application gourmande en CPU va gagner peut-être 10%
de vitesse à passer en 64 bits (test fait avec POV-Ray).
En revanche, l'occupation mémoire peut se trouver augmentée. Ce ne sera pas
toujours le cas. En particulier, pour beaucoup de programmes, l'essentiel de
la mémoire est pris par des données plates (typiquement, une image), qui
n'est pas influencée. Mais avec des langages de haut niveau manipulant
automatiquement des structures de données pleines de pointeurs, ça peut
jouer.
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup
d'applications Linux compatible 64bits ?
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à
ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même
semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un
dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre
histoire.
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel
"compilé en mode 64 bits",
Oui. Parfois un peu pénible, selon la distribution, pour les histoires de
bibliothèques partagées, mais aucun problème de fond.
Il y a quelques rares cas de périphériques dont certaines fonctionnalités ne
sont pas disponibles en émulation 32 bits, mais la plupart des applications
ne touchent pas aux périphériques.
Nanar Duff , dans le message <47090c23$0$16428$, a
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire passer les registres du prcesseur de 32 à 64 bits.
Oui, c'est ça.
À noter que dans le cas x86 / x86_64, il me semble que le mode 64 bits a aussi plus de registres généralistes.
Donc, le (seul ?) avantage du 64 bits pour les application ne demandant pas de calculs avec des chiffres (relativement) enorme,
Note que dans les applications qui demandent des calculs avec des nombres énormes, tu as toute la cryptographie asymétrique : TLS, SSH, PGP. Là, le facteur de vitesse est considérable.
Les calculs sur les temps aussi gagnent énormément à pouvoir se faire sou 64 bits. Si tu comptes sur 32 bits en millisecondes, tu reboucles au bout de 50 jours (il me semble que les vieux windows NT avaient un problème à ce niveau-là). Une application qui doit tourner plus de 50 jours, et a besoin de mesurer le temps en dessous de la seconde, ce n'est pas rare.
c'est l'augmentation de l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce marketing ?
Si on considère que la plupart des machines vendues actuellement ont 1 Go de RAM minimum, donc on est très près de la limite de l'espace d'adressage. Si on se rappelle aussi que les OS modernes savent faire de la mémoire virtuelle et des fichiers mappés en mémoire, et que les disques durs font plusieurs centaines de giga-octets, c'est loin d'être négligeable.
De plus, il faut en toute logique que les applications soit compilées par un gcc en "mode 64bits" (?): ce mode "est il au point" ?
Oui.
Ne change-t-il vraiment rien d'autre que quelques broutilles concernant l'addressage ?
Si, ça change énormément. Du point de vue du compilateur, un Core 2 en 32 bits, c'est un 386 un peu plus rapide, avec quelques instructions en plus. Le compilateur peut faire l'effort d'utiliser ces instructions, mais une grande partie l'architecture du code produit reste quelque chose de compatible avec le 386.
C'est ce qu'on appelle l'ABI d'un système (couple système d'exploitation et architecture physique) : les conventions sur la manière dont les fonctions doivent se passer les arguments. Avec un Core 2 aujourd'hui, cette ABI reste compatible avec le 386.
C'est en particulier vrai pour les calculs sur les flottants : l'ABI de Linux en 32 bits utilise les registres du coprocesseur arithmétique 387. Un Core 2 a un système appelé SSE2 qui est plus pratique pour ça (en particulier parce qu'il peut échanger directement des registres avec le processeur, le 387 doit passer par la mémoire il me semble). Donc même si le compilateur peut, dans une fonction, utiliser SSE2 s'il sait que ça tournera sur un Core 2, dès qu'il y a des appels de fonctions, il doit passer par le 387.
À l'inverse, le Core 2 en 64 bits est un tout nouveau processeur (enfin, c'est l'AMD64 le nouveau, mais bon), qui n'est pas encombré de la compatibilité avec l'ancien. L'ABI a été conçue pour tirer parti directement de ses nouvelles possibilités.
D'autre part, comme la partie génération et optimisation du code du processeur dû être réécrite depuis le début pour le nouveau processeur, elle peut intégrer plus directement les nouvelles possibilités. Là encore, j'ai l'exemple d'un problème entre 387 et SSE2 : même sans appel de fonctions, où le calcul pourrait se faire entièrement avec SSE2, gcc va parfois passer par le 387 simplement parce qu'il n'a pas vu qu'il pouvait couper court. Du coup, le code produit est beaucoup plus lent en 32 bits qu'en 64 bits. En optimisant l'assembleur à la main, on arrive à les amener à égalité, mais gcc ne le voit pas.
L'un dans l'autre, une application gourmande en CPU va gagner peut-être 10% de vitesse à passer en 64 bits (test fait avec POV-Ray).
En revanche, l'occupation mémoire peut se trouver augmentée. Ce ne sera pas toujours le cas. En particulier, pour beaucoup de programmes, l'essentiel de la mémoire est pris par des données plates (typiquement, une image), qui n'est pas influencée. Mais avec des langages de haut niveau manipulant automatiquement des structures de données pleines de pointeurs, ça peut jouer.
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup d'applications Linux compatible 64bits ?
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre histoire.
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel "compilé en mode 64 bits",
Oui. Parfois un peu pénible, selon la distribution, pour les histoires de bibliothèques partagées, mais aucun problème de fond.
Il y a quelques rares cas de périphériques dont certaines fonctionnalités ne sont pas disponibles en émulation 32 bits, mais la plupart des applications ne touchent pas aux périphériques.
et cela ralentit-il l'application ?
Pas du tout.
Merci de cette réponse :-)
Taureau Debout
remy wrote:
Le test d'unreal http://www.phoronix.com/scan.php?page=article&itema6&num=2
C'est unreal 32 bits?
cela démontre juste que le compilateur na pas fait sont boulot optimisation en 64 bit
Non mais l'essai d'un jeu 32 bits sur une architecture 64 bits ca sert a rien
remy wrote:
Le test d'unreal
http://www.phoronix.com/scan.php?page=article&itema6&num=2
C'est unreal 32 bits?
cela démontre juste que le compilateur na pas fait sont boulot
optimisation en 64 bit
Non mais l'essai d'un jeu 32 bits sur une architecture 64 bits ca sert a
rien
Bien sûr, l'exécution de binaires 32 bits (flash, acrobat frigidaire, etc) ne profite en rien du processeur 64 bits.
Le binaire quake-smp.x86 sous un amd64 x2 ,ca utilise le smp avec l'emul 32 bits?
Nanar Duff >
Jerome Lambert wrote:
(...)
Suite aux quelques idées avancés dans le sujet, je me demande bien: est-il possible d'avoir une machine plus ou moins protable d'un autre type que x86 ou PowerPC
Il existe des portables SPARC, p.ex. chez tadpole.
Hum, aucun constructeur plus abordable ? 10 000$ la machine, non merci.
Jerome Lambert wrote:
(...)
Suite aux quelques idées avancés dans le sujet, je me demande bien:
est-il possible d'avoir une machine plus ou moins protable d'un autre
type que x86 ou PowerPC
Il existe des portables SPARC, p.ex. chez tadpole.
Hum, aucun constructeur plus abordable ? 10 000$ la machine, non merci.
Suite aux quelques idées avancés dans le sujet, je me demande bien: est-il possible d'avoir une machine plus ou moins protable d'un autre type que x86 ou PowerPC
Il existe des portables SPARC, p.ex. chez tadpole.
Hum, aucun constructeur plus abordable ? 10 000$ la machine, non merci.
Nicolas George
JKB , dans le message , a écrit :
Non. Puisque tu connais parfaitement le fonctionnement interne des processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Non, ça ne me saute pas aux yeux, alors vas-y, impressionne-moi.
Moins que se palucher un décodeur _beaucoup_ plus complexe.
Certains ingénieurs n'ont pas l'air d'accord. Et d'ailleurs, je vois très bien pourquoi.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5% près la même puissance de calcul.
Les calculs dans quel cache ? Tu as une machine avec deux processeurs, je te rappelle.
JKB , dans le message <slrnfgklbs.3at.knatschke@fermat.systella.fr>, a
écrit :
Non. Puisque tu connais parfaitement le fonctionnement interne des
processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Non, ça ne me saute pas aux yeux, alors vas-y, impressionne-moi.
Moins que se palucher un décodeur _beaucoup_ plus complexe.
Certains ingénieurs n'ont pas l'air d'accord. Et d'ailleurs, je vois très
bien pourquoi.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5%
près la même puissance de calcul.
Les calculs dans quel cache ? Tu as une machine avec deux processeurs, je te
rappelle.
Non. Puisque tu connais parfaitement le fonctionnement interne des processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Non, ça ne me saute pas aux yeux, alors vas-y, impressionne-moi.
Moins que se palucher un décodeur _beaucoup_ plus complexe.
Certains ingénieurs n'ont pas l'air d'accord. Et d'ailleurs, je vois très bien pourquoi.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5% près la même puissance de calcul.
Les calculs dans quel cache ? Tu as une machine avec deux processeurs, je te rappelle.
Nicolas George
remy , dans le message <fedktv$1mh$, a écrit :
si re lit le lien l'info elle et ou pour gettimeofday()
Tu me gonfles : le jour où tu parleras français et où tu manifestera une vague compréhension de ce dont il est question ici, je te répondrai peut-être.
remy , dans le message <fedktv$1mh$1@s1.news.oleane.net>, a écrit :
si re lit le lien l'info elle et ou pour gettimeofday()
Tu me gonfles : le jour où tu parleras français et où tu manifestera une
vague compréhension de ce dont il est question ici, je te répondrai
peut-être.
si re lit le lien l'info elle et ou pour gettimeofday()
Tu me gonfles : le jour où tu parleras français et où tu manifestera une vague compréhension de ce dont il est question ici, je te répondrai peut-être.
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 :
Non. Puisque tu connais parfaitement le fonctionnement interne des processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Non, ça ne me saute pas aux yeux, alors vas-y, impressionne-moi.
Non, continue avec tes certitudes. Je ne vais pas te faire un cours de systèmes séquentiels. Ouvre les revues spécialisées (Tiens, pour ta gouverne, il y a une revue IEEE consacrée à cela, et que je reçois tous les mois depuis quelques années, et pas grand monde n'adopte ta position, parce que celle-ci est absurde pour tout nouveau design, mais c'est à toi de voir. Je te conseille de lire certains articles, attentivement. Mais tu dois bien mieux connaître le domaine que les types qui écrivent là-dedans.).
Moins que se palucher un décodeur _beaucoup_ plus complexe.
Certains ingénieurs n'ont pas l'air d'accord. Et d'ailleurs, je vois très bien pourquoi.
C'est bizarre, on ne connaît pas les mêmes.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5% près la même puissance de calcul.
Les calculs dans quel cache ? Tu as une machine avec deux processeurs, je te rappelle.
Et alors ? Chaque processeur possède deux niveaux de cache avant d'attaquer le mbus. À force de couper tout le monde, tu ne comprends même plus de quoi on parle.
JKB, fin de la discussion
-- 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 <slrnfgklbs.3at.knatschke@fermat.systella.fr>, a
écrit :
Non. Puisque tu connais parfaitement le fonctionnement interne des
processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Non, ça ne me saute pas aux yeux, alors vas-y, impressionne-moi.
Non, continue avec tes certitudes. Je ne vais pas te faire un cours
de systèmes séquentiels. Ouvre les revues spécialisées (Tiens, pour
ta gouverne, il y a une revue IEEE consacrée à cela, et que je
reçois tous les mois depuis quelques années, et pas grand
monde n'adopte ta position, parce que celle-ci est absurde pour tout
nouveau design, mais c'est à toi de voir. Je te conseille de lire
certains articles, attentivement. Mais tu dois bien mieux connaître
le domaine que les types qui écrivent là-dedans.).
Moins que se palucher un décodeur _beaucoup_ plus complexe.
Certains ingénieurs n'ont pas l'air d'accord. Et d'ailleurs, je vois très
bien pourquoi.
C'est bizarre, on ne connaît pas les mêmes.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5%
près la même puissance de calcul.
Les calculs dans quel cache ? Tu as une machine avec deux processeurs, je te
rappelle.
Et alors ? Chaque processeur possède deux niveaux de cache avant
d'attaquer le mbus. À force de couper tout le monde, tu ne comprends
même plus de quoi on parle.
JKB, fin de la discussion
--
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 :
Non. Puisque tu connais parfaitement le fonctionnement interne des processeurs et des décodeurs des codes OP, ça doit te sauter aux yeux.
Non, ça ne me saute pas aux yeux, alors vas-y, impressionne-moi.
Non, continue avec tes certitudes. Je ne vais pas te faire un cours de systèmes séquentiels. Ouvre les revues spécialisées (Tiens, pour ta gouverne, il y a une revue IEEE consacrée à cela, et que je reçois tous les mois depuis quelques années, et pas grand monde n'adopte ta position, parce que celle-ci est absurde pour tout nouveau design, mais c'est à toi de voir. Je te conseille de lire certains articles, attentivement. Mais tu dois bien mieux connaître le domaine que les types qui écrivent là-dedans.).
Moins que se palucher un décodeur _beaucoup_ plus complexe.
Certains ingénieurs n'ont pas l'air d'accord. Et d'ailleurs, je vois très bien pourquoi.
C'est bizarre, on ne connaît pas les mêmes.
Non. Les calculs dans le cache prouvent qu'elles ont à moins de 5% près la même puissance de calcul.
Les calculs dans quel cache ? Tu as une machine avec deux processeurs, je te rappelle.
Et alors ? Chaque processeur possède deux niveaux de cache avant d'attaquer le mbus. À force de couper tout le monde, tu ne comprends même plus de quoi on parle.
JKB, fin de la discussion
-- 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.
