Seulement si la quantité de travail à lui fournir ne varie pas. Ce qui généralement n'est pas le cas pour les centres de calcul (modèles plus précis nécessitant plus de puissance de calcul, ou bien tout simplement même modèle, mais avec une machine plus puissante, on traite des problèmes plus gros).
Ensuite, dans de « vrais » centres HPC, un cluster dure quand même au moins cinq ans. Étant donné le nombre de personnes qui l'utilisent, ça reste correct.
Je parle des implémentations de référence de Python (et oui, Ruby et Perl ont le même problème). IronRuby, IronPython ou Jython sont des exceptions, et quelque part c'est triste à dire, mais ils introduisent une incompatibilité si tu fais du « vrai » multithreading avec (techniquement, Python permet le multithreading pour le multiplexage des E/S). Donc je maintiens ce que je dis : Python, celui utilisé à peu près partout, ne supporte pas un multithreading « général ».
En même temps, une "université" US n'est pas du tout la même chose qu'une "Université" Française.
Nous sommes d'accord. En plus, je crois bien que ma fac veut vendre du temps de calcul aux boites alentours… ;-)
A moment, ils voulaient créer l'université de Paris, en fusionnant tous les numéros pour augmenter leur masse critique. Ainsi chaque université pourrait avoir son cluster mais réellement utilisé. Ou alors, il faut rendre obligatoire la disponibilité du cluster pour d'autre université pour les creux.
Houla, je ne pensais même pas jusque là. L'admin dont je parlais ne parlais QUE de sa région géographique. Il avait en tête deux universités (dont l'UTT) et un centre de recherche, qui pour des raisons plutôt « territoriales » voulaient chacun LEUR centre.
Vous avez combien d'admin pour les 2 noeud de calcul ? Cela ne serait pas mieux mutualisé, si les noeuds était à l'Idris ?
Dans le cas des nœuds AMD, le cluster complet a une équipe de sysadmins. Ça fait partie des coûts mutualisés d'infrastructure.
Dans le cas du nœud Intel, seul notre labo y a accès et donc nous nous chargeons de faire l'admin. Je suis dans un labo de « computer engineering », donc nous faisons plutôt la programmation de couches basses, et ça nécessite de pouvoir activer/désactiver certaines fonctionnalités du matériel, ce qui évidemment est impossible si on n'a pas un contrôle total du nœud de calcul (ce qui est le cas avec la machine AMD).
J'ai l'impression que les fac font leur tambouille juste pour éviter de la gestion administrative. Je me trompe ?
Je ne pourrais pas te dire. Je bosse dans une fac US. Dans notre cas je ne pense vraiment pas. Le cluster est réellement utilisé autant par les chimistes que les mécaniciens ou les informaticiens.
Après, je me souviens avoir discuté avec un admin (bossant à Troyes je crois bien), qui se désolait du fait que chaque fac ou centre de recherche voulait son cluster (qui du coup va être occupé à 25%), alors qu'il serait tellement plus économique qu'elles mutualisent les ressources et achètent un seul cluster partagé, avec une équipe d'admins uniques…
[à propos de l'overhead MPI dont les équipes HPC veulent se débarrasser] J'en suis persuadé, mais vous ne réutilisez jamais de code commun ou générique écrit uniquement en MPI ?
Si bien sûr, mais un bon runtime MPI va utiliser des segments de mémoire partagée pour éviter la duplication inutile de files de messages, lorsqu'on est en intra-nœud. Ensuite je me répète, mais si les centres de calcul utilisent de l'InfiniBand (ou du Quadrics pour les plus fortunés), c'est aussi parce que pour un débit pas forcément beaucoup important que du Ethernet 10Gbps, on a une latence inférieure de plusieurs ordres de grandeur… Et aussi que la fiabilité de ce genre de réseau comparé à Ethernet est bien meilleure.
Je parlais de java parce qu'on dit tant de bien de lui, alors que personnellement je n'ai jamais été convaincu par ce langage dès l'instant où python est arrivé.
Tu viens de démontrer une grande ignorance avec cette phrase. Python est arrivé en 1991. Java, bien qu'existant plus ou moins en interne chez Sun à ce moment, n'était même pas encore disponible pour le grand public (et puis, histoire d'être complet, Perl existe depuis 1987).
De plus tu ne connais visiblement pas bien les limites de chacun de ces langages. Java permet de faire du vrai multi-threading, pas Python.
Mon labo a acheté un nœud de calcul AMD (Bulldozer), 4 sockets, 12 cœurs par chip (techniquement 2×6 cœurs, m'enfin…), 128GB DDR3. Je crois que ça nous a coûté dans les 6000$ en tout. Certes, le cluster a été acheté par la fac, et ensuite les nœuds sont mutualisés : un nœud acheté par une entité pourra être utilisé par d'autres s'il est idle, ce qui je trouve est normal. Par contre, si je pousse du boulot sur notre file d'attente perso, alors j'ai priorité. Et aussi, tout ce qui est stockage a été mutualisé (avec du Lustre, etc.). Donc mon labo n'a pas eu à supporter le coût d'achat initial de l'infrastructure. Par contre, comme c'est un modèle extensible, on pourrait racheter un nœud si on le désirait. Je trouve que c'est un bon compromis : on fait payer l'infra à un groupe d'entités (en pratique, il s'agit ici de la fac pour laquelle je bosse), et on paie individuellement pour certaines ressources, à un prix correc'.
À l'opposé et pour aller dans ton sens, nous avons aussi acheté un nœud de calcul quad-socket pour SandyBridge (24 cœurs/48 threads en tout), avec aussi 128GB, et un peu de stockage. Celui-ci nous a coûté aux alentours de 10 000$, et en plus il faut que nous l'administrions nous-même.
Enfin, tout dépend œuf corse des applications à faire tourner. Pour certaines, la latence, tout autant que le débit, sont importants (je pense notamment aux applis qui font dans l'algèbre linéaire creuse, ou bien certains parcours de graphes, etc.). Pour d'autres, Ethernet suffit largement.
Cependant dans le cadre du HPC, je peux te garantir que si tu peux te passer de l'overhead de MPI et passer par de la mémoire partagée, le gain en vitesse, bien que « juste » constant, peut être significatif (×2, ×4, etc.). Je n'irais pas jusqu'à dire un ordre de grandeur, mais parfois presque. Ce n'est pas pour rien que pour les gros clusters (genre celui de ma fac), on passe par de l'infiniband : la latence est un tueur de perfs.
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 ?
Oui, il est possible d'écrire des programmes concurrents en C/C++ qui font ce qu'on veut
Si on veut faire quelque chose de complexe, il faut un programmeur expert pour le faire correctement
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.
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.
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.
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 :
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.
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.
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.
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-keme 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. :-)
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 2.
Seulement si la quantité de travail à lui fournir ne varie pas. Ce qui généralement n'est pas le cas pour les centres de calcul (modèles plus précis nécessitant plus de puissance de calcul, ou bien tout simplement même modèle, mais avec une machine plus puissante, on traite des problèmes plus gros).
Ensuite, dans de « vrais » centres HPC, un cluster dure quand même au moins cinq ans. Étant donné le nombre de personnes qui l'utilisent, ça reste correct.
[^] # Re: Proust alors.
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 2.
Je parle des implémentations de référence de Python (et oui, Ruby et Perl ont le même problème). IronRuby, IronPython ou Jython sont des exceptions, et quelque part c'est triste à dire, mais ils introduisent une incompatibilité si tu fais du « vrai » multithreading avec (techniquement, Python permet le multithreading pour le multiplexage des E/S). Donc je maintiens ce que je dis : Python, celui utilisé à peu près partout, ne supporte pas un multithreading « général ».
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 2.
Nous sommes d'accord. En plus, je crois bien que ma fac veut vendre du temps de calcul aux boites alentours… ;-)
Houla, je ne pensais même pas jusque là. L'admin dont je parlais ne parlais QUE de sa région géographique. Il avait en tête deux universités (dont l'UTT) et un centre de recherche, qui pour des raisons plutôt « territoriales » voulaient chacun LEUR centre.
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 2.
Dans le cas des nœuds AMD, le cluster complet a une équipe de sysadmins. Ça fait partie des coûts mutualisés d'infrastructure.
Dans le cas du nœud Intel, seul notre labo y a accès et donc nous nous chargeons de faire l'admin. Je suis dans un labo de « computer engineering », donc nous faisons plutôt la programmation de couches basses, et ça nécessite de pouvoir activer/désactiver certaines fonctionnalités du matériel, ce qui évidemment est impossible si on n'a pas un contrôle total du nœud de calcul (ce qui est le cas avec la machine AMD).
Je ne pourrais pas te dire. Je bosse dans une fac US. Dans notre cas je ne pense vraiment pas. Le cluster est réellement utilisé autant par les chimistes que les mécaniciens ou les informaticiens.
Après, je me souviens avoir discuté avec un admin (bossant à Troyes je crois bien), qui se désolait du fait que chaque fac ou centre de recherche voulait son cluster (qui du coup va être occupé à 25%), alors qu'il serait tellement plus économique qu'elles mutualisent les ressources et achètent un seul cluster partagé, avec une équipe d'admins uniques…
Si bien sûr, mais un bon runtime MPI va utiliser des segments de mémoire partagée pour éviter la duplication inutile de files de messages, lorsqu'on est en intra-nœud. Ensuite je me répète, mais si les centres de calcul utilisent de l'InfiniBand (ou du Quadrics pour les plus fortunés), c'est aussi parce que pour un débit pas forcément beaucoup important que du Ethernet 10Gbps, on a une latence inférieure de plusieurs ordres de grandeur… Et aussi que la fiabilité de ce genre de réseau comparé à Ethernet est bien meilleure.
[^] # Re: Proust alors.
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 2.
Tu viens de démontrer une grande ignorance avec cette phrase. Python est arrivé en 1991. Java, bien qu'existant plus ou moins en interne chez Sun à ce moment, n'était même pas encore disponible pour le grand public (et puis, histoire d'être complet, Perl existe depuis 1987).
De plus tu ne connais visiblement pas bien les limites de chacun de ces langages. Java permet de faire du vrai multi-threading, pas Python.
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 3.
Mon labo a acheté un nœud de calcul AMD (Bulldozer), 4 sockets, 12 cœurs par chip (techniquement 2×6 cœurs, m'enfin…), 128GB DDR3. Je crois que ça nous a coûté dans les 6000$ en tout. Certes, le cluster a été acheté par la fac, et ensuite les nœuds sont mutualisés : un nœud acheté par une entité pourra être utilisé par d'autres s'il est idle, ce qui je trouve est normal. Par contre, si je pousse du boulot sur notre file d'attente perso, alors j'ai priorité. Et aussi, tout ce qui est stockage a été mutualisé (avec du Lustre, etc.). Donc mon labo n'a pas eu à supporter le coût d'achat initial de l'infrastructure. Par contre, comme c'est un modèle extensible, on pourrait racheter un nœud si on le désirait. Je trouve que c'est un bon compromis : on fait payer l'infra à un groupe d'entités (en pratique, il s'agit ici de la fac pour laquelle je bosse), et on paie individuellement pour certaines ressources, à un prix correc'.
À l'opposé et pour aller dans ton sens, nous avons aussi acheté un nœud de calcul quad-socket pour SandyBridge (24 cœurs/48 threads en tout), avec aussi 128GB, et un peu de stockage. Celui-ci nous a coûté aux alentours de 10 000$, et en plus il faut que nous l'administrions nous-même.
Enfin, tout dépend œuf corse des applications à faire tourner. Pour certaines, la latence, tout autant que le débit, sont importants (je pense notamment aux applis qui font dans l'algèbre linéaire creuse, ou bien certains parcours de graphes, etc.). Pour d'autres, Ethernet suffit largement.
Cependant dans le cadre du HPC, je peux te garantir que si tu peux te passer de l'overhead de MPI et passer par de la mémoire partagée, le gain en vitesse, bien que « juste » constant, peut être significatif (×2, ×4, etc.). Je n'irais pas jusqu'à dire un ordre de grandeur, mais parfois presque. Ce n'est pas pour rien que pour les gros clusters (genre celui de ma fac), on passe par de l'infiniband : la latence est un tueur de perfs.
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 2.
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.
[^] # Re: Proust alors.
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 10.
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 ?
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 2.
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.
[^] # Re: La question a 1 giga yuan...
Posté par lasher . En réponse à la dépêche Sortie du Top 500 de juin 2013. Évalué à 3.
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.
[^] # Re: Il parait que...
Posté par lasher . En réponse au journal Overmon recherche des freelance. Évalué à 10.
Est-ce que quelqu'un a validé le formulaire avec le moteur du W3C?
… Quoi, qu'est-ce j'ai dit ?
[^] # Re: Superbe article !
Posté par lasher . En réponse à la dépêche LLVM 3.3 et Clang 3.3. Évalué à 5.
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.
[^] # Re: Pendant ce temps...
Posté par lasher . En réponse à la dépêche C++11 : sur le fil. Évalué à 2.
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!
[^] # Re: Et pendent ce temps chez Microsoft...
Posté par lasher . En réponse à la dépêche C++11 : sur le fil. Évalué à 2.
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.
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Perso j'utilise/utilisais
rdtscparce 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).[^] # Re: Un utilisateur reconnaissant
Posté par lasher . En réponse au journal Attention au dépôt debian-multimedia.org !. Évalué à 3.
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.
[^] # Re: Durée de l’épreuve
Posté par lasher . En réponse à la dépêche Concours de programmation CodinGame le 28 mai 2013. Évalué à 3.
Reponds en Anglais. Toujours repondre dans la langue dans laquelle on te parle, si tu sais la parler. :)
[^] # Re: Ai-je bien compris ?
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
J'ai pas, mais il a enfin réussi à récupérer un visa, donc il est de retour. Je lui demanderai. :)
[^] # Re: manipulations ?
Posté par lasher . En réponse au journal Méthode de calcul. Évalué à 2.
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.
[^] # Re: Ai-je bien compris ?
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
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.
[^] # Re: Ai-je bien compris ?
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Il y a des références dans cette présentation :
http://www.capsl.udel.edu/courses/eleg652/2012/slides/05_sm.pdf
[^] # Re: Ai-je bien compris ?
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
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.
[^] # Re: Ai-je bien compris ?
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
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-keme 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.
[^] # Re: Ai-je bien compris ?
Posté par lasher . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
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 devchanger au "même" moment. Les deux threads doivent donc s'accorder sur une séquence unique des valeurs successives dev.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,
xety, Je me fiche de savoir si T1 et T2 voient les écritures dexetyde façon totalement identique en tant que "paire" d'adresses mémoire , tant que les accès individuels axsont tous vus dans le même ordre par tous les threads, et que les accès ayidem.</pedantic>[^] # Re: Ça me choque
Posté par lasher . En réponse au journal Adblock maintenant installé par défaut sur Debian 7 : bonne chose ou initiative malheureuse ?. Évalué à 5.
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. :-)