« Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution. »
Autant sur ce troll je suis globalement avec toi, autant ta définition de machine virtuelle est selon moi totalement erronée. Tu insistes beaucoup sur le « virtuel » dans « machine virtuelle », mais tu fais totalement l'impasse sur « machine ». C'est pourtant le mot le plus important, vu qu'il s'agit du nom (et pas de l'épithète qui lui est accolé). :-) Une machine virtuelle suppose nécessairement un jeu d'instructions intermédiaire. Le C, le C++, etc., n'en proposent pas, et ne sont donc pas des langages utilisant des VM. Le fait qu'un runtime plus ou moins léger soit rajouté à un langage n'en fait pas une VM. Sinon, que penser de machins comme OpenMP, qui permet de faire du parallélisme « facile » ? Il y a des directives/pragmas de compilation, une bibliothèque proposant tout un tas de fonctions utilitaires, ainsi qu'un runtime qui réagit entre autres à la topologie de ta machine, à l'existence et la valeur de certaines variables d'environnement, etc.
Bah il faut bien avouer que le C est limité. Comment je fais pour récupérer le bit d'overflow qui apparaît de temps en temps quand je fais de la crypto, moi, hein ? :-)
Euh. LISP a fait l'expérience des premiers ramasse-miettes et autres bidules qu'on trouve désormais dans les VM. Alors certes en tant que tel le langage n'a jamais eu besoin de VM, mais en pratique, on en était déjà vraiment pas très loin (je me souviens de mon prof d'IA qui racontait avec émoi ses lundi matin, où il lançait le garbage collector sur la machine, puis passait les 3h suivantes à siroter son café et préparer son prochain programme ...)
« En fait, tu reproches au C des choses qui viennent avec des fonctionnalités qui n'existent pas avec C#, c'est débile comme argumentation! »
It's not a bug, it's a feature ? :-) Plus sérieusement, le problème de la taille des types (genre sizeof(char) == 1 d'après la norme, mais en fait, un char fait 16 bits à cause de contraintes d'alignement), ça existe depuis suffisamment longtemps pour que stdint.h ait été rajouté à C99, avec tous les types de taille fixe garantis qui vont bien. Ce n'est pas pour rien.
Plus ça va, et plus je finis par admettre que le C n'est qu'un assembleur portable. Et pourtant, je fais de gros efforts pour être conforme avec C99, mais c'est vraiment *dur*, à cause de tous les comportement indéfinis que comporte ce langage.
« oui mais aujourd'hui, il y a valgrind, et cela change tout. »
Tu supposes que tu as affaire à de bons programmeurs, capables de piger ce que sort valgrind. Honnêtement, c'est loin d'être toujours le cas ...
« int reste 32 bits, donc ça ne change pas. »
Sur un système POSIX. En C ISO/ANSI, la seule garantie à ma connaissance, c'est la relation d'ordre : char <= short <= int <= long et si je ne me trompe pas, POSIX impose que la taille d'un int soit de 32 bits au minimum, sizeof(long) == sizeof(void *) == taille d'un registre (logique), etc.
Et dans tous les cas, un long change de taille en passant de 32 à 64 bits. Les bons programmeurs C qui en plus connaissent bien les différentes normes sont quand même pas si nombreux que ça. Enfin si, quand c'est leur métier depuis des années. Sinon, en sortant d'école/fac, la plupart (moi le premier) ne savent que ce qu'on a bien voulu leur apprendre en cours (c'est-à-dire très souvent pas grand chose en terme de conformité avec la norme).
Le C est peut-être utilisé dans « tous les domaines », mais si sa part fait dans les 50% dans l'embarqué (comme le dit Nicolas), dans le calcul scientifique, sa part est quasi-négligeable (tout est fait en Fortran à hauteur de 70% je dirais, de C++ pour 20%, et de divers trucs pour les 10% qui restent), dans le domaine de l'informatique de gestion on a vite compris qu'utiliser Java ou C# (couplé à un bon IDE) permettait d'éviter tellement de bourdes de la part du programmeur moyen que le C n'est plus parlé que pour maintenir des codes existants.
En fait, le C a la dragée haute là où il a encore de l'intérêt : là où la gestion fine des ressources est importante -- donc l'embarqué, et dans une moindre mesure, si on confond C et C++, le calcul haute performance [1]. À cela il faut rajouter les boites qui font du middleware (genre fournisseurs de bibliothèques pour boites de jeux vidéo, ou d'applications ayant de fortes contraintes niveau perfs).
Bref, le C est cantonné (comme la plupart des langages) à des niches technologiques.
Dans le cas du logiciel libre, c'est différent. Le C est très souvent un « presque premier langage » (ou bien le premier « langage sérieux ») que beaucoup de dévs qui officient dans le libre utilisent. Ça reste un langage du cœur selon moi, et c'est pour ça qu'on voit tant d'applications utilisant le C là où d'autres langages seraient plus adaptés. Mais ce qui est drôle c'est que dans le même temps les langages de scripts (perl/python/ruby) sont aussi nés de la mouvance libre, et que ceux qui sont revenus de leurs errements en C en font l'apologie. C'est à la fois la grande force et la grande faiblesse du libre : la réactivité immédiate [2].
Au contraire, ce qui fait qu'en entreprise encore plein d'applis se retrouvent écrite en C (++ ? ;-)) alors qu'on devrait clairement tout casser et recommencer avec des langages de script/4è génération (avec un temps de dév 5 fois moins grand), c'est qu'en fait, elles ne sont qu'étendues, ces applis. Pas écrites from scratch, mais plutôt maintenues. Il y a une très grande inertie, et forcément, le C peine à partir. De la même façon que Java a eu du mal à s'imposer au début (entre autres à cause de sa lenteur initiale), mais que ça fait bien 10 ans qu'il est à peu près clair que Java ce n'est plus « l'avenir », mais le présent (au sens d'une boite : sauf cataclysme, tant que l'appli tourne, on ne change rien).
[1] Pour être précis, le C est souvent utilisé en tant que « glu » entre divers modules de compilation écrits en Fortran, typiquement pour les entrées/sorties ou les communications de type MPI.
[2] Faiblesse aussi, car dès que ça brille on en voit souvent beaucoup se précipiter sur une nouvelle techno sans avoir bien digéré la précédente... Ça fait des gens touche à tout mais pas forcément pointus sur un domaine précis...
Petit problème : Fortran est très souvent utilisé [1] pour faire de gros calculs, sur de grosses machines, très souvent coupées d'Internet. Des machins militaires quoi. Du coup les gens qui bossent sur ce genre de codes ont tendance à ne pas trop trop la ramener sur le net (entre autres parce que de toute manière, au boulot ils ont un accès ultra-limité au net le plus souvent).
Sinon, pour tout ce qui est simulation numérique, on a des tonnes d'applications industrielles et académiques : simulation de combustion en 3D dans des fourneaux industriels, simulation de moulage de pièces métalliques à destination de divers moteurs de voitures/bus/etc, influence de l'air sur un avion en marche, prévisions météo, simulation des mouvements des plaques tectoniques, et modélisation de phénomènes naturels en règle générale, et j'en ai encore quelques uns en réserve si tu veux.
De par ses origines, Fortran est principalement utilisé par des physiciens de formation. Mais j'ai eu sous la main des codes parlant souvent de machins incompréhensibles pour moi en mécanique des fluides, de résolution de Navier-Stoke ou Newton-Raphson qui font mal à la tête rien que pour piger les équations qui aident à résoudre des problèmes par la simulation là où avant il fallait aligner prototype après prototype jusqu'à obtenir le bon. On fait désormais une grande partie de simulation, ce qui fait gagner beaucoup de temps aux industriels. Bref, le Fortran a encore de très beaux jours devant lui. Simplement, ce n'est pas un langage « sexy » ou à la mode. Par contre il est diablement efficace dans ce pour quoi il a été conçu : l'analyse numérique. Et il est utilisé par beaucoup de gens, mais ce ne sont pas des informaticiens, donc du coup, tu en vois peu venir troller sur linuxfr...
« Le boulot des philosophes, c'est de troller, certe. »
Ah bon ? J'aurais dit que c'était le boulot des pros de la sophistique/rhétorique. Cela dit, un bon philosophe se doit d'être un bon sophiste (cf. Socrate et Schopenhauer avec son art d'avoir toujours raison, par exemple).
Un philosophe qui trolle, c'est un philosophe qui ne fait pas de philosophie (éventuellement, il s'amuse).
- Parce que le chef a dit
Tiens, comme Fortran dans le cas d'applications scientifiques, ou bien C++ (toujours dans le même cas), où tout a été tellement surchargé qu'au final on se retrouve à faire des machins horribles de type tab(i) plutôt que tab[i].
Honnêtement, j'adore le C, je tripatouille l'asm toute la journée, mais les gens ne voient pas à quel point MS a été intelligent avec .Net.
On a C#, certes, mais aussi VB (pour les masochistes), et F# (pour les adeptes de Caml), IronPython, IronRuby (bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental), et tout se retrouve dans une seule et même VM. C'est ça le gros intérêt de .Net. Rien n'empêche ensuite de passer à du JIT (ah ben tiens, la VM le fait déjà), et même de demander une génération directement en binaire si vraiment on en a besoin -- mais souvent les justifications sont fumeuses, car pour continuer à bénéficier de la sûreté des types et autres joyeusetés, on se retrouve à devoir générer les garde-fous qui vont bien et les insérer dans le binaire résultat, et au final on ne va pas spécialement plus vite que VM+compilation JIT.
De plus, là où en embarqué les ressources sont extrêmement rares/limitées (le problème est similaire dans le calcul haute-performance), dans le cas de l'informatique "généraliste", c'est rarement le cas. C'est en faisant entre autres ce constat que des compilateurs très intéressants tels que LLVM sont arrivés, avec un mode "VM-qui-se-spécialise" (et aussi tout le côté "je génère du code pseudo-asm bas-niveau mais avec des références aux CFG/DDG de la représentation intermédiaire) pour ceux qui peuvent attendre, et un mode "compilé-comme-les-grands" pour ceux qui veulent un résultat tout de suite, potentiellement moins bon que s'ils avaient accepté d'avoir une appli un peu plus lente au départ (mais bon, après tout dépend des impératifs).
void matvec(double *mat, double *vec1, double *vec2, const int m, const int n) {
int i,j;
#pragma omp parallel for default(none) shared(mat,vec1,vec2) private(i,j)
for (i = 0; i < m; ++i)
for (j = 0; j < n; ++j)
vec2[i] += mat[i][j] * vec1[i];
}
Bien sûr il s'agit d'un code naïf de multiplication de matrice, mais ça montre quand même l'idée. Faire ça en pthreads est bien plus fastidieux si tu veux bien le faire. Il y a tout un tas de cas où avoir une syntaxe qui gère le parallélisme (directement dans le langage ou les pragmas) permet d'aller quand même bien plus vite que les pthreads.
En cycle processeur, c'est donc, kif-kif (add ou inc à notre époque c'est 1 cycle)
Perdu. inc et add ne sont pas toujours équivalents en termes de vitesse d'exécution (par exemple sur les processeurs de type x86).
Et au passage le "++x" est vraiment moche, et très dangereux. De là où je viens, c'est même formellement interdit !
Tu peux argumenter s'il te plaît ? De là où je viens, ++x est moins dangereux que x++, vu que l'incrémentation est d'abord faite, et que du coup, x n'est évalué qu'une fois (en C on s'en fout, en C++, ça a son importance, si x est une instance de classe et que ++ a été surchargé ...).
Comme dit précédemment, le goto est très bien lorsqu'il faut gérer des catastrophes. En fait une règle à laquelle il faut se conformer à mon avis est de toujours utiliser goto pour faire des sauts en avant.
Sinon, utiliser un goto pour créer un 2è point d'entrée dans une boucle n'est pas toujours une bonne idée je pense, car s'il s'agit d'un langage compilé, le compilateur va avoir beaucoup plus de mal à optimiser le code (un compilateur aime bien quand les nœuds de ses graphes sont simples à gérer). Certaines transformations optimisantes sur les boucles nécessitent que celles-ci disposent de certaines propriétés, et le goto casse tout ça. Si la boucle n'est pas souvent prise, on s'en fiche, bien sûr. Mais dans le cas contraire...
J'ai fait très peu de Pascal, et c'était hors de mes cours d'info. Le C permet tout un tas de constructions « laxistes » (dont je me sers souvent par ailleurs ...) qui n'existent pas en Pascal. Du coup, ça en fait un langage plus structuré et sans doute mieux adapté pour débuter.
Après, il est toujours possible d'imposer un certain style de programmation aux élèves s'il le faut vraiment, même en C -- mais ce qui fait préférer un langage à un autre, c'est justement les capacités d'expressivité. Je trouverais dommage d'empêcher un élève d'utiliser i++ comme construction juste « parce que ».
OpenMP et MPI c'est vraiment pas pareil. Déjà, MPI ne fonctionne « officiellement » qu'avec des processus (même s'il existe des implémentations à base de threads), car c'est ce qui est marqué dans le standard. Ensuite, OpenMP ne propose pas que des appels de fonctions à une bibliothèque, mais aussi un ensemble de directives de compilation et un runtime (pilotable via la bibliothèque et des variables d'environnement). De plus les approches OpenMP et MPI sont différentes :
- MPI propose un ensemble d'appels de fonctions plus complexes (communications 1-1, 1-*, *-*, etc, canaux, en fonction du nombre de processus, etc), et tout doit être explicite. En contrepartie, le principe de MPI est très simple, et une fois assimilé, c'est toujours pareil, et on sait ce qu'on fait. En plus de ça, comme il faut communiquer explicitement quand on utilise MPI, utiliser un programme MPI sur un ou plusieurs nœuds de calcul se fait de façon identique (après il faut espérer que le runtime MPI est assez intelligent pour faire la différence entre communication inter-nœud et intra-nœud).
- OpenMP propose un modèle de programmation basé sur les tâches/threads, en mémoire partagée. Ça exclut d'office le calcul inter-nœud (même s'il existe des machins qui essaient de fabriquer une fausse mémoire globale inter-nœuds, mais pour ce que j'en ai vu, ça marche mal). Comme pour tout prog multithreadé, ça suppose que tout est partagé implicitement, mais du coup on y gagne en empreinte mémoire, on n'a pas besoin de faire d'appel de fonction spécifique pour accéder aux données ou les modifier -- mais par contre il faut toujours faire des synchros à la main...
Les TBB sont un ensemble de templates C++ pour faire de « l'OpenMP » juste avec de la programmation. Cela dit ça va plus loin puisqu'il propose des conteneurs, etc., et aussi moins loin, car le compilateur OpenMP est capable de détecter des choses au niveau de la représentation intermédiaire, en se « souvenant » que plusieurs threads sont mis en jeu, ce qui n'est pas le cas des TBB.
Quant à POP-C++, là aussi a priori le compilateur est du coup capable de générer du code plus efficace vu que les mots-clef sont intégrés au niveau du langage... Mais j'ai des doutes malgré tout sur l'efficacité au final. À tester donc. :)
Hum. Je suis d'accord avec toi concernant les classements sur la recherche en règle générale. Par contre concernant les calculateurs, il n'y a rien à dire. Soit on en a une grosse, soit pas. Bon ben, on a la 4è plus grosse. Machine, hein.
Maintenant il faut garder à l'esprit que Linpack permet d'avoir une idée des perfs crête d'un calculateur (car les calculs sont indépendants, et nécessitent très peu de communication entre les cœurs), mais qu'en pratique, sur une application parallèle, le problème vient de la contention sur la mémoire, des parties intrinsèquement séquentielles, etc.
D'ailleurs pas plus tard qu'il y a deux semaines, j'ai eu un code à modifier. Le programmeur avait implémenté son algorithme, en prenant soin d'optimiser le mieux possible, mais n'avait pas vu que le parcourt des tableaux 2D et 3D dans les boucles les plus internes provoquaient énormément de défaut de cache, ce qui ralentissait énormément la fonction (et comme cette dernière prend 60% du temps d'exécution global, ça ralentissait aussi beaucoup l'application au final). En effectuant une transformation de code totalement pas « intuitive » (car on « casse » la logique de l'algorithme, même si au final le résultat reste correct), j'ai réussi à accélérer la fonction de 80% environ. Bon. Ben le compilateur était incapable de faire ce que j'ai fait à la main, tout simplement parce que le code était trop compliqué pour lui (trop de tableaux, d'accès à ceux-ci avec plusieurs itérateurs, de calculs d'indirections en sus, etc.).
Euh, l'aspect NUMA n'est absolument pas lié au fait d'avoir des « centaines de cœurs ». NUMA = « Non-Uniform Memory Access », qui permet d'avoir un seul espace d'adressage même si on a différents modules physiques de mémoire, et c'est tout. C'est à opposer à des DSM (« Distributed Shared Memory ») par exemple, où là les nœuds de calcul ont eux aussi chacun des modules mémoire physiquement séparés, mais où le transfert de donnée d'un nœud à l'autre doit se faire explicitement car l'espace d'adressage est privé à chaque nœud.
Pour info, la technologie d'Hypertransport d'AMD et récemment QPI d'Intel sont des technos ccNUMA, c'est à dire que la cohérence des caches est assurée au niveau matériel. Mais sur une carte SMP de Nehalem par exemple (avec 2 processeurs Nehalem, soit 2x4 cœurs, soit 16 threads matériels en tout), on a 2 jeux de barrettes mémoire (un par processeur), 2 bus, etc., et chaque processeur est relié à l'autre par un lien QPI qui permet d'accéder de façon transparente à la RAM de l'autre processeur.
Évidemment, dans le cas de machines réellement massivement CMP, on va se retrouver avec des architectures NUMA, mais certainement pas ccNUMA (car trop compliqué à câbler).
[^] # Re: La soluce
Posté par lasher . En réponse au message sed, c'est dien. Évalué à 3.
On a donc plutôt /[a-z]\{1,\}/ pour faire l'équivalent de /[a-z]+/ .
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution. »
Autant sur ce troll je suis globalement avec toi, autant ta définition de machine virtuelle est selon moi totalement erronée. Tu insistes beaucoup sur le « virtuel » dans « machine virtuelle », mais tu fais totalement l'impasse sur « machine ». C'est pourtant le mot le plus important, vu qu'il s'agit du nom (et pas de l'épithète qui lui est accolé). :-) Une machine virtuelle suppose nécessairement un jeu d'instructions intermédiaire. Le C, le C++, etc., n'en proposent pas, et ne sont donc pas des langages utilisant des VM. Le fait qu'un runtime plus ou moins léger soit rajouté à un langage n'en fait pas une VM. Sinon, que penser de machins comme OpenMP, qui permet de faire du parallélisme « facile » ? Il y a des directives/pragmas de compilation, une bibliothèque proposant tout un tas de fonctions utilitaires, ainsi qu'un runtime qui réagit entre autres à la topologie de ta machine, à l'existence et la valeur de certaines variables d'environnement, etc.
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
It's not a bug, it's a feature ? :-) Plus sérieusement, le problème de la taille des types (genre sizeof(char) == 1 d'après la norme, mais en fait, un char fait 16 bits à cause de contraintes d'alignement), ça existe depuis suffisamment longtemps pour que stdint.h ait été rajouté à C99, avec tous les types de taille fixe garantis qui vont bien. Ce n'est pas pour rien.
Plus ça va, et plus je finis par admettre que le C n'est qu'un assembleur portable. Et pourtant, je fais de gros efforts pour être conforme avec C99, mais c'est vraiment *dur*, à cause de tous les comportement indéfinis que comporte ce langage.
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tu supposes que tu as affaire à de bons programmeurs, capables de piger ce que sort valgrind. Honnêtement, c'est loin d'être toujours le cas ...
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Sur un système POSIX. En C ISO/ANSI, la seule garantie à ma connaissance, c'est la relation d'ordre : char <= short <= int <= long et si je ne me trompe pas, POSIX impose que la taille d'un int soit de 32 bits au minimum, sizeof(long) == sizeof(void *) == taille d'un registre (logique), etc.
Et dans tous les cas, un long change de taille en passant de 32 à 64 bits. Les bons programmeurs C qui en plus connaissent bien les différentes normes sont quand même pas si nombreux que ça. Enfin si, quand c'est leur métier depuis des années. Sinon, en sortant d'école/fac, la plupart (moi le premier) ne savent que ce qu'on a bien voulu leur apprendre en cours (c'est-à-dire très souvent pas grand chose en terme de conformité avec la norme).
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bien sûr, mais c'est pour ça que je parle de « souvent » et pas « toujours ». :-)
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 4.
En fait, le C a la dragée haute là où il a encore de l'intérêt : là où la gestion fine des ressources est importante -- donc l'embarqué, et dans une moindre mesure, si on confond C et C++, le calcul haute performance [1]. À cela il faut rajouter les boites qui font du middleware (genre fournisseurs de bibliothèques pour boites de jeux vidéo, ou d'applications ayant de fortes contraintes niveau perfs).
Bref, le C est cantonné (comme la plupart des langages) à des niches technologiques.
Dans le cas du logiciel libre, c'est différent. Le C est très souvent un « presque premier langage » (ou bien le premier « langage sérieux ») que beaucoup de dévs qui officient dans le libre utilisent. Ça reste un langage du cœur selon moi, et c'est pour ça qu'on voit tant d'applications utilisant le C là où d'autres langages seraient plus adaptés. Mais ce qui est drôle c'est que dans le même temps les langages de scripts (perl/python/ruby) sont aussi nés de la mouvance libre, et que ceux qui sont revenus de leurs errements en C en font l'apologie. C'est à la fois la grande force et la grande faiblesse du libre : la réactivité immédiate [2].
Au contraire, ce qui fait qu'en entreprise encore plein d'applis se retrouvent écrite en C (++ ? ;-)) alors qu'on devrait clairement tout casser et recommencer avec des langages de script/4è génération (avec un temps de dév 5 fois moins grand), c'est qu'en fait, elles ne sont qu'étendues, ces applis. Pas écrites from scratch, mais plutôt maintenues. Il y a une très grande inertie, et forcément, le C peine à partir. De la même façon que Java a eu du mal à s'imposer au début (entre autres à cause de sa lenteur initiale), mais que ça fait bien 10 ans qu'il est à peu près clair que Java ce n'est plus « l'avenir », mais le présent (au sens d'une boite : sauf cataclysme, tant que l'appli tourne, on ne change rien).
[1] Pour être précis, le C est souvent utilisé en tant que « glu » entre divers modules de compilation écrits en Fortran, typiquement pour les entrées/sorties ou les communications de type MPI.
[2] Faiblesse aussi, car dès que ça brille on en voit souvent beaucoup se précipiter sur une nouvelle techno sans avoir bien digéré la précédente... Ça fait des gens touche à tout mais pas forcément pointus sur un domaine précis...
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Sinon, pour tout ce qui est simulation numérique, on a des tonnes d'applications industrielles et académiques : simulation de combustion en 3D dans des fourneaux industriels, simulation de moulage de pièces métalliques à destination de divers moteurs de voitures/bus/etc, influence de l'air sur un avion en marche, prévisions météo, simulation des mouvements des plaques tectoniques, et modélisation de phénomènes naturels en règle générale, et j'en ai encore quelques uns en réserve si tu veux.
De par ses origines, Fortran est principalement utilisé par des physiciens de formation. Mais j'ai eu sous la main des codes parlant souvent de machins incompréhensibles pour moi en mécanique des fluides, de résolution de Navier-Stoke ou Newton-Raphson qui font mal à la tête rien que pour piger les équations qui aident à résoudre des problèmes par la simulation là où avant il fallait aligner prototype après prototype jusqu'à obtenir le bon. On fait désormais une grande partie de simulation, ce qui fait gagner beaucoup de temps aux industriels. Bref, le Fortran a encore de très beaux jours devant lui. Simplement, ce n'est pas un langage « sexy » ou à la mode. Par contre il est diablement efficace dans ce pour quoi il a été conçu : l'analyse numérique. Et il est utilisé par beaucoup de gens, mais ce ne sont pas des informaticiens, donc du coup, tu en vois peu venir troller sur linuxfr...
[1] Fortran = FORmula TRANslator, tout ça ...
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ah bon ? J'aurais dit que c'était le boulot des pros de la sophistique/rhétorique. Cela dit, un bon philosophe se doit d'être un bon sophiste (cf. Socrate et Schopenhauer avec son art d'avoir toujours raison, par exemple).
Un philosophe qui trolle, c'est un philosophe qui ne fait pas de philosophie (éventuellement, il s'amuse).
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 5.
Tiens, comme Fortran dans le cas d'applications scientifiques, ou bien C++ (toujours dans le même cas), où tout a été tellement surchargé qu'au final on se retrouve à faire des machins horribles de type tab(i) plutôt que tab[i].
Honnêtement, j'adore le C, je tripatouille l'asm toute la journée, mais les gens ne voient pas à quel point MS a été intelligent avec .Net.
On a C#, certes, mais aussi VB (pour les masochistes), et F# (pour les adeptes de Caml), IronPython, IronRuby (bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental), et tout se retrouve dans une seule et même VM. C'est ça le gros intérêt de .Net. Rien n'empêche ensuite de passer à du JIT (ah ben tiens, la VM le fait déjà), et même de demander une génération directement en binaire si vraiment on en a besoin -- mais souvent les justifications sont fumeuses, car pour continuer à bénéficier de la sûreté des types et autres joyeusetés, on se retrouve à devoir générer les garde-fous qui vont bien et les insérer dans le binaire résultat, et au final on ne va pas spécialement plus vite que VM+compilation JIT.
De plus, là où en embarqué les ressources sont extrêmement rares/limitées (le problème est similaire dans le calcul haute-performance), dans le cas de l'informatique "généraliste", c'est rarement le cas. C'est en faisant entre autres ce constat que des compilateurs très intéressants tels que LLVM sont arrivés, avec un mode "VM-qui-se-spécialise" (et aussi tout le côté "je génère du code pseudo-asm bas-niveau mais avec des références aux CFG/DDG de la représentation intermédiaire) pour ceux qui peuvent attendre, et un mode "compilé-comme-les-grands" pour ceux qui veulent un résultat tout de suite, potentiellement moins bon que s'ils avaient accepté d'avoir une appli un peu plus lente au départ (mais bon, après tout dépend des impératifs).
[^] # Re: YaST, Java, Mono..
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Et pourquoi pas OpenMP ?
Posté par lasher . En réponse au message Programmation parallèle en POP-C++. Évalué à 2.
void matvec(double *mat, double *vec1, double *vec2, const int m, const int n) {
int i,j;
#pragma omp parallel for default(none) shared(mat,vec1,vec2) private(i,j)
for (i = 0; i < m; ++i)
for (j = 0; j < n; ++j)
vec2[i] += mat[i][j] * vec1[i];
}
Bien sûr il s'agit d'un code naïf de multiplication de matrice, mais ça montre quand même l'idée. Faire ça en pthreads est bien plus fastidieux si tu veux bien le faire. Il y a tout un tas de cas où avoir une syntaxe qui gère le parallélisme (directement dans le langage ou les pragmas) permet d'aller quand même bien plus vite que les pthreads.
[^] # Re: GOTO : Nostalgie...
Posté par lasher . En réponse au journal Sortie de PHP 5.3. Évalué à 0.
Perdu. inc et add ne sont pas toujours équivalents en termes de vitesse d'exécution (par exemple sur les processeurs de type x86).
[^] # Re: GOTO : Nostalgie...
Posté par lasher . En réponse au journal Sortie de PHP 5.3. Évalué à 2.
Tu peux argumenter s'il te plaît ? De là où je viens, ++x est moins dangereux que x++, vu que l'incrémentation est d'abord faite, et que du coup, x n'est évalué qu'une fois (en C on s'en fout, en C++, ça a son importance, si x est une instance de classe et que ++ a été surchargé ...).
[^] # Re: GOTO : Nostalgie...
Posté par lasher . En réponse au journal Sortie de PHP 5.3. Évalué à 3.
Sinon, utiliser un goto pour créer un 2è point d'entrée dans une boucle n'est pas toujours une bonne idée je pense, car s'il s'agit d'un langage compilé, le compilateur va avoir beaucoup plus de mal à optimiser le code (un compilateur aime bien quand les nœuds de ses graphes sont simples à gérer). Certaines transformations optimisantes sur les boucles nécessitent que celles-ci disposent de certaines propriétés, et le goto casse tout ça. Si la boucle n'est pas souvent prise, on s'en fiche, bien sûr. Mais dans le cas contraire...
[^] # Re: TPB
Posté par lasher . En réponse au journal ThePirateBay.org racheté. Évalué à 2.
[^] # Re: Et ça pleure et ça pleure
Posté par lasher . En réponse au journal He's bad.... Évalué à 2.
[^] # Re: Pascal ?
Posté par lasher . En réponse à la dépêche Des logiciels libres dans les programmes de mathématiques du lycée. Évalué à 2.
Après, il est toujours possible d'imposer un certain style de programmation aux élèves s'il le faut vraiment, même en C -- mais ce qui fait préférer un langage à un autre, c'est justement les capacités d'expressivité. Je trouverais dommage d'empêcher un élève d'utiliser i++ comme construction juste « parce que ».
[^] # Re: Et pourquoi pas OpenMP ?
Posté par lasher . En réponse au message Programmation parallèle en POP-C++. Évalué à 3.
- MPI propose un ensemble d'appels de fonctions plus complexes (communications 1-1, 1-*, *-*, etc, canaux, en fonction du nombre de processus, etc), et tout doit être explicite. En contrepartie, le principe de MPI est très simple, et une fois assimilé, c'est toujours pareil, et on sait ce qu'on fait. En plus de ça, comme il faut communiquer explicitement quand on utilise MPI, utiliser un programme MPI sur un ou plusieurs nœuds de calcul se fait de façon identique (après il faut espérer que le runtime MPI est assez intelligent pour faire la différence entre communication inter-nœud et intra-nœud).
- OpenMP propose un modèle de programmation basé sur les tâches/threads, en mémoire partagée. Ça exclut d'office le calcul inter-nœud (même s'il existe des machins qui essaient de fabriquer une fausse mémoire globale inter-nœuds, mais pour ce que j'en ai vu, ça marche mal). Comme pour tout prog multithreadé, ça suppose que tout est partagé implicitement, mais du coup on y gagne en empreinte mémoire, on n'a pas besoin de faire d'appel de fonction spécifique pour accéder aux données ou les modifier -- mais par contre il faut toujours faire des synchros à la main...
Les TBB sont un ensemble de templates C++ pour faire de « l'OpenMP » juste avec de la programmation. Cela dit ça va plus loin puisqu'il propose des conteneurs, etc., et aussi moins loin, car le compilateur OpenMP est capable de détecter des choses au niveau de la représentation intermédiaire, en se « souvenant » que plusieurs threads sont mis en jeu, ce qui n'est pas le cas des TBB.
Quant à POP-C++, là aussi a priori le compilateur est du coup capable de générer du code plus efficace vu que les mots-clef sont intégrés au niveau du langage... Mais j'ai des doutes malgré tout sur l'efficacité au final. À tester donc. :)
[^] # Re: L'Amééériqueuuuuu !
Posté par lasher . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 4.
Maintenant il faut garder à l'esprit que Linpack permet d'avoir une idée des perfs crête d'un calculateur (car les calculs sont indépendants, et nécessitent très peu de communication entre les cœurs), mais qu'en pratique, sur une application parallèle, le problème vient de la contention sur la mémoire, des parties intrinsèquement séquentielles, etc.
[^] # Re: et les bibliotheques python ?
Posté par lasher . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 3.
[^] # Re: Dans Juropa, il y a du Bull
Posté par lasher . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 5.
Pour info, la technologie d'Hypertransport d'AMD et récemment QPI d'Intel sont des technos ccNUMA, c'est à dire que la cohérence des caches est assurée au niveau matériel. Mais sur une carte SMP de Nehalem par exemple (avec 2 processeurs Nehalem, soit 2x4 cœurs, soit 16 threads matériels en tout), on a 2 jeux de barrettes mémoire (un par processeur), 2 bus, etc., et chaque processeur est relié à l'autre par un lien QPI qui permet d'accéder de façon transparente à la RAM de l'autre processeur.
Évidemment, dans le cas de machines réellement massivement CMP, on va se retrouver avec des architectures NUMA, mais certainement pas ccNUMA (car trop compliqué à câbler).