De l'utilité du 64 bit sous Linux

Nanar Duff > wrote:

Bonjour,


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.


Nanar Duff.

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, relativement bien supporté par Linux et avec
une bonne logithèque ?

(...)

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.

Le Mon, 08 Oct 2007 01:35:17 +0200,

Mais... quel interet d'avoir un processeur 64 bits si ce n'est pas
pour profiter d'une quelconque optimisation spécifique à la machine ?

S'il y a des optimisations spécifiques à faire, comme tu dis, ce sera
le compilateur qui s'en chargera, au moment où on préparera le binaire.

Miod t'a cité la principale: l'utilisation de plus de registres.


--
Jérémy JUST <jeremy_just@netcourrier.com>

Le 07-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Nanar Duff écrivait dans fr.comp.os.linux.debats :

Jérémy JUST wrote:

Le Sun, 07 Oct 2007 19:12:06 +0200,

Par cette anectode apparemment insignifiante, voudrais-tu me signaler
que sous une Gentoo 64 bits, tout ce compile automatiquement en "mode
64 bits" (ce qui serait logique ma fois %) ? Mais il doit tomber des
erreurs de compils à la pelle ?!

Il faut noter que les machines 64 bits ne sont pas si récentes que tu
le crois. Elles le sont certes pour le grand public, mais datent des
années 90 dans le monde professionnel.

Sur une machine Sparc, sous Solaris, j'avais constaté que la
quasi-totalité des applications bien écrites compilaient en 64 bits,
même quand les développeurs n'avaient aucune idée de ce que pouvait
vouloir dire « 64 bits ».
À l'époque, GCC était en version 2.95, mais j'utilisais le
compilateur Sun pour compiler en 64 bits.

Mais... au risque de paraitre idiot: seul une minorité de programme fait
pour les machines Sparc reste "compatible" avec un compilateur pour
processeur de type i386 non ? Le 64 bit pour processeur de type i386
est-il lui aussi ancien (ça, je dois avouer que je serais étonné de
l'apprendre ;-) ?

Un programme écrit correctement restera compatible. Ce n'est pas
parce qu'un processeur est 32 bits qu'il ne peut pas faire des
calculs en 64 bits (au moins avec une émulation soft). De même, ce
n'est pas parce qu'un processeur est 32 bits que son bus d'adresse
fera 32 bits (même si c'est le cas le plus courant) et rien ne
contraint un processeur 32 bits à ne pouvoir adresse que 4 Go de
mémoire.

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 07-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Miod Vallat écrivait dans fr.comp.os.linux.debats :

N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi
maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une
utilisation de "tout les jours" ?

C'est plus rapide. Le reste est sans importance.

Dans la grande majorité des cas, c'est plus rapide en raison du
nombre accru de registres. Si on colle autant de registres dans un
32 bits que dans un 64 bits, à un poil près, les deux tourneront de
la même manière.

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 07-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Michel Talon écrivait dans fr.comp.os.linux.debats :

Miod Vallat wrote:

C'est plus rapide. Le reste est sans importance.

Sans optimisation d'aucune sorte, les plate-formes amd64 disposent de
deux fois plus de registres en mode 64 bits, qu'en mode 32 bits. Cela
permet d'utiliser moins de mémoire pour du stockage temporaire, ce qui
suffit à rendre tout le code compilé avec un compilateur 64 bits plus
rapide, même si c'est un mauvais compilateur.

Voilà, il a fallu attendre un nombre impressionnant de posts pour que Miod
dise enfin que les prémisses du post initial étaient fausses, et qu'en mode
64 bits le processeur dispose de plus de registres, ce qui est important
car le x86 manque cruellement de registres. A titre d'information, sur nos
machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui,
une augmentation de 100%) sur des calculs symboliques avec, par exemple
Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper
court aux arguments ridicules prétendant que le 64 bits ne sert qu'à
adresser plus de 4 Gigs de mémoire. Remarque que les mêmes prétendent qu'un
biproc est plus lent à cause des changements de contexte, il est clair que
des clients se sont échappés de Sainte Anne. Le cas où le 64 bits est
pénalisé est le cas où un calcul tient dans le cache en 32 bits et n'y
tient plus en 64 bits (les exécutables sont plus gros). Dans ce cas il y a
une fenêtre où le 32 bits est plus rapide. Si on grossit le calcul pour que
les deux sortent du cache, la différence s'estompe rapidement.

C'est un peu bizarre, ce que tu viens d'écrire ici. Lors d'un
dernier fil, tu as essayé de nous dire que les tailles des exécutables
64 bits et 32 bits étaient les mêmes alors que je te prouvais que
non... J'ai la flemme de chercher l'ID du message...

Maintenant, je ne sais pas comment Maple est codé en interne, mais
pour avoir une différence d'un facteur 2, il n'y a pas que le simple
passage de 32 vers 64 bits. Il doit y avoir des trucs beaucoup plus
sournois comme la gestion de la mémoire _dans sa globalité_. Je
suis à peu près sûr que les deux codes sources sont _différents_.

Par ailleurs, il est trivialement faux de dire qu'un multipro n'est
pas pénalisé par rapport à un calculateur monoprocesseur (ou alors,
tu ne t'es jamais penché sur le problème). La surcharge n'est
généralement pas bien lourde, mais elle existe. Dans certains
contextes bien particuliers, elle peut être très lourde (threads
verrouillés par des mutex rompant les décisions du noyau entre autre)
si le code est mal fichu. J'ai un exemple très simple : le simple
fait d'avoir dû mettre un mutex dans un thread ramasse-miette dans
un programme a ralenti la vitesse d'exécution du thread principal de
30%, le prix à payer pour une gestion entièrement dynamique de la
mémoire de ce processus ! De toute façon, il n'y a pas que les
changement de contexte, il y a aussi les accès concurrents à la
mémoire ou aux autres bus du système. Compare pour rigoler une SS20
avec deux processeurs SM71 (75 MHz) à une Ultra1 (140 MHz), les deux
sous Solaris9 32 bits, avec le même code lançant cinq ou six
threads. Les _deux_ machines ont la même architecture, le même OS au
bit près, et tu verras que l'Ultra1, même en 32 bits, est avantagée
par rapport à la SS20. Tu peux faire la même chose sur i386 ou
amd64.

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 07-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Thierry B. écrivait dans fr.comp.os.linux.debats :

--{ Nanar Duff a plopé ceci: }--

Si l'on regarde le résultat de la compilation du kernel on voit que le
temps est bien moins important pour les machines 64 bits. Ceci

Ah, bon, décodons un peu. C'est quoi qui est le "résultat" ?

Le temps qu'il faut pour compiler un kernel, ou le gain de temps
_quantifialble_ sur l'exécution d'une tache précise faisant appel
fréquement à _ce_ kernel compilé ? Chez moi, sur une de mes machines,
compiler un QT récent prend entre trois et quatre jours. Mais quand
il est là, je suis à même de juger si il marche mieux ou moins bien
que la version précédente.

C'est juste un exemple, hein, sur le benchmarkisme.

Surtout qu'on oublie de dire qu'un compilo est de complexité
exponentielle en terme de nombre de registre...

implique-t-il que gcc est optimisé pour 64 bit pour un tel gain de temps
? Si oui, en attendant quelques années les "64 bits en x86" deviendront
un réel "avantage" ?

Bah, au siècle dernier, il y avait aussi des 64bits, et même des
80bits, tout le monde en était content, mais il n'y avait pas de
marketing, ni de ***********

J'ai même une carte-mère alpha avec un bus mémoire de 256 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 07-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Jérémy JUST écrivait dans fr.comp.os.linux.debats :

Le Sun, 7 Oct 2007 18:31:39 +0000 (UTC),

L'utilisateur de base, même s'il a l'impression de faire tourner
des applications en parallèle quand il a un Firefox et un OpenOffice
ouverts en même temps, ne bénéficiera pas d'un grand avantage avec
des processeurs multicoeurs.

Voire d'un "désavantage" sur les changements de contexte et
les occupations de bus...

J'y avais pensé, mais je me suis dit que le temps ainsi perdu devait
être compensé par le fait que, pendant les rares pics d'utilisation du
CPU, l'interface graphique et autres gadgets résidents pouvaient
tourner sur l'autre CPU.

Si le code est dans le cache. Dans le cas contraire, il faut gérer
les accès simultanés. Il est cependant vrai que pour une une machine
de bureau où le ou les procs font généralement les pieds au mur
pendant 95% du temps, on ne verra pas la surcharge (de toute façon,
quel est l'avantage d'un tel truc sur une machine de bureau destinée
principalement à la bureautique...), donc la question ne se pose
pas.

Par ailleurs, sur une machine chargée (vraiment chargée, hein, pas
une charge de 5 ou 6...), la pénalisation est plus issue de
l'architecture elle-même (proc + carte-mère) que du processeur
seul.

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 07-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Jérémy JUST écrivait dans fr.comp.os.linux.debats :

Le Sun, 07 Oct 2007 21:45:39 +0200,

Mais, on a dit plus haut que certains programme Sparc était
"optimisé" pour les 64 bits.

Où as-tu lu ça?

Car si un programme "optimisé" pour 64 bit donne un binaire 32 bits
où est l'utilité de la chose, qu'est ce que le programme fera sur une
machine 64 bit qui ne fera pas (ou en plusieurs étapes) sur une
machine 32 bits ?

Je n'ai jamais rencontré de programmes « optimisés pour les
64 bits ». J'ai juste vu des programmes propriétaires, distribués sous
forme de binaires 64 bits, qui ne tournaient que sur la machine 64 bits
pour laquelle ils étaient compilés.
Mais j'imagine qu'on pouvait acheter la version 32 bits à côté.

Sinon, si ton programme utilise plus de 4 Go de RAM, effectivement,
il ne pourra pas tourner sur une machine 32 bits. Mais ce n'est pas lié
directement au programme.


Après, peut-être que le cas dont tu parles existe, hein. Mais je n'en
ai jamais entendu parler.

Question connexe... Sur sparc64/linux, le userland est 32 bits et le
noyau 64 bits. Quelle est la taille maximale de mémoire utilisable
par un processus ? J'ai déjà réussi à faire des processus de plus de
3 Go de mémoire à coups de malloc(), mais je n'ai jamais eu de
renseignements sur ce sujet...

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.

--{ Miod Vallat a plopé ceci: }--

N'y aurait il donc pas quelqu'un pour nous avancer les progrès (aussi
maigre soit ils pour le moment) qu'aporte les machines 64 bits pour une
utilisation de "tout les jours" ?

C'est plus rapide. Le reste est sans importance.

Et l'espace d'adressage ? Il y a de cela très très longtemps, j'avais
lu un article sur l'utilisation d'immenses espaces d'adressage par
les bases de données, permettant une grande simplification du code,
je crois que c'était des travaux de l'équipe Ingres.

On retrouve d'ailleurs cette idée dès la conception des as400, de leur
processeur 48bits, et de leur OS si particulier.


--
<ptilou> Mes partagaient, " Bougre de ma fatche" ...