lasher a écrit 2732 commentaires

Les structures de données (domaine où il est impossible d'être exhaustif), les threads (ou tout autre manière de supporter du multitâche), gestion du réseau,.... tu t'arrète où ? AWT fais parti de la bibliothèque standard de Java.

Oui alors euh, justement, pour les threads, il y a de très bons articles (je ne sais pas s'ils sont disponibles librement sur le net) qui expliquent que par exemple les threads ne devraient pas être implémentés dans une bibliothèque. Par exemple, Threads Cannot not be Implemented as a Library a été écrit par J.Boehm, l'un des concepteurs du modèle mémoire du prochain standard de C++. The Problem with Threads, écrit par E.A. Lee, explique bien les problèmes liés à la façon dont le parallélisme dans les langages actuel est généralement mal exprimé et donc exploité.

Je suis totalement d'accord avec cette vision des choses (et un jour, OoOooOoh oui, un jour, j'écrirai un journal sur ce thème). Tant que les threads (ou une quelconque façon de gérer le parallélisme) sera exprimé à coup de PThreads, tant que les compilateurs considéreront qu'ils optimisent pour des programmes mono-thread (et donc effectueront des transformations dangereuses), etc, alors on aura toutes les difficultés du monde à produire des programmes parallèles efficaces sans passer un temps fou à les debugger.

Dans un langage de programmation, avoir une « évaluation stricte » signifie qu'on évalue les arguments d'une fonction sous forme de recherche en profondeur et de gauche à droite dans l'arbre d'appel des fonctions. C'est-à-dire: les arguments d'une fonction sont toujours évalués de gauche à droite, récursivement jusqu'à avoir évalué tous les arguments de toutes les fonctions nécessaires à l'appel de la fonction initiale.

Ce dont tu parles ressemble beaucoup à de l'inférence de type (du genre de ce qu'on trouve dans les langages fonctionnels).

Oui ben à ce propos, j'ai jamais vu dans la doc Intel où on pouvait avoir des pages d'1Gio. 2MiB iu 4MiB, oui, c'est dedans. Mais sinon je vois pas. L'autre problème est aussi que la taille de la TLB pour les pages de 4Kio est de 128 entrées (de mémoire), alors que pour les grandes pages, il n'y a que 4 entrées (toujours de mémoire). C'est aussi ce qui explique selon moi pourquoi on ne doit pas (pour le moment) avoir des grosses pages par défaut.

Ce que l'on peut surtout retenir de la propriétarisation de Nessus c'est qu'un logiciel peut être très populaire sans pour autant attirer de contributions. http://www.useit.com/alertbox/participation_inequality.html le dit assez bien sans pour autant apporter de solution miracle.

C'est vrai. Je pense cependant que l'absence de contribution n'était pas tellement le problème. Le vrai problème (dans le cas de Nessus) était le nombre de boites qui utilisaient le soft, corrigeaient des bugs quand elles les trouvaient, mais ne remontaient pas les patchs. Je pense que si les gens de Nessus avaient vu que personne ne contribuait activement (donc les « 90% de lurkers » du lien que tu donnes, ou même 99% dans le cas de Nessus), ils n'auraient pas trop gueulé. C'est vraiment la façon dont des entités privées ont récupéré le boulot sans jamais rien reverser qui a énervé les dév. originaux de Nessus.

A l'origine était Nessus, scanner de vulnérabilités. En 2005, l'auteur décida de quitter les chemins du libre et de continuer le développement sous forme d'un logiciel privateur. La communauté créa un fork à partir de la dernière version libre. Initialement appelé GNessUs, le projet fut renommé OpenVAS.

Nessus était libre à la base, et est devenu proprio, certes. Il y a une raison a ça : personne ne contribuait. Plus exactement, les boites de consulting faisaient exactement ce que la licence libre autorisait (i.e. repackageaient le soft, et le faisaient passer pour un super soft maison à la pointe du progrès). Certaines corrigeaient même Nessus. Elles "oubliaient" juste de remonter les patchs. Bizarrement, l'auteur original en a juste eu marre, et a décidé de rendre la version 3 de Nessus propriétaire. Et la, ô miracle, certains se réveillent, et décident enfin de contribuer (d'ou OpenVAS).

Il est maintenant la pierre angulaire de l'activité de plusieurs sociétés, sur trois continents. Ces sociétés développent activement le logiciel et ont construit tout un modèle économique autour de lui.

Combien y a-t-il de mainteneurs ? Sont-il tous de la meme boite ? Parce que je vois bien le scénario Nessus se répéter pour OpenVAS dans quelques années.

Mais justement, tout le monde fait pareil, tout le monde est au courant, et tout le monde sait que tout le monde veut faire passer ses idées, etc., et tout le monde se connaît dans le milieu. Je ne vois pas en quoi MS détonne plus que les autres ici.

Je connais merci. Et tu sais quoi ? Cette politique, même si elle reste sans doute vraie de la part de MS à bien des niveaux, est bien plus difficile à appliquer dans le cas d'un comité de normalisation — justement parce que euh, cette fois, ils poussent leurs fonctionnalités pour les inclure dans la norme. Et bien entendu, si ça passe, ça veut aussi dire qu'ils auront déjà l'implémentation toute prête, là où les autres devront peut-être consacrer du temps de dév (et donc de l'argent) pour s'adapter. Ça arrive aussi pour le standard OpenMP, où Intel a beaucoup poussé pour inclure la notion de liste de tâches (task list) dans le standard, pour gérer la récursion et des trucs type listes chaînées ou arbres. Au final l'idée a été retenue, mais avec un syntaxe et une sémantique différentes de ce qu'Intel avait déjà implémenté dans ses compilateurs ...

Bon là tu dis un peu de la merde. Et je te renvoie aux tests effectués sur FF à une époque, et qui montraient que FF3 (si je me souviens bien) était plus rapide en passant par la version Windows+Wine que la version native linux, tout simplement parce que sous Windows ils utilisaient l'optim par profilage. Une optimisation efficace se fait presque toujours aux dépends de la portabilité...

Alors euh, même si je suis d'accord sur le fait qu'il faut toujours étiqueter ses graphes, ton ton condescendant (certificat d'études, tout ça ...) me fait un peu vomir. Le fait qu'un auteur oublie de le faire (mais précise quand même les unités dans son article, par ailleurs) n'en fait pas quelqu'un de pas crédible.

Tu as juste décidé que tu n'étais pas d'accord parce que pour toi, MS c'est caca.

c) MS a de gros intérêts financiers à voir des développeurs passer à d'autres langages, et freine des 4 fers toute avancée du C, en proposant un compilo C incomplet face à ce qui se fait sur le marché et en noyautant les organismes de standardisation.

N'importe quoi. Il faut arrêter la paranoïa un peu. C'est comme si tu disais que l'une des personnes qui a mis au point le nouveau modèle mémoire de Java avait désormais tout intérêt à voir celui de la future norme de C++ s'écrouler (et pour info, il y a bien une personne qui a aidé à spécifier le JMM, et la même qui aide à le faire en ce moment aussi pour C++ ...).
C'est comme si tu disais que puisque désormais, Leslie Lamport bosse pour MS Research, sa recherche ne vaut plus rien.

Bref. MS a un intérêt commercial à avoir un langage C qui lui convient et qui convient aux gens qui programment pour son système. Ni plus, ni moins. Et bien entendu, ils vont essayer de pousser certaines fonctionnalités dans un sens qui les arrange. Exactement comme dans tous les comités de normalisation.

<div class="rms">Mauvais boulot, changer boulot.</div>

-------->[ ]

L'anglais n'est pas si précis que ça. Et le français propose lui aussi des nuances extrêmement subtiles de son côté. Il s'agit simplement de nuances sur des sujets différents.

Par exemple, le mot « fuck » doit systématiquement être remis dans son contexte pour pouvoir correctement le traduire en français ... :)

Mmmh, s'il s'agissait de vraiment prendre uniquement un langage simple, il faudrait préférer l'espagnol à l'anglais, car ce dernier comporte tellement d'exceptions que c'en est risible. Ah, et aussi, un dico anglais est généralement deux fois plus épais qu'un dico français, pour une raison toute bête : Guillaume le conquérant est passé par l'Angleterre en 1066 (si ma mémoire ne me trompe pas). Du coup, il a imposé le « français » (je pense qu'il s'agit plutôt d'une forme de bas Latin à ce moment-là) à la cour.

Bref, il existe des nuances sémantiques dans la langue anglaise que la langue française n'a pas, et inversement.

Je suis d’accord pour dire que la vectorisation est facilement réalisable automatiquement pour les cas simples (c’est bien pour ça que je me suis contenté d’écrire 1:N dans le premier cas, comme le Fortran le permet, au lieu d’une version C qui masquerait ça). Mais pour moi ça nécessite toujours de penser les algos. dans ce sens, il suffit de quelques variables temporaires dans la boucle, qu’un élément j du vecteur attende le résultat sur l’élément i et la boucle n’est plus vectorisable de façon triviale, voir pas du tout dans le cas d’un arbre.

Il ne faut pas confondre trois choses :

1. L'algorithme général qui permet de régler ton problème, et
2. la façon dont tu implémentes la solution (et les structures de données afférentes)., et enfin
3. les (micro-)optimisations que tu peux faire sur un code.

Les deux premiers points sont les deux plus importants, car ils t'apportent une solution correcte. Le troisième point, si les deux premiers ont été correctement effectués (meilleur algo possible pour le problème à résoudre, meilleur choix de structure de données pour réaliser l'implémentation de l'algo, etc.), alors on peut enfin se pencher sur la (micro-)optimisation du code.

Et oui, si tu veux juste traverser un arbre (pour faire un parcours en profondeur par exemple), mais que tu n'as pas de gros calcul à effectuer sur les nœuds, alors la vectorisation est inutile (ou infaisable). Mais tu parles déjà d'un type de programmation bien plus avancé que ce que la plupart des gens connaissent. Pour la plupart des physiciens ou numériciens que j'ai pu croiser, si le compilateur leur dit « j'ai vectorisé tes boucles », ils sont tout contents, mais sinon, de toute manière, ils ont ce gros machin MPI à écrire, et ça leur bouffe déjà la plupart de leur temps de cerveau disponible. :)

Ce qu'il nous faut en fait, c'est le même genre de bibliothèques de bases que ce qui est proposé en Java par exemple (dans util.concurrent si je me souviens bien — en tout cas un truc dans le genre) ou en C++ avec Boost (même si pour le moment c'est un peu léger) : des machins qui sont « parallel-proof » (dans une certaine limite). Et il nous faut d'autres gens qui programment d'autres structures de données qui permettent des accès concurrents efficaces (pas de gros verrou en entrée de la structure de donnée par ex). Sauf que la programmation efficace de ce genre de bibliothèque n'est pas à la portée du premier venu. Par exemple, une implémentation concurrente et efficace d'une liste chaînée passe par l'utilisation d'opérations de type compare-and-swap, pour « verrouiller » atomiquement (et efficacement) un maillon de la chaîne que tu traverses. Les algos pour le faire sont loin d'être triviaux. Par exemple, je t'encourage à aller regarder du côté des implémentations lock-free des Skip-list : le papier original explique très bien comment faire, mais malgré tout c'est pas évident à réaliser sans bug.

Bref, il nous faut des gens qui nous fournissent des implémentations génériques et efficaces (en C, C++, etc.) de structures de données qui gèrent la concurrence. Sur une machine « normale » (entre 2 et 8 cœurs ou threads), ces algos sont suffisants pour garantir un passage à l'échelle. Sur une grosse machine parallèle, là oui, il va falloir travailler un peu plus. Mais c'est ce qui fait que je vais avoir du boulot pour les dix prochaines années au moins ... :)

Argl, et je vois une énôôÔôÔôrme faute dans le message précédent : C est bien typé, mais faiblement (donc pas fortement ! :-))

Bon, j'ai fait une thèse, et s'il est vrai qu'une portion non-négligeable venait comme moi d'école d'ingénieur, ce n'était clairement pas la majorité dans mon labo. Et c'est très bien comme ça : ça permet de mélanger un peu les historiques.

Enfin dans tous les cas, tu as tort, la majorité des doctorants ne vient clairement pas de grandes écoles. Et comme ni toi, ni moi n'avons de chiffres concrets, je vais me cacher derrière un argument d'autorité et te dire que je suis docteur, moi monsieur. ;-)

Ah oui mais là par exemple ça pose problème : la plupart des codes (même industriels hein) que j'ai vu tourner étaient écrits au mieux en Fortran 90. Je ne doute pas que plein de gens se soient mis au goût du jour, mais c'est comme pour C99 : l'adoption des nouvelles normes est extrêmement lent.

Ensuite j'ai regardé ta page, et forall en F95 et supérieur est différent du foreach en Perl, Java, etc., puisqu'il ne concerne finalement que des objets de type tableau, là où dans les autres langages ça marche pour n'importe quel type de collection, et surtout, sans besoin d'utiliser de variable d'indexation.

Sans compter le fait que LISP par exemple a été extrêmement précieux dans la création d'AutoCAD par exemple...

Grosso modo, voici ce qui t'attends : * La syntaxe est cryptique pour un débutant, il y a les ";" les "*", les "{}", les "[]" et les "()"

Oui, carrément.

• Le langage est fortement typé, encore une notion de plus à aborder

Non, C n'est carrément pas typé, et tu n'as carrément pas besoin d'expliquer ce qu'est un type [1] aux étudiants pour qu'ils comprennent à quoi ils servent.

• Il faut expliquer comment fonctionne la mémoire, hello malloc
• les trois quarts de tes étudiants se casseront les dents sur les pointeurs, tu viens de leur expliquer le principe de la variable que déjà tu introduis le concept d'une variable qui en référence une autre

Ça par contre, ça dépend vraiment de comment est abordé le langage. Tu peux parfaitement utiliser un sous-ensemble du C et apprendre aux étudiants à manipuler des tableaux (en omettant de leur expliquer ce qu'est un pointeur, et en passant par l'utilisation de typedef). Là où j'ai fini mes études, ils utilisent C+SDL en cours de prog de première année, et les étudiants ne voient jamais de malloc ou autres pendant le premier semestre. Ils découvrent le principe de la programmation structurée et impérativement tranquillement, en « voyant » ce que leurs algos produisent, graphiquement. Les makefiles sont déjà écrits pour eux, et il suffit qu'ils utilisent Geany (par exemple) pour pouvoir compiler leurs trucs. Et ils sont quand même suffisamment futés pour piger la surface de ce qu'est la compilation : la transformation d'un programme écrit dans un certain langage vers un autre langage (le binaire dans le cas de la compilation C).

• Créer un concept abstrait aussi simple qu'une liste requiert l'apprentissage de quasiment tout le langage : structures, pointeurs, allocation mémoire, ...

Oui, mais j'insiste sur le fait qu'il y a déja beaucoup d'algos que tu peux apprendre à des élèves juste avec des tableaux.

Ceci étant dit, et ayant fini de jouer à l'avocat du diable, je suis d'accord avec toi. :-P C n'est sans doute pas le meilleur premier langage (sauf si tu as une formation « complète » en informatique pour accompagner son enseignement : c'est ce qui se passe dans pas mal d'IUT).

[1] Bon, pas tout à fait : il faut quand même expliquer les règles de conversion des types primitifs (int->float, float->int, etc), mais sinon normalement le compilateur est censé gueuler à chaque fois que tu essaies de mettre le contenu d'une variable là où ça n'a pas de sens.

Je ne pouvais pas paralléliser chacune des boucles vectorisées, car la parallélisation a un sur-coût trop important.

Attention à ne pas confondre architectures vectorielles et instructions SIMD (type SSE ou AltiVec). C'est vraiment pas pareil [1]. :-) Un processeur vectoriel des familles implémente une certaine forme de parallélisme de données (donc SIMD), mais fonctionne vraiment différemment d'une instruction SIMD. Mais ce n'est pas très important.

Dans ton exemple de boucle, les instructions SIMD que tu utilises permettent d'obtenir du parallélisme d'instruction (ILP). Il s'agit de parallélisme à grain fin, et oui dans ce cas, on va choisir les boucles les plus internes, car l'overhead (le surcoût) est minimal [2]. C'est aussi quelque chose de possible uniquement parce que tu as un jeu de données extrêmement régulier (mêmes bornes pour tous tes vecteurs, ou bien il est possible de s'arranger pour que la boucle ait les bonnes propriétés). Lorsque tu veux paralléliser un ensemble d'instructions par contre (et pas l'instruction elle-même), tu dois passer par des mécanismes à grain plus gros (pthread, tâche OpenMP, processus MPI, etc.). Et dès lors, oui, bien sûr, il y a un coût pour initialiser les constructions parallèles, l'initialisation de la liste des tâches de ton programme, etc. Que ce soit écrit avec des pthread_create() ou via une construction Cuda, je ne vois pas ce que ça change: ça reste du bête parallélisme de données. Il faudra donc avoir suffisamment de données à fournir à une des tâches créées pour cacher le coût de création de la tâche elle-même, mais je ne vois pas ce qu'il y a de nouveau là-dedans.

Du coup, tu as quand même titillé ma curiosité : quel langage as-tu utilisé pour paralléliser ta boucle ? S'il s'agit d'OpenMP, quel compilateur ? (Par exemple, l'implémentation d'Intel dans leur compilateur est notoirement meilleure que celle de gcc...) Et surtout, surtout, quelle était la taille de tes vecteurs ?

Quant à la vectorisation en règle générale, j'estime qu'un compilateur suffisamment évolué devrait savoir gérer les cas relativement simples sans passer par un humain (de la même manière qu'un bon compilateur C devrait savoir reconnaître for (i=0;i<N;++i) a[i] = 0; et remplacer le tout par un appel à memset(a,0,N*sizeof(type_de_a))). Le compilateur d'Intel le fait, gcc sait le faire dans une certaine mesure, si je ne me trompe pas le compilateur d'IBM le fait pour POWER, etc.

Ici c’est trivial, mais sur un algo. un poil complexe, je ne vois pas comment : par exemple le parcours d’un arbre, je vois bien comment le paralléliser en donnant un sous-arbre à chaque process, par contre je ne sais pas comment le vectoriser.

C'est vrai, mais je ne vois pas le rapport avec les GPU. En fait c'est même pire, les GPU sont notoirement mauvais pour traiter d'opérations sur les graphes en parallèle. Par contre, si tu as les bons outils (et là, je vais ressortir Cilk, que j'ai cité plus haut), tu utilises ... Cilk, qui est parfait pour ça (enfin dans certaines limites quand même), propose une approche divide-and-conquer de la parallélisation, et a même permis d'obtenir des programmes de d'IA pour échecs parmi les plus performants (ça commence à dater, mais Socrates a, à plusieurs reprises, fini dans le top 5 de grosses compèt' d'IA d'échecs vers la fin des années 90).

Cela dit, tu as raison de faire remarquer que le plus gros des applications gourmandes en ressources et tournant sur des gros calculateurs étaient en majorité des applications très régulières en termes structures de contrôle (if, while, etc.). D'où l'importance de trucs genre TOP500, avec comme seule métrique le nombre d'opérations flottantes par seconde (FLOPS).

Mais avec l'apparition des réseaux sociaux, etc., on s'aperçoit enfin dans les sphères du HPC que la métrique est peut-être un peu désuète (ou en tout cas incomplète). D'où la création fin 2010 du challenge Graph500 (patrick_g avait fait une news sur le sujet à l'époque). Ici la métrique est plutôt le nombre de nœuds traversés à la seconde si je me souviens bien, dans un parcours en largeur.

Donc si tu me dis que la parallélisation d'un programme dépend fortement des structures de données utilisées pour traiter un problème donné, je suis d'accord, mais je ne vois pas ce que ça change par rapport à la programmation séquentielle : en fait, si tu veux vraiment passer par une boucle for parallèle pour traverser une arbre par exemple, tu peux parfaitement recourir aux mêmes stratagèmes et algos utilisés pour parcourir un arbre de façon itérative et pas récursive. Il suffit d'utiliser une pile pour simuler les niveaux de récursion. Comme en plus il s'agit d'un arbre, tu sais que les nœuds ne peuvent pas être partagés (les données qu'ils contiennent par contre, c'est une autre histoire). Évidemment, un arbre n'est pas forcément équilibré, et dès lors on se retrouve avec un problème d'équilibrage de charge (mais là encore, Cilk avait fait fort et avait montré qu'ils pouvaient avoir un ordonnancement proche de l'optimal — mais, ironiquement, pas forcément le plus efficace).

Mais je digresse. Tout ça pour dire que je ne suis pas sûr de voir le rapport entre ce que je disais à propos des GPU (et surtout il faut faire bien attention : les GPU Nvidia n'ont rien à voir avec ceux d'AMD du point de vue architectural), et du fait qu'ils ne réinventaient pas vraiment grand chose pour quelqu'un qui a du bagage en prog parallèle, et ce que tu racontes à propos de la vectorisation — qui est vrai hein, c'est juste que j'appelle pas ça de la parallélisation au sens où la plupart des gens l'entendent. :)

[1] Même si par ailleurs, les instructions SIMD sont clairement inspirées par les machines vectorielles.
[2] Dans ce cas précis on peut carrément le considérer comme nul.

Juste un petit mot : il n’est pas dit que les architectures multi-cœurs restent importantes dans le calcul. Entre les deux les algorithmes ne doivent pas du tout être pensés de la même manière.

Les GPU n'utilisent absolument pas une autre forme de parallélisation. Ils imposent l'utilisation d'API ou d'extensions de langages spécifiques (Cuda/Stream/OpenCL), mais au final ça ne change pas grand chose (ce qui ne veut pas dire que certains codes ne devront pas être totalement récrits). Les concepts dont je parle (faire des algos « modulaires » et « parallel-friendly ») restent valable, qu'on parle de machines « many-core » façon GPU ou de vrais nœuds de calculs « many-cores » (avec 16 cœurs/32 threads ou plus sur un nœud). Alors oui les détails changent; oui, quand on utilise Cuda ou OpenCL, il faut déclarer explicitement les entrées et les sorties (par exemple); mais quelqu'un qui a eu à programmer avec MPI ou MPI+OpenMP a eu le même genre de problèmes auparavant. En fait si tu demandes aux chercheurs qui font du parallélisme ou de l'architecture et qui sont dans le coin depuis un moment, les GPU ne font finalement que remettre au goût du jour les architectures vectorielles des années 80-90.

De plus, on a un rapprochement GPU/CPU plus qu'évident depuis ces deux-trois dernières années entre AMD/ATI qui va produire un machin (Fusion) qui allie CPU et GPU, Intel et Knight's {Ferry|Corner|blah}, et Nvidia qui va produire des chips ARM pour accompagner ses GPU. Et je ne parle même pas des projets d'architectures et langages parallèles (genre les langages PGAS) financés par la DARPA...

on devrait apprendre l’ensemble des méthodes, et commencer par accorder plus de place à l’enseignement de la parallélisation tant d’un point de vue théorique que pratique

C'est vrai pour les informaticiens, beaucoup moins pour les physiciens/mathématiciens/biologistes/etc. Plus exactement, pour reprendre l'objectif de Rice avec CnC utilisé en première année de prog ou presque, il s'agit vraiment d'apprendre aux étudiants à correctement structurer leurs programmes, mais il n'est fait nulle part allusion au parallélisme à ce stade. Par contre les étudiants en info en fin de cycle de license/début de master (fin de cycle undergraduate) vont sans doute apprendre un peu plus d'algo/prog parallèle (là où d'habitude il s'agit de cours réservés aux grad students, donc master et plus).

Si tu me demandes de dériver ou intégrer dans les cas simples (polynômes) je sais faire. Si je dois passer par les cas spéciaux (genre lim ±oo / lim ±oo), j'ai totalement oublié comment on gère le cas. Parce que je n'ai plus eu besoin de faire d'analyse depuis bientôt 8 ans. Idem pour le calcul différentiel (pire en fait : je ne pense plus savoir comment résoudre une équa diff du 2nd ordre).

Si tu me donnes un peu de temps pour réapprendre (pas réviser hein, réapprendre) mes cours de lycée/école d'ingé en analyse, je pourrai bien entendu de nouveau faire tout ça (et comme je connais déjà les principes, ça me prendra moins de temps que la première fois). Mais en attendant, j'en suis incapable.

Quant aux histoires de 80% d'une classe d'âge arrivée au bac, tout ça : oui, à partir du moment où on passe de quelques centaines/milliers d'étudiants dans le supérieur, à plusieurs dizaines/centaines de milliers, ô surprise, on a plus de « déchets ». Mais dans l'absolu, on a toujours plus de bacheliers capables qu'avant. Si tu veux vraiment parler des 80% d'une classe d'âge tout ça, on devrait aussi faire comme on faisait dans les années 50-60 : concours d'entrée au collège, concours d'entrée au lycée, et baccalauréat en 2 ans (première ET terminale). Ça coco, c'était de la sélection.

J'en profite pour remarquer que tu n'as pas réagi au fait que les connaissances d'un élève de TS qui sort de nos jours du lycée pourrait plus facilement prétendre intégrer l'X au XIXè siècle que maintenant. Comme ça resterait un concours, on aurait toujours autant de gens qui intégreraient Polytechnique au final, mais on aurait aussi bien plus de candidats qu'à l'époque...

Maintenant, si tu me dis qu'il faudrait revaloriser les études réellement courtes (bacs pro,bacs techno), les formations liées à l'artisanat, etc., là oui je tombe d'accord avec toi, et mécaniquement, ça signifie que moins de gens échoueront dans les autres filières (enfin on peut le supposer). Mais si on forme des étudiants à des métiers dont l'avenir est bouché (genre électro-technique), on fabrique toujours tout plein de chômeurs. Qualifiés, certes, mais chômeurs malgré tout.

La différence entre la fac et les IUT/IUP/STS/Écoles d'ingénieur, c'est que la fac n'a pas le droit de sélectionner à l'entrée. C'est un peu facile de dire que (par exemple) mon ancien IUT a 95-100% de réussite en 2è année quand

• 25% n'ont jamais atteint ladite deuxième année
• Sur 3500-4000 dossiers examinés, seuls 190 sont retenus (soit environ 5-6%)

Une fac de sciences (hors facs de médecine et formations paramédicales) récupère tous les mecs qui n'ont pas réussi à entrer dans les filières sélectives d'une part, et les mecs qui veulent/ont une approche plus théorique ou qui ne veulent pas de la pression imposée par les prépas d'autre part. Donc oui, au bout d'une à trois années de fac, seuls environ 30% des étudiants obtiennent une licence. Ça reste toujours plus important que les 6-10% qui entrent en IUT (dont une partie ne va pas atteindre la 2è année), tu ne trouves pas ?

D'autre part, une bonne partie des enseignements que l'Université (en général, donc) fournit n'a pas vocation à être « professionnalisante » en soit (je pense aux sciences humaines, entre autres, mais aussi aux parties « fondamentales » des sciences dures, genre maths, physique, etc.). Et comme aucun institut professionnalisant (IUT/IUP/etc) ne va proposer de formation allant dans ce sens (enfin, pas la plupart, car heureusement certains comprennent l'importance d'être un chouïa plus pluridisciplinaire dans leurs formations).

En fait je serais bien plus d'accord avec toi si on avait de vrais cours d'algo/prog à partir du lycée, par exemple. Dans ce cas, oui, arrivé à la fac, on utilise simplement un langage que la profession utilise. Mais en attendant, les facs qui utilisent des langages « vraiment utilisés » n'utilisent pas Python (qui est libre et a des qualités certaines, tels qu'un typage fort). Elles utilisent Matlab (qui a des bugs tout partout, et un typage faible tout pourri).

Quelle version de Fortran ? Pas F77. Et je ne l'ai pas vu en F90 non plus.