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.
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ... http://www.phoronix.com/scan.php?page=article&itema6&num=1
Jérémy JUST
Le Sun, 07 Oct 2007 19:01:17 +0200,
Là encore, mais idées sur cette technologie reste floue: comme son nom l'indique, elle permets de traiter plusieurs threads pendant le même cycle ? Dans une Gentoo par exemple dans le make.conf il faut mettre
MAKEOPTS="-j3" avec un amd X2
Pourquoi « il faut »? Non, le bon argumentaire est: pour que les compilations utilisent les deux coeurs, on peut passer l'option « -j3 » (certains makefiles ne le supportent pas, par exemple celui d'XEmacs). Ça ne change rien au résultat de la compilation, mais celle-ci se déroule plus vite.
Il faut donc que le noyau soit (extremement bien) optimisé pour cette technologie afin qu'elle serve à quelque chose ?
Le grand public découvre ça maintenant, mais le fait de pouvoir faire tourner plusieurs processus en même temps doit dater des années 70 (ou au moins 80), avec les machines SMP. Le noyau Linux gère ça de façon satisfaisante depuis longtemps. Il a en plus été amélioré il y a deux ou trois ans sur ce point.
Le noyau doit être compilé avec l'option SMP, et ensuite, tout est transparent pour les utilisateurs.
-- Jérémy JUST
Le Sun, 07 Oct 2007 19:01:17 +0200,
Là encore, mais idées sur cette technologie reste floue: comme son
nom l'indique, elle permets de traiter plusieurs threads pendant le
même cycle ?
Dans une Gentoo par exemple dans le make.conf il faut mettre
MAKEOPTS="-j3" avec un amd X2
Pourquoi « il faut »?
Non, le bon argumentaire est: pour que les compilations utilisent les
deux coeurs, on peut passer l'option « -j3 » (certains makefiles ne
le supportent pas, par exemple celui d'XEmacs). Ça ne change rien au
résultat de la compilation, mais celle-ci se déroule plus vite.
Il faut donc que le noyau soit (extremement bien) optimisé pour
cette technologie afin qu'elle serve à quelque chose ?
Le grand public découvre ça maintenant, mais le fait de pouvoir faire
tourner plusieurs processus en même temps doit dater des années 70
(ou au moins 80), avec les machines SMP.
Le noyau Linux gère ça de façon satisfaisante depuis longtemps. Il a
en plus été amélioré il y a deux ou trois ans sur ce point.
Le noyau doit être compilé avec l'option SMP, et ensuite, tout est
transparent pour les utilisateurs.
Là encore, mais idées sur cette technologie reste floue: comme son nom l'indique, elle permets de traiter plusieurs threads pendant le même cycle ? Dans une Gentoo par exemple dans le make.conf il faut mettre
MAKEOPTS="-j3" avec un amd X2
Pourquoi « il faut »? Non, le bon argumentaire est: pour que les compilations utilisent les deux coeurs, on peut passer l'option « -j3 » (certains makefiles ne le supportent pas, par exemple celui d'XEmacs). Ça ne change rien au résultat de la compilation, mais celle-ci se déroule plus vite.
Il faut donc que le noyau soit (extremement bien) optimisé pour cette technologie afin qu'elle serve à quelque chose ?
Le grand public découvre ça maintenant, mais le fait de pouvoir faire tourner plusieurs processus en même temps doit dater des années 70 (ou au moins 80), avec les machines SMP. Le noyau Linux gère ça de façon satisfaisante depuis longtemps. Il a en plus été amélioré il y a deux ou trois ans sur ce point.
Le noyau doit être compilé avec l'option SMP, et ensuite, tout est transparent pour les utilisateurs.
-- Jérémy JUST
Taureau Debout
chalten wrote:
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ... http://www.phoronix.com/scan.php?page=article&itema6&num=1
Le test d'unreal http://www.phoronix.com/scan.php?page=article&itema6&num=2
C'est unreal 32 bits?
chalten wrote:
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ...
http://www.phoronix.com/scan.php?page=article&itema6&num=1
Le test d'unreal
http://www.phoronix.com/scan.php?page=article&itema6&num=2
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ... http://www.phoronix.com/scan.php?page=article&itema6&num=1
Le test d'unreal http://www.phoronix.com/scan.php?page=article&itema6&num=2
C'est unreal 32 bits?
Jérémy JUST
Le Sun, 07 Oct 2007 19:15:09 +0200,
Hum, mais la technologie double c½ur ne change en rien la manière qu'a une application (non multi-threadé) de s'executer, non ?
Non. Le multicoeur est intéressant quand tu fais tourner plusieurs applications qui occupent chacune un coeur entier. Typiquement, pour du calcul intensif.
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.
-- Jérémy JUST
Le Sun, 07 Oct 2007 19:15:09 +0200,
Hum, mais la technologie double c½ur ne change en rien la manière
qu'a une application (non multi-threadé) de s'executer, non ?
Non. Le multicoeur est intéressant quand tu fais tourner plusieurs
applications qui occupent chacune un coeur entier. Typiquement, pour du
calcul intensif.
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.
Hum, mais la technologie double c½ur ne change en rien la manière qu'a une application (non multi-threadé) de s'executer, non ?
Non. Le multicoeur est intéressant quand tu fais tourner plusieurs applications qui occupent chacune un coeur entier. Typiquement, pour du calcul intensif.
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.
-- Jérémy JUST
JKB
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 19:15:09 +0200,
Hum, mais la technologie double c½ur ne change en rien la manière qu'a une application (non multi-threadé) de s'executer, non ?
Non. Le multicoeur est intéressant quand tu fais tourner plusieurs applications qui occupent chacune un coeur entier. Typiquement, pour du calcul intensif.
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...
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 19:15:09 +0200,
Hum, mais la technologie double c½ur ne change en rien la manière
qu'a une application (non multi-threadé) de s'executer, non ?
Non. Le multicoeur est intéressant quand tu fais tourner plusieurs
applications qui occupent chacune un coeur entier. Typiquement, pour du
calcul intensif.
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...
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 19:15:09 +0200,
Hum, mais la technologie double c½ur ne change en rien la manière qu'a une application (non multi-threadé) de s'executer, non ?
Non. Le multicoeur est intéressant quand tu fais tourner plusieurs applications qui occupent chacune un coeur entier. Typiquement, pour du calcul intensif.
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...
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.
Nanar Duff
chalten wrote:
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ... http://www.phoronix.com/scan.php?page=article&itema6&num=1
Merci du lien.
Donc, un 64 bits ne change rien à la donne à moins que...
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 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" ?
chalten wrote:
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ...
http://www.phoronix.com/scan.php?page=article&itema6&num=1
Merci du lien.
Donc, un 64 bits ne change rien à la donne à moins que...
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
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" ?
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.
ci joint un lien vers un test comparatif entre une ubuntu 32 et 64 bits ... http://www.phoronix.com/scan.php?page=article&itema6&num=1
Merci du lien.
Donc, un 64 bits ne change rien à la donne à moins que...
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 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" ?
Mihamina Rakotomandimby
Nanar Duff > wrote:
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 ?
De toutes façons, tu ne peux quasiment plus acheter que des processerus 64bits, de nos jours!
Nanar Duff > wrote:
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 ?
De toutes façons, tu ne peux quasiment plus acheter que des processerus
64bits, de nos jours!
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 ?
De toutes façons, tu ne peux quasiment plus acheter que des processerus 64bits, de nos jours!
Jérémy JUST
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.
-- Jérémy JUST
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.
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.
-- Jérémy JUST
Jérémy JUST
Le Sun, 07 Oct 2007 20:45:16 +0200,
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 ?
Si tu parles du code-source des programmes, il suffit qu'il soit écrit proprement pour qu'on puisse le compiler sur n'importe quelle plate-forme, Sparc, x86, PPC... En pratique, presque toutes les applications libres maintenues depuis plusieurs années par une équipe de développeurs sont écrites suffisamment proprement pour être compilables partout. Les applications qui ne compilaient pas que j'ai rencontrées étaient des bouts de code expérimentaux, ou développés par une personne isolée.
Ensuite, il faut que le compilateur supporte la plate-forme. GCC peut compiler pour la grande majorité des architectures, avec une efficacité variable suivant le cas. Pour chaque architecture, il existe au moins un compilateur propriétaire optimisé.
Enfin, les binaires sont évidemment non portables entre architectures.
-- Jérémy JUST
Le Sun, 07 Oct 2007 20:45:16 +0200,
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 ?
Si tu parles du code-source des programmes, il suffit qu'il soit
écrit proprement pour qu'on puisse le compiler sur n'importe quelle
plate-forme, Sparc, x86, PPC...
En pratique, presque toutes les applications libres maintenues depuis
plusieurs années par une équipe de développeurs sont écrites
suffisamment proprement pour être compilables partout. Les applications
qui ne compilaient pas que j'ai rencontrées étaient des bouts de code
expérimentaux, ou développés par une personne isolée.
Ensuite, il faut que le compilateur supporte la plate-forme. GCC peut
compiler pour la grande majorité des architectures, avec une efficacité
variable suivant le cas.
Pour chaque architecture, il existe au moins un compilateur
propriétaire optimisé.
Enfin, les binaires sont évidemment non portables entre
architectures.
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 ?
Si tu parles du code-source des programmes, il suffit qu'il soit écrit proprement pour qu'on puisse le compiler sur n'importe quelle plate-forme, Sparc, x86, PPC... En pratique, presque toutes les applications libres maintenues depuis plusieurs années par une équipe de développeurs sont écrites suffisamment proprement pour être compilables partout. Les applications qui ne compilaient pas que j'ai rencontrées étaient des bouts de code expérimentaux, ou développés par une personne isolée.
Ensuite, il faut que le compilateur supporte la plate-forme. GCC peut compiler pour la grande majorité des architectures, avec une efficacité variable suivant le cas. Pour chaque architecture, il existe au moins un compilateur propriétaire optimisé.
Enfin, les binaires sont évidemment non portables entre architectures.
-- Jérémy JUST
Mihamina Rakotomandimby
Nanar Duff > wrote:
Donc, un 64 bits ne change rien à la donne à moins que... ... c'est incroyable: le 64 bit est l'étape suivante des processeurs.
Comment veux-tu que les programmes soient correctement écrits pour eux se stabilisent si tu ne les utilise pas? Je n'irais pas jusqu'à dire que c'est obligatoire d'avoir des utilisateurs poura voir des programmes bien écris, mais le feedback contribue fortement au développement.
Nanar Duff > wrote:
Donc, un 64 bits ne change rien à la donne à moins que...
... c'est incroyable: le 64 bit est l'étape suivante des processeurs.
Comment veux-tu que les programmes soient correctement écrits pour eux
se stabilisent si tu ne les utilise pas? Je n'irais pas jusqu'à dire que
c'est obligatoire d'avoir des utilisateurs poura voir des programmes
bien écris, mais le feedback contribue fortement au développement.
Donc, un 64 bits ne change rien à la donne à moins que... ... c'est incroyable: le 64 bit est l'étape suivante des processeurs.
Comment veux-tu que les programmes soient correctement écrits pour eux se stabilisent si tu ne les utilise pas? Je n'irais pas jusqu'à dire que c'est obligatoire d'avoir des utilisateurs poura voir des programmes bien écris, mais le feedback contribue fortement au développement.
