Ubuntu-fr

Cathou

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Soit, essayons:

sous chacun de mes noyaux 386, k7-smp et 686-smp, je lance glxgears dans un terminal:

glxgears -iacknowledgethatthistoolisnotabenchmark

et ça donne:

noyau 386:
41756 frames in 5.0 seconds = 8351.165 FPS
41814 frames in 5.0 seconds = 8362.628 FPS
41818 frames in 5.0 seconds = 8363.594 FPS
41817 frames in 5.0 seconds = 8363.207 FPS
41817 frames in 5.0 seconds = 8363.295 FPS
41696 frames in 5.0 seconds = 8339.148 FPS

noyau k7-smp:
41815 frames in 5.0 seconds = 8362.828 FPS
41834 frames in 5.0 seconds = 8366.603 FPS
41839 frames in 5.0 seconds = 8367.741 FPS
41839 frames in 5.0 seconds = 8367.636 FPS
41838 frames in 5.0 seconds = 8367.458 FPS
41837 frames in 5.0 seconds = 8367.286 FPS

noyau 686-smp:
41809 frames in 5.0 seconds = 8361.699 FPS
41824 frames in 5.0 seconds = 8364.719 FPS
41829 frames in 5.0 seconds = 8365.699 FPS
41824 frames in 5.0 seconds = 8364.694 FPS
41832 frames in 5.0 seconds = 8366.331 FPS
41829 frames in 5.0 seconds = 8365.605 FPS

Ce qui donne des moyennes de fps:

noyau 386 -> 8357.173

noyau k7-smp -> 8366.592

noyau 686-smp -> 8364.791

J'appelle pas ça un changement radical de fps

je pense que ca reste valable pour voir l'apport du kernel...

Ben je suis pas d'accord, au contraire. A mon avis, le direct rendering du driver nvidia doit probablement se faire en dma vers la carte vidéo, et dans ce cas le noyau, quel qu'il soit, est bien tranquillou..

Du reste, j'ai bien mis en évidence chez moi que le noyau 386 est catastrophique (utilisation d'un seul coeur de mon amd). Si tu étais dans le vrai, je devrais constater une chute significative des fps pour ce noyau..

Quand je parlais de 'faire gaffe', c'était justement pour illustrer le b.a ba de la métrologie: savoir ce qu'on mesure.

glxgears -iacknowledgethatthistoolisnotabenchmark

"Chers téléspectateurs, un indice se cache dans cette ligne de commande. Saurez-vous le retrouver?"

Dernière modification par Cathou (Le 19/05/2006, à 09:11)

dylhoxic

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Bon j'ai pas de pc pour faire le test mais je le ferais ce soir... Il me semblait bien que les fps avait pas mal augmenté lorsque j'étais passé d'un noyau 386 à k7

Ben je suis pas d'accord, au contraire. A mon avis, le direct rendering du driver nvidia doit probablement se faire en dma vers la carte vidéo, et dans ce cas le noyau, quel qu'il soit, est bien tranquillou..

Je doute que ce soit aussi simple. Une application 3D utilise à la fois le CPU et la carte graphique.

Par exemple, en bas de cette page :
http://download.nvidia.com/XFree86/Linu … dix-e.html

Quand je parlais de 'faire gaffe', c'était justement pour illustrer le b.a ba de la métrologie: savoir ce qu'on mesure.

glxgears -iacknowledgethatthistoolisnotabenchmark
"Chers téléspectateurs, un indice se cache dans cette ligne de commande. Saurez-vous le retrouver?"

Oui c'est connu glxgears n'est pas un benchmark mais je l'avais utilisé lors d'un test rapide pour me donner une idée...
Peut-être avec quake3 alors ?

Dernière modification par dylhoxic (Le 19/05/2006, à 09:35)

---

Kubuntu++

alexmic

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Porc -> proc : désolé je ne tappe qu'avec six doigts De plus, ma préférence serait plutôt vers les cochones... Hum bon, bref.

Désolé, j'avais promis de faire un effort pour garder le niveau du thread, mais voilà c'est mon anniversaire...:cool:

Quake3 pour benchmarker? A mon avis, avec de tels processeurs, la différence sera infime. Quake 3 étant prévu pour tourner sur un PII 266Mh (source:jeuxvideo.com), et étant seulement optimisé MMX (ce que font les trois noyaux).

Bref pour moi: I Acknoledge that quake III cannot be considered as a kernel benchmark.

Cathou : il me semble que ton bench fait une forte place au multithreading, favorisant ainsi les kernels smp. C'est interressant mais en mon sens pas suffisant: peux-tu refaire les tests sur un calcul compliqué ne demandant qu'un thread? Un truc du type la racine 37 ème d'une factorielle de 50 (je sais pas si le double prendra factorielle 50... mes connaissances en c sont limitées)

---

OMG Lawl pwnd rofl... Plaît-il?

dylhoxic

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Quake3 pour benchmarker? A mon avis, avec de tels processeurs, la différence sera infime. Quake 3 étant prévu pour tourner sur un PII 266Mh (source:jeuxvideo.com), et étant seulement optimisé MMX (ce que font les trois noyaux).

Bref pour moi: I Acknoledge that quake III cannot be considered as a kernel benchmark.

Mouarff je me suis gourré je voulais parler de doom3 en fait ...

---

Kubuntu++

Lestat the vampire

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Je reprends le fil de la discussion ayant d'autres chats à fouetter entre temps...
Je trouve tout cela très interessant, comme quoi finalement, les dévelopeurs d'ubuntu ont peut etre préféré ne pas optimiser à 100% les noyaux pour nos chers X2...mais d'après ce que raconte cathou, la config actuelle suffirait pour 99.9% des utilisateurs...non ??
Bref, je vais poser une question con qui va bien foutre la merde...:P est-ce que vous avez testé tout ca sur les nouveaux noyaux de Dapper ??? (et oui il faut bien se mettre à jour et dans une dizaine de jours, la question sera carrément d'actualité !!) parce que moi j'adore aussi faire mumuse avec ubuntu !! mais si les problèmes sont déjà réglés avec les nouvelles versions...ca m'amuse beaucoup moins...:rolleyes:

En tout cas félicitations à tous pour ce thread, c vrai qu'il est très interessant !! (malheureusement, ce n'est pas moi qui vais relever le niveau étant largué depuis bel lurrette !! mais j'adorerais aussi tester des trucs de fou !! mais les journées ne font que 24h...et il faut bien dormir un peu de temps en temps...)
A+

Cathou

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Ben je suis pas d'accord, au contraire. A mon avis, le direct rendering du driver nvidia doit probablement se faire en dma vers la carte vidéo, et dans ce cas le noyau, quel qu'il soit, est bien tranquillou..

Je doute que ce soit aussi simple. Une application 3D utilise à la fois le CPU et la carte graphique.

Heu.. c'est pas ce que j'ai dit: le cpu doit sûrement être pas mal sollicité, mais le noyau ça m'étonnerais. En fait, je fais une différence entre stress du noyau et stress du cpu. D'après moi, c'est pas la même chose!

il me semble que ton bench fait une forte place au multithreading, favorisant ainsi les kernels smp.

C'est normal, au départ je cherchais à comparer différents noyaux smp. Et puis on est sous un O/S multitâches. En revanche, il ne favorise pas plus les noyaux smp que les autres noyaux! Si j'ai qualifié le noyau 386 de 'catastrophique', c'est parce que dans mon /proc/cpuinfo j'avais qu'un seul des 2 coeurs de détecté, mais à part ça c'est un très bon noyau.. pour les procs monocores

peux-tu refaire les tests sur un calcul compliqué ne demandant qu'un thread?

C'est marrant que tu demandes ça, parce que les tests fpu, c'est les premiers que j'ai écrits, pendant que mon noyau custom était encore en train de compiler. Voila le prog de base:

/* fpu.c */

#include <stdlib.h>
#include <math.h>

#define TABSIZE 5
#define NLOOP 100000000
#define VMAX 1e20

int main(int argc, char**argv)
{
   int i,c;

   double vals[] = {1.0, 2.0, 3.0};

   double *dtab = malloc(TABSIZE*sizeof(double));

   if(!dtab) return 1;

   for(i=0; i<TABSIZE; ++i)
   {
      dtab[i] = vals[i%3];
   }

   for(c=0; c<NLOOP; ++c)
   {
      for(i=0; i<TABSIZE; ++i)
      {
         dtab[i] = sqrt(dtab[(i+1)%TABSIZE]*dtab[(i+2)%TABSIZE]*dtab[(i+3)%TABSIZE]*dtab[(i+4)%TABSIZE]);

         if(dtab[i]>VMAX) dtab[i]/=VMAX;
      }
   }

   free(dtab);
   return 0;
}

Je l'ai compilé de 3 manières différentes:

du code 386, avec utilisation d'instructions fpu 387 'normales':
gcc -mtune=i386 -m32 -mfpmath=387 -lm fpu.c -o fpu387

du code AMD, en forçant l'utilisation d'instructions SSE:
gcc -mtune=k8 -m32 -mfpmath=sse -mmmx -msse -msse2 -m3dnow -lm fpu.c -o fpuSSE

la même chose, avec en plus de l'optimisation de code:
gcc -mtune=k8 -m32 -mfpmath=sse -mmmx -msse -msse2 -m3dnow -O2 -lm fpu.c -o fpuSSEopt

En lançant successivement les programmes fpu387, fpuSSE et fpuSSEopt dans chacun des 4 noyaux, voila ce que ça donne en temps d'exécution:

           386      k7-smp      686-smp     64x2-custom

fpu387     80.82    81.40       80.76       80.82
fpuSSE     48.70    49.38       49.38       48.91
fpuSSEopt  15.72    15.50       15.55       15.50

Avec de tels tests monothreads, le programme utilisé se met sur un seul coeur, et comme on peut le voir le noyau 386 n'apparaît pas particulièrement désavantagé. De la même manière qu'avec le test glxgears de dylhoxic, en fait.

En revanche, c'est pas pareil si on lance plusieurs tests en parallèle. Mon programme lanceur:

/* stress.c */
/* compil: gcc -mtune=i586 -m32 stress.c -o stress */

#include <stdlib.h>
#include <stdio.h>

#include <unistd.h>

#define NPID 7

#define PROG "./fpuSSE"

/*
#define PROG "./fpu387"
#define PROG "./fpuSSEopt"
#define PROG "./imulti386"
#define PROG "./imultiK8"
*/

int main(int argc, char **argv)
{
   int i;
   pid_t pids[NPID];
   pid_t currpid;
   int remaining;

   for(i=0; i<NPID; ++i)
   {
      pids[i] = fork();

      if(pids[i]==0)
      {
         printf("fork et lancement: %i ..\n", i);
         execl (PROG, PROG, NULL);	
      }
      else  if(pids[i]==-1)
            {
               fprintf(stderr, "echec de fork: %i\n", i);
            }
   }

   remaining = NPID;

   do
   {	
      int status;
      
      currpid = wait(&status);

      for(i=0; i<NPID; ++i)
      {
         if(currpid==pids[i])
         {
            if(!status)
               printf("retour normal du fork %i\n", i);
            else
               printf("retour du fork %i avec statut: %i\n", i, status);

            remaining--;
         }
      }
   }
   while(currpid!=-1);

   if(!remaining)
      printf("tous les forks ont rendu la main\n");
   else
      printf("merdouille\n");

   return 0;
}

Le résultat des benchs (7 forks):

           386      k7-smp      686-smp     64x2-custom

fpu387     561.39   281.13      281.03      280.94
fpuSSE     340.30   169.28      169.91      169.73
fpuSSEopt  105.44   52.63       52.83       53.10

En prenant comme référence le temps le plus long, ça donne:

           386      k7-smp      686-smp     64x2-custom

fpu387     100%     50%         50%         50%
fpuSSE     61%      30%         30%         30%
fpuSSEopt  19%      9%          9%          9%

Ce qui amène les remarques:

1) Le noyau 386 se prend une méchante claque: normal, il doit gérer le multithread sur un seul coeur.
2) Les 3 noyaux smp sont équivalents (du point de vue perfs)
3) Ce qui compte pour les perfs, c'est la manière dont l'applicatif est codé.

En bref, c'est les mêmes conclusions que pour le bench de multiplications entières que j'avais déja décrit.

Cathou

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Pour illustrer le tableau final de mon dernier post, et histoire d'enfoncer le clou ...

- Si on imagine d'utiliser une appli qui fait du calcul flottant intensif, par exemple POVray.

- Si on imagine une gourdasse qui a un 64x2 et qui est restée en noyau 386.
( C'était mon cas en tout début de thread avant que Lestat vienne me donner un coup de main )

- Si on imagine d'autre part un gros nerd velu qui a également un 64x2 mais qui passe son temps à tweaker son noyau smp.

Si pour une scène 3D donnée, le rendu de POVray se fait en 1h40 chez la gourdasse, il se fait en 50 minutes chez le nerd.

Si maintenant la gourdasse récupère les sources de POVray et les recompile (par exemple via apt-build) en utilisant des options du genre:
-mtune=k8 -m32 -mfpmath=sse -msse2 -O2

Ben à la suite de ça, le rendu de la scène se fera en 19 minutes chez la gourdasse, c'est à dire beaucoup mieux que chez le tweakeur de noyau

est-ce que vous avez testé tout ca sur les nouveaux noyaux de Dapper ???

Je pense pas passer à dapper avant plusieurs mois. Je sais bien que c'est très 'hype' mais ça m'intéresse pas. C'est un peu comme les trolls gnome/kde ou les guéguerres de distros, j'arrive pas à m'intéresser à ça

Malgré tout je pense que mes conclusions, dans la mesure où elles sont valables, le sont aussi sous dapper.

mais les journées ne font que 24h...

Ouais hélas.. D'ailleurs il fait super beau, je vais me faire une ballade en rollers. @+

Dernière modification par Cathou (Le 20/05/2006, à 14:37)

dylhoxic

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Bon pas de gain de performance avec glxgears et autres applictions 3D chez moi. C'est même bizarre mais avec un noyau 386 ca va même légèrement plus vite...Ca doit venir de ma config :/.

Bon Mea culpa alors et bonne continuation pour ces benchs que je continuerai à suivre avec attention...

---

Kubuntu++

alexmic

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

Interressant!

-mtune=k8 -m32 -mfpmath=sse -msse2 -O2 sont des paramètres valables pour toutes les compilations?

---

OMG Lawl pwnd rofl... Plaît-il?

Cathou

Re : [Résolu] Mon nouveau noyau 686-smp saura faire.. ?

bonne continuation pour ces benchs

J'ai arrêté mes pseudo-benchs orientés 'noyaux'. J'ai d'ors et déja viré mon noyau 386. Si des gens veulent s'amuser, il y a dans les posts précédents tous les progs et les indications de compilation correspondantes, quant à moi basta

Bon pas de gain de performance avec glxgears et autres applictions 3D chez moi. C'est même bizarre mais avec un noyau 386 ca va même légèrement plus vite

Faut être prudent dans les résultats apparents, et jamais oublier que derrière t'as un système multitâches avec des démons et des trucs gourmands qui peuvent se déclencher sans crier gare (exemple: les trucs triggés par cron.hourly). En plus pour glxgears, t'es fatalement sous X. Ce dernier, ainsi que gnome/kde ont un impact de consommation de ressources qui n'est pas constant. Pour t'en convaincre, ouvre un deuxième terminal et lance top.

-mtune=k8 -m32 -mfpmath=sse -msse2 -O2 sont des paramètres valables pour toutes les compilations?

Si tu veux le savoir en toute généralité, j'ai pas (encore) la réponse. Je peux te dire que les options -mfpmath=sse -msse2 sont totalement inutiles si ce que tu compiles n'utilise pas de nombres flottants.

Tu peux aller voir dans le manuel de référence de gcc.

Tu as aussi chez amd des 'Compiler Usage Guidelines'. En règle générale, il y a des papiers intéressants chez amd.

Malheureusement, toutes sources confondues ( dont le forum gentoo ) les infos sont contradictoires sur les options à utiliser et sur celles à éviter absolument pour l'AMD64.
J'en saurai plus dans quelques temps, par la force des choses, car mon nouveau dada est de recompiler des paquets ubuntu, et dans cette perspective on peut pas faire l'impasse sur les options de compil qui vont bien.