SMPFR

J'ai fait quelques tests de compilation sous Linux. Ca peut interesser ceux qui se demandent si upgrader (vers) un bi-proc vaut le coup :

Ma config :
-> Carte mere Tyan Tiger MPX
-> 512Mo RAM standard
-> Carte controleur IDE Promise Ultra TX2 133
-> Disque dur IBM 120GXP 120Go
-> O.S. : Linux mandrake 9.0
-> Noyau 2.4.19mdk
-> Compilateur C : GCC 3.2

*** 1er test : compilation du noyau : meme test que celui effectué sur hardware.fr avec le pentium 4 3.06GHz HyperTreadé ( voir http://www.hardware.fr/articles/445/page6.html )
-> temps de compilation avec 2 processeurs AMD MP2000+ : 189s (3m 9s)
-> temps de compilation avec 1 processeur AMD MP2800+ : 264s (4m 24s)
-> temps de compilation avec 2 processeurs AMD MP2800+ : 136s (2m 16s)
-> temps de compilation avec 1 processeur Pentium 4 3.06GHz HT : 188s (3m 8s)

*** 2eme test : compilation de xine-lib-1-rc3a ( lecteur de videos dispo sur http://xinehq.de )
-> temps de compilation avec 2 processeurs AMD MP2000+ : 367s (6m 7s)
-> temps de compilation avec 2 processeurs AMD MP2800+ : 298s (4m 58s)

Conclusions :
-> Pour faire de la compilation ou de l'encodage de filsm, entre un pentium 4 HyperThreadé et un bi proc AMD il n'y a pas photo, à pseudo frequence égale, la solution bi-AMD est bien plus rapide que l'hyper-threading d'intel. De plus, on peut facilement s'en tirer pour moins cher avec un bi-AMD qu'avec un seul pentium HT.

-> A la question le bi-proc apporte t'il quelque chose, on peut voir que le temps de compilation est quasiment divisé par 2 entre un mono-proc et un bi-proc ! (136s contre 264s). Ceci dit, ce n'est pas vrai pour tout. Pour l'encodage de filsm, le gain est de 1.5 environ. Pour la bureautique, on ne voit pas la difference.

-> Enfin, faut-il upgrader un bi 2000+ pour un bi 2800+ (ce que j'ai fait), je repondrai encore que ca depend ce qu'on fait avec son PC. Pour la compilation, le gain est proportionel à la frequence des procs (soit ici : 1667MHz -> 2133MHz = 28% de gain, soit grosso-modo ce que je gagne en temps de compil : 189s -> 136s)

sympa comme test

dommage que le 760MP ne supporte pas la DDR400 ...

Ben il a déjà à gérer 2 canaux FSB 133 DDR pour les procs et derrières faut rajouter la mémoire, l'AGP et le canal vers le southbridge

bah ouai net! en plus il est pas tout jeune ce shipset!!!

mais j'avou que si il gerait le double canal en fsb 200 se serais une balle!!!!

quoi? hein?! qui a dit que j'avais rever d'un NF2 en bicpu?

entre une vrai platform smp avec des xp barton mod, ou 1 seul p4C, vous preferez quoi ?

un vrai bi-cpu

même si ca fait tro pde bien a edf

[:canaille] Plus l'temps passe, plus j'me d'mande si j'vé poa passer sous debian :/

Suis sous debian

J'en suis super content. Je trouve cette distrib terrible.
J'ai aussi 2 postes en FreeBSD pour le boulot mais j'aime moins pour des raisons de productivité surement car je suis moins à l'aise... (On passe souvent un temps fou sur des merdes et à compiler tout ce qui bouge )

Par contre pour les compils des noyaux et autre, faut penser à utiliser l'option -j avec make

Attention, contrairement à ce qui est écri dans l'article HFR, le chiffre passé argument de cette option n'est pas le nombre de processeurs présents dans la machine mais bien le nombre de jobs à effectuer en parallèle.

Il est conseillé -j4 avec un P4HT et -j8 avec une machine bi CPU genre Bi athlonsMP etc... (de mémoire)

Donc à tester

Hum. Je tiens simplement à préciser qu'un tel test, sous "Mandrake", n'est pas des plus significatifs. Cette distribution ayant la fâcheuse tendance de bourrer le noyau inutilement, je ne serais pas supris de noter de bien meilleurs résultats avec une distribution plus "professionnelle" tel "Slackware" ou "Debian", ou encore, mieux, "FreeBSD" (qui n'est pas, en soit, "Linux", mais mieux).

Alors on va commencer par le début : Mandrake a une "facheuse tendance de bourrer le noyau inutilement" :
Mandrake utilise le noyau officiel, sur lequel ils font de très legeres modifications qui ne changeront certainement pas le temps de compilation
Ce qu'ils font chez Mandrake c'est que dès le départ ils compilent une grande partie des modules disponibles dans le noyau, afin de supporter un maximum de matériel ; si c'est à ca que tu fais reference alors bien sur re-compiler un noyau c'est plus long sur Mandrake que sur Slackware, mais au final tu as plus de choses aussi !

Concernant les Debian, Slackware, ... qui font plus "professionelle" : oui ca fait mieux de dire je tourne sous Slackware que de dire je tourne sous Mandrake. Mais à part le coté "ca le fait", une Mandrake est beaucoup plus facile à configurer qu'une Slackware ou qu'une Debian. Mandrake a des outils de configuration unifiés (un seul outil : drakconf pour configurer pratiquement tout le systeme).
Mandrake n'enleve pas les firmware contenus dans le noyau. Il faut aimer s'embeter pour choisir une Debian, ils ont la facheuse tendance à supprimer tout ce qu'ils considerent comme pas complétement libre, du coup tu te retrouves avec un noyau incomplet, un lecteur vidéo qui a perdu toutes ses fonctionnalités (mplayer), ...

Je passe sur le FreeBSD qui est mieux parce qu'il est mieux ; j'ai jamais essayé. Ceci dit je ne vois pas très bien le rapport avec le test du temps de compilation d'un noyau Linux, vu qu'on ne pourrait meme pas le faire

1. des légères modifications qui font que les lecteurs dvd liteon se flashent tout seul (d'accord, c'est un problème du coté lite on, mais seul la mandrake a posé ce problème)
2. ca a l'énorme inconvénient d'etre un outil graphique, qui implique donc qu'une mandrake doit forcément etre utilisé comme pc desktop, pas comme debian avec laquelle tu peux quasi tout faire
2.1 dpkg-reconfigure est ton ami (et pour la slack, faut aussi etre pas bien dans sa tete)
2.2 debian ne supprime RIEN, vu que ce qui n'est pas libre, N'est PAS dans le noyau.
2.3 pour mplayer et co, t'as des repository officieux, comme celui de nerim (et il a juste perdu les codes proprios)
3. rien ne t'empeche de compiler un kernel linux sur du bsd. ya juste qu'il bootera pas avec du bsd derrière

Je passe sur le FreeBSD qui est mieux parce qu'il est mieux ; j'ai jamais essayé. Ceci dit je ne vois pas très bien le rapport avec le test du temps de compilation d'un noyau Linux, vu qu'on ne pourrait meme pas le faire

C'est sur que c'est constructif comme justification "FreeBSD est mieux parce qu'il est mieux" ...

Je ne parlais pas de la compilation noyau, mais bien, en apparté, de l'installation de chaque package que tu veux installer et qui prends un temps fou. Question productivité c'est la merde, à part d'utiliser pkg_ad, mais alors là tu t'éloignes de la philosophie ... ou de stocker sur un serveur tes compilations déjà réalisées. Là encore tu t'éloignes de la philosophie de départ... car les applis ne sont plus compilées en ft de ton environnement.