lasher a écrit 2738 commentaires

Dans le cas de Earth Simulator, le bâtiment était prévu exprès pour pouvoir récupérer l'air chaud et le refaire circuler dans mes souvenirs. Mais bien sûr, je peux me tromper.

« soit g95 est vraiment (très très très très)^50 mauvais. »
Ben oui. Il faudrait tester avec ifort (le compilateur d'Intel), mais en l'occurrence, g95 était loin d'être un foudre de guerre en termes d'optimisation ...

C'est ce qui est fait pour les calculateurs du genre de Blue Gene, ou Earth Simulator : on essaie de récupérer l'air chaud, de le faire circuler dans le bâtiment où se trouve le calculateur, afin de le refroidir, et de le « réinjecter » afin d'économiser un peu en refroidissement.

Les deux mon capitaine. J'entends beaucoup parler de l'utilisation de différents langages pour tout plein de choses dans le domaine du calcul scientifique (notamment l'utilisation de certains langages fonctionnels), mais au final malheureusement, la plupart des langages offrent des performances vraiment moins bonnes que des langages intrinsèquement peu sûrs (genre C ou FORTRAN).

Après, tout dépend de l'application qu'on veut faire. Je dirais que, mis à part le calcul scientifique, ou en tout cas les noyaux de calcul ou la conception d'OS, il serait de bon ton de lâcher le plus possible des langages tels que C ou FORTRAN, car ils sont (enfin je trouve) extrêmement difficiles à maîtriser correctement.

Pour ceux que la prog fonctionnelle ne gêne pas, programmer avec OCaml permet d'obtenir de très bonnes perfs tout en ayant un système de vérification des types extrêmement bon (et le pattern matching de code est un super outil). Pour les autres, tout dépend de ce qu'on veut faire, mais je trouve que les langages dits de 4è génération sont plutôt bons et permettent d'éviter pas mal d'erreurs car le code est simple à écrire et à relire (beaucoup plus simple qu'en C/C++/FORTRAN/etc).

Enfin, ce n'est que mon avis. :)

Euh, déjà, Ada est fortement typé (tout comme OCaml, d'ailleurs -- je crois que c'est le cas aussi pour Haskell, mais je ne suis pas sûr). Donc tout comme pour les langages dont tu parles, énormément de vérifications sont possibles à la compilation.

De plus, même si j'aime beaucoup les langages fonctionnels [1], il n'en demeure pas moins que la machine, elle, reste bêtement impérative dans son fonctionnement et son architecture. Vouloir à tout prix passer par du fonctionnel n'est pas toujours la bonne idée.

[1] Serait-ce une sorte de syndrôme de Stockholm ? :-)

Euh. Le fait est que l'utilisation de FORTRAN tient à plusieurs choses, mais 3 retiennent particulièrement mon attention :

1/ Beaucoup des bibliothèques d'analyse numérique ont leur API en FORTRAN [1], ce qui force le programmeur/utilisateur à comprendre un minimum comment fonctionne ce langage (et dans le cas de pas mal de numériciens et physiciens, ils ont carrément appris la programmation avec ce langage, car il permet certaines constructions très pratiques qui n'existent pas nativement en C, comme par exemple les instructions vectorielles « natives »).

2/ En F77, comme il n'y a pas de pointeur, il n'y a aucun risque d'aliasing, c'est-à-dire de pointeurs différents dont les zones mémoires pointées se recouvriraient. C'est une propriété extrêmement importante en ce qui concerne les transformations optimisantes qu'un compilateur peut appliquer sur un code.
Avec FORTRAN 90 et ses successeurs, il est toujours possible de signaler qu'il n'y a pas de recouvrement de zones mémoires (tout comme en C avec certains compilateurs d'ailleurs), mais là ça devient la responsabilité du programmeur de s'en assurer a priori.

Comme je l'ai dit précédemment, on a aussi la présence d'instructions « vectorielles », qui permettent d'effectuer une même opération entre deux tableaux, de façon transparente, et qui simplifie du coup énormément l'écriture de programmes.

3/ À cause de 1/ et 2/, le FORTRAN se prête déjà bien à tout ce qui est analyse numérique, mais tout ça, on pourrait certainement le dire avec Haskell ou LISP, en effet. Ce qui différencie FORTRAN du reste des langages, c'est qu'en plus, il est, tout comme le C, proche de la machine, ce qui est extrêmement important.

Enfin, une petite remarque : FORTRAN est lui aussi « issu des maths ». :-)

[1] Ce qui est gênant, car il m'arrive de voir parfois des implémentations en f77 qui sont sémantiquement correctes, mais à des années lumières de l'optimisation souhaitée pour les architectures actuelles.

C'eut été sympa de commenter ton code, histoire de comprendre ce que tu faisais.

Juste pour troller un chouïa :-)

Ada est un excellent langage, mais ne rend pas les programmeurs plus intelligents ... Ce qui mène à des explosions de fusée à cause de programmeurs qui font des hypothèses erronées quant à la taille de certaines variables.

Il ne faut pas confondre « null » (la « valeur ») et « NullPointerException » qui est une exception, comme son nom l'indique. Mon prof de typage dirait que dans ce dernier cas, on se retrouve bien dans une situation clairement définie, et définitivement non « bloquée » : on sait où a eu lieu l'exception (la jvm a même la politesse de nous donner la ligne pour le source), et on n'a pas de risque de comportement indéfini (comme par exemple lorsque j'écrase la pile d'un thread avec un autre de mes threads en C...).

Java embarque une plâtrée de lambda calcul dans son moteur, justement pour assurer une certaine sûreté des types. Le seul moment où ce n'est pas vrai, c'est avec les types de base (int, char, byte, etc.), où là par contre, on peut encore faire du cast sauvage (jusqu'à certaines limites).

s/processeurs scalaires (Opteron)/processeurs superscalaires (Opteron)/

Pour le coup c'est toi qui lis mal mes messages (ou bien je rédige très mal). La bêtise qualifiait smiley, qui justement voulait caractériser le côté « bête » de ma remarque. Bref, passons.

Je comprends parfaitement ce qu'est « une conditionnelle » comme tu le dis si elliptiquement bien. Maintenant, quand tu me cites mais que tu oublies la partie où je fais comprendre que j'ironise gentiment -- à la limite de la bêtise, c'est-à-dire quand tu coupes mon smiley, tu fais dire à ma phrase autre chose que ce que je voulais je pense.

Ensuite, je pense que tu peux au moins citer le cas de choses comme Mono, gnu classpath (au moins avant que Java ne soit vraiment libéré), les libc (qui ont des api -- voire des abi -- stables), etc.

En fait, dès qu'on parle « standard » (bon, ça, pas forcément) mais surtout de normes, il n'y a plus rien à dire, GPL, BSD, ou proprio, par définition, il faut pouvoir « interchanger » les appels de fonction (POSIX est l'exemple le plus criant, mais comme c'est un gros morceau de logiciel, je me permets de le recaser ici).

Je pense que ta question a déjà été posée lorsque les gens ont expliqué que faire un chroot ou un jail n'était pas non plus la panacée. Cloisonner peut aider à limiter les dégâts, mais pour le coup, je suis d'accord avec d'autres intervenants dans ce fil : un matériel/un service, ça reste dans l'absolu plus sécurisé. Maintenant, les notions de sécurité évoluent en fonction de la façon dont tu évalues les risques (sensibilité des données, etc).

Ah bon ? Donc les implémentations libres ou proprio des pthreads n'ont pas la même api (voire abi) ? :-)

De même qu'on voit mal des admins mettre en prod des debian testing, n'est-ce pas ? :-)

NIS+ ? LDAP + Kerberos + ... (l'équivalent d'active directory de Windows, quoi) ?

Va dire ça à Jaures.

Je fais bien la distinction GPL / LGPL, car la GPL seule est la plus restrictive.

Je ne connaissais pas Joomla. De plus, on peut difficilement taxer ZFS et DTRACE de « projets historiques ». :-)

Par contre, tu aurais pu parler de Java qui sera vraissemblablement en GPL v3, si j'ai bien compris.

Je me suis posé la question. Et en fait, en essayant un raisonnement logique, bien que contredisant mon intuition, je me suis dit que « c'est » était impersonnel, et qu'à aucun moment je n'employais la première personne du singulier. Cela étant, bien que « douloureux » à l'oreille, j'ai choisi « C'est moi qui a » (alors qu'à l'oral, sans me poser de question, j'aurais dit « c'est moi qui ai » .... comme quoi).

« J'ai toujours du mal à retenir un sourire quand on m'explique que les droits liés à la GPL sont trop restrictifs et donc que, en gros, 75% des logiciels libres restreignent les libertés ;-). »

Mmmh. Là c'est moi qui a souri. :-)

En pratique, certes, Linux est sous GPL, ainsi que les outils de ligne de commande de base (shells, etc). GCC aussi, et, dans une moindre mesure, emacs. Il y a évidemment pléthore de logiciels libres sous GPL -- et c'est très bien.

Maintenant, prenons d'autres logiciels libres qui sont aussi extrêmement utilisés.

- OpenSSH (BSD)
- Perl (Artistic license)
- Python (licence BSD-isante)
- Firefox / Thunderbird (MPL)
- Postfix (IBM Public License)
- Apache (APL)
- BIND (licence ISC)
- Sendmail (BSD jusqu'à la version 8.9 excluse puis, depuis quelques temps, une licence moins libre dans le cas d'un usage à caractère commercial sans redistribution des sources)
- X11 (MIT)
- ZFS
- DTRACE
- ...

Entre le nombre de softs sous GPL (indépendemment de la taille du projet), et la fréquence avec laquelle ils sont utilisés, il peut exister un gouffre énorme.

Évidemment, à mon énumération (non-exhaustive) de logiciels sous licence non-GPL, on peut opposer GIMP, Samba, etc.

Ce que je veux dire (et ensuite, j'arrête le troll pour 2h au moins), c'est que cette notion que « la licence GPL est la plus commune » est sans doute vraie en termes de quantité de logiciels publiés sur le net, mais pas nécessairement en termes de quantité de logiciels réellement utilisés par un nombre significatif de personnes.

Ce qui me fait dire que finalement, il n'y a pas tellement de quoi sourire quand on dit que la GPL est par trop restrictive -- en tout cas, pas en « brandissant » l'argument du nombre de softs sous GPL. :-)

« Ensuite, pourquoi 3 reseaux? --> Pour qu'il y ai une concurrence dans la qualité. »

Il ne faut quand même pas oublier que les trois opérateurs se sont pris une amende il y a peu parce qu'ils ont été reconnus coupable d'entente sur les prix (nuisant donc à la concurrence). Et même comme ça, je ne suis pas certain que ce ne soit pas encore le cas...

Ah.

Je connais au moins un domaine où la compilation peut prendre un temps pas possible : le calcul haute performance.

Un code scientifique, comportant de nombreuses indirections de tableaux (inévitables, car usant de maillages adaptatifs et de matrices creuses, qui intrinsèquement nécessitent ce genre de structures de données), avec pourtant le maximum de code dont le comportement est statiquement connu à la compilation (parce que programmé en FORTRAN 77 et donc pas de risque d'aliasing, etc), ça peut mettre dans les 45-60 minutes à compiler. Bon ok, le fait que le compilateur voie plein d'opportunités d'optimisation peut clairement jouer, mais la complexité du code est la principale raison de la lenteur de compilation.

Ici donc, pas d'objet, du bête code, à peine mieux que de l'assembleur (bon ok, j'exagère un chouilla).

Par contre, si on parle « presqu'objet », parlons des templates, qui de par leur côté totalement statique fait que les temps de compilation s'allongent, s'allongent ...

Enfin, là on parle de code C, et effectivement, gcc est clairement beaucoup plus lent qu'avant, alors qu'il a relativement peu de choses à analyser (comparé à du code C++).

C'est bien simple, d'après ce que je lisais, il n'y a tout simplement pas de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop de trucs plus urgents à faire) à consacrer à un compilateur quelconque. Donc non, pas de OpenCC ou autre.

Je ne sais pas ce que vaut pcc, mais tcc fait tout en une passe, et n'optimise pas grand chose (càd : rien). Ce n'est pas son but. Donc si pcc optimise des trucs, alors il est sans doute plus performant que tcc :-)

Oui enfin, poser des phi fonctions c'est pas dur non plus hein. Et si la représentation intermédiaire est bien faite, remonter les arcs c'est pas spécialement compliqué. Ce qui est difficile dans SSA, c'est le calcul des frontières de domination, etc. Donc tout dépend si l'algo est implémenté ou pas.