Gentoo?

Dans l'article news:3f607195$1_1@news.bluewin.ch,
Bernard <bameylan@bluewin.ch> écrivait :

Qqun a-t-il déjà testé la distrib Gentoo? Je voudrais avoir vos avis
et réactions sur cette distrib dont j'ai lu qu'elle constituait un
must en la matière.

fr.comp.os.linux.debats

--
TiChou

Qqun a-t-il déjà testé la distrib Gentoo? Je voudrais avoir vos avis et
réactions sur cette distrib dont j'ai lu qu'elle constituait un must en
la matière.

Bernard

Ce genre de question a plus sa place sur fcold.
Sinon, le Manchot Papou (traduction de l'anglais Penguin Gentoo), est connu
pour être le plus rapide des manchots :
http://www.edunet.ch/activite/wall/encyclopedie/manchot_papou.htm

fu2 fcold

--
Richard

Pour moi, gentoo est une debian-slackware.
Simplicité d'administration d'une debian (installation, update, ...)
grace au systeme de packages.
Puissance et optimisation d'une slackware (due à la compilation de la
majorité des softs).

Les softs proposés sont très nombreux, mais certains sont indisponibles
(je pense notamment à FreePascal qui lui, est disponible sous debian).

Et les versions proposées sont toutes très récentes, y compris dans les
kernel (2.4.22, 2.6.x, ...).

Ses principaux inconvénients à mon gout, sont dus à ses avantages :
- lenteur d'installation (selon le cpu, mais tout de meme), étant donné
que tous les softs sont compilés (y compris gcc ... tout quoi :)
- nécessité absolue d'une connexion internet haut débit (je vois mal
quelqu'un dl X avec un 56k ou faire un mirror de 30go des sources
disponibles).

Bref, pour moi, Gentoo est la distrib à tout faire, bien que je lui
préfère encore Debian Woody pour les serveurs nécessitant une stabilité
exemplaire (Gentoo étant trop jeune à mon gout).

Pour information, j'utilise Gentoo sur mon portable depuis bientot 6mois
sans aucune mauvaise surprise (aucun plantage, ni compilation foireuse).
CPU: AMD Athlon-4 1200MHz

Voici les optimisations GCC de mon fichier /etc/make.conf :

CHOST="i686-pc-gnu-linux"
CFLAGS="-march=athlon-4 -mfpmath=sse -mmmx -msse -m3dnow -O3 -pipe
-fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop
-frerun-loop-opt -falign-functions=4"
CCFLAGS="{$CFLAGS}"

Et ma var USE (qui définit en quelque sorte les dépendances définies par
l'utilisateur). Exemple: compiler mplayer ou nmap avec X dans la var USE
impliquera la compilation du gui de ces softs. CRYPT implique la
compilation des modules de cryptage, etc etc etc.

USE="-3dfx 3dnow acpi -arts avi cdr crypt cups -curl dvd encoder -esd
gif gpm jpeg -kde libwww mad -matrox mmx mpeg mozilla ncurses nls
oggvorbis opengl oss pam png quicktime sdl sse ssl svga tiff truetype
-voodoo X xmms xv zlib x86"

A l'installation (en stage3), il est demandé de faire un "emerge -u
system", cette instruction prend chez moi environ 5h (y compris les
temps de téléchargement depuis les USA extremement lents :|)
Et la compilation de ces packages
[http://fap.prout.be/gentoo/gentoo-pkg-list.txt] prend environ 20heures.

Très bon CPU requis :) (quoique grace a distcc on peut aller encore +
vite : http://distcc.samba.org/).

Bonne chance (et patience).

grosnours.

Bernard wrote:

Qqun a-t-il déjà testé la distrib Gentoo? Je voudrais avoir vos avis et
réactions sur cette distrib dont j'ai lu qu'elle constituait un must en
la matière.

Bernard

Dans article <3f61814e$0$27594$626a54ce@news.free.fr>,
nikopole@free.fr.invalid disait...

Bref, après moultes prises de tête, j'ai appris à paufiner et configurer mon
noyau, sur une slackware et une debian, et j'ai tout ce que je veux au niveau
performances.

Un gcc bien optimisé est également beaucoup plus rapide (près de 30%!).
Les deux choses intéressantes à compiler soi-même : gcc et le noyau.
Sauf si on fait des trucs de calcul poussé, bien sûr.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Dans article <3f61814e$0$27594$626a54ce@news.free.fr>,
nikopole@free.fr.invalid disait...

Bref, après moultes prises de tête, j'ai appris à paufiner et configurer
mon noyau, sur une slackware et une debian, et j'ai tout ce que je veux
au niveau performances.

Un gcc bien optimisé est également beaucoup plus rapide (près de 30%!).
Les deux choses intéressantes à compiler soi-même : gcc et le noyau.
Sauf si on fait des trucs de calcul poussé, bien sûr.

AMHA, on peut rajouter XFree86, qui peut ainsi utiliser les instructions
MMX, SSE, 3Dnow, etc, et tout ce qui est multimedia : xine, mplayer, ...

--
Richard

On Fri, 12 Sep 2003 11:57:21 +0200, Richard Delorme wrote:

Dans article <3f61814e$0$27594$626a54ce@news.free.fr>,
nikopole@free.fr.invalid disait...

Bref, après moultes prises de tête, j'ai appris à paufiner et configurer
mon noyau, sur une slackware et une debian, et j'ai tout ce que je veux
au niveau performances.

Un gcc bien optimisé est également beaucoup plus rapide (près de 30%!).
Les deux choses intéressantes à compiler soi-même : gcc et le noyau.
Sauf si on fait des trucs de calcul poussé, bien sûr.

AMHA, on peut rajouter XFree86, qui peut ainsi utiliser les instructions
MMX, SSE, 3Dnow, etc, et tout ce qui est multimedia : xine, mplayer, ...

XFree ne tire pas grand parti du SIMD... A part pour gratter quelques
% en vitesse sur les memcpy (mais c'est valable pour tous les programmes).
Le MMX n'est carrément pas rentable, sur ix86: le temps gagné dans
les routines MMX est largement reperdu lors des switchs de contextes
entre le mode FPU et le mode MMX (de 30 à 300 cycles suivant le CPU...).
Et les SSE et autres 3Dnow sont des extensions pour les flottants
qui ne servent pas à grand chose pour faire de l'affichage 2D.
Il n'y a guère que mesa qui puisse y gagner.

Par contre, en effet, les algorithmes de décompression et de
post-processing de vidéo sont facilement parallélisables et nécéssitent
des flottants. Pour ceux là, SSE2 est tout indiqué...
A part le calcul parrallèle (traitement d'image, resampling de son...),
les process ne gagnent rien de sensible avec les extensions SIMD...

Gcc gagne beaucoup plus à optimiser les algorithmes générés qu'à
essayer d'utiliser des instructions spéciales. Bien sur, il évite
les instructions du 80286 qui sont devenues obsolètes (et émulées
en soft dans les CPU...), mais les quelques instructions concernées
ne font plus vraiment partie du language ix86...

On Fri, 12 Sep 2003 11:57:21 +0200, Richard Delorme wrote:

Dans article <3f61814e$0$27594$626a54ce@news.free.fr>,
nikopole@free.fr.invalid disait...

Bref, après moultes prises de tête, j'ai appris à paufiner et
configurer mon noyau, sur une slackware et une debian, et j'ai tout ce
que je veux au niveau performances.

Un gcc bien optimisé est également beaucoup plus rapide (près de 30%!).
Les deux choses intéressantes à compiler soi-même : gcc et le noyau.
Sauf si on fait des trucs de calcul poussé, bien sûr.

AMHA, on peut rajouter XFree86, qui peut ainsi utiliser les instructions
MMX, SSE, 3Dnow, etc, et tout ce qui est multimedia : xine, mplayer, ...

XFree ne tire pas grand parti du SIMD... A part pour gratter quelques
% en vitesse sur les memcpy (mais c'est valable pour tous les programmes).

Quelques % ? chez moi, les memcpy utilisant les instructions MMX ou SSE sont
deux fois plus rapides (soit un gain de 100% en vitesse) que le memcpy
"traditionnel" de la glibc.

Le MMX n'est carrément pas rentable, sur ix86: le temps gagné dans
les routines MMX est largement reperdu lors des switchs de contextes
entre le mode FPU et le mode MMX (de 30 à 300 cycles suivant le CPU...).

A ma connaissance, les athlons n'ont pas ce problème.

Et les SSE et autres 3Dnow sont des extensions pour les flottants
qui ne servent pas à grand chose pour faire de l'affichage 2D.
Il n'y a guère que mesa qui puisse y gagner.

Je ne dis pas le contraire, mesa fait parti de xfree86. Voici, par exemple,
le contenu d'un répertoire :

$ ls xc/extras/Mesa/src/X86/
3dnow.c clip_args.h mmx.h sse_xform4.S
3dnow.h common_x86_asm.h norm_args.h x86.c
3dnow_normal.S common_x86_asm.S sse.c x86_cliptest.S
3dnow_vertex.S common_x86.c sse.h x86.h
3dnow_xform1.S common_x86_features.h sse_normal.S x86_vertex.S
3dnow_xform2.S common_x86_macros.h sse_vertex.S x86_xform2.S
3dnow_xform3.S gen_matypes.c sse_xform1.S x86_xform3.S
3dnow_xform4.S glapi_x86.S sse_xform2.S x86_xform4.S
assyntax.h mmx_blend.S sse_xform3.S xform_args.h

Je constate la présence de fichiers en assembleur, optimisé pour 3dnow, mmx
ou sse. C'est sans doute dommage de s'en priver.

Par contre, en effet, les algorithmes de décompression et de
post-processing de vidéo sont facilement parallélisables et nécéssitent
des flottants. Pour ceux là, SSE2 est tout indiqué...
A part le calcul parrallèle (traitement d'image, resampling de son...),
les process ne gagnent rien de sensible avec les extensions SIMD...

On est donc d'accord. Les applications multimedia gagnent a être recompilé
pour le processeur qui va les utiliser. Sur ma machine (Athlon XP 2000),
xine donne des films aux images saccadés pour les versions binaires
(Mandrake 8.2 et Debian Woody), mais fluide quand il est recompilé (sur les
mêmes distributions ou sur gentoo). Dans un cas, il est inutilisable, dans
un autre, il est très bien.

Gcc gagne beaucoup plus à optimiser les algorithmes générés qu'à
essayer d'utiliser des instructions spéciales.

gcc ne change pas les algorithmes, il optimise du code.

Bien sur, il évite
les instructions du 80286 qui sont devenues obsolètes (et émulées
en soft dans les CPU...), mais les quelques instructions concernées
ne font plus vraiment partie du language ix86...

sur les i686 ou +, il y a aussi quelques instructions spécifiques (cmov
p.ex.) qui permettent de gagner pas mal en vitesse.

--
Richard

On Sat, 13 Sep 2003 11:55:46 +0200, Richard Delorme wrote:

Quelques % ? chez moi, les memcpy utilisant les instructions MMX ou SSE
sont deux fois plus rapides (soit un gain de 100% en vitesse) que le
memcpy "traditionnel" de la glibc.

Je veux voir des exemples. J'ai fait des benches sur pas mal de ix86,

du Geode à l'Athlon XP et P-III en faisant des memcpy "classiques"
et des memcpy en MMX avec les prefetchs fait à la main.
Le plus gros gain que j'ai observé est de 30%, sur le Geode.
Les caches sont tellement optimisés, sur les CPU récents qu'ils
saturent déjà pratiquement le bus mémoire en permanence quand
on fait un bête:
rep movl ...

Xine fait ce benchmark, sur ma machine (athlon xp 2000) cela donne :
$ xine -v
Voici xine (X11 gui) - un lecteur vidéo libre v0.9.21
(c) 2000-2003 par G. Bartch et l'équipe du projet xine.

$ xine
Benchmarking memcpy methods (smaller is better):
glibc memcpy() : 629413447
linux kernel memcpy() : 625738622
MMX optimized memcpy() : 549848141
MMXEXT optimized memcpy() : 335734572
SSE optimized memcpy() : 332004112

D'après le source, le chiffre est le nombre de cycles nécessaire pour
copier 100 fois 1 Mo. sur ce test, la version optimisée SSE est 89% plus
rapide que la version de la glibc.

Pour refaire le test, il faut éditer le fichier .xine/config pour qu'il
contienne la ligne (vers le bas du fichier) :

# Memcopy method to use in xine for large data chunks.
# { probe glibc kernel mmx mmxext sse }, default: 0
misc.memcpy_method:probe

--
Richard

On Sat, 13 Sep 2003 15:03:36 +0200, Richard Delorme wrote:

On Sat, 13 Sep 2003 11:55:46 +0200, Richard Delorme wrote:

Quelques % ? chez moi, les memcpy utilisant les instructions MMX ou SSE
sont deux fois plus rapides (soit un gain de 100% en vitesse) que le
memcpy "traditionnel" de la glibc.

Je veux voir des exemples. J'ai fait des benches sur pas mal de ix86,

du Geode à l'Athlon XP et P-III en faisant des memcpy "classiques"
et des memcpy en MMX avec les prefetchs fait à la main.
Le plus gros gain que j'ai observé est de 30%, sur le Geode.
Les caches sont tellement optimisés, sur les CPU récents qu'ils
saturent déjà pratiquement le bus mémoire en permanence quand
on fait un bête:
rep movl ...

Xine fait ce benchmark, sur ma machine (athlon xp 2000) cela donne :
$ xine -v
Voici xine (X11 gui) - un lecteur vidéo libre v0.9.21
(c) 2000-2003 par G. Bartch et l'équipe du projet xine.

$ xine
Benchmarking memcpy methods (smaller is better):
glibc memcpy() : 629413447
linux kernel memcpy() : 625738622
MMX optimized memcpy() : 549848141
MMXEXT optimized memcpy() : 335734572
SSE optimized memcpy() : 332004112

D'après le source, le chiffre est le nombre de cycles nécessaire pour
copier 100 fois 1 Mo. sur ce test, la version optimisée SSE est 89% plus
rapide que la version de la glibc.

C'est extrèmement étrange, il faudrait que je regarde le source...
Ou alors, c'est que le cache fait plus de 1 Mo, et dans ce cas,
le bench n'est pas un bench mémoire, mais uniquement un bench
CPU, et dans ce cas, je suis d'accord, les instructions SSE
sont bcp plus rapide puisque les registre SSE font 128 bits,
donc, il faut 2 fois moins d'instructions qu'en MMX/3Dnow,
et 4 fois moins qu'avec les registres ix86. Le cache de mon
Athlon faisant 256ko, il faudrait commencer le bench après la
copie des 256 premiers ko pour avoir un bench réaliste du point
de vue de la vitesse de la copie en fonctionnement "normal",
ou utiliser des tailles de copie très largement supérieures
à la taille du cache.
A par ça, ta glibc et ton kernel doivent être particulièrement mal
compilés: ils ont des version MMX, SSE, SSE2 et 3Dnow du memcpy...
Le kernel utilise en principe toujours la version la plus rapide.
Je me demandes d'ailleurs comment xine peut accéder au memcpy
du kernel... Encore une fois, il faudrait que je regarde le source...

$ xine
Benchmarking memcpy methods (smaller is better):
glibc memcpy() : 629413447
linux kernel memcpy() : 625738622
MMX optimized memcpy() : 549848141
MMXEXT optimized memcpy() : 335734572
SSE optimized memcpy() : 332004112

D'après le source, le chiffre est le nombre de cycles nécessaire pour
copier 100 fois 1 Mo. sur ce test, la version optimisée SSE est 89% plus
rapide que la version de la glibc.

C'est extrèmement étrange, il faudrait que je regarde le source...
Ou alors, c'est que le cache fait plus de 1 Mo, et dans ce cas,
le bench n'est pas un bench mémoire, mais uniquement un bench
[...]

Mon athlon xp n'a que 256 Ko de cache

A par ça, ta glibc et ton kernel doivent être particulièrement mal
compilés: ils ont des version MMX, SSE, SSE2 et 3Dnow du memcpy...
Le kernel utilise en principe toujours la version la plus rapide.
Je me demandes d'ailleurs comment xine peut accéder au memcpy
du kernel... Encore une fois, il faudrait que je regarde le source...

le source est disponible ici (j'utilise la version 1.24 pour la
xinelib-1-beta12) :
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xine/xine-lib/src/xine-utils/memcpy.c

ce que xine appelle le "linux kernel memcpy", ne vient pas du noyau, mais
est une version interne à Xine, sans doute copiée du noyau, sans
utilisation d'instruction spécialisée. Mon noyau est bien compilé (enfin
j'espère).
Par contre, le "glibc memcpy" provient bien de la glibc. Je ne trouve pas de
version SIMD de memcpy dans les sources de la glibc.2.3.2 de mon système :(
Il y a bien une version dite optimisée pour i686 dans
glibc.2.3.2/sysdeps/i386/i686/memcpy.S, mais elle n'utilise pas
d'instruction MMX ou SSE, ni de prefetch :(

--
Richard