lasher a écrit 2732 commentaires

Oui, je suis bien d'accord. Pedobear, c'est vraiment toi.

Mon problème avec de type de raisonnement, c'est que c'est forcément la prime au dernier arrivé.Pour s'imposer dans un marché saturé, Free est forcément obligé d'essayer de casser les prix. Est-ce pour cela de forcément les autres se sont foutus de la gueule du monde ?

Oui.

Une amie qui n'est passée que par la fac (agrégée de maths, docteur en crypto tout ça tout ça) me disait que de son point de vue, avant l'année de licence (donc L3 désormais), elle trouvait qu'on n'apprenait pas réellement à faire des démonstrations en maths. Selon ce qu'elle me disait, on apprend à redémontrer, mais pas forcément à démontrer « tout court ». Donc de ce point de vue, pour elle, DEUG ou prépa, c'est kifkif. :)

Oui. Moralité : si tu veux intégrer une école après une licence (ou même valider la licence !) il faut bosser. Sans doute autant qu'en prépa pour aller dans une grande école, et en tout cas pas mal si tu veux ta licence. Du coup, l'avantage de la prépa c'est que l'élève est forcé de bosser régulièrement (à cause des devoirs maison hebdomadaires, des colles, etc.), là où la fac laisse l'étudiant libre de glander, et de se souvenir que le partiel a lieu dans une semaine, sans aucune note intermédiaire pour le rattraper...

Aux USA ils ont tout compris: « corporations are people » ! (et je déconne pas)

Ah ben c'est bon à savoir pour quand/si je reviens en France pour de bon... :)

Manque de bol, une période d'essai, c'est deux fois trois mois au mieux ... :)

J'ai plussoyé. Cependant, j'ai un problème avec cette partie de ton commentaire :

Enfin, le logo CC-by-NC-ND apposé sur chaque page est incompatible avec le FLOSS (au sens de la FSF et au sens de l'opensource selon l'OSI) : est-ce voulu ? C'est peut-être un choix un peu rapide d'une licence affichée pour les contenus, incompatible d'ailleurs avec le § legal indiqué ci-dessus ?

FLOSS = « Free and Libre Open Source Software ». Il dit qu'il voit pas le rapport avec un logo qui par essence n'est pas du logiciel.

Il dit surtout qu'il faudrait qu'il lise plus soigneusement... (j'ai barré la vilaine phrase). Donc euh oui, du coup, je suis d'accord avec ce que tu dis finalement, c'est bizarre d'avoir des contenus explicitement « à la discrétion de l'auteur du document » et dans le même temps de déclarer tout en CC-by-NC-ND… Est-ce que ce ne serait pas plutôt la « forme » du site plus que le contenu (sa structure, etc.) qui est concernée dans ce cas ?

Ouaiiis, je suis d'accord !

... Bon OK, j'ai fait un IUT puis une école d'ingé, mais, même, il faut en chier ! Aussi, le coup de « ça forge le caractère », merci bien, mais ça ira. On m'avait aussi dit ça à propos de passer la bite au cirage.

Plus sérieusement, je pense que la filière prépa est bonne, mais ce que beaucoup de gens oublient, c'est que le programme entre MPSI/PCSI est le même que pour les licences en fac¹. Simplement, au lieu de faire le programme en deux années scolaires, on le fait en une année et demie à cause ... des concours. Je pense que les deux sont plutôt complémentaires, mais je connais un bon nombre d'ingés qui sont passés par autre chose que la prépa et qui n'ont eu aucun problème majeur à intégrer une école.

Pour connaître certaines facs relativement bien, je peux aussi dire que pas mal de cours d'info sont de bonne qualité, et qu'il n'est pas besoin d'aller en école (même si, il faut bien l'avouer, les moyens en école sont souvent plus gros qu'en fac, pour des effectifs plus réduits).

En ce qui concerne les « fondamentaux » j'ai tendance à être d'accord, même si ça dépend aussi beaucoup de ton activité. Un pote bosse pour une boite qui fait de la géolocalisation, donc tout ce qui est algo et géométrie est super important pour son boulot. J'ai fait de la micro-optimisation de code pour calcul haute-performance : la base des probas pour vérifier que mes tests et mes résultats veulent dire quelque chose est suffisante. Par contre, il a fallu que je me tape des révisions d'algèbre linéaire pour piger comment certaines optimisations de programme peuvent être accomplies. Mais tu sais quoi ? On voit ça pendant 2 trimestres en IUT. :-)

[1] Exception faite des prépas « étoile »

À ma connaissance, les cours magistraux et TD ne sont pas obligatoires à la fac (alors qu'en STS, IUT, et la plupart des écoles d'ingé, si). J'avais dû m'absenter en urgence pendant près de deux semaines, et quand j'ai demandé à mon responsable des études où il fallait que je donne un justificatif il m'a répondu que « Depuis 68, plus besoin de justification ».

On prend le CV, et on barre la liste des competences qui sont directement lies a l'enseignement recu par le candidat.

Sur mon CV il y avait marqué « Perl » dans mes compétences. Est-ce que tu aurais considéré que c'était lié à ma formation ? Si oui, pourquoi ? Si non, pourquoi ?¹

Je n'avais aucun projet d'envergure à mon actif lorsque j'étais en IUT ou en école. Du coup je ne voyais pas l'intérêt de dire « hé, j'ai écrit des scripts pour gérer des playlists en Perl pour pouvoir utiliser ogg123 avec ! », étant donné que je trouve qu'il s'agit de trucs triviaux à programmer (un « mauvais » programmeur mettra simplement plus de temps qu'un « bon » programmeur à finir le script).

Je pense sincèrement que préjuger de la « curiosité » d'un étudiant/stagiaire potentiel est très très difficile.

Par exemple, un autre truc est que maîtriser l'environnement unix/linux nécessite beaucoup de temps. L'environnement Windows n'est pas naturel non plus, mais c'est l'environnement par défaut du coup pas mal de gens ont appris à s'en servir et ont intégré son fonctionnement. Du coup si en tant qu'étudiant je te dis que « je sais me servir d'unix et j'ai mon propre serveur à la maison », tu considères que c'est un « projet perso » ? Et si je dis juste « je maîtrise Linux » ? Où se trouve la limite ?

On peut être curieux et ne pas avoir fait « beaucoup » non plus : on peut n'avoir JAMAIS réellement programmé en (disons) OCaml, mais avoir voulu voir à quoi ça ressemble. C'est de la curiosité, mais il n'y a aucune preuve concrète que je sais me débrouiller mieux qu'un autre.

Je crois qu'à l'époque mon CV racontait quelque chose du genre (dans la section « compétences techniques ») :
- Maîtrise de l'environnement UNIX (Linux, FreeBSD, OpenBSD), et des services de base (Packet Filter, NAT, Apache [Note que je savais juste l'installer et le configurer de façon basique], MySQL [idem], etc.
- Langages: C (bon), C++ (débutant), PROLOG (débutant), LISP (débutant), XML/HTML/XSL (intermédiaire [ce qui n'était pas tout à fait vrai mais bon]), Java (intermédiaire), Perl (bon), Javascript (intermédiaire [et c'était à l'époque où AJAX pointait à peine le bout de son museau]), SQL (intermédiaire).

J'en ai p'tet oublié sur le côté. L'idée étant que j'ai toujours été honnête concernant mon niveau réel pour chaque langage que je décrivais (après est-ce que ça correspondait à la réalité ou pas, c'est un autre problème).

[1] Indice: il existe une UV dans l'école d'où je viens où ils utilisent Perl pour faire du web sémantique. Je n'ai pas appris le langage là-bas (j'ai juste lu le bouquin de R.Schwartz), mais j'aurais pu.

T'es sûr de toi ? Parce que je sors d'une école d'ingénieur (que je ne considère pas être une Grande École au sens de Centrale, Polytechnique ou les Mines par exemple), et on me disait très clairement que par exemple dire « ingénieur technico-commercial » ne correspondait à rien : tu as le « droit » de mettre ça comme nom, mais ce n'est qu'un nom, et pas un titre.

Si dans ta signature ou ta carte de visite tu marques que tu es ingénieur, de ce que j'avais compris, ça voulait dire « je suis passé par une école qui m'a délivré le diplôme ».

Mon expérience dans les labos est que les horaires et le besoin de temps de présence "physique" sont, en règle générale, extrêmement souples. Par exemple, pendant mon stage en labo, le mois de juillet de cette année était extrêmement chaud. J'ai passe presque tous les jours chez moi pour travailler, parce que les locaux étaient insupportables (a cause de la chaleur). Chez moi aussi, mais au moins la douche n’était pas loin...

Je me serais mal vu dire ca mes patrons de me faire confiance, et que j'allais bosser chez moi sans supervision. Comme je le disais dans le message auquel tu réponds, cette flexibilité a bien entendu un prix : j'ai aussi passé pas mal de week-ends à bosser sur mon sujet.

[à propos des employés pas feignasses] Dans le lot il y a les entubés (ceux qui continuent d'offrir malgré les non-remerciements, exploités), mais il y a aussi les remerciés (primes exceptionnelles, joli projet, monter en hiérarchie...)

(L'emphase est de moi)
[note: c'est RELOU de devoir écrire "il/elle" tout le temps. Donc mon programmeur pour la suite de ce post est une programmeuse, parce que pourquoi pas.]

Ça rejoint ce que quelqu'un disait plus haut : peut-être que ce que tu cites comme "remerciement" n'est pas ce que voudrait l’employée. Peut-être qu'elle voudrait avoir un salaire identique, des responsabilités identiques, mais quelques jours de congés supplémentaires à la place. Et peut-être que le patron lui, ne veut pas, parce qu'il aimerait bien garder son employée occupée tout le temps, le maximum de temps.

Bien entendu il y a un juste milieu : on ne peut pas réclamer 2 mois de vacances supplémentaires juste parce qu'on bosse bien (à moins d'avoir une telle productivité que tous les projets sont effectivement rendus 2-3 mois en avance...).

pour moi, les stagiaires compétents et motivés trouvent un stage plus tôt que les autres

C'est tout simplement faux. J'ai vu autant de bons stagiaires compétents et motivés qui s'y prenaient à l'avance que ceux qui étaient bien à l'arrache. Je pense notamment à deux de mes amis qui ont fini dans la même équipe et ont bossé ensemble pendant des années, et sont depuis devenus des experts en C++/multithreading/algorithmique (ils étaient déjà bons avant d’être recrutés pour leur stage cela dit).

Bon, je suis dans un domaine (recherche) qui a tendance à être chronophage et les horaires sont ultra souples -- par contre la semaine, on ne sait pas trop quand elle commence ou finit (genre je bosse "moyennement" le lundi, mais le weekend précédent j'ai bossé comme un fou pour un article, ou une proposition de financement, ou...). J'ai aussi bossé dans des boites avant ça (pour des stages en IUT et école d'ingé), avec des horaires plus ou moins fixes.

Apres avoir pas mal discuté avec des amis (pas qu'informaticiens), je retire trois règles de base :

1. L'heure c'est l'heure, en général.
2. Parfois il y a une urgence, et un technicien (DUT ou BTS ou ...) n'est pas tenu de rester, même si beaucoup le font. Et c'est très bien comme ça. Comme me disait notre prof d'IUT à l'époque : "Vous savez ce qui change entre le boulot d'un ingénieur et le votre ? Le salaire." (il parlait dans le cadre de développement logiciel) Puis d'ajouter : "Enfin, si y'a un truc quand même : le technicien n'est pas censé gérer l'imprévu." Le mec qui est cadre/ingénieur, etc., lui est payé entre autres pour gérer les urgences et les imprévus. En bref, il est payé pour être "chef" (même si ce n'est que de lui-même). :-)
3. Parfois il y a des taches planifiées, qui sortent des horaires traditionnels. Je pense qu'il est normal de demander de contribuer dans ces cas-là.

Mon expérience perso a été très diverse (que dans des petites boites) :

1. Premier stage, j'étais le seul infoteux "pur jus" (admin & sécu) a l'exception de mon maitre de stage, dans une petite entreprise composée principalement de commerciaux (qui eux bossent avec des horaires fixes vu qu'ils devaient répondre au tél/mail pour les clients etc.). A cause de cela, j'étais moi aussi obligé d’être à l'heure (9h du mat), et j'avoue que je suis pas trop du matin. En pratique je me suis fait remonter les bretelles ca l'époque car j'arrivais entre 5 et 10 minutes en retard. Par contre j'adorais mon boulot la-bas, du coup je partais non pas à 18h30 (comme la plupart des employés) mais à 19h30... Quand le dernier de la boite (avec les clefs des locaux) me disait "on ferme".
2. Deuxième stage, les horaires étaient plus souples (il fallait arriver à 9h-9h30, et partir du coup vers 18h-18h30 en fonction). Ce que j'ai beaucoup, BEAUCOUP aimé pendant ce stage c'est que, lorsqu'il a fallu que nous restions plus longtemps (je crois que nous avons fini vers 10h ce soir-là), l'un des responsables était réellement embêté, et c'est nous, stagiaires, qui avons insisté pour rester parce que le client testait le lendemain vers 8h. Réaction : "OK, mais on vous paie la bouffe ce soir, et le taxi." Leur objectif était réellement que la boite ferme ses portes le soir à 19h. Ce qui a fait que nous, stagiaires, ayons insisté, était aussi que l'équipe était dynamique, ne nous traitait pas comme des robots, et prenait en compte notre avis lorsqu'on émettait des doutes (au niveau technique bien sur) sur la direction que pouvait parfois prendre le projet.
3. Troisième stage : "projet de fin d'étude" (stage de dernière année d'école d'ingé), ou j'ai compris ce qu'était être un code monkey. Alors que j'étais censé effectuer quelque chose de technique, certes, mais qui montrait que je pouvais fonctionner comme ingénieur "junior", j'ai eu moins de responsabilités que jamais (comparé aux stages d'IUT et stage "technicien" de début d'école), et je ne faisais que des formulaire web en j2ee/struts/hibernate, etc. Niveau horaire, c'était plutôt souple (tant qu'on arrivait dans les 9h-9h30 la plupart du temps, arriver de temps en temps à 10h ça allait). Par contre la boite était vraiment située loin de tout, et je me tapais 3h de transport par jour. Du coup, quand le chef de projet me disait "ce serait bien si tu pouvais finir ça ce soir" à 19h, c'était non. Parce que 19h, c'était la dernière limite pour chopper le bus qui mène à la gare qui me mène à l'autre gare qui me mène chez moi. Accessoirement, tous les RER semi-directs devenaient omnibus après 18h30...
4. Stage Master recherche : bon ben c'est un monde très différent, donc je refuse de comparer. :)

Bref, comme ce qui a été dit précédemment, l'ambiance dans l'équipe, la façon dont on a l'impression d’être valorisé, etc., est très importante, et le projet sur lequel on bosse aussi. Mais vraiment, vraiment, le cotée humain/l'environnement est primordial.

Ah, c'est tout bête, pourquoi n'y a-t-on pas pensé auparavant.

Il existe bien entendu des modèles d'exécutions qui privilégient le grain fin (l'un des plus connus est l'exécution par flot de données, le dataflow).

En pratique tu as tout plein de cas où effectivement les gens ne pensent pas de cette manière, et les modèles d'exécution « à grain fin » ne sont pas si courants que ça. Bon, je vais essayer de faire au moins un journal qui va parler de tout ça.

Quel est l'intérêt exactement d'avoir des centaines ou milliers de coeurs ? Il n'y a quasiment pas d'applications qui vont passer à l'échelle, de toute façon.

C'est parce que tu penses en termes de threads « lourds ». Quand tu as 2000 cœurs à ta disposition, du moment que tu as suffisamment de tâches à effectuer en parallèle, même s'il y a des dépendances, il suffit de « penser grain fin ».

De plus, on ne réduit que la consommation dynamique. [...] Dans le cas du passage à 50% de cpu, le cpu baisse sa conso mais celle du cache est toujours la même, ce qui fait que dans certain cas, le système consomme plus pour une tache à 50% qu'à 100% ! (c'est le cas des cpu intel, dont la baisse de puissance est juste une protection thermique)

Alors, j'essaie de parler sans révéler quoi que ce soit de confidentiel, ce qui rend mes propos un peu trop vagues. Je vais essayer de préciser.

L'idée est de pouvoir couper l'alimentation d'une partie des caches/scratchpads et de la RAM quand on se fiche de ce qu'ils contiennent (le write-back est terminé, etc.).

Pour ce qui est de la cohérence mémoire, je ne dis pas qu'il ne faut pas fournir des garanties, juste que le modèle de « cohérence » (memory consistency, et pas memory coherence) doit être capable de passer à l'échelle. En l'occurrence, si on te file un software cache, tu peux changer la politique de gestion de la mémoire en fonction de ce que tu désires. Et oui, bien entendu, s'il n'y a pas de mécanisme implicite de cohérence mémoire, alors l'archi propose les briques de base pour avoir des barrières mémoire. L'idée n'est pas de déporter tout le poids de la cohérence sur les épaules du programmeur, loin de là. L'idée est de fournir les blocs hardware de base, et ensuite de laisser les programmeurs de middleware programmer le cache logiciel qui convient en fonction des objectifs.

J'aurais beaucoup plus de choses à dire, mais je crois qu'à ce niveau, il faudrait que je me sorte les doigts, et que j'écrive un journal sur le sujet des super-calculateurs de demain. :)

A propos de fréquence vs tension:

Je ne comprends pas bien cette phrase, si le but est de baisser la consommation de la puce, baisser uniquement la fréquence fait augmenter la consommation de la puce (à cause des fuites statiques, la conso dynamique étant proportionnel à la fréquence et la durée d'une tache augmente avec la baisse de la fréquence).

Alors d'une, je ne suis pas un expert, loin de la (d'ailleurs si tu regardes mes commentaires sur LinuxFR, j'ai plus tendance à parler compilos et programmation parallèle avec des bouts d'archi haut-niveau que de machins genre conception des processeurs ;-)). Donc je vais très probablement dire des conneries, et ce sera uniquement ma faute, pas celle des ingénieurs avec qui je bosse et qui expliqueraient ça bien mieux que moi.

Tu as raison, en baissant la fréquence, on ne change rien a la conso statique. Cependant, l’idée est de pouvoir déterminer dynamiquement la charge des coeurs, et d'adapter en conséquence la fréquence du processeur. L'autre idée est que parfois, avec des puces qui contiendront des centaines, voire des milliers de coeurs, que la puce chauffera un peu trop. Plusieurs mécanismes devront du coup être disponibles sur architectures "manycore": la possibilité de couper un (ensemble de) CPU mais pas le cache/scratchpad ("clock gating"), couper totalement le cpu+mémoire locale ("power gating"), mais aussi simplement réduire la tension appliquée à un (ensemble de) coeur(s), ou simplement réduire la fréquence. La réduction de fréquence peut être utile si un coeur est peu chargé (mais a quand même du boulot ca faire qui arrive régulièrement) et attend que des requêtes vers la mémoire reviennent (le plus souvent des requêtes de type DMA, ou bien si tu as une techno de type SMT, un autre thread prend la main). La réduction de tension est bien entendu bien plus efficace, mais de ce que j'ai compris, c'est loin d’être instantané, i.e. pour la fréquence, on peut s'arranger en quelques cycles, alors que pour la tension, il faut attendre plusieurs centaines/milliers de cycles (encore une fois, j'ai peut-être mal compris ce que m'expliquaient les ingés).

Concernant la présentation que tu donnes en lien : j'avais vu d'autres présentations par la même personne je crois bien (il a des présentations intéressantes en règle générale). Perso je déteste Cuda. C'est un mal nécessaire en attendant que certains modèles de programmation arrivent à s'imposer (ou que les langages "standard" intègrent ce qu'il faut de constructions concurrentes/parallèles pour devenir utilisables en environnement multithreadé), mais l'idée de devoir gérer explicitement ca peu pres tout, j'ai vraiment horreur de ça. D'ailleurs, Nvidia le sait bien, et ils se sont alliés avec Cray et 2-3 autres boites pour proposer une sorte de "standard" concurrent à OpenCL, mais plutôt à base de pragmas que d'API (comme cela si tu as un compilo intelligent, il peut générer de l'OpenMP, du Cuda, ou d'autres trucs en fonction du type d'accélérateur dispo sur la machine).

Par contre, pour bosser sur un projet de système (système = cpu + softs bas-niveau + compilateurs haut niveau + demos sur applications réelles) "manycore" d'ici à l'horizon 2020, je pense que le monsieur ne se rend pas du tout compte de ce qui va être proposé et des contraintes dont il va falloir jouer pour arriver à produire des puces réellement dotées de centaines ou milliers de coeurs. Il veut absolument de la cohérence de cache par exemple, et tout laisse à penser que celle-ci ne sera au mieux que partielle -- i.e. soit on aura des scratchpads, soit des caches gérés par un logiciel (donc en gros il faudra un cache logiciel, ou bien l'application se chargera elle-même d'invalider les lignes), soit un hybride entre les deux. La cohérence totale est très probablement impossible pour un nombre de coeurs par puce élevé. J'aurais vraiment plein plein plein d'autres trucs à dire sur le sujet, mais j'ai déjà écrit un roman ... :-P

Sur le fond de ce commentaire précis je suis d'accord avec toi (l'exemple de la voiture est bien trouvé). Cependant, cette suite de compromis ne fonctionne que si lesdits compromis satisfont tout le monde non ?

Si je reprends ton exemple, disons qu'effectivement ma maison est sur le chemin du retour. Mais imaginons qu'en pratique, je doive retourner au même endroit le lendemain (et peut-être pour plusieurs jours/semaines d'affilée). Supposons enfin que le temps de transport (en voiture) est de 30 minutes (au lieu d'une heure en temps normal). Comme le temps de transport est divisé par deux, au final je peux passer une heure de plus sur le lieu de travail (et c'est OK parce que je suis moins fatigué par le temps de transport, etc.). Au final mon patron y gagne (je passe plus de temps sur place), et moi aussi (plus confortable). Dans ce cas précis, je ne respecte pas la loi, mais mon patron considère qu'il y gagne au final¹.

Maintenant, toujours le même patron, mais pour quelque chose de différent : les jours de congés, les jours fractionnés, etc. La loi dit que j'y ai droit, car je prends des congés en dehors de la période mai-octobre. Le patron ça le fait suer de me les donner (pour une raison qui ne concerne que lui)². La loi me dit que j'ai le droit, et je n'ai pas envie de me passer de mes deux jours de congés (ou alors je veux qu'on me compense autrement). Ben là, comme il n'y a pas de compromis, je voudrais que mon patron s'aligne. Je ne sais pas si je suis clair, mais généralement quand le patron acquiesce pour ce genre de choses, c'est qu'il est

1. Humain bien entendu.
2. Convaincu que ça n'a pas de conséquence néfaste sur sa boite.
3. Pas au courant en fait. :-)

Bref. Le patron pourrait bien entendu revenir sur tout ce qu'il a autorisé de par le passé juste pour montrer qu'il est le plus fort , et que si on respecte la loi à la lettre, ben on va jusqu'au bout. Mais au final ça ne peut que faire du mal à son entreprise selon moi vu que ça ne peut que dégrader les relations avec son/ses employé(s). Donc en cas de conflit et d'absence d'accord tacite entre patron et employé, j'ai envie de dire qu'il faut se référer au contrat et à la loi.

[1] Note bien que je suppose ici que « je » passe bien une heure supplémentaire (ou même 30 minutes, à la limite) chaque jour chez le client ou je ne sais qui, ce qui a potentiellement de bonnes répercussions niveau image de la boite, etc.
[2] Je ne fais pas de jugement sur la pertinence des jours de congés fractionnés/etc.

Voyons voir. Avant, pas de multithreading et le C avait une sémantique séquentielle. Maintenant, le langage C a une sémantique qui admet l’exécution concurrente de plusieurs fils d’exécution, et donc de parallélisme potentiel. Avant, il fallait une bibliothèque externe au langage (mais il faut reconnaître que les bons compilo ont tous une certaine connaissance du modèle de threading lié à l'OS pour lequel ils génèrent du code). Désormais, il s'agit d'appels à une bibliothèque standard, ce qui implique que le compilo connait officiellement son existence et peut faire des trucs automagiques avec. Dans tous les cas il s'agit d'un mieux : avant C ne pouvait meme pas concevoir que SCC "existe" (techniquement il ne peut toujours pas, mais tu vois ce que je veux dire j’espère).

Désormais, il est donc possible d'obtenir un code C multithreadé portable (et pas juste "conforme POSIX" ou "conforme WinThread" ou ...).

Pour ce qui est de SCC spécifiquement, le MPB (message passing buffer) est une sorte de scratchpad utilisé pour 2 coeurs, et visible de tous les autres. Y accéder se fait via des coordonnées (x,y) sur la grille de processeurs. C64 dont je parlais précédemment a un scratchpad par coeur. Je ne vois pas trop la différence au final (mis à part les caches qui existent sur SCC que n'a pas C64 -- mais il se rattrape ailleurs).

Je voulais juste expliquer que la demande finira par orienter l'offre. Les fonctionnalités d'OpenMP 3 (gestion du parallélisme de taches en plus du parallélisme de données) font qu'OpenMP devient une alternative intéressante pour le programmeur scientifique (généralement un physicien ou ingénieur en mécanique, etc., qui n'a pas de formation initiale en informatique) qui a besoin de faire plus qu'un #pragma omp parallel for dans son code. Or Microsoft essaie lentement mais surement d'entrer dans le domaine du calcul scientifique. Ça ne peut fonctionner que si les outils existent pour ceux qui font du HPC.

Que devais faire les députés PS ? Être pour et suivre leur idée première ou bien jouer le jeu de la démagogie et voter contre ? Et de toute façon ils étaient en minorité et le oui serait passé de toute manière.

Tu parles de démagogie, mais si je suis député PS, et que le texte qui m'est soumis ressemble pour beaucoup au texte précédent, et que cette fois on ne passe pas par un référendum, mon intégrité (sens éthique, tout ca) devrait me faire dire "y'a un problème". Ensuite, mon sens politique devrait me faire dire "mes électeurs, ceux qui ont vote 'non' vont a-do-rer" tout en sachant qu'au final je suis en minorité et que je n'ai rien à perdre.

Or il me semble que les députés PS se sont dit "con de peuple", tout comme Sarkozy s'est dit la même chose.

MSVC++ ne supporte que OpenMP 2.0 alors qu'on en est à OpenMP 3.0 (et bientot 3.5 si je ne me trompe pas). Ça n’empêche pas les gens de programmer avec la dernière version d'OpenMP. MS devra finir par accepter certaines mises à niveau (que ce soit C99 ou C11 peut importe).