lasher a écrit 2731 commentaires

ever heard of literate programming ? :)
http://www.literateprogramming.com/
literate%20programming

« Triturage » ? :) Sinon, je ne vois pas ce que tu reproches à « Hacking »

C'est qu'y va pleuvoir, c'est qu'y va faire gris ?

Intéressant. On parle bien d'impôts en France ? Si oui ben je me suis trompé. :)

« Sarko il a dû juste dire "Organisez moi le sommet au grand Palais" »
C'est vrai. Mais même comme ça, tu vois bien le devis qu'on te file, et le coût que ça aura au final. Et puis surtout, quand tu dis, « fais-moi ça », tu dis avec quel budget !

Non ça par contre, depuis que c'est arrivé une fois, je crois bien que t'as plus le droit.

Je ne suis pas à proprement parler un codeur Fortran, mais on m'a déjà demandé d'optimiser pas mal de codes écrits en Fortran, parce que tout bêtement, la syntaxe est très similaire à celle du C. Comparons:

do i = 1, M
____do j = 1, N
________acc = beta * C(i,j)
________do k = 1,L
____________acc = acc + alpha * A(i,k) * B(k,j)
________enddo
________C[i,j] = acc
____enddo
enddo

En C, on aurait :
for (i = 0; i < M; i = i + 1)
{
____for (j = 0; j < N; j = j + 1)
____{
________acc = beta * C[i][j];
________for (k = 0; k < K; k = k + 1)
________{
____________acc = acc + alpha * a[i][k] * b[k][j];
________}
________c[i][j] = acc;
____}
}

(En se souvenant qu'en Fortran on est en column major, alors qu'en C on est en row major... Techniquement ça veut dire qu'il faudrait échanger toutes les boucles de mon code Fortran pour faire plaisir à la machine, ce qui rend le code beaucoup moins intuitif, de suite).

Déjà, je ne vois pas de grande différence entre les deux codes. Ensuite, les entrées sorties en C, c'est déjà pas la fête, mais en Fortran c'est carrément imbitable. Du coup je persiste dans mes dires : soit on parle de Fortran 77, et là comme tout est statique ou presque, effectivement il y a un gros avantage sur le C; soit on parle de Fortran 90 et plus, et là en gagnant des fonctionnalités, on perd en simplicité (logique), obligeant le compilateur à être plus intelligent, et du coup on ne gagne plus rien sur le C/C++.

Techniquement, LLVM permet bien plus facilement l'injection de nouvelles transformations dans le processus de compilation. Du coup, il est mieux fichu (pour le moment) que GCC car il permet de tester directement de nouvelles idées sans avoir un compilateur de recherche à portée de main (c'est généralement comme ça que les chercheurs voient qu'une idée est bonne : en l'implémentant dans leur compilateur maison -- sauf que tout le monde n'en a pas).

Mais comme il a été dit dans un journal d'ailleurs, GCC est sur le point d'avoir les plugins autorisés. Et ça, c'est grâce à LLVM, car il n'en était pas question au départ.

Enfin il y a aussi la licence de GCC qui gêne certains (oui, ceux qui voudraient bien l'améliorer sans rien reverser à la communauté, ou ceux qui veulent utiliser le front-end pour leur compilateur, etc.)

Pour ce qui est des opérations vectorielles (opérations entre tableaux), au final, c'est pareil.

Que tu tapes C = A + B ou for (int i = 0; i < N; ++i) c[i] = a[i] + b[i] le compilateur sait correctement optimiser la chose. Là où ça peut être trompeur, c'est quand tu fais des trucs du genre C = A * B en Fortran, car ça ne fait pas du tout un produit matriciel, mais un produit membre à membre. Au final, tu te retrouves à devoir coder la plupart des noyaux de calcul d'algèbre linéaire à la main, et que ce soit du C ou du Fortran, la difficulté (et finalement la syntaxe) est plus ou moins la même.

Ah ah ah! J'ose esperer que c'est une blague ou de la meconnaissance. Non le C n'est absolument pas adapte au calcul scientifique.

Tu dis n'importe quoi. Le C est tout aussi bon que Fortran pour faire du calcul intensif/scientifique. Ou tout aussi mauvais, ça dépend du point de vue.

Il [le C] est trop bas niveau et chiant comme pas possible pour la gestion de la memoire (par exemple).

Le Fortran est aussi bas niveau que le C, avec en plus comme désavantage de cacher les pointeurs à l'utilisateur (certains pensent sans doute que c'est une bonne chose, mais quand il s'agit de faire de l'optimisation de code, c'est clairement un problème).

Là où je te rejoins, c'est qu'il propose un ensemble d'opération sur les tableaux assez pratiques (pouvoir faire tabC = tabA + tabB est quand même appréciable, sans avoir à faire de boucle ou autre).

Concernant la gestion de la mémoire, les codes que j'ai pu voir géraient *tous* la mémoire à la main, que ce soit en C ou en Fortran. La méthode est assez simple : gros allocate() ou gros malloc() en début de programme, puis on découpe à la main cette grosse zone mémoire entre les différentes structures de données à allouer. D'ailleurs le faire en Fortran est bien plus simple qu'en C, vu qu'il n'y a pas de notion de prototype de sous-routine/fonction. Du coup pas de vérification des types, notamment lors de l'appel d'une sous-routine (et donc, si le programmeur fait une erreur, il ne la verra que trop tard ...).

Tant qu'on se cantonne à du Fortran 77, au moins comme tout est alloué statiquement, on maîtrise réellement tout (et le compilateur peut faire des merveilles). À partir du moment où on glisse vers F90, le compilateur se retrouve avec les mêmes préoccupations qu'un compilo C. Sauf qu'en plus je trouve que la syntaxe pour utiliser des pointeurs est juste merdique (mais cet avis n'engage que moi, et c'est vrai que j'ai 8 ans de C derrière moi, forcément, ça me déforme un peu).

Bref, c'est quasiment bonnet blanc et blanc bonnet entre utiliser C et Fortran, en termes d'abstraction (je parle de F77 en particulier).

La plupart des codes industriels que j'ai pu toucher qui étaient écrits en Fortran l'étaient en Fortran 77 en grande majorité (avec parfois un peu de Fortran 90, mais presque rien du langage n'était réellement utilisé, juste les facilités pour les boucles, la déclaration des variables, ce genre de choses).

Ensuite, il existe tout un tas de classes de problèmes qui nécessitent du calcul intensif et qui se résolvent plus facilement en C qu'en Fortran. Le plus clair a trait à la cryptographie, avec tous les XOR qu'ils nécessitent (je ne dis pas que ce n'est pas possible en Fortran, juste que de ce que j'ai pu voir, c'est moins pratique).

Je peux même te dire que certains ont développé un environnement de calcul scientifique écrit tout en C++, avec tous les trucs crades possibles dedans (surcharge d'absolument TOUS les opérateurs, templates, etc.). Pas de classes par contre.

Perl a un moment été très à la mode pour la bio-informatique, et plus précisément pour le recoupement de chaînes d'ADN (normal, vu que les séquences sont représentées par des lettres, et que Perl est quand même 'achement utilisé dans le cadre de pattern matching ...).

Concernant le calcul scientifique, tous les codes que j'ai vus passer depuis bientôt 4 ans sont écrits principalement dans 3 langages : Fortran, C, et C++. Avec parfois un peu d'assembleur pour faire bonne mesure (mais comme la plupart du temps il s'agit de programmes écrits par des physiciens, l'ASM quand je le vois, c'est généralement que je l'y ai mis).

Je ne dis pas que scheme/lisp/etc. ne sont pas faits pour ça, mais euh. Un peu quand même en fait. Plus exactement : faire un soft de CFD (Computational Fluid Dynamics) nécessite d'utiliser des bibliothèques/fonctions d'algèbre linéaire dense et creux. Jusque là, pas de problème, on peut utiliser n'importe quel langage. Mais quand on parle de logiciel de calcul intensif, le moindre cycle compte (au moins pour les fonctions les plus appelées), et là on commence à voir poindre pas mal de soucis, pour la plupart liés à l'architecture. De ce côté, Fortran et C(++) se débrouillent mieux bêtement parce qu'ils sont plus « bêtes » que LISP/Scheme/OCaml/etc.

Euh, à ma connaissance USB est une norme, et à ce titre, tout est spécifié (notamment la tension et l'intensité à fournir par un port USB). Je ne suis pas certain qu'Apple soit coupable dans ce cas précis.

Aux dernières nouvelles, le « non » du Parlement Européen signifiait simplement « non à une législation commune sur les brevets », et plus précisément « non à CETTE proposition de législation commune sur les brevets européens, entre autres logiciels ». Ce qui signifie qu'avant chaque pays faisait comme bon lui semblait, et qu'après le « non », chaque pays fait ... comme bon lui semble :)

« les brevets logiciels, ont s'en fout, ils ne sont pas valables en Europe. »
Petite correction : pas valables dans TOUTE l'Europe (l'UE en fait). C'est réglé au cas par cas, par pays.

ICC génère des fichiers objet « dummy » quand il fait de l'IPO, càd qu'il y a toutes les infos normales d'un .o, mais il y rajoute des symboles qui du coup empêchent ledit fichier objet de pouvoir être utilisé tel quel par un autre compilateur. En contrepartie, il y a bien plus d'informations pouvant aider à l'optimisation au moment de l'édition de lien.

On est bien d'accord. :-) Je sais qu'il existe des tentatives pour faire des mémoires transactionnelles « light » au niveau soft. Je me demande si du coup, ça ne serait pas plus envisageable aussi pour les réaliser en hard...

« Ce ne sont pas les industriels qui décident de l'avenir de la musique: ce sont les artistes. »
S'ils se concertaient avant d'agir, tu aurais peut-être raison. Ce n'est pas le cas en pratique, pour la plupart d'entre eux.

« Tu le dis toi-même, ils sont feignants. Bien fait pour leur gueule, je n'ai absolument pas envie de payer ne serait-ce que 1€ par mois de taxe ou de licence globale pour compenser la fainéantise des gens, la bêtise des artistes et/ou la vétusté du modèle économique de l'industrie du disque. »
Oh ben oui. Tu te rends compte que le « bien fait pour leur gueule » c'est exactement le même genre de réflexion qui aurait poussé une certaine autrichienne à dire « s'ils n'ont pas de pain, qu'ils mangent de la brioche » ? C'est-à-dire : tu fais partie d'une certaine classe privilégiée (et j'espère que tu t'en rends compte). Tu as non seulement accès à la culture, mais tu as (grâce à ton éducation, tes études, etc.) aussi la capacité de prendre du recul sur le processus.

Pour caricaturer un peu : on n'a pas besoin d'assistantes sociales, après tout, si le mec est en surendettement, c'est quand même de sa faute, il n'avait qu'à savoir que prendre tous ces crédits qu'on lui proposait et accordait, ça allait lui retomber sur le coin du bec.

« Si les auteurs ont envie que ça change, ils peuvent commencer par sortir de ce modèle économique, se débarrasser des majors et se rapprocher de leur public. »
J'espère que tu appliques ce que tu prêches dans tous tes rapports au libre, i.e. j'espère que tu n'utilises pas MSN, même via une passerelle (car MSN a un protocole fermé/proprio), j'espère que tu n'utilises jamais de formats propriétaires, même indirectement (via des machins de streaming par exemple), car enfin, il faut signifier aux fournisseurs de contenu que le libre est la seule vraie solution.

J'achète beaucoup de musique (moins récemment, crise, tout ça), que j'encode en ogg. Je n'ai aucun remord à télécharger de temps en temps (en fait, depuis que Hadopi a été initiée, je télécharge beaucoup plus, mon esprit de contradiction sans doute). J'estime moi aussi qu'il y a eu détournement du droit d'auteur, qui servait avant à protéger l'auteur contre les éditeurs peu scrupuleux, et qui désormais se protège des lecteurs/auditeurs/spectateurs. Je propose donc que désormais, il soit interdit d'écouter plus de trois fois la même chanson dans la semaine, de peur que celle-ci reste indéfiniment dans le crâne de celui qui l'écoute, contrevenant nécessairement au droit d'auteur. :P

« Maintenant, si les artistes continuent de signer chez les majors, c'est qu'ils veulent garder le système actuel. »
Non, s'ils vont chez une major, c'est que se dire « ouais nous on est artistes, le fric c'est pas bien grave, on va quand même y arriver », ça va un temps, mais qu'il arrive qu'au bout d'un moment, on veuille plus qu'un confort de base. Et pour le moment malheureusement, ça passe par une major qui a la capacité de communiquer sur leur musique.

Un peu comme un infoteux qui aime le libre, vraiment, et à qui on dit de se prendre un peu par la main pour trouver une boite qui fait du libre, s'il aime tellement ça. Il essaie, tombe peut-être sur une SSLL, s'aperçoit que niveau ambiance c'est pas mieux qu'une SSII (voire pire), et qu'en plus s'il allait ailleurs il serait mieux payé. Donc il va ailleurs, parce que l'ambiance/le salaire sont meilleurs, et pour ça il a fallu qu'il fasse un compromis.

Mmmmmh... Quid du duck typing alors ? :)

Je ne dis pas que c'est nécessairement réalisable (enfin, réalisable selon des contraintes du genre coût, consommation supplémentaire, etc.), mais ce que je dis en tout cas, c'est que tous les papiers que j'ai pu lire concernant les mémoires transactionnelles, et qui se faisaient en soft avaient la plupart du temps un, voire deux problèmes :

- ils plombent les perfs dans leurs implémentations actuelles; et parfois,
- ils rajoutent (lire : surchargent) de nouveaux mots-clefs dans les langages (j'ai souvenir d'une implém de mémoire transactionnelle dans une JVM qui rajoutait encore des qualificatifs en plus des synchronize et autres joyeusetés).

Fortress ça vit encore ? Et mis à part pour le calcul scientifique, ça sert à quelque chose ? :)

« Un langage avec des thread (dépassé, voir mémoire transactionnel, Scoop, etc...) »

Faudrait arrêter un peu de dire des bêtises des fois. :)

Les mémoires transactionnelles, dans le principe c'est très bien, mais en pratique ça offre une perte de performances, et ce sera toujours le cas tant que ce sera fait en soft uniquement. Il faudrait d'abord convaincre les constructeurs de matériel ...

Sinon, pour le moment en tout cas, dès qu'il s'agit de faire de la perf, malheureusement, utiliser des threads (et donc un modèle non-déterministe) est un peu obligatoire.

J'attends beaucoup de trucs genre GCD et tout ce qui est closures cependant. Le boulot fait dans C# à ce niveau pour pouvoir générer du parallélisme est assez intéressant.

Ben oui, mais c'est un peu le seul endroit où le compilateur peut faire quelque chose finalement : insérer des symboles pour le linker dans les fichiers objet. Et si sur de GROS codes ça explose, sur des codes de taille raisonnable ça va encore (et surtout, la compilation avec ipo peut être partielle : une partie des fichiers objet qui est compilée de façon classique, et une autre avec ipo).

Est-ce vraiment pour des raisons de perf que GCC (au sens Compiler Collection) ne permet pas ça ?

« La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être. »

Je ne suis pas tout à fait d'accord. Lorsqu'on active les optimisations inter-procédurales, c'est-à-dire l'optimisation de code entre des fichiers objets séparés, si le code est vraiment gros, ça peut vraiment faire exploser le temps de compilation. Au point que parfois c'est carrément le compilateur qui abandonne (j'ai déjà vu le cas se présenter avec les compilateurs d'Intel pour Fortran et C, avec des codes assez énormes, et où on avait activé l'IPO).

Peut-être pas : a priori sous Minix 3, quand un pilote plante, un démon finit par le détecter et « reboote » le pilote qui ne répond plus.

À ma connaissance, Apple a surtout aidé au dév de gcc pour y rajouter le support d'AltiVec.