Tom's Hardware a eu la bonne idée d'inclure un test Linux assez amusant qui consiste à compiler le kernel. Sauf que la, c'est tellement rapide qu'il fait une mesure en nombre de noyaux Linux compilés à l'heure, intéressante nouvelle unité de mesure !
"Ma machine fait du 34 noyaux à l'heure" Ca sonne quand même mieux que "Ma machine fait 2400 BogoMips" :-)
Accessoirement, Intel n'assure pas trop sur ce coup là...
Aller plus loin
- L'article (3 clics)
- Le graphique comparatif (4 clics)
- Tom's Hardware (2 clics)
# Faire pareil
Posté par Anonyme . Évalué à 0.
Ce serait interessant d'avoir leur config file pour pouvoir faire exactement le meme test..
[^] # Re: Faire pareil
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
Et la version du noyau =)
[^] # Re: Faire pareil
Posté par Olivier Jeannet . Évalué à 1.
> et la version du noyau
Ben là c'est pas difficile, suffit de lire le test : "SuSE Linux 6.4, Kernel 2.2.14, THG benchmarking kernel, gcc 2.95.2" . (cf http://www.tomshardware.com/cpu/00q4/001120/p4-18.html(...(...)) )
C'est justement ma distribution et ma version de noyau, faudrait que je recompile pour voir (je n'ai qu'un "modeste" K6-3 400 MHz). Si ça se trouve il prend la config par défaut et fait juste un "make zImage". Comme le faisait remarquer quelqu'un plus haut, il faudrait savoir ce qu'il fait exactement. Quelqu'un pour poser la question ? (si j'y pense je le ferai demain)
# 34 noyaux à l'heure :o)
Posté par poil oq . Évalué à 1.
le problème c'est qu'avant les noyaux, faut avaler les cerises ou les pruneaux, et dans les deux cas, attention les traces de pneus. :o)
Sinon les BOGOMIPS je trouvais ça marrant, en vrai ça signifie qqchose ???
[^] # Re: 34 noyaux à l'heure :o)
Posté par Anonyme . Évalué à 0.
regarde, il y a un bogomips mini howto pour avoir tous les renseignements sur cette superbe unité de mesure
[^] # Re: 34 noyaux à l'heure :o)
Posté par Anonyme . Évalué à 0.
Le bogomips ne sert a rien, tout au plus a verifier que sa CPU et sa mémoire cache (interne) est bien celle qui figure sur la facture.
[^] # Re: 34 noyaux à l'heure :o)
Posté par Olivier Jeannet . Évalué à 1.
> Sinon les BOGOMIPS je trouvais ça marrant, en vrai ça signifie qqchose ???
Ca sert à calibrer le processeur pour pouvoir créer des boucles d'attente très courtes et très précises, qui sont utilisées en particulier pour les drivers. Quand une attente est longue (par rapport au kernel, du style plusieurs milli-secondes), on endort la tâche proprement avec un sleep(), mais on ne peut pas le faire pour des attentes très courtes, comme quelques micro-secondes (ou moins). On utilise donc des boucles d'attente actives pour ce faire, et les bogoMIPS permettent de calibrer ces boucles.
[^] # Re: 34 noyaux à l'heure :o)
Posté par poil oq . Évalué à 1.
merci
# Bizarre
Posté par Anonyme . Évalué à 0.
C'est bizarre, le test est sorti aujourd'hui sur http://www.hardware.fr .
En tout cas, les rares tests où le P4 est devant, il pousse le vice jusqu'à l'overclocker alors qu'il est déjà à une fréquence plus élevée...
Et franchement, il attend un miracle des instructions SSE2, mais si le proc rame à 1.4 Ghz, un programme utilisant aussi bien 3DNow ! que SSE2 devrait montrer la supériorité de l'Athlon, même à fréquence inférieure.
Donc, je ne vois pas ce qu'il y a de bien excitant dans ce processeur, à part qu'il faut débourser au moins 12000 francs pour upgrader (boîtier ATX nouvelle formule, proc, mémoire RDRAM, CM => cf www.hardware.fr)
--
Yachar
[^] # Re: Bizarre
Posté par Anonyme . Évalué à 0.
bah, c'est toujours moins cher qu'un mac..
et comme un mac, c'est toujours plus pourri qu'un bon biproc.
[^] # Re: Bizarre
Posté par Anonyme . Évalué à 0.
Oh le beau troll.
[^] # Re: Bizarre
Posté par Anonyme . Évalué à 0.
En ce moment pas tellement, Appleu fait des rédos sur les G4 bi-pro et de toute façon le P4 restera solitaire au moins jusqu'à la fin du printemps.
[^] # Re: Bizarre
Posté par Jak . Évalué à 1.
Ben, justement, le miracle viendra bien des instructions SSE2, c'est là qu'Intel veut pousser, et c'est pour cela qu'ils n'ont pas optimisé le x87 (qui, au passage, est une vraie merde à optimiser). C'est peut-être un moyen de changer en douceur de jeu d'instructions. Et puis c'est vrai que le SSE2 peut donner des résultats exceptionnels, c'est dans cette optique qu'il a été conçu, mais comme toujours, il va falloir attendre les compilos optimisés et tout ça...
De toute façon, la conclusion est partout la même : 'faut pas l'acheter, car le socket 423 n'est pas viable.
[^] # Re: Bizarre
Posté par Anonyme . Évalué à 0.
he he :)
Ils sont victimes du fameux 'Reality Distorsion Field' de notre ami St S.P. Jobs ;-).
Depuis 1 an et demi la pomme fait que des benchs utilisant a fond les unités de calcul vectoriel du G4 (qui sont sacrément efficaces cela dit), ce qui est la seule et unique façon pour un G4 de botter les fesses d'un PIII au double de la fréquence (parce que avec des benchs plus "classiques", heuu, comment dire, ...).
Donc intel essaie de muscler à fond ses unités de calcul vectoriel. Ca sera intéressant de voir ce que donne ces benchs entre le P4 et le G4 .
Au passage les performances médiocres de la FPU, c'est peut-être une façon de préparer le passage de témoin vers l'itanium pour les PCs utilisés comme stations graphiques (3D, Vidéo et Autres). Ce qui signifierait que les performances en flottant de l'Itanium ne serait stratosphériques, mais bon tout le monde s'y attendait...
# Unification des benchs
Posté par Olivier Cahagne . Évalué à 1.
A mon avis, c'est plutot pour unifier les graphes des benchs: higher is better.
Il calcule encore la compil' d'un kernel et le ramene a 1 heure.
En revanche, c'est juste une indication car les kernels ne possedent que recemment des optimisations pour P-III (SIMD) et encore plus pour P-IV (test11).
[^] # Re: Unification des benchs
Posté par Anonyme . Évalué à 0.
pour les noyaux, vous voulez dire, n'est-ce pas ?
# Drôle de bench...
Posté par Antoine Labour . Évalué à 1.
Ça ne me paraît pas une méthode très efficace pour comparer des vitesses de processeur... La compilation d'un noyau n'est pas bêtement un calcul, c'est surtout beaucoup de lectures et d'écritures sur le disque.
Personnellement, quand je compile mon noyau, je donne à make l'option -j 5 pour lancer 5 processus concurrents. Et le temps de compilation est facilement 2 à 3 fois plus court, alors que je suis sur un monoprocesseur (C300A surcadencé à 483 Mhz :). Ça veut bien dire que la compilation est loin de prendre la totalité du temps machine, et que le système passe une grande partie de son temps à attendre les lectures/écritures sur le disque.
À mon avis un meilleur test est le client RC5, en comptant le nombre de clés par secondes, on mesure vraiment la capacité de calcul du processeur. Et le fait que ce soit un algorithme compliqué sur des données de petite taille nous assure qu'on ne sera pas trop perturbé par les temps d'accès mémoire...
[^] # Re: Drôle de bench...
Posté par Olivier Jeannet . Évalué à 1.
> Ça ne me paraît pas une méthode très efficace pour comparer des vitesses de processeur... La compilation d'un noyau n'est pas bêtement un calcul, c'est surtout beaucoup de lectures et d'écritures sur le disque.
C'est vrai, mais en fin de compte ce qui est intéressant c'est de voir à quel point un processeur (censé être plus puissant) accélère le vrai travail (comme une compilation), au lieu d'un benchmark qui est toujours un peu artificiel. Cela dit, voir qu'on dépasse le GFLOPS sur un simple benchmark c'est toujours sympa bien sûr :-)
[^] # Re: Drôle de bench...
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Dans tous ses tests, c'est le même disque qui est utilisé et pourtant, on constate pas mal de différences d'un processeur à l'autre. C'est la preuve que son test n'est pas si mauvais que cela.
En plus, Linux a l'intéressante manie de tout cacher en Ram et comme les configs testées ont 128 MB, les sources comme gcc sont cachés en Ram, il y a très peu d'IO disque pendant une compil.
[^] # Re: Drôle de bench...
Posté par Sébastien Koechlin . Évalué à 1.
Les lectures sont cachées, mais toutes les écritures sont faites réellement et ne restent pas bien longtemps en mémoire.
Il me semble avoir lu quelque part que l'age maximal d'un cache en écriture sous Linux est de 3 secondes. Donc au bout de 3 seconde, Linux écrit les fichiers produits, et met à jour tout le système de fichier, les inodes, les bitmaps etc... L'écriture de méta-données est toujours un peu lourde pour garantir quelque chose de cohérent en cas de crash en cours d'écriture.
[^] # Re: Drôle de bench...
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Oui, m'enfin écrire quelques .o sur le disque, ça n'est pas bloquant pour les performances. Surtout que l'écriture s'effectue quelques instants aprés la requète effective.
C'est un bon test finalement : il faut de la rapidité processeur et de la bande passante mémoire. Ca fait pas mal de lectures (cachées) et un peu d'écriture. C'est assez représentatif.
[^] # Re: Drôle de bench...
Posté par Antoine Labour . Évalué à 1.
C'est peut-être un bon test de performance globale de la machine, mais c'est un mauvais test de processeur ! Et les différences montrées sur le graphique sont plutôt faibles : quand je suis passé d'un P200 (non mmx) à un C483A, le gain sur RC5 a été de 250 Kkeys/s à 1,20 Mkeys/s : il ne s'agit pas d'un gain de quelques pourcents !
[^] # Re: Drôle de bench...
Posté par Serge Rossi (site web personnel) . Évalué à 1.
C'est un mauvais exemple puisque RC5 profite justement du MMX.
Ta machine va presque 5 fois plus vite pour cette appli précise mais dans le cas général, ça doit être plus proche de 2 à 3 fois (puisque bien peu de "vraies" applis utilisent MMX).
# P 90
Posté par Anonyme . Évalué à 0.
Moi mon P 90 il lui faut quelques heures pour compiler un noyau 2.2.17 avec tous les modules et quelques patches, mais il marche tres bien ! :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.