4/ il est nécessaire de prendre les pilotes Alsa de développement (comme lors de la sortie du 2.6.19 quoi).
Avec quelles cartes?
La mienne déjà (Terratec Aureon 7.1 Space) et pas mal d’autres à en juger par le fait que Gentoo a intégré un snapshot alsa-driver pour la sortie du 2.6.20.
http://gentoo-portage.com/media-sound/alsa…ChangeLog#ptabs
edit : comme lors de la sortie du 2.6.19, j’ai compilé alsa dév à la main (j’aime bien faire ma sauce :p), après avoir aperçu les erreurs lors d’une première compilation de la version stable d’Alsa (1.0.13).
2.6.20.1 Out!!!
Changelog
Ça va il fait pas mal à la tête le changelog 
Bon je ferai la MAJ un de ces jours par principe, mais c’est pas pressé quoi…
j attendrais la mise a jour auto suis trop mou pour le faire moi meme^^
http://marc.theaimsgroup.com/?l=linux-kern…95529425248&w=2
"if you run a NFS server" ha ben patchons…
opérationnel sur ubuntu edgy
Linux zerhuel 2.6.20.1 #1 SMP PREEMPT Sun Feb 25 20:39:25 CET 2007 i686 GNU/Linux
fréquence de l’ordonnanceur a block (1000HZ), ca répond vachement mieux qu’avec le noyau par défaut (250HZ je crois)
Le noyau d’Ubuntu est en 250Hz par défaut ? Mmmh je vais finir par en refaire un à ma sauce
en effet
l33thium@Sapphire:~$ grep -i hz /boot/config-2.6.17-11-generic
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_MACHZ_WDT=m
ceci dit quand je suis passé de ma gentoo aux petits oignons à ma ubuntu generique, j’ai rien senti, ou alors un plus pour ubuntu.
Si ta gentoo aux petits oignons était compilée avec -O3 par exemple, c’est pas étonnant, vu que tes petits oignons étaient pourris
-Os, aucune option agressive
pour être précis :
CFLAGS="-Os -march=athlon-xp -mfpmath=sse,387 -ffast-math -fmove-all-movables -fomit-frame-pointer -pipe"
Ah, j’avais sensiblement la même chose en dehors de -ffast-math et -fmove machin (après un passage avec des optimisations aggressives, j’avais vite compris que rien ne valent les optimisations de base :))
Je comprends pas trop votre terme optimisations aggréssives… Vous pouvez préciser votre pensée?
CedeRhum : suivant les options que tu lui passe gcc genere les binaires de manières differentes, on parlais de -O3, par exemple, qui genere des binaires plus gros que la normal parce qu’il "déroule" le programme d’une manière qui soulagerais le processeur à l’execution.
Mais ça donne des resultats bizarres parfois et donc une perte d’espace disque non negigeable si tu fait tout ton OS comme ça sans compter les risques de binaires cassés.
-Os optimise la taille, il tente de generer les plus petits binaires possibles.
les optimisations de ce niveau ca se ressent pas sur un desktop, ya trop de bordel qui tourne
par contre pour des applis scientifiques, tu arrive vite a des différences de temps d’exécution et d’occupation mémoire qui sont énormes
Merci de l’info, il est vrai que pour mes programmes, j’en étais resté au -O3… :paf:
Je’m’sens moins bête! :ane: :miam:
PS: comme le disait très justement dg-switcher, ben en ce qui me concerne, mon programme est exactement deux fois plus long. Mais l’exec est d’un tiers plus petit en taille. CQFD. 
Le truc de -O3 c’est que notamment il déroule toutes les boucles, ce qui est censé être plus rapide à l’exécution. Sauf qu’apparemment c’est beaucoup plus sensible aux erreurs de cache dans le proc donc au final ça va moins vite :paf:
Dans le meme ordre d’idées, et un poil hors de ce topic, mais c’est la suite des messages précédents… (j’espere que les modos me tomberont pas dessus! )
Comment se fait-il que le meme programme (pas une ligne ne change, pas une seule), une fois compilé sous windows et linux l’un prend 270ko et l’autre 70ko avec les memes options de compilation. Pourquoi l’exe win est si gros? qu’y a-t-il dedans comme info dont l’exec linux n’a pas besoin. Car là, la différence est quand meme plus que non négligeable… :neutre:
linkage statique dans le binaire win32 ?
statique!! comme dans la version linux d’ailleurs…