lasher a écrit 2738 commentaires

CORBA, le truc imbitable, avec une architecture tellement complexe que pour un simple « hello world » il faut 1 min. pour traverser toutes les couches d'abstraction ? :-)

Plus sérieusement, dans le cadre du calcul haute-performance, le surcoût qu'impose CORBA est clairement trop important. De plus les objectifs des deux projets ne sont pas les mêmes :

- CORBA propose une abstraction « objet » pour une architecture logicielle distribuée et multi-plateforme (enfin, au moins C++ et Java)
- de ce que j'ai pu voir POP-C++, il s'agit surtout de rajouter des mots-clef à la syntaxe pour prendre en compte le parallélisme, et ainsi gérer les synchro, la concurrence en règle générale, etc (et bon, quelque part, j'ai envie de dire que ça permet un peu de rattraper le retard sur le langage Java qui propose déjà des "synchronize", etc.)

Du coup, j'aurais plutôt envie de demander à Laurent si rajouter des mots-clef à C++ (qui en est déjà bien rempli) est une bonne chose. Comment se compare POP-C++ à Thread Building Blocks d'Intel, par exemple (qui ne se servent « que » de templates) ?

Un peu comme pour les BSD quoi ...

Tu as tout à fait raison. Mais passer par un segment de mémoire partagé, ou un fichier mappé demande à la fois de le créer explicitement ET de faire attention à ce qu'on en fait ... Quelque part, je trouve que c'est le pire des deux mondes (multiprocessus Vs multithread). :-)

Cela dit, c'est ce qui est fait dans tout un tas d'applications, notamment celles qui ne sont pas (encore ?) thread-safe et qui ont besoin de communiquer.

En pratique, des bibliothèques numériques non-libres, telles celles d'Intel, proposent deux version des BLAS : celles qui sont un front-end aux BLAS Fortran, et celles qui sont des « C-BLAS » (càd : tout réimplémenté en C et assembleur). Ça a deux avantages :

1/ Si on a vraiment besoin de l'interface officielle, on l'a, même en C.
2/ Si on passe par une interface « C », on s'affranchit du besoin de tout passer par « référence » (càd par pointeur, vu que l'interface doit fonctionner depuis le C), ce qui, mine de rien, est plutôt une bonne chose, et permet de faire certaines optimisations quasi-impossible quand on doit gérer des cas potentiels d'aliasing à cause de gens qui se croient malins ...

Dernière chose : l'interface des BLAS prévoit un argument « row major » Vs « column major », donc je ne comprends pas où est le problème avec NumPy (que je ne connais pas). Au pire on doit spécifier l'argument et c'est tout non ?

Une dernière chose. Pourrais-tu expliciter ton les tableaux multi-dimensionnels du C ne servent à rien) ? Il n'y a pas de « vrai » tableau multidimensionnel en C, j'en conviens, mais la majorité des codes Fortran que je vois passer font une grosse allocation unidimensionnelle en début de programme, avant de les « transformer » en tableaux multidimensionnels en les passant à des fonctions/sous-routines qui justement pensent avoir à faire à des tableaux multi-D. Et ça marche très bien.

Notamment pour le calcul scientifique, il y a Fortress qui est basé sur les concepts de Fortran et qui tourne sur la JVM.

Oui enfin, devoir repasser par une syntaxe différente uniquement pour faire du calcul haute performance, c'est un peu dommage ... Par exemple en Fortran, les dimensions des tableaux sont stockées à partir de la dernière, puis en remontant (donc un tableau déclaré comme TAB(M,N,K) sera rangé suivant K, puis N, puis M), là où en C/C++/Java on stocke d'abord par rapport à la première dimension de tableau. Quand les codes sont « simples », le compilateur est capable de renverser l'ordre des boucles comme un grand, mais c'est tout à fait différent dès qu'on commence à faire des trucs un peu complexes dans des nids de boucle.

Le multiprocessing c'est différent du multithreading.

Dans le cas d'une application multiprocessus, l'intégralité du processus est dupliqué (pile, tas, variables statiques et globales, etc.). La mémoire est compartimentée pour chaque processus (cf. man fork(2) sous Unix). Cela implique que pour communiquer entre les différents processus ainsi créés, il va falloir utiliser des appels explicites pour envoyer/recevoir des données : Socket BSD, pipe SysV, etc.

Dans le cas du multithreading, on a un même processus qui exécute plusieurs threads à la fois, la mémoire est implicitement partagée. Il faut donc faire attention à ne pas écraser la donnée du voisin. En contrepartie, la création d'un thread est bien moins lourde que celle d'un processus, l'empreinte mémoire est bien moins élevée si jamais mon application doit allouer de gros blocs, etc.

Ah ? On peut utiliser les sémaphores maintenant ? (sur OSX 10.3 on pouvait pas ...)

Sauf que faire du multi-processus ça veut dire installer tout un tas de mécanismes pour pouvoir passer les données à son processus voisin, alors qu'avec le multithreading les données sont partagées. Et surtout, la consommation mémoire est moindre pour une application multi-threadée comparée à son équivalent multi-processus.

OK. Si on parlait multithreading sur systèmes multi-cœurs/multi-processeurs ? Ah ben zut, python fait pas. :-/

Ben je suis assez d'accord en fait. Une des premières sources de bugs dans les programmes c'est quand même les problèmes de gestion mémoire. D'ailleurs ce n'est pas pour rien que Boost en C++ permet d'avoir des pointeurs « magiques » (avec comptage de références). Alors certes, ça implique une certaine perte de perfs, mais qu'est-ce qu'on y gagne en temps de débogage !

Hem. Je suis plutôt d'accord avec toi sur le fait que Java n'est pas si mauvais en termes de perfs, mais il y a quelques limites quand mêmes ... Parce que bon, tes histoires d'algos d'analyse numérique, s'il s'agit d'algèbre linéaire dense par exemple, sauf à avoir des classes qui en réalité passent par du C en sous-main, malheureusement Java est derrière le langage C. Il y a d'autres domaines où au contraire Java rivalise sans rougir avec C++ bien sûr.

Mais quand même globalement, en termes de consommation mémoire et de rapidité, quand la latence réseau n'est pas le facteur limitant, Java reste globalement moins rapide que C (après parfois il s'agit d'un « à peine moins rapide » et du coup, autant se simplifier la vie et rester sur Java, bien sûr).

« Je me demande si il existe un successeur à NFS qui est capable de faire de la réplication mais en privilégiant au maximum la machine local qui lit et écrit les données (GFS ?). »

Je ne sais pas si la machine locale est privilégiée, mais Lustre n'est pas censé être un successeur de NFS dans le cadre du calcul haute performance ?

Mais (neuneu != dev)
Certes, mais sysadmin != dev. De la même façon qu'on ne demandera pas à un admin de faire plus que scripter pour l'admin justement (je me vois mal demander à un sysadmin de développer une application critique temps réel pour faire décoller une fusée), je me vois mal demander à un dév de faire de l'admin. Oh, il finira peut-être par faire marcher l'appli, mais ce sera certainement au mépris des règles d'admin et/ou de sécurité élémentaires, vu que c'est pas son boulot, et qu'il ne sait pas forcément quelles contraintes il doit respecter.

Dans ton post, on peut d'ailleurs substituer « dev » par « admin » et « programme » par « config ». Ce qui commencerait comme ça : « On en connaît tous des configs mal faites. Elles sont mal faites lorsque l'admin est un neuneu. [...] »

Les bibliothèques oui je sais, tout comme les pamphlets de Céline ou autres... Et il faut montrer patte blanche pour y accéder (ie « être du métier » : journaliste, traducteur, universitaire, etc). Maintenant étant donné que l'incitation à la haine raciale est interdite en France, j'aimerais bien savoir comme un truc comme Mein Kampf pourrait être en vente libre ici ... Si c'est possible, il doit bien y avoir une raison officielle non ?

Hum, en France le livre est aussi interdit à la vente.

Admettons plein de trucs. Admettons que le disque était quasi-neuf. Admettons qu'on sait quel OS se trouvait sur le disque avant de le récupérer, et même quel FS et avec quelles versions. Admettons que du coup, grâce à notre expert local en dév linux/ext3 (par exemple), on sache où sont passés des pans importants du système sur le disque (quels secteurs, etc.), et donc qu'au final, on sait plus ou moins où trouver les fichiers de "/home". Bon, même comme ça, ton linux, sur un disque dur de 100 Go, il fait peut-être 10 à 20 Go (en étant optimiste).

Même en sachant que /home n'occupait que (disons) 40% du reste (soit 40% de 80Go, soit 32 Go), il reste encore à trouver notre aiguille dans la meule de bits que représentent ces 32 Go. Si je cherche une information précise, ça risque de prendre un temps sacrément long à retrouver. On parlait de crypto un peu plus haut, et quelqu'un disait que les problèmes de crypto étaient plus difficiles à résoudre. Du point de vue mathématique très certainement, mais du point de vue « combien de temps me faudra-t-il pour récupérer l'information, et celle-ci sera-t-elle toujours pertinente au moment où je l'aurais trouvée ? », je ne pense pas qu'on soit si éloigné des bonnes méthodes cryptographiques en termes de résultat : imaginons que je récupères mes bits 1 à 1, histoire d'avoir mes 87% de chances de récupérer mon image disque, combien de temps cela aura-t-il pris ? Passons ensuite des codes de correction d'erreur, des algos permettant de récupérer des infos, tout ça ... Là encore, combien de temps ? (Sans parler des risques d'erreur lors de la récupération des données, bien sûr)

Et une dernière chose : sur le disque des chinois du FBI ou de la marine, ils chiffrent pas les données ? :-)

En même temps, tu as déjà vu le warning affiché par gcc si tu utilises gets() ?

C'est vrai, mais par exemple, un compilateur comme icc qui génère du code SSE assez facilement (ie du moment que le code est assez régulier pour le justifier, sans if ou while imbriqués) refusera systématiquement de générer ledit code SSE si on lui dit qu'on veut coller exactement à la norme IEEE 754 (ou son équivalent double précision). Il doit bien y avoir certaines hypothèses de commutativité donc (je passe sur le côté "sur x86 je stocke les nombres sur 80 bits en interne avant de les refoutre sur 64/32 bits") quand on demande au compilo d'optimiser.

je pense que ceux qui utilisent les OS alternatifs, il y en a une majorité qui font du multiboot et donc qui ne peuvent pas scratcher tout le disk, donc nous sommes en contradiction.

J'avais l'impression que de plus en plus de gens passaient par la virtualisation pour tester de nouveaux OS... En tout cas c'est ce que je fais.

C'est drôle, après avoir eu droit à tout un tas d'installations plus ou moins graphiques, j'ai trouvé que celle qui me convenait le mieux était celle d'OpenBSD. Une fois qu'on a compris le système de « slices », il y a très peu de questions, et l'installation est réglée en 15 minutes pour le système de base. Ça change de machins genre CentOS, Ubuntu ou autres, où il faut absolument passer par 36 écrans (certes, la plupart du temps il suffit de cliquer sur next, mais c'est long).

tant qu'on y est : « packet » => « paquet »

Euh, les Blue Gene/L et autres calculateurs d'IBM tournent quand même en grande majorité sous Linux ...

En 2005-2007, c'était de l'ordre de 30-36 k€ bruts / an pour un ingé fraîchement sorti de l'école.

certains codes assez malins sont organisés par exemple pour intercaler des additions de nombres positifs et négatifs pour éviter les dépassements, et il suffit d'un bête échange d'opération qui semble anodin pour faire un overflow

Juste une petite remarque : sur un processeur tel que le x86 ou le PowerPC, intercaler ce genre d'opération ne garantit absolument rien quant à l'ordre des opérations, vu que le système out-of-order va choisir dans quel ordre émettre les instructions (en fonction de la place restante dans la station de réservation). Ce qui pourrait presque rendre « caduque » certaines transformations du compilateur d'ailleurs. Tout dépend du coup de la chaîne de dépendances qui existe entre les registres (i.e. plus j'ai des registres dont le contenu sert à mettre à jour d'autres registres, moins l'exécution dans le désordre aura d'effet ... mais du coup plus on sera potentiellement limité dans le parallélisme d'instruction).

Mmmmh, ça sent la propagande crypto-communiste d'un prof de fac ça ... O:-) Bon bon. Sinon, je corrobore ce que dit Cédric.