« 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).
CORBA, le truc imbitable, avec une architecture tellement complexe que pour un simple « hello world » il faut 1 min. pour traverser toutes les couches d'abstraction ? :-)
Plus sérieusement, dans le cadre du calcul haute-performance, le surcoût qu'impose CORBA est clairement trop important. De plus les objectifs des deux projets ne sont pas les mêmes :
- CORBA propose une abstraction « objet » pour une architecture logicielle distribuée et multi-plateforme (enfin, au moins C++ et Java)
- de ce que j'ai pu voir POP-C++, il s'agit surtout de rajouter des mots-clef à la syntaxe pour prendre en compte le parallélisme, et ainsi gérer les synchro, la concurrence en règle générale, etc (et bon, quelque part, j'ai envie de dire que ça permet un peu de rattraper le retard sur le langage Java qui propose déjà des "synchronize", etc.)
Du coup, j'aurais plutôt envie de demander à Laurent si rajouter des mots-clef à C++ (qui en est déjà bien rempli) est une bonne chose. Comment se compare POP-C++ à Thread Building Blocks d'Intel, par exemple (qui ne se servent « que » de templates) ?
Tu as tout à fait raison. Mais passer par un segment de mémoire partagé, ou un fichier mappé demande à la fois de le créer explicitement ET de faire attention à ce qu'on en fait ... Quelque part, je trouve que c'est le pire des deux mondes (multiprocessus Vs multithread). :-)
Cela dit, c'est ce qui est fait dans tout un tas d'applications, notamment celles qui ne sont pas (encore ?) thread-safe et qui ont besoin de communiquer.
En pratique, des bibliothèques numériques non-libres, telles celles d'Intel, proposent deux version des BLAS : celles qui sont un front-end aux BLAS Fortran, et celles qui sont des « C-BLAS » (càd : tout réimplémenté en C et assembleur). Ça a deux avantages :
1/ Si on a vraiment besoin de l'interface officielle, on l'a, même en C.
2/ Si on passe par une interface « C », on s'affranchit du besoin de tout passer par « référence » (càd par pointeur, vu que l'interface doit fonctionner depuis le C), ce qui, mine de rien, est plutôt une bonne chose, et permet de faire certaines optimisations quasi-impossible quand on doit gérer des cas potentiels d'aliasing à cause de gens qui se croient malins ...
Dernière chose : l'interface des BLAS prévoit un argument « row major » Vs « column major », donc je ne comprends pas où est le problème avec NumPy (que je ne connais pas). Au pire on doit spécifier l'argument et c'est tout non ?
Une dernière chose. Pourrais-tu expliciter ton les tableaux multi-dimensionnels du C ne servent à rien) ? Il n'y a pas de « vrai » tableau multidimensionnel en C, j'en conviens, mais la majorité des codes Fortran que je vois passer font une grosse allocation unidimensionnelle en début de programme, avant de les « transformer » en tableaux multidimensionnels en les passant à des fonctions/sous-routines qui justement pensent avoir à faire à des tableaux multi-D. Et ça marche très bien.
Notamment pour le calcul scientifique, il y a Fortress qui est basé sur les concepts de Fortran et qui tourne sur la JVM.
Oui enfin, devoir repasser par une syntaxe différente uniquement pour faire du calcul haute performance, c'est un peu dommage ... Par exemple en Fortran, les dimensions des tableaux sont stockées à partir de la dernière, puis en remontant (donc un tableau déclaré comme TAB(M,N,K) sera rangé suivant K, puis N, puis M), là où en C/C++/Java on stocke d'abord par rapport à la première dimension de tableau. Quand les codes sont « simples », le compilateur est capable de renverser l'ordre des boucles comme un grand, mais c'est tout à fait différent dès qu'on commence à faire des trucs un peu complexes dans des nids de boucle.
Le multiprocessing c'est différent du multithreading.
Dans le cas d'une application multiprocessus, l'intégralité du processus est dupliqué (pile, tas, variables statiques et globales, etc.). La mémoire est compartimentée pour chaque processus (cf. man fork(2) sous Unix). Cela implique que pour communiquer entre les différents processus ainsi créés, il va falloir utiliser des appels explicites pour envoyer/recevoir des données : Socket BSD, pipe SysV, etc.
Dans le cas du multithreading, on a un même processus qui exécute plusieurs threads à la fois, la mémoire est implicitement partagée. Il faut donc faire attention à ne pas écraser la donnée du voisin. En contrepartie, la création d'un thread est bien moins lourde que celle d'un processus, l'empreinte mémoire est bien moins élevée si jamais mon application doit allouer de gros blocs, etc.
[^] # 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).
[^] # Re: Et pourquoi pas CORBA ?
Posté par lasher . En réponse au message Programmation parallèle en POP-C++. Évalué à 2.
Plus sérieusement, dans le cadre du calcul haute-performance, le surcoût qu'impose CORBA est clairement trop important. De plus les objectifs des deux projets ne sont pas les mêmes :
- CORBA propose une abstraction « objet » pour une architecture logicielle distribuée et multi-plateforme (enfin, au moins C++ et Java)
- de ce que j'ai pu voir POP-C++, il s'agit surtout de rajouter des mots-clef à la syntaxe pour prendre en compte le parallélisme, et ainsi gérer les synchro, la concurrence en règle générale, etc (et bon, quelque part, j'ai envie de dire que ça permet un peu de rattraper le retard sur le langage Java qui propose déjà des "synchronize", etc.)
Du coup, j'aurais plutôt envie de demander à Laurent si rajouter des mots-clef à C++ (qui en est déjà bien rempli) est une bonne chose. Comment se compare POP-C++ à Thread Building Blocks d'Intel, par exemple (qui ne se servent « que » de templates) ?
[^] # Re: On est pas vendredi mais ça me démange
Posté par lasher . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 5.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par lasher . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
Cela dit, c'est ce qui est fait dans tout un tas d'applications, notamment celles qui ne sont pas (encore ?) thread-safe et qui ont besoin de communiquer.
[^] # Re: et les bibliotheques python ?
Posté par lasher . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
1/ Si on a vraiment besoin de l'interface officielle, on l'a, même en C.
2/ Si on passe par une interface « C », on s'affranchit du besoin de tout passer par « référence » (càd par pointeur, vu que l'interface doit fonctionner depuis le C), ce qui, mine de rien, est plutôt une bonne chose, et permet de faire certaines optimisations quasi-impossible quand on doit gérer des cas potentiels d'aliasing à cause de gens qui se croient malins ...
Dernière chose : l'interface des BLAS prévoit un argument « row major » Vs « column major », donc je ne comprends pas où est le problème avec NumPy (que je ne connais pas). Au pire on doit spécifier l'argument et c'est tout non ?
Une dernière chose. Pourrais-tu expliciter ton les tableaux multi-dimensionnels du C ne servent à rien) ? Il n'y a pas de « vrai » tableau multidimensionnel en C, j'en conviens, mais la majorité des codes Fortran que je vois passer font une grosse allocation unidimensionnelle en début de programme, avant de les « transformer » en tableaux multidimensionnels en les passant à des fonctions/sous-routines qui justement pensent avoir à faire à des tableaux multi-D. Et ça marche très bien.
[^] # Re: et les bibliotheques python ?
Posté par lasher . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
Oui enfin, devoir repasser par une syntaxe différente uniquement pour faire du calcul haute performance, c'est un peu dommage ... Par exemple en Fortran, les dimensions des tableaux sont stockées à partir de la dernière, puis en remontant (donc un tableau déclaré comme TAB(M,N,K) sera rangé suivant K, puis N, puis M), là où en C/C++/Java on stocke d'abord par rapport à la première dimension de tableau. Quand les codes sont « simples », le compilateur est capable de renverser l'ordre des boucles comme un grand, mais c'est tout à fait différent dès qu'on commence à faire des trucs un peu complexes dans des nids de boucle.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par lasher . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
Dans le cas d'une application multiprocessus, l'intégralité du processus est dupliqué (pile, tas, variables statiques et globales, etc.). La mémoire est compartimentée pour chaque processus (cf. man fork(2) sous Unix). Cela implique que pour communiquer entre les différents processus ainsi créés, il va falloir utiliser des appels explicites pour envoyer/recevoir des données : Socket BSD, pipe SysV, etc.
Dans le cas du multithreading, on a un même processus qui exécute plusieurs threads à la fois, la mémoire est implicitement partagée. Il faut donc faire attention à ne pas écraser la donnée du voisin. En contrepartie, la création d'un thread est bien moins lourde que celle d'un processus, l'empreinte mémoire est bien moins élevée si jamais mon application doit allouer de gros blocs, etc.
[^] # Re: Pas de concurrence
Posté par lasher . En réponse au journal La mise à jour de Snow Léopard sera vendu 29$. Évalué à 1.