lasher a écrit 2732 commentaires

Bon, désolé alors. ;-)

Si tu es rigoureux, genre tu ne modifies tes paramètres que si tu as une certitude (quasi)-absolue que modifier plus d'un ne va pas avoir d'impact sur les autres params, et si tu es capable de réiterer l'expérience et d'obtenir les mêmes résultats (et par « tu » ici je veux surtout dire « la communauté scientifique »), alors la démarche est scientifique.

En informatique on pourrait croire que ce genre de choses est facile à faire, mais malheureusement, il existe tout un tas de papiers qui montrent des méthodes qui certes semblent convenir, mais malheureusement ne fournissent pas le code (parfois parce que ledit code est propriétaire/placé chez un client, parfois par réelle malhonnêteté, etc.). Et donc reproduire les résultats, ou bien se comparer à ceux desdits papiers est parfois difficile. Parfois simplement la méthode est bonne, mais sans les détails d'implémentation (et donc il faut aller au-delà de l'algorithme proposé dans le papier) sont cachés, et ceux-ci sont primordiaux.

[à propos de la sûreté des langages de programmation] Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.

Je code en C et C++ très régulièrement. En fait, ce sont presque les deux seuls langages que j'utilise. J'écris et j'utilise du code multithreadé à longueur de journée. En fait, une partie de mon boulot consiste à maintenir une bibliothèque pour l'expression de programmes parallèles.

Le C, par définition, n'est pas sûr pour le multi-tâche. Plus exactement, C89 et C99 ne le sont pas, car ils ne savent pas ce qu'est une tâche. C11 a repris le même concept de tâche que C++11, et ça copie plus ou moins les threads POSIX. Bon ben autant dire qu'on est toujours pas dans le « sûr » par défaut.

En fait, l'un des créateurs du modèle mémoire de C++, J.Boehm (quand on suppose un processus séquentiel, pas besoin de modèle mémoire, mais une fois qu'on parle d'un modèle multi-tâches, alors il faut pouvoir décrire les règles de visibilité de lectures/écritures) a même écrit un papier qui s'intitule Threads Cannot Be Implemented as a Library. Un autre, grand expert des modèles d'exécution parallèles, a écrit un excellent article intitulé The Problem With Threads. Dans son papier, il décrit toutes les jolies propriétés liées aux machines séquentielles de Turing. Il explique en quoi c'est extrêmement important pour garantir que les programmes séquentiels sont corrects. Puis il explique comment, dès qu'on a des threads de type PThreads, toutes ces garanties s'envolent par la fenêtre, et qu'il est impossible de prouver qu'un programme multi-threadé est dépourvu de bogues et de race conditions (ou data races). Il propose ensuite un modèle où tout est déterministe par défaut, et seules des régions précises de code sont marquées comme « non-déterministes ». Bref, l'inverse de ce que proposent les threads classiques.

Tout ça pour dire quoi ?

1. Oui, il est possible d'écrire des programmes concurrents en C/C++ qui font ce qu'on veut
2. Si on veut faire quelque chose de complexe, il faut un programmeur expert pour le faire correctement
3. Si un langage de programmation intègre la concurrence directement (Java, Ada par ex), alors il est possible de simplifier la gestion de la concurrence car un ensemble de règles (liées à la mémoire, aux opérations autorisées au sein du programme, etc.) rendront la gestion de la concurrence mieux encadrée.
4. En règle générale, si quelque chose requiert un expert pour être correctement programmée, alors il faut sans doute qu'elle soit intégrée au langage.
5. Seule exception à la règle précédente : lorsque le contrôle sur le matériel est un critère dominant dans les pré-requis du projet (et encore, Ada et d'autres langages ont prouvé qu'on pouvait faire du bas-niveau sans sacrifier nécessairement en perfs ou en structures pour le langage…)

Le principe-même de faire bouger un paramètre à la fois pour observer les conséquences sur le résultat final c'est très très clairement une méthodologie scientifique.

Un quad-socket coûte notablement plus qu'un bi-socket tout simplement parce que tu y gagnes en latence et sur le fait que tu partages de la mémoire. C'est un plus indéniable sur un truc genre Ethernet (même 10Gbps). En HPC une faible latence (oublions la mémoire partagée 2s) est quelque chose d'extrêmement précieux.

Est-ce que quelqu'un a validé le formulaire avec le moteur du W3C?

… Quoi, qu'est-ce j'ai dit ?

Histoire d'être un peu plus précis : LLVM génère du code assembleur et objet (.o). Il s'appuie toujours (pour le moment) sur GNU ld/gold pour la résolution des liens (ça va bientôt changer). Donc si je reprends ton schéma :

Clang → LLVM → fichier objet → linker → executable.

Autant j'aime bien VS en tant qu'IDE, autant les rares fois où j'ai utilisé XCode (qui a fait des progrès depuis que je l'ai utilisé, certes), j'ai trouvé que c'était vraiment tout pourri. Après comme mon expérience date beaucoup, je me suis tourné vers des gens qui développent professionnellement pour Mac OS X / iOS. Ils trouvent que cet IDE est vraiment lourd est pas pratique, notamment comparé à VS. Mais aussi (surprise!) comparé à NetBeans!

Visual Studio n'implémentera sans doute jamais C99 dans sa totalité. Seules les fonctionnalités qui se recoupent avec C++ le seront. C'est dit quelque part sur le site de Herb Sutter. En gros : VSC++ != VSC (qui n'a jamais existé). Sutter dit qu'ils se concentrent uniquement sur l'implémentation de C++. Le reste est un effet de bord bonus.

Perso j'utilise/utilisais rdtsc parce que ca me permet d'avoir un nombre de cycles plutot qu'un nombre de nanosecondes. C'est important, car j'etais reellement au cycle pres, et que certains effets dus aux latences/debits memoire peuvent influer sur la performance finale (par ex: un processeur a 1GHz avec un bus a "1333MHz", la latence pour acceder a la memoire sera minime, alors que pour le meme bus memoire avec un proc. a 3GHz, les latences auront triple).

Non : c'est par défaut en fait sous Windows, c'était une exemple, mais chut, on note la non connaissance sur les autres OS.

Ma « nouvelle » machine sous Windows 7 y'a 1-2 ans avait le windows media player installé par défaut. J'ai essayé de l'utiliser histoire de voir comment ça avait changé. Bon ben, un « l'application ne répond plus » plus tard (et en fait, plusieurs, je voulais voir si c'était restreint à une seule vidéo), j'ai fini par faire comme d'hab : installer VLC. Et en règle générale sous Windows, j'ai toujours fini par avoir sous le coude une « check-list » des softs à installer (7zip, filezilla, vlc, etc.), car Windows est trop limité sinon.

Reponds en Anglais. Toujours repondre dans la langue dans laquelle on te parle, si tu sais la parler. :)

J'ai pas, mais il a enfin réussi à récupérer un visa, donc il est de retour. Je lui demanderai. :)

Avec ces discours-là, on se retrouve avec des Américains qui disent que le parti démocrate est de gauche, et les républicains de droite. La bonne blague. La Gauche et la Droite sont effectivement bien définies. Je te propose d'aller sur le site de Political Compass pour te faire une idée. Ils ont une explication de la façon dont ils positionnent les hommes politiques sur leur grille 2D. Grosso-modo, ils ont un axe horizontal « Gauche-Droite » qui prend en compte la politique économique de la personne considérée, et un axe vertical « libertaire-autoritaire » concernant les contraintes imposées aux individus par l'État.

J'en profite pour rajouter une autre référence (mêmes auteurs) :
Verification of Causality Requirements in Java is Undecidable. C'est quand même ballot. :-)

Un de mes collègue a aussi pu montrer un exemple de code multithreadé qui peut être « optimisé » en respectant les règles du modèle mémoire de Java, et qui malgré tout provoquera une exécution non conforme aux souhaits du programmeur.

Enfin, juste pour que nous soyons d'accord : je suis d'accord avec toi sur le fond : quand un langage intègre un modèle mémoire, c'est beaucoup mieux, et ça autorise la création de programmes concurrents dont le comportement est prévisible. Encore faut-il que le modèle en question soit correct/implémentable. Même un environnement tel qu'OpenMP qui est d'une certaine manière plus simple que le modèle mémoire de Java est extrêmement complexe à prouver en tant que modèle mémoire.

Il y a des références dans cette présentation :
http://www.capsl.udel.edu/courses/eleg652/2012/slides/05_sm.pdf

Bah, le modèle SPARC v9 (RMO, Relaxed Memory Order) propose différents types de barrières mémoire: celles qui stoppent tout tant que toutes les opérations en cours ne sont pas terminées; celles qui permettent d’exécuter des loads spéculativement; celles qui permettent d'exécuter des loads et des d’exécuter stores spéculativement (tant que les dépendances de données sont respectées); et même d'émettre des loads spéculativement malgré la présence d'une dépendance de contrôle.

Tu veux dire comme Java ? Parce que le premier modèle est cassé, et que le second (qui date de 2005) permet des trucs qui en pratique autorisent de briser la causalité.

Pour C++-11, ils ne se sont pas trop trop foulés : le principe-même d'un modèle mémoire c'est de définir la sémantique des "conflits" de lecture-écriture (data race). En disant "toute data race est un UB", en gros les gens de C-11 et C++-11 disent simplement "si tu as une data race, tout peut arriver, même que le compilo génère du code pour t'acheter 20000 big macs via le net en utilisant ta carte de crédit".

Le problème, c'est qu'il existe quelques (rares) cas ou les data races sont correctement contrôlées, i.e. on sait qu'il existe un conflit lecture/écriture sur une adresse mémoire, mais on sait évaluer l'amplitude de l'erreur, ou bien on n'a pas besoin de la toute dernière valeur de la variable, la n-k^eme valeur est OK aussi. C'est le cas dans les solveurs à relaxation chaotique par exemple. Avec C++, il est impossible de garantir quoi que ce soit, parce que le compilateur, pour des raisons d'optimisation, va peut-être mettre une valeur arbitraire a l'adresse de la variable ciblée.

Bon, "Sequential consistency" ça va beaucoup plus loin que "cohérent".

<pedantic>
Sequential consistency (SC—"Constance séquentielle" ?) garantit que tous les threads d'une machine a mémoire partagée voient les lectures et écritures mémoire dans un ordre identique. En pratique le matériel n'a pas a garantir que l'ordre des opérations est strictement identique, mais il doit apparaître comme si. Donc si j'ai 2 threads, dont l'un des deux au moins écrit dans une variable v, lorsque T0 écrit, alors T1 doit voir la séquence des valeurs de v changer au "même" moment. Les deux threads doivent donc s'accorder sur une séquence unique des valeurs successives de v.

La cohérence ("Cache consistency" ou "Coherence") relaxe fortement SC. Désormais, l'ordre des opérations se fait adresse mémoire par adresse mémoire. Ainsi, si j'ai 2 threads (T0,T1) et deux variables, x et y, Je me fiche de savoir si T1 et T2 voient les écritures de x et y de façon totalement identique en tant que "paire" d'adresses mémoire , tant que les accès individuels a x sont tous vus dans le même ordre par tous les threads, et que les accès a y idem.
</pedantic>

Ah oui ? Mais quand j'installe un "flash blocker" (ou tout simplement que je n'ai pas de plugin flash installé avec mon navigateur), alors du coup j’empêche les sites web de diffuser leur pub "interactive" (lemonde.fr est un habitué du fait) ! Damn ! Vite, vite, il faut que j'installe Flash !

Et puis quand Flash aura disparu mais qu'une autre techno l'aura remplacé, au début ce sera OK, car une pub interactive en 3D et odoramat de temps en temps, ça va. Mais quand tout le monde voudra te faire sentir ton camembert en même temps que la nouvelle recette de Saupiquet, on verra si la recrudescence de bloqueurs d'odoramat ne se fera pas sentir. :-)

L’équipe dont je faisais partie se spécialise dans la création d'outils pour la mesure et l'analyse de performance. Ce sont loin d’être des manches. Tout ce dont tu parles, nous le savons bien. ;-) J'ai passé une soirée de rêve avec mon directeur à l’époque à utiliser gdb et essayer de comprendre ce qui se passait avec la MKL (multiplication de matrices) sur Itanium 2.

L’expérience joue un énorme rôle aussi. Faire la course aux cache misses (par exemple) n'est pas toujours payante car on sous-estime d'autres facteurs qui pourraient jouer sur la (non-)performance d'une application.

Pour répondre a ta deuxième question, je fais de la recherche dans une fac aux USA, mais pas en analyse/mesure de performance. Je fais dans les modèles d’exécution pour machines parallèles (c'est a dire : modèle de concurrence, modèle mémoire, et modèle de synchronisation). On implémente tout ça dans un runtime (que j’espère pouvoir libérer très bientôt).

Il fallait comprendre : "30 personnes par type de processeur". :)

Mon expérience sur du multicœur un peu massif (AMD Bulldozer/Interlagos 48 cœurs en mémoire partagée, NUMA, 4×12 cœurs) est contraire à la tienne. Tant qu'il n'y avait pas de frequency scaling et un FSB (sur archi Intel Core 2/Core 2 Quad), tout allait bien en utilisant la bonne version de rdtsc. Le moment où tu as de la variation dynamique de tension et de fréquence, avec en plus plusieurs processeurs reliés entre eux par un réseau d'interconnexion souvent un peu douteux, j'ai appris à mes dépends que rdtsc passait à la trappe (j'ai eu plusieurs fois droit à des comportements très étranges où je me trouvait au final avec un temps négatif, malgré mes précautions …).

Tu as tort. Utiliser rdtsc est parfaitement logique surtout si ton bench prend peu de temps (après tout, les risques de modification de fréquence sont bien moindres). Ça n'empêche pas qu'il faut une certain stabilité. Généralement lorsque je fais des micro-benchmarks, j'utilise un truc du genre:

for ( outer = 0; outer < MAX_OUTER; ++outer) {
    FLUSH_CACHES();
#if OBSERVE_IN_CACHE_BEHAVIOR
    run_kernel(); // warm up caches 
#endif
    uint64_t exec_time = read_rdtsc();
    for (inner = 0; inner < MAX_INNER; ++inner) {
        run_kernel();
    }
    exec_times[outer] = (double) (read_rdtsc() - exec_time) / MAX_INNER;
}
/* ... */

/* exec_times[] contient un « histogramme » des différentes exécutions */
REMOVE_OUTLIERS(exec_times,MAX_OUTER); // supprime les temps les plus courts et les plus longs en fonction de lubies statistiques

COMPUTE_MEAN(exec_times, MAX_OUTER); // arithmétique, harmonique, etc., en fonction des besoins

Note que MAX_INNER/MAX_OUTER peuvent être extrêmement petits dans le cas de microbenchmarks, surtout si l'environnement de benchmarking permet de fixer un thread sur un cœur donné : on évite les variations dues à l'ordonnanceur qui est moins con qu'avant, mais qui va quand même réordonnancer certains threads pour les remettre sur le même cœur juste après… mais avec des caches et TLB qui ont eu droit à des entrées évincées.

Maintenant ce que j'appelle « micro-benchmarks », ce sont vraiment de minuscules benchs, où je teste un sous-système de mon micro-processeur. Genre je veux tester la latence réelle de mon cache L3 partagé : je vais faire tourner 4 threads en parallèle sur mon core i7, un par cœur. Ensuite je vais m'assurer que chaque thread copie un mot de 64 bits dans un registre, puis copie le (i+8×k)è mot dans le même registre à l'itération suivante, etc. J'ai besoin de faire i+8×k car les prefetchers des archis x86 ont tendance à rapatrier la ligne de cache adjacente lors d'un défaut de cache. Du coup il faut précharger au moins tous les 16 mots. L'autre problème étant que, au moins pour les micro-archis Intel, il existe un « stride préfetcher » (« préchargeur de distance » ? je ne sais pas comment traduire). Il détecte tout seul comme un grand si la distance entre deux mots mémoire est fixe. Si c'est le cas, il va précharger les mots mémoire suivants sans qu'on lui demande quoi que ce soit (dans la limite d'une page mémoire, donc pas au-delà de 4096 octets). Du coup il faut faire son sioux, et précharger un mot aléatoire dans la ligne de cache « suivante ».

Soupir…

Désolé pour le HS complet. J'ai pas pu m'empêcher. :)

Bon alors, dans le principe je suis d'accord. En pratique, comme dirait mon ancien directeur de thèse, « il y a peut-être 20 ou 30 personnes dans le monde qui savent réellement quels compteurs utiliser et ce qu'ils font (et ceux qui existent mais qui ne compte pas ce qu'on croit) ».

J'ai fait de l'analyse de performance pendant très longtemps. J'ai mis grosso modo un an à me retrouver avec un tout petit sous ensemble de compteurs qui comptent ce qu'il faut et dont je suis certain de ce qu'ils comptent. Et ce savoir est déjà dépassé : de Core 2/Core Quad on est passé à Nehalem, puis à Sandy Bridge… Ben mon savoir sur Nehalem était déjà à moitié faux (en plus du fait que certains compteurs avaient été renommés, et donc il fallait de nouveau tester ce qu'ils comptaient pour de vrai), et depuis les Sandy/Ivy Bridge, ben il y a peut-être 3 compteurs dont je suis sûr. :-)

Ceci étant dit, j'ai pas fait d'analyse de perf depuis un bail, mais mon directeur (avec qui j'ai causé y'a quelques jours) me disait que comparé aux autres outils existants (HPCToolKit, PAPI, PerfMon), Linuxperf est définitivement le plus fiable, au moins sur x86/Intel (à l'époque j'avais été regarder comment PAPI comptait certains événements dont j'avais besoin, et j'ai remarqué qu'ils prenaient le mauvais compteur… J'ai arrêté d'utiliser PAPI).