Pour moi c'était pas tant un troll, que d'essayer de pousser la logique et comprendre jusqu'où cette feature est utile. Mes questions, aussi enquiquinantes soient-elles, sont de vraies questions, et ne sont pas là pour faire de la provoc' pure et dure. :-)
Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.
Oui, mais une fois que tu as codé ton truc avec des milliards de templates affreux, tu as sans doute une interface simple à utiliser (du genre de ce que je proposais). Et c'est écrit une fois pour toutes, et fonctionnera pour toutes les classes qui ont un comportement « prévisible » (i.e. qui implémentent les opérateurs de comparaison, affectation, etc., selon un mode de fonctionnement similaire aux opérations utilisables sur les types primitifs).
Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.
Pour info, je me considère comme « moyen » en C++ pour le langage lui-même, et j'ai mis moins d'une heure¹ pour créer un template de classe qui vérifie dynamiquement les bornes; je sais comment faire la même chose statiquement en théorie, mais comme je pratique peu la méta-programmation, il est évident que ça me prendrait beaucoup plus de temps à correctement programmer. Ceci étant dit, programmer la fonctionnalité des plages dans un compilateur Ada n'est pas nécessairement moins compliquée, et dans les deux cas, l'utilisateur final n'a pas à regarder l'implémentation. ;-)
[1] Évidemment, l'implémentation est sans doute ultra trouée dès qu'on utilisera un type non primitif. Heureusement, le compilo gueulera très certainement… ;-)²
[2] Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.
Dans ma dépêche, je réponds à toutes les questions que vous vous posez sûrement: mon mode de pensée justement n'a rien avoir avec la vanne en elle-même.
Le fait que tu rabâches la même chose depuis je ne sais quand montre quand même que « tu t'en fiches du karma », mais comme tu as l'air de mal comprendre comment il fonctionne (il faut que BEAUCOUP de gens te moinssent pour que tu en arrives là où tu en es, et il faut que quasiment aucun de tes commentaires ne soient plussés).
Surtout que ceux qui ont lu mes remarques et qui ont pris ce temps ont très bien compris que je m'en fiche du karma mais je pense aux autres…
Les autres n'ont qu'à réagir. Ils sont grands, qu'ils se débrouillent. Qu'ils fassent comme on fait dans la vraie vie quand on veut intégrer un groupe : on observe un minimum ses us et coutumes, la façon dont les gens se comportent vis-à-vis des autres, etc., jusqu'au moment où on se retrouve à participer plus activement. Et là, ben soit on a « bien » lu la façon dont fonctionne le groupe, soit pas.
Je trouve que les gens de LinuxFR ont globalement fait preuve de beaucoup de patience avec toi. C'est justement parce que, malgré la dureté des mots (parfois), ils sont tout de même ouverts à la discussion dans l'ensemble.
Si quelqu'un se retrouve avec un karma très négatif, et que c'est injuste, et qu'il en parle, figure-toi qu'il arrive qu'on lui porte assistance. Un bon exemple est PasBillPasGates. Certains zélotes anti-MS le moinssaient systématiquement au point qu'il commençait à -2 ou -4 directement. Sauf que, même si on peut être en désaccord avec lui, et qu'il est loin d'échapper à des accès de mauvaise foi (en même temps, LinuxFR est aussi appelé trollFR par d'autres, donc bon … ;-)), en fait très souvent il avait des réponses argumentées et détaillées (je l'ai très certainement plus pertinenté que non-pertinenté au total).
Donc je répète : laisse les autres se défendre un peu. S'ils ne font même pas l'effort de gueuler s'ils estiment qu'on les brime, je ne vois pas pourquoi nous on ferait un effort pour eux.
Tu es sûr de l'enchaînement des événements ? J'avais retenu limite le contraire : Sony update le firmware et vire OtherOS. Là-dessus GeoHot, qui avait une console jamais utilisée, commence à s'y intéresser, et trouve la faille (TLB stockée en RAM, qui permet ensuite d'accéder à l'hyperviseur).
Bref, Sony a eu peur d'un piratage qui, pour autant que je sache, n'était pas évident du tout (quand on offre aux hackers un peu d'ouverture, ils ont tendance à être contents et déjà explorer ce que le truc ouvert permet de faire). En fermant leur console, ils ont précipité l'intérêt pour casser ses protections.
Seulement si tu joues ET que tu te sers de la console comme PC. Sinon pour la PS3, Sony a été forcé de permettre aux clients de la versions « fat » de pouvoir rétrograder vers le dernier firmware OTHER_OS compatible.
« basé sur » ne signifie pas « reprend tous les éléments de ». Il est tout à fait possible que Grub soit considéré plus pratique pour les développements par ex. Ensuite, Mac OS X est « basé sur FreeBSD » aussi, mais presque tous les outils de ligne de commande sont des outils GNU (gmake et pas bsd make, etc.).
C'est un peu l'objet de certaines blagues sur reddit/imgur : le fait que MS fasse sa campagne de pub sur le mode « jouez avec des gens de partout dans le monde », et en pratique, « tout le monde », ça veut dire « Amérique du Nord », une partie de l'Europe (je ne suis même pas certain que toute l'UE soit couverte), une partie de l'Asie, etc.
Ça fait un peu penser aux « coupes du monde » (baseball, foot US) qui pendant longtemps n'étaient finalement ouvertes qu'aux états US. Forcément, être champion du monde ça devient plus simple tout à coup. ;-)
Là tu vois, être à -10, c'est parfaitement justifié : pas pertinent sur ton propre sujet de journal, pleurnicheur (si si, tu peux dire que tu ne fais constater les faits, tout ça, n'empêche que tu pleurniches), et limite condescendant.
Ensuite, penser que « kadalka, c'est tabou ici » c'est penser bien trop de ta personne. Même si c'est une « blague », ça explique pas mal ton mode de pensée en ce moment.
Passer de -10 à +10, peut-être pas (quoique je suis certain d'avoir vu la chose arriver ici même). Par contre, passer d'une note très négative (même -10) à +5/+6, ça arrive tout le temps. C'est juste que les mecs pas d'accord (rarement ceux qui pensent que c'est pas pertinent) sont passés avant les autres (ceux qui sont d'accord, et ceux qui pensent que le contenu est pertinent sans être forcément d'accord).
Soit dit en passant, on s'en fiche un peu qu'Intel bosse plus sur Linux que sur F/BSD ou autre OS. Tout simplement parce que le matos de la PS4 et de l'X-Box One tourne sur de l'AMD (d'ailleurs tu as bien mis un lien vers AMD dans ton journal).
Ensuite, grosse surprise, AMD travaille AUSSI plus sur Linux que F/BSD. Mais je ne vois vraiment pas où est le problème. Soit Sony a des programmeurs systèmes expérimentés, et Linux, F/BSD, etc., ça ne les dérangera pas plus que ça; soit pas.
Soit je peux déterminer, à la compilation, la valeur d'une variable dont je veux limiter la plage de valeurs. Dans ce cas, je ne vois pas bien où est le souci (un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques). Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution. Mais je ne vois pas en quoi ce serait différent avec Ada.
Je ne sais pas ce que « compilateur parallèle » signifie. Intel a une option de parallélisation « automatique » qui n'est mise en œuvre que lorsque les boucles sont triviales à paralléliser (pas de dépendance portée sur plus d'une itération, etc.). Sinon, icc comme gcc implémentent OpenMP, qui nécessite une parallélisation explicite d'un programme écrit en C/C++ (ou Fortran avec ifort/gfortran).
Bien que je sois d'accord sur l'utilité évidente d'établir des plages de valeurs pour un « même type » directement dans le langage, au final ça revient malgré tout à créer deux types différents et laisser le système de typage (fort) faire son boulot. En C++ on ferait sans doute ça en créant une interface avec template, quelque chose qui aurait une interface du genre:
typedefRange<unsigned,0U,65535U>u16;// on pourrait sans doute faire sans le unsigned
… Avec toutes les opérations de surcharges d'opérateurs qui vont bien œuf corse (qui peut être facilité grâce à l'utilisation de Boost). Au final le système de typage ferait aussi son boulot.
Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.
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.
[^] # Re: Mmmh
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 2.
Pour moi c'était pas tant un troll, que d'essayer de pousser la logique et comprendre jusqu'où cette feature est utile. Mes questions, aussi enquiquinantes soient-elles, sont de vraies questions, et ne sont pas là pour faire de la provoc' pure et dure. :-)
[^] # Re: Mmmh
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 3.
Oui, mais une fois que tu as codé ton truc avec des milliards de templates affreux, tu as sans doute une interface simple à utiliser (du genre de ce que je proposais). Et c'est écrit une fois pour toutes, et fonctionnera pour toutes les classes qui ont un comportement « prévisible » (i.e. qui implémentent les opérateurs de comparaison, affectation, etc., selon un mode de fonctionnement similaire aux opérations utilisables sur les types primitifs).
Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.
Pour info, je me considère comme « moyen » en C++ pour le langage lui-même, et j'ai mis moins d'une heure¹ pour créer un template de classe qui vérifie dynamiquement les bornes; je sais comment faire la même chose statiquement en théorie, mais comme je pratique peu la méta-programmation, il est évident que ça me prendrait beaucoup plus de temps à correctement programmer. Ceci étant dit, programmer la fonctionnalité des plages dans un compilateur Ada n'est pas nécessairement moins compliquée, et dans les deux cas, l'utilisateur final n'a pas à regarder l'implémentation. ;-)
[1] Évidemment, l'implémentation est sans doute ultra trouée dès qu'on utilisera un type non primitif. Heureusement, le compilo gueulera très certainement… ;-)²
[2] Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.
[^] # Re: La vraie question
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 6.
Le fait que tu rabâches la même chose depuis je ne sais quand montre quand même que « tu t'en fiches du karma », mais comme tu as l'air de mal comprendre comment il fonctionne (il faut que BEAUCOUP de gens te moinssent pour que tu en arrives là où tu en es, et il faut que quasiment aucun de tes commentaires ne soient plussés).
Les autres n'ont qu'à réagir. Ils sont grands, qu'ils se débrouillent. Qu'ils fassent comme on fait dans la vraie vie quand on veut intégrer un groupe : on observe un minimum ses us et coutumes, la façon dont les gens se comportent vis-à-vis des autres, etc., jusqu'au moment où on se retrouve à participer plus activement. Et là, ben soit on a « bien » lu la façon dont fonctionne le groupe, soit pas.
Je trouve que les gens de LinuxFR ont globalement fait preuve de beaucoup de patience avec toi. C'est justement parce que, malgré la dureté des mots (parfois), ils sont tout de même ouverts à la discussion dans l'ensemble.
Si quelqu'un se retrouve avec un karma très négatif, et que c'est injuste, et qu'il en parle, figure-toi qu'il arrive qu'on lui porte assistance. Un bon exemple est PasBillPasGates. Certains zélotes anti-MS le moinssaient systématiquement au point qu'il commençait à -2 ou -4 directement. Sauf que, même si on peut être en désaccord avec lui, et qu'il est loin d'échapper à des accès de mauvaise foi (en même temps, LinuxFR est aussi appelé trollFR par d'autres, donc bon … ;-)), en fait très souvent il avait des réponses argumentées et détaillées (je l'ai très certainement plus pertinenté que non-pertinenté au total).
Donc je répète : laisse les autres se défendre un peu. S'ils ne font même pas l'effort de gueuler s'ils estiment qu'on les brime, je ne vois pas pourquoi nous on ferait un effort pour eux.
[^] # Re: Grub
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 5.
Tu es sûr de l'enchaînement des événements ? J'avais retenu limite le contraire : Sony update le firmware et vire OtherOS. Là-dessus GeoHot, qui avait une console jamais utilisée, commence à s'y intéresser, et trouve la faille (TLB stockée en RAM, qui permet ensuite d'accéder à l'hyperviseur).
Bref, Sony a eu peur d'un piratage qui, pour autant que je sache, n'était pas évident du tout (quand on offre aux hackers un peu d'ouverture, ils ont tendance à être contents et déjà explorer ce que le truc ouvert permet de faire). En fermant leur console, ils ont précipité l'intérêt pour casser ses protections.
[^] # Re: Orbis OS
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 2.
Seulement si tu joues ET que tu te sers de la console comme PC. Sinon pour la PS3, Sony a été forcé de permettre aux clients de la versions « fat » de pouvoir rétrograder vers le dernier firmware OTHER_OS compatible.
[^] # Re: Grub
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 2.
« basé sur » ne signifie pas « reprend tous les éléments de ». Il est tout à fait possible que Grub soit considéré plus pratique pour les développements par ex. Ensuite, Mac OS X est « basé sur FreeBSD » aussi, mais presque tous les outils de ligne de commande sont des outils GNU (gmake et pas bsd make, etc.).
[^] # Re: drôle d'interrogation
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 5.
C'est un peu l'objet de certaines blagues sur reddit/imgur : le fait que MS fasse sa campagne de pub sur le mode « jouez avec des gens de partout dans le monde », et en pratique, « tout le monde », ça veut dire « Amérique du Nord », une partie de l'Europe (je ne suis même pas certain que toute l'UE soit couverte), une partie de l'Asie, etc.
Ça fait un peu penser aux « coupes du monde » (baseball, foot US) qui pendant longtemps n'étaient finalement ouvertes qu'aux états US. Forcément, être champion du monde ça devient plus simple tout à coup. ;-)
[^] # Re: La vraie question
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 5.
Là tu vois, être à -10, c'est parfaitement justifié : pas pertinent sur ton propre sujet de journal, pleurnicheur (si si, tu peux dire que tu ne fais constater les faits, tout ça, n'empêche que tu pleurniches), et limite condescendant.
Ensuite, penser que « kadalka, c'est tabou ici » c'est penser bien trop de ta personne. Même si c'est une « blague », ça explique pas mal ton mode de pensée en ce moment.
[^] # Re: La vraie question
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 3.
Passer de -10 à +10, peut-être pas (quoique je suis certain d'avoir vu la chose arriver ici même). Par contre, passer d'une note très négative (même -10) à +5/+6, ça arrive tout le temps. C'est juste que les mecs pas d'accord (rarement ceux qui pensent que c'est pas pertinent) sont passés avant les autres (ceux qui sont d'accord, et ceux qui pensent que le contenu est pertinent sans être forcément d'accord).
[^] # Re: La vraie question
Posté par lasher . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 5.
Soit dit en passant, on s'en fiche un peu qu'Intel bosse plus sur Linux que sur F/BSD ou autre OS. Tout simplement parce que le matos de la PS4 et de l'X-Box One tourne sur de l'AMD (d'ailleurs tu as bien mis un lien vers AMD dans ton journal).
Ensuite, grosse surprise, AMD travaille AUSSI plus sur Linux que F/BSD. Mais je ne vois vraiment pas où est le problème. Soit Sony a des programmeurs systèmes expérimentés, et Linux, F/BSD, etc., ça ne les dérangera pas plus que ça; soit pas.
[^] # Re: Mmmh
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 1.
Je ne comprends pas bien.
Soit je peux déterminer, à la compilation, la valeur d'une variable dont je veux limiter la plage de valeurs. Dans ce cas, je ne vois pas bien où est le souci (un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques). Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution. Mais je ne vois pas en quoi ce serait différent avec Ada.
[^] # Re: Mmmh
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 2.
Si je fais
Je ne vois pas trop ce qui est gênant (contrairement au C, C++ n'acceptera pas qu'on substitue un
intà unenumn'importe comment).[^] # Re: Mmmh
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 2.
Oui, j'aurais dû être plus précis, car c'était bien là que je voulais en venir.
[^] # Re: Proust alors.
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 2.
Je ne sais pas ce que « compilateur parallèle » signifie. Intel a une option de parallélisation « automatique » qui n'est mise en œuvre que lorsque les boucles sont triviales à paralléliser (pas de dépendance portée sur plus d'une itération, etc.). Sinon,
icccommegccimplémentent OpenMP, qui nécessite une parallélisation explicite d'un programme écrit en C/C++ (ou Fortran avecifort/gfortran).[^] # Re: Mmmh
Posté par lasher . En réponse au journal Ada, langage et ressources. Évalué à 4.
Alors j'ai une remarque et une question.
Ma remarque d'abord :
"sa" (désolé mais ça me piquait les n'œils).
La question ensuite :
Bien que je sois d'accord sur l'utilité évidente d'établir des plages de valeurs pour un « même type » directement dans le langage, au final ça revient malgré tout à créer deux types différents et laisser le système de typage (fort) faire son boulot. En C++ on ferait sans doute ça en créant une interface avec template, quelque chose qui aurait une interface du genre:
… Avec toutes les opérations de surcharges d'opérateurs qui vont bien œuf corse (qui peut être facilité grâce à l'utilisation de Boost). Au final le système de typage ferait aussi son boulot.
Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.
[^] # 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.