Voici les résultats de rapides recherches visant à choisir un processeur Intel[1].
Dans un premier temps, j'élimine les processeurs trop vieux (pentium 4), ligne bas de gamme (Celeron), ou ligne serveur (Xeon et Extreme Edition).
1. comparaison Pentium D / Core 2 Duo
Choisissons pour chacun un processeur de prix égal (prix glannés sur rue-montgallet.com) : Pentium D 950 (3.4 GHz, 198 euros), Core 2 Duo E6400 (2.13 GHz, 200 euros).
D'après Tom's Hardware les performances sont sont appels en faveur du Core 2 Duo :
- encodage MP3 : P-D : 4'10'' ; Core2 : 3'10''
- photoshop, conversion de photos : 2'22'' <-> 1'56''
- word, conversion doc 950 pages en pdf : 3'09'' <-> 2'13''
- framerate UT2004 : 70 <-> 99
2. problème du 64 bits
Le Core 2 est 64 bits (technologie EM64T qui est une copie de la technologie AMD64) - si j'achète un processeur 64 bits, ne serais-je pas gêné avec les paquets binaires proposés souvent en 32 bits uniquement, et les paquets propriétaires en 32 bits uniquement ?
En fait, deux solutions :
- installation de la distro en 32 bits : aucun problème particulier à attendre, et les pertes de performance rencontrées sont de l'ordre de 2 à 3%[2] ; ensuite on installe tout paquet 32 bits sans autre
- installation de la distro en 64 bits : je croyais que la technologie AMD64 avait ceci de bon qu'elle permettait d'exécuter nativement du code 32 bits ? effectivement, cela semble être le cas, il est donc possible d'installer un paquet 32 bits par après, par contre devront être installés aussi tous les paquets en dépendance en 32 bits aussi car un binaire 32 bits ne peut pas exécuter du code de bibliothèque 32 bits, au final on a donc deux glibc par exemple, etc
Voilà. Je me dirige donc gaillardement vers l'achat d'un Core 2 Duo. Ce journal a pour but de partager cette expérience et éventuellement que des pros du hardware corrigiâssent de possibles bourd(asses).
PS : attention cependant pour les windowsiens occasionnels, il semble que les G965 ne seront peut-être pas compatibles DX10, http://www.clubic.com/actualite-38882-idf-intel-g965-directx(...) .
[1] le but est de construire une nouvelle machine autour du chipset G965 après la lecture de http://linuxfr.org/2006/08/10/21185.html et http://linuxfr.org/~clearstream/22361.html
[2] http://www.linuxforums.org/forum/linux-tutorials-howtos-refe(...) parle même d'aucune différence prouvable
Journal choisir son processeur Intel
24
oct.
2006
# Pub...
Posté par Calim' Héros (site web personnel) . Évalué à 2.
# Core 2
Posté par Croconux . Évalué à 6.
Pour ce qui est du 64 bits, c'est comme tu le sens. Je suis sur AMD64 depuis peu tout en 64 bits et je n'ai eu aucun problème. Les seuls programmes emmerdant sont les cochonneries propriétaires qui n'existent qu'en 32 bits (flash, codec WMV9, ...).
Pour le flash (moi ça ne me gêne pas, mais bon) deux solutions : Attendre la version 64 bits de flash 9 ou tenter Gnash. Pour ce dernier, j'ai essayé le plugin pour konqueror et je l'ai viré vite fait. Après être passé par des sites avec des animations flash, j'avais plusieurs instances zombie qui bouffaient tout le cpu.
Pour WMV9, le support a viens d'être ajouté dans la lib ffmpeg, donc les choses s'arrangent.
[^] # Re: Core 2
Posté par Anonyme . Évalué à 3.
Donc trois en fait : un firefox 32bits pour discuter tranquillement avec flash : la compatibilité 64bits/32bits n'est nécessaire qu'entre les programmes et les librairies, pas avec le noyau (via linux32). Résultat : les programmes en 32bits et 64bits tournent parfaitement côte a côte sur un système 64bits.
[^] # Re: Core 2
Posté par Prosper . Évalué à 4.
Et avec ca http://www.gibix.net/dokuwiki/en:projects:nspluginwrapper , ca ferait pas une 4eme possibilité ?
[^] # Re: Core 2
Posté par Croconux . Évalué à 3.
[^] # Re: Core 2
Posté par Calim' Héros (site web personnel) . Évalué à 4.
Ou alors le chrootage est transparant dans le script de lancement du firefox-bin sur gentoo...
La majorité des appli 32bits qui tournent sur un linux 64 peuvent desormait le faire sans chroot si je ne m'abuse, juste avec les lib qui vont bien (on retrouev sur gentoo d'ailleurs un /lib64 et un /lib32)
[^] # Re: Core 2
Posté par Mark Havel . Évalué à 4.
[^] # Re: Core 2
Posté par polytan . Évalué à 2.
Ca se fait tout seul, c'est pas mal stable et en plus on a du flash 9.
[^] # Re: Core 2
Posté par pipo_molo . Évalué à 10.
# Et la carte mère ?
Posté par Alexandre Belloni (site web personnel) . Évalué à 1.
C'est bien beau que le G965 ait des drivers libres mais le pb, c'est que souvent, le VGA n'est tout simplement pas cablé sur la carte mère du coup, c'est pas très utilisable...
[^] # Re: Et la carte mère ?
Posté par gc (site web personnel) . Évalué à 2.
C'est bien beau que le G965 ait des drivers libres mais le pb, c'est que souvent, le VGA n'est tout simplement pas cablé sur la carte mère du coup, c'est pas très utilisable...
Je ne suis pas sûr de comprendre - qu'y aurait-il comme sortie vidéo, s'il n'y a pas de port VGA ? Si tu penses à un port DVI c'est tout aussi utilisable je pense (avec un moniteur DVI s'entend). En tous cas d'après les specs de cette carte mère il y a un port VGA (page 49).
[^] # Re: Et la carte mère ?
Posté par Alexandre . Évalué à 1.
[^] # Re: Et la carte mère ?
Posté par krumtrash . Évalué à 1.
Le problème est plutôt qu'il n'y a pas de DVI alors que les LCD pullulent. :-(
[^] # Re: Et la carte mère ?
Posté par krumtrash . Évalué à 1.
http://www.oakcourt.dyndns.org/%7Eandrew/wiki/index.php/Debi(...)
http://www.phoronix.net/forums/showthread.php?t=145
# 64 bits
Posté par pipo_molo . Évalué à 3.
ubuntu 6.06 en 32bits: 70000 pystones/sec
debian sid en 64bits: 83000 pystones/sec
[^] # Re: 64 bits
Posté par Anonyme . Évalué à 7.
Ce qui serait plus pertinent, ce serait plutôt de comparer à configuration identique :
Debian sid 32 bits vs Debian sid 64 bits
Ubuntu 6.06 32 bits vs Ubuntu 6.06 64 bits
Et pour alimenter de nombreux trolls :
Debian sid 32 bits vs Ubuntu 6.06 32 bits
Debian sid 64 bits vs Ubuntu 6.06 64 bits
:-)
[^] # Re: 64 bits
Posté par Benoît Ganne (site web personnel) . Évalué à 7.
Il y'a 1 ou 2 mois, un pote a fait tourner un calcul : une bête grosse boucle for() qui faisaient 2/3 calculs simples (additions, multiplications) sur des doubles, en C.
Son système est un AMD64 bicoeur avec 1Go de RAM, avec une Gentoo 64bits.
Et bien le calcul était 2 fois plus rapide sur mon Athlon XP 1500+ 512Mo de RAM, 32bits donc.
Pour en avoir le coeur net, on a fait plusieurs tests :
1) Athlon XP 1500, 32bits -> ~ 5-6s
2) AMD64 64bits -> ~ 10s
3) AMD64 32bits -> ~ 4s
Les tests ont été conduits plusieurs fois chacuns, même en single user mode en nice -19 (on sait jamais...), avec différents flags d'optim de gcc (-O0, -O2, etc), et sur des machines différentes (enfin 2 AMD64 bicoeur distincts en fait).
Toujours le même résultat : 2x plus rapide en 32bits (au moins), alors que bêtement, on pensait que se serait plus rapide en 64bits (ben oui un double en C c'est sur 64bits, ie 1 seul registre en 64bits contre 2 en 32bits, toussa).
Bref en cherchant un peu, il s'avère que le 64bits est en général plus lent que le 32bits, et que c'est surtout intéressant pour avoir une précision accrue en calcul scientifique ou pour adresser plus de 4Go de mémoire (gros SGBD, etc).
Donc pour le commun des mortels (comme moi) le 64 bits présente peu d'intérêts pour l'instant.
Si vous avez des infos là-dessus je suis preneur, c'est dur à trouver...
[^] # Re: 64 bits
Posté par Vivi (site web personnel) . Évalué à 3.
Pour ce qui est de la précision en calcul scientifique, ça serait plutôt l'inverse : les 2 archis utilisent des flottants 64 bits (double précision) mais avec le x387 les calculs intermédaires se font avec 80 bits de précision.
[^] # Re: 64 bits
Posté par Benoît Ganne (site web personnel) . Évalué à 1.
Je suis d'accord, mais en l'absence d'autres benchmarks, c'est dur à dire...
Et [2] semble aller dans mon sens.
D'autre part je n'ai toujours pas trouvé d'explication satisfaisante pour ce phénomène. J'ai testé avec valgrind pour les caches hits/miss, le nombre d'instructions éxécutées, etc. et je ne vois toujours pas pourquoi.
Une hypothèse serait que en 64bits, les calculs sont effectués via SSE, j'ai lu ca quelque part mais je n'ai pas vérifié (à prendre avec des pincettes donc) et que AMD est mauvais sur les instructions SSE qui seraient plus lentes que les instructions x387. Bon c'est beaucoup de 'peut-être', mais je n'arrive pas à trouver d'explications.
J'ai d'ailleurs laissé tombé et garde un a priori négatif tant que l'on ne m'aura pas prouver que 64bits c'est vraiment mieux dans la vie de tous les jours :) !
Apparemment on peut utiliser des long long double en 128bits avec certains compilateurs, c'est ce que je voulais dire par 'précision accrue'
[^] # Re: 64 bits
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
Ce bench est pas mal :
http://www.x86-secret.com/articles/cpu/32vs64/32vs64-3.htm
http://www.x86-secret.com/articles/cpu/32vs64/32vs64-4.htm
Et en effet ils disent que en flottants l'opteron est moins bon en x86_64 car les calculs flottants sont faits en SSE mais que par contre sur les entiers ont gagne bien.
Sinon avec john j'avais vu une grosse difference de perfs mais visiblement maintenant ils ont une version SSE2 qui arrive aux mêmes perfs sans avoir besoin du 64 bits (SSE2 est en 128 bits je crois).
[^] # Re: 64 bits
Posté par Vivi (site web personnel) . Évalué à 3.
les jeux d'instructions SSE utilisent des registres 128 bits (les registres XMM), alors que MMX utilise des registres 64 bits. SSE1 ne traite que des flottants simple précision, pas les doubles. SSE2 a des instructions pour flottants double précision. L'archi x86_64 a 2 fois plus de registres 128 bits disponibles pour le SSE que l'archi 32 bits.
En mode 64 bits, le calcul de flottant "normal" se fait en SSE2 mais il est éventuellement possible d'utiliser le vieux FPU avec l'option -mfpmath=387 de gcc.
Pour john je comprends pas, c'est du calcul entier non ? (c'est john the ripper, le password cracker ?).
Pour les long double (un seul long suffira :)), ils font 96 bits en archi 32 bits (mais le FPU ne calcule qu'avec 80 bits), 128 en archi 64 bits. Mais y'a pas d'instructions pour le calcul direct en quadruple-précision je crois, c'est fait en software.
# Choisir son processeur Intel et sa distrib x86-64
Posté par Gwenole Beauchesne . Évalué à 2.
Concernant, les performances, le message en [2] n'a pas de sens. Recompiler pour x86_64 optimise de facto pour cette architecture (data 64-bit, deux plus de registres, etc.). Il n'y a pas d'optimisation "64-bit" à faire. Le gain de performances typiquement constaté est de l'ordre de +20% (depuis 4+ ans que j'utilise et compile avec).
Concernant les packages 32-bit, urpmi te les installera sans problème si tu fournis une source 32-bit et passe l'option --strict-arch (pour les updates). Il n'y a pas de soucis, ça installe juste les libs 32-bit nécessaires. Au passage, la glibc de Mandriva Linux est naturellement biarch.
Concernant le support i965, sache qu'il existe actuellement 2 problèmes dans Mesa. Un trivialement fixable (pb d'aliasing dans le sens règles du C), un autre qui l'est beaucoup moins (pb de textures dans certains cas). Je ne connais pas les performances de la puce, apparemment UT2004 est jouable, mais je ne sais pas si c'est un jeu gourmand non plus...
# Comparatif plus large
Posté par redfoxx . Évalué à 1.
Sans vouloir lancer un nouveau troll AMD vs. Intel, quelqu'un aurait sous la main des liens vers des comparatifs entre les différents processeurs actuellement disponible sur le marché?
[^] # Re: Comparatif plus large
Posté par darklumina . Évalué à 2.
comparatif AMD / Intel P4 / Intel C2D
http://www.linuxhardware.org/article.pl?sid=06/08/22/0415251
sinon c'est vrai que je me pose aussi la question du support 32/64bits sous linux et du réel avantage dans la vie de tous les jours (je fais pas d'encodage 18h/24).
avoir toutes les lib en double, je trouve que c'est moyen.
Après si c'est juste pour dire que ton systeme a été compilé spécial 64bits sous [mettre le nom de la distrib] pour 5% de perf en plus et 10% de fonctionalité en moins (ex : pas de plugin flash 64bits) oui d'accord lepropriocaymal toussa. mais moi je cherche avant tout un systeme qui marche et ensuite si je peux l'avoir en libre tant mieux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.