Brice Goglin a écrit 181 commentaires

Non, libX11/XCB n'est pas du tout dans Etch. C'est seulement dans experimental avec tout Xorg 7.2. Il y a une réflexion en cours sur les problemes liés à XCB (lenteur et gros bug de locking dans Java). libX11/XCB ne devrait pas arriver dans unstable avant qu'une solution à peu près satisfaisante soit trouvée.

Il y a un backport de gnome 2.16 pour Etch dans http://people.debian.org/~nobse/etch/gnome2.16/

Sinon gnome 2.18 est en train d'arriver dans experimental et devrait donc débarquer dans unstable assez rapidement maintenant que le freeze va être enlevé.

C'est un peu caca cette détection :) Il y a des distribs qui ont backporté les modifs liées à autoconf.h, config.h et utsrelease.h dans des noyaux < 2.6.18 (notamment des fedora 2.6.17 si je me souviens bien). Donc ces tests basés sur les versions ne marcheront pas toujours.

Pour utsrelease.h, il suffit d'inclure version.h puis ensuite de tester si UTS_RELEASE est défini et si ce n'est PAS le cas, inclure utsrelease.h.

Pour autoconf/config.h, il vaut mieux regarder si AUTOCONF_INCLUDED est défini (il l'est au début de autoconf.h, qui est inclu automatiquement depuis plusieurs noyaux), et si ce n'est PAS le cas, inclure config.h a la main.

> Je sais pas où tu t'es trompé dans tes calculs mais je sais que:
> La perfo crête d'un Itanium est 4 flops / cycle / coeur

Peut-être que c'est lié au fait que Tera-10 avait initialement des Madison (single core) et doit migrer vers des Montecito (dual-core) au fur et à mesure que Intel les livre. Je ne sais pas si c'était déjà fait au moment où ils ont tourné Linpack, et ça pourrait expliquer un facteur 2 dans mes calculs.

Le truc étrange, c'est que cette grappe a toujours été annoncée à 60Teraflops. Si des Madison doivent encore être remplacés par des Montecito, les 50 actuels pourraient devenir 100Teraflops. Y a un truc qui m'échappe aussi...

> 8 Gflop/s/ core sur Woodcrest.... j'ai mal à mon Opteron, j'ai mal à mon Itanium.

Woodcrest, c'est 4 par core.
http://www.theinquirer.net/default.aspx?article=31836
D'ailleurs cet article confirme ton 12.8 Gflops pour un dual-core montecito 1.6GHz.

Bref, Itanium est un peu mieux qu'un Opteron, et Woodcrest tue tout. Mais la génération actuelle d'Opteron est en fin de vie... attendons de voir...

Le classement dans le top500 dépend de beaucoup d'autres choses, pas seulement la puissances des processeurs, notamment des communications entre les noeuds de la grappe, mais éventuellement aussi d'autres choses comment le stockage qui peut réduire les performances globales de la machine.

Le classement est fait selon Rmax (la puissance observée par Linpack), mais la liste détaillée donne aussi Rpeak qui est la puissance théorique de l'ensemble des processeurs. Le Rpeak du 5ème est 55700Gflops (soit 6.4Gflops par Itanium2) contre 49800 pour le 7ème (soit 4.81Gflops par Opteron). Les deux grappes ont une efficacité (Rmax/Rpeak) de l'ordre de 77%. Mais par contre, par exemple, le 6ème a seulement 59% ce qui fait qu'il est 6ème alors que son Rpeak le classerait 4ème (il doit y avoir un composant de la grappe qui "ralentit" les processeurs).

Pour revenir à Itanium vs Opteron:
Si je me souviens bien, Tera-10 (5ème) est composé de 544 noeuds de Novascale qui contient 4 QBB de 4 Itanium2 (je compte en processeur, pas en coeurs). Ca nous donne donc les 8704 processeurs indiqués. Mais ils sont censés être des Montecito (dernier cri des Itanium2 je crois), et donc dual-core. Ca voudrait donc dire qu'un Itanium2 Montecito dual-core 1.6GHz calcule 6.4Gflops (soit 2 flop par cycle et par coeur).

Dans le 7ème, ce sont des Opteron single core 2.4/2.6GHz. Ca donne donc également 2 flop par cycle et par coeur. Mais ces opterons sont beaucoup moins récents que les Itanium2 Montecito. Avec un Opteron récent, disons dual-core 2.4GHz, on aurait le double, soit 9.6Gflops par processeur, soit 50% de plus que le Montecito.

Tous ces calculs sont faits à la louche, mais en tout cas ils semblent indiquer que l'Itanium2 ne casse pas l'Opteron du tout en puissance flottante pure. Et il faut bien garder à l'esprit que dans le top500, il a beaucoup d'autres facteurs qui sont mis en jeu.

J'aurais tendance à être avec toi. Le seul argument que j'ai entendu en faveur de l'Itanium c'est les gros caches.

Intel joue aussi. Par exemple pour la grappe Thunderbird à Sandia, après l'appel d'offre, ça devait être AMD/Myrinet. Mais ca n'a pas plus à Intel que AMD puisse avoir une énorme grappe donc ils ont offert les processeurs (9000 Xeons...) à condition que ce soit l'offre de Dell avec Infiniband qui soit choisie.

C'est vrai que j'avais oublié Cray... j'ai un peu trop tendance à les considérer comme déjà morts, alors qu'ils sont encore un peu vivants grâce aux perfusions d'argent du gouvernement :)

Le top500 n'est pas représentatif de la réelle utilisabilité des machines, ni des besoins réels des gens. Les Blue-gene sont parait-il très difficiles à programmer (leur architecture diffère des supercalculateurs classiques). Linpack y a été extrèmement optimisé (d'où les très bons classements dans le top500), mais pour faifre tourner une autre application, c'est une autre paire de manches.

Sur des grappes classiques, disons quelques centaines de noeuds, on sait faire tourner pas mal de code différents, que ce soit des simulations pétrolières (pour gérer les stocks), des prévisions météorologiques, des prévisions financiéres, ou des crash test automobiles. Ce sont eux les vrais clients qui font marcher le monde du HPC.

Toutes les grappes gigantesques sont plutôt là parce que les américains jouent à qui aura la plus grosse (grappe), IBM et Intel notamment. A part Linpack, on ne doit pas faire tourner souvent d'application utilisant 2 milles noeuds. Dans beaucoup de cas, les utilisateurs ne prennent qu'un bout de la grappe et laisse le reste des noeuds à d'autres applications.

La recherche actuelle ne s'intéresse plus vraiment aux très grosses grappes. Les chercheurs font plutôt de la grille maintenant, donc ils veulent plutôt beaucoup de petites grappes interconnectées.

Microsoft a fait beaucoup d'annonces récemment à propos de son système pour clusters. Mais leur but est plutôt les petits clusters que les gros. En gros ils veulent prendre le marché des grappes jusqu'à 64 ou 128 noeuds en fournissant un système "facile à gérer". Pour les plus grosses grappes, ils semblent savoir qu'ils auront du mal à rivaliser avec les vrais OS.
Donc il est peu probable que Windows apparaissent beaucoup dans le top500 même si Microsoft réussit à entrer dans le marché du HPC.

Ce dont tu te rappelles, ca devait être S4bios, un suspend-to-disk spécial entièrement géré par le BIOS et l'APM. Ca n'a jamais vraiment marché sous Linux car les drivers sont hyper machine/bios-dépendant et donc n'existaient que sous Windows. ACPI n'existait peut-être même pas encore à ce moment là.

Je crois que le pseudo-support pour s4bios dans Linux a été supprimé recemment car il ne marcherait jamais et est obsolète comparé aux différents S4 logiciels d'aujourd'hui (swsusp, suspend2, ...).

Ca fait très longtemps que r300 est supporté. Les premiers morceaux sont arrivés dans 2.6.11 (grep r300 dans le long changelog) et ca marche bien depuis 2.6.14 ou 2.6.15. Depuis, ils ajoutent régulièrement des nouveaux IDs de cartes et améliorent le support. 2.6.17 est mieux, mais pas révolutionnaire dans ce domaine. Perso, ma Radeon X300 (une rv370) marche bien depuis 2.6.15.

Ca a été vaguement envisagé mais rien n'a été decidé. Et vu tous les commits dans le git du noyau depuis 2.6.17, ca n'est pas pour 2.6.18.

> après c'est immondice nommée Caml

Apparemment, tu t'es bouffé plus de Caml que de grammaire...

Les gens voulant un mutex utilisaient les semaphores.

Est-ce qu'il y a un vrai problème technique pour supporter IPv6 ? Il ne suffit pas de changer les gethostbyname par des getaddrinfo ? :)

Est-ce que le module radeon est chargé ? Est-ce qu'il y a des warnings dans dmesg ?

Est-ce que tu as installé mesa-dri ? Je ne sais pas comment ca s'appelle sous Mandrake mais ces libs sont indispensables.

Xorg.log doit dire des choses du genre :

(WW) RADEON(0): Enabling DRM support
(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] DRM interface version 1.2
...
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
....
(II) RADEON(0): [drm] dma control initialized, using IRQ 169
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
(II) RADEON(0): Direct rendering enabled

Fix du lien :
http://dri.freedesktop.org/wiki/ATIRadeon

Pour les cartes ATI récentes (mais pas trop quand meme), le driver radeon qui est dans le noyau marche bien. Il faut Xorg >= 6.9 (pour avoir le driver Xorg r300) et mesa-dri (paquet libgl1-mesa-dri sous Debian). Comme ca, pu besoin de patcher et recompiler fglrx à chaque nouveau noyau.

Cette méthode doit supporter toutes les cartes a base de processeur R3xx et rv3xx. J'ai testé avec les Radeon X300 (et X600) avec 2.6.15, ca marche très bien. Et le support de R4xx et rv4xx est censé commencer à marcher aussi.

Voir le DRI Wiki (http://dri.freedesktop.org/wiki/ATIRadeon) pour le détail des processeurs dans les différentes cartes ATI.

Faut arrêter avec les drivers propriétaires... En plus, fglrx n'est jamais à jour pour les derniers noyaux. Ce patch est connu depuis plus d'un mois (depuis les changements de VM dans les 2.6.15-rc). Y a eu deux releases de fglrx depuis, mais ATI n'est pas foutu d'intégrer le patch. S'ils lisaient un peu KLML des fois au lieu de coder des drivers crades dans leur coin...

Y a eu un gros troll a ce propos sur LKML. Ils vont essayer de merger les multiples implementations disponibles, mais ca risque de prendre du temps avant que tout le monde se mette d'accord.

Voir http://lkml.org/lkml/2005/12/5/142 et les suivants.

Dans 2.6.15, c'est le pilote 1.0.8 donc le dernier.

Au niveau européen, il y avait déjà le Mare Nostrum à Barcelone en position 8 du dernier top 500 (il etait numero 4 dans l'édition précédente).

Je crois que c'est déjà incorporé dans 2.6.13 dans arch/pp64/bpa_* via l'option de config CONFIG_PPC_BPA,non ?
Le ChangeLog de 2.6.13 contient plusieurs entrées parlant de Cell.

Et un post récent sur LKML
http://lkml.org/lkml/2005/8/31/296(...)
propose de bouger ces fichiers dans arch/powerpc/platforms/cell et de changer l'option de config en CONFIG_PPC_CELL car l'ancienne dénomination BPA (Broadband Processor Architecture) doit être remplacée par Cell.

Juste un masquage pour le moment.

D'après ce que j'ai compris :

Les gros trucs hexadecimaux, c'est des hash qui servent d'identifiants dans git.

Pour chaque patch mergé dans un arbre git, git calcule ce gros hash sur le contenu du patch. Vu la taille du hash et l'algo de calcul utilisé, il est tres peu probable que deux patchs aient le meme hash. Ca permet donc d'identifier rapidement tous les patchs, meme si ca n'est pas tres intuitif.

Les différentes revisions de l'arbre git en entier sont aussi identifiées par des hash du même genre.
Ainsi, chaque commit peut être caracterisé par le hash du patch associé, ou le hash de l'arbre avant et apres le commit.
Apparemment, chaque commit est aussi associé aux hash de chaque fichier avant et apres le commit.

Auparavant aussi, il fallait déjà éviter avant de débrancher à chaud sans démonter.
Même si tu avais sync dans les options de mount, il n'était pas supporté par vfat avant 2.6.12. Donc ca allait vite puisque ce n'était en fait pas synchronisé.

Depuis 2.6.12, soit tu enleves sync et tu as le comportement d'avant.
Soit tu mets sync et ca rame mais tu peux debrancher sans démonter.
Je n'ai pas vu de différence avec les 2.6.13-rc*.

Certains ont conseillé de mettre dirsync pour que les modifications des répertoires soient synchrones.