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.
Le Tue, 09 Oct 2007 20:19:14 +0200, Nina Popravka a écrit :
Et... avec un autre OS que MacOS, la différence est flagrante ?
Non, je ne crois pas. La seule chose qui était flagrante quand j'ai acheté mon iBook en 2004, c'est qu'à 1200 euros aucun PC ne faisait moins de 3kg, et aucun ne tenait non plus 6 heures sur sa batterie de base. Quant au ventilateur, je l'entends tourner moins d'une fois par mois, c'est également appréciable.
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Tue, 09 Oct 2007 20:19:14 +0200, Nina Popravka a écrit :
Et... avec un autre OS que MacOS, la différence est flagrante ?
Non, je ne crois pas. La seule chose qui était flagrante quand j'ai
acheté mon iBook en 2004, c'est qu'à 1200 euros aucun PC ne faisait
moins de 3kg, et aucun ne tenait non plus 6 heures sur sa batterie de
base. Quant au ventilateur, je l'entends tourner moins d'une fois par
mois, c'est également appréciable.
--
Les défauts n'apparaissent qu'après que le programme a passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
Le Tue, 09 Oct 2007 20:19:14 +0200, Nina Popravka a écrit :
Et... avec un autre OS que MacOS, la différence est flagrante ?
Non, je ne crois pas. La seule chose qui était flagrante quand j'ai acheté mon iBook en 2004, c'est qu'à 1200 euros aucun PC ne faisait moins de 3kg, et aucun ne tenait non plus 6 heures sur sa batterie de base. Quant au ventilateur, je l'entends tourner moins d'une fois par mois, c'est également appréciable.
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Emmanuel Florac
Le Mon, 08 Oct 2007 21:16:18 +0200, pehache-tolai a écrit :
Alors, ces bouzins propriétaires qui fonctionnent mal en 64 bits, c'est lesquels ?
Windows 64 n'a paraît il aucun driver et aucune appli, non?
-- Sutor ne ultra Crepidam.
Le Mon, 08 Oct 2007 21:16:18 +0200, pehache-tolai a écrit :
Alors, ces bouzins propriétaires qui fonctionnent mal en 64 bits, c'est
lesquels ?
Windows 64 n'a paraît il aucun driver et aucune appli, non?
Le Mon, 08 Oct 2007 21:48:57 +0200, Eric Masson a écrit :
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou encore amdahl qui ont passé cette barrière depuis un certain temps.
Sans oublier les Unix proprios, pour Solaris au moins depuis 1996, idem je pense pour Ultrix et HP/UX, et IRIX depuis 1994 ou 1995 avec le R8000.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Nina Popravka
On Tue, 09 Oct 2007 21:59:50 +0200, Emmanuel Florac wrote:
Windows 64 n'a paraît il aucun driver et aucune appli, non?
Aucun pb pour 2003, c'est un serveur, on est pas là pour faire pouet pouet. Y a un Vista 64 bits grand public, qui effectivement a relativement peu de drivers, et les applis elles se débrouillent. -- Nina
On Tue, 09 Oct 2007 21:59:50 +0200, Emmanuel Florac
<eflorac@imaginet.fr> wrote:
Windows 64 n'a paraît il aucun driver et aucune appli, non?
Aucun pb pour 2003, c'est un serveur, on est pas là pour faire pouet
pouet. Y a un Vista 64 bits grand public, qui effectivement a
relativement peu de drivers, et les applis elles se débrouillent.
--
Nina
On Tue, 09 Oct 2007 21:59:50 +0200, Emmanuel Florac wrote:
Windows 64 n'a paraît il aucun driver et aucune appli, non?
Aucun pb pour 2003, c'est un serveur, on est pas là pour faire pouet pouet. Y a un Vista 64 bits grand public, qui effectivement a relativement peu de drivers, et les applis elles se débrouillent. -- Nina
Nina Popravka
On Tue, 09 Oct 2007 21:55:13 +0200, Emmanuel Florac wrote:
Non, je ne crois pas. La seule chose qui était flagrante quand j'ai acheté mon iBook en 2004
Petite machine très sympa, en effet :-) -- Nina
On Tue, 09 Oct 2007 21:55:13 +0200, Emmanuel Florac
<eflorac@imaginet.fr> wrote:
Non, je ne crois pas. La seule chose qui était flagrante quand j'ai
acheté mon iBook en 2004
On Tue, 09 Oct 2007 21:55:13 +0200, Emmanuel Florac wrote:
Non, je ne crois pas. La seule chose qui était flagrante quand j'ai acheté mon iBook en 2004
Petite machine très sympa, en effet :-) -- Nina
JKB
Le 09-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Le Mon, 08 Oct 2007 21:48:57 +0200, Eric Masson a écrit :
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou encore amdahl qui ont passé cette barrière depuis un certain temps.
Sans oublier les Unix proprios, pour Solaris au moins depuis 1996, idem je pense pour Ultrix et HP/UX, et IRIX depuis 1994 ou 1995 avec le R8000.
À ma connaissance, Ultrix est 32 bits. Contrairement à OSF/1 et son successeur Tru64.
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 09-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Le Mon, 08 Oct 2007 21:48:57 +0200, Eric Masson a écrit :
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou encore
amdahl qui ont passé cette barrière depuis un certain temps.
Sans oublier les Unix proprios, pour Solaris au moins depuis 1996, idem je
pense pour Ultrix et HP/UX, et IRIX depuis 1994 ou 1995 avec le R8000.
À ma connaissance, Ultrix est 32 bits. Contrairement à OSF/1 et son
successeur Tru64.
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 09-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Le Mon, 08 Oct 2007 21:48:57 +0200, Eric Masson a écrit :
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou encore amdahl qui ont passé cette barrière depuis un certain temps.
Sans oublier les Unix proprios, pour Solaris au moins depuis 1996, idem je pense pour Ultrix et HP/UX, et IRIX depuis 1994 ou 1995 avec le R8000.
À ma connaissance, Ultrix est 32 bits. Contrairement à OSF/1 et son successeur Tru64.
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.
Nina Popravka
On Tue, 9 Oct 2007 21:30:43 +0200, "Thierry B." wrote:
Altivec powaaa, altivec de profundis.
Oui, et les démos de la mort qui tuent utilisaient Altivec à donf. Le pb, c'est qu'IRL Altivec était assez peu exploité. A une époque, fallait même penser à rajouter le plugin idoine à Photoshop à la main, et je soupçonne que même avec ça il n'y avait que quelques filtres qui en tiraient bénéfice. -- Nina
On Tue, 9 Oct 2007 21:30:43 +0200, "Thierry B." <tth@prout.stex>
wrote:
Altivec powaaa, altivec de profundis.
Oui, et les démos de la mort qui tuent utilisaient Altivec à donf. Le
pb, c'est qu'IRL Altivec était assez peu exploité. A une époque,
fallait même penser à rajouter le plugin idoine à Photoshop à la main,
et je soupçonne que même avec ça il n'y avait que quelques filtres qui
en tiraient bénéfice.
--
Nina
On Tue, 9 Oct 2007 21:30:43 +0200, "Thierry B." wrote:
Altivec powaaa, altivec de profundis.
Oui, et les démos de la mort qui tuent utilisaient Altivec à donf. Le pb, c'est qu'IRL Altivec était assez peu exploité. A une époque, fallait même penser à rajouter le plugin idoine à Photoshop à la main, et je soupçonne que même avec ça il n'y avait que quelques filtres qui en tiraient bénéfice. -- Nina
Jérémy JUST
Le Tue, 9 Oct 2007 07:03:19 +0000 (UTC),
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 ? 4 Go, je pense.
Je pense aussi, mais je n'ai jamais trouvé de référence
là-dessus...
En tous cas, c'est le cas sous Solaris/Sparc: les processus 32 bits sont limités à 4Go (je me suis régulièrement heurté à cette limite).
-- Jérémy JUST
Le Tue, 9 Oct 2007 07:03:19 +0000 (UTC),
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 ?
4 Go, je pense.
Je pense aussi, mais je n'ai jamais trouvé de référence
là-dessus...
En tous cas, c'est le cas sous Solaris/Sparc: les processus 32 bits
sont limités à 4Go (je me suis régulièrement heurté à cette limite).
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 ? 4 Go, je pense.
Je pense aussi, mais je n'ai jamais trouvé de référence
là-dessus...
En tous cas, c'est le cas sous Solaris/Sparc: les processus 32 bits sont limités à 4Go (je me suis régulièrement heurté à cette limite).
-- Jérémy JUST
Jerome Lambert
--{ Nina Popravka a plopé ceci: }--
par SJ himself, mais dans la vraie vie, ça m'a jamais percutée...
Altivec powaaa, altivec de profundis.
Quand j'ai acheté mon iMac G5, j'avais fait quelques tests avec john the ripper 1.6.8, et j'obtenais les résultats suivants pour le bench "Traditional DES" (Many salt, c/s real), en compilant avec les options les plus adaptées au processeur-cible: - G5 1.8 GHz : 961049 - Athlon 64 3000+: 717515 - Athlon 2600+ : 621170 - P4 2.8 GHz : 604966 Les autres tests avaient grosso modo les mêmes rapports de performance.
On peut aussi s'en convaincre en allant sur le site distributed.net, où une base de données des performances comparées est maintenue http://n0cgi.distributed.net/speed/ On constate que des "vieux" G4 équipés d'Altivec tiennent encore maintenant la dragée haute à des processeurs x86 bien plus récents. P.ex, avec le RC5-72, on obtient des choses comme (en .10^6): Athlon64 4800+: 22 Core2 Duo 3,6Ghz: 18 G5 2,7Ghz: 20 G4 2GHz: 21
Le problème est que ces bonnes performances dépendent énormément des optimisations apportées au code. Ainsi avec john the ripper, en compilant avec l'option - macosx-ppc32 (32 bits, sans Altivec): 261331 c/s - macosx-ppc64 (64 bits, sans Altivec): 627953 c/s (Et dans ce cas précis on obtient bien le rapport 2 atteint par le passage 32 -> 64 bits évoqué ailleurs dans ce thread) - macosx-ppc32-Altivec (32 bits, avec Altivec): 961049 c/s
Moralité: si le code n'est pas optimisé pour en tirer parti... :-(
--{ Nina Popravka a plopé ceci: }--
par SJ himself, mais dans la vraie vie, ça m'a jamais percutée...
Altivec powaaa, altivec de profundis.
Quand j'ai acheté mon iMac G5, j'avais fait quelques tests avec john the
ripper 1.6.8, et j'obtenais les résultats suivants pour le bench
"Traditional DES" (Many salt, c/s real), en compilant avec les options
les plus adaptées au processeur-cible:
- G5 1.8 GHz : 961049
- Athlon 64 3000+: 717515
- Athlon 2600+ : 621170
- P4 2.8 GHz : 604966
Les autres tests avaient grosso modo les mêmes rapports de performance.
On peut aussi s'en convaincre en allant sur le site distributed.net, où
une base de données des performances comparées est maintenue
http://n0cgi.distributed.net/speed/
On constate que des "vieux" G4 équipés d'Altivec tiennent encore
maintenant la dragée haute à des processeurs x86 bien plus récents.
P.ex, avec le RC5-72, on obtient des choses comme (en .10^6):
Athlon64 4800+: 22
Core2 Duo 3,6Ghz: 18
G5 2,7Ghz: 20
G4 2GHz: 21
Le problème est que ces bonnes performances dépendent énormément des
optimisations apportées au code. Ainsi avec john the ripper, en
compilant avec l'option
- macosx-ppc32 (32 bits, sans Altivec): 261331 c/s
- macosx-ppc64 (64 bits, sans Altivec): 627953 c/s
(Et dans ce cas précis on obtient bien le rapport 2 atteint par le
passage 32 -> 64 bits évoqué ailleurs dans ce thread)
- macosx-ppc32-Altivec (32 bits, avec Altivec): 961049 c/s
Moralité: si le code n'est pas optimisé pour en tirer parti... :-(
par SJ himself, mais dans la vraie vie, ça m'a jamais percutée...
Altivec powaaa, altivec de profundis.
Quand j'ai acheté mon iMac G5, j'avais fait quelques tests avec john the ripper 1.6.8, et j'obtenais les résultats suivants pour le bench "Traditional DES" (Many salt, c/s real), en compilant avec les options les plus adaptées au processeur-cible: - G5 1.8 GHz : 961049 - Athlon 64 3000+: 717515 - Athlon 2600+ : 621170 - P4 2.8 GHz : 604966 Les autres tests avaient grosso modo les mêmes rapports de performance.
On peut aussi s'en convaincre en allant sur le site distributed.net, où une base de données des performances comparées est maintenue http://n0cgi.distributed.net/speed/ On constate que des "vieux" G4 équipés d'Altivec tiennent encore maintenant la dragée haute à des processeurs x86 bien plus récents. P.ex, avec le RC5-72, on obtient des choses comme (en .10^6): Athlon64 4800+: 22 Core2 Duo 3,6Ghz: 18 G5 2,7Ghz: 20 G4 2GHz: 21
Le problème est que ces bonnes performances dépendent énormément des optimisations apportées au code. Ainsi avec john the ripper, en compilant avec l'option - macosx-ppc32 (32 bits, sans Altivec): 261331 c/s - macosx-ppc64 (64 bits, sans Altivec): 627953 c/s (Et dans ce cas précis on obtient bien le rapport 2 atteint par le passage 32 -> 64 bits évoqué ailleurs dans ce thread) - macosx-ppc32-Altivec (32 bits, avec Altivec): 961049 c/s
Moralité: si le code n'est pas optimisé pour en tirer parti... :-(
Nicolas George
Jerome Lambert , dans le message <470bfb42$0$22314$, a écrit :
"Traditional DES" (Many salt, c/s real) P.ex, avec le RC5-72
Du DES ou du RC5, ça peut bien profiter de calcul vectorisé, mais ça fait assez peu intervenir l'architecture du processeur pour les opérations plus complexes, avec des branchements typiquement. Je trouverais plus intéressant un benchmark qui porte sur par exemple ffmpeg.
Jerome Lambert , dans le message
<470bfb42$0$22314$ba620e4c@news.skynet.be>, a écrit :
"Traditional DES" (Many salt, c/s real)
P.ex, avec le RC5-72
Du DES ou du RC5, ça peut bien profiter de calcul vectorisé, mais ça fait
assez peu intervenir l'architecture du processeur pour les opérations plus
complexes, avec des branchements typiquement. Je trouverais plus intéressant
un benchmark qui porte sur par exemple ffmpeg.
Jerome Lambert , dans le message <470bfb42$0$22314$, a écrit :
"Traditional DES" (Many salt, c/s real) P.ex, avec le RC5-72
Du DES ou du RC5, ça peut bien profiter de calcul vectorisé, mais ça fait assez peu intervenir l'architecture du processeur pour les opérations plus complexes, avec des branchements typiquement. Je trouverais plus intéressant un benchmark qui porte sur par exemple ffmpeg.
