lasher a écrit 2741 commentaires

Le problème n'est pas la mémoire, mais la taille des registres. 32 bits, c'est trop peu.

s/en Europe/dans certains pays de l'UE (dont la France)/

Concernant l'utilisation d'instructions vectorielles, si on prend un compilo non-libre (icc), oui, il vectorise (mieux que gcc dans l'ensemble, mais gcc est en train de sérieusement combler son retard). Par contre, il faut des contraintes fortes à garantir à la compilateur (ou facilement vérifiable à l'exécution sans prendre trois plombes). Du coup, hors des cas « faciles », il faut encore se faire l'appel d'intrinsics à la main dans le code là où ça a du sens.

Georges, c'est pour un homme. George, c'est pour une femme.

Et « George » (avec l'accent angliche), c'est pour un homme dont le prénom est pas français.

Je déteste les numéros « automatiques ». Centralisés pourquoi pas, mais centralisé avec quelqu'un qui peut me rediriger là où je veux. Parce que le coup du « robot » qui m'explique qu'il faut que je tape 1 ou 2 ou #, ça me donne envie d'exploser mon téléphone. Sauf à être habitué du service, tu es obligé de te taper les 3 minutes (surtaxées) d'explications sur les différents choix qui s'offrent à moi. Lorsqu'enfin je tape sur (disons ) 9 ( « autre choix » ) je dois encore patienter quelques instants pour que quelqu'un veuille finalement me prendre.

Au final, j'aurai perdu des sous ET du temps avec leurs machins automatiques à la con.

Sauf que si ton programme a été optimisé et que du coup il utilise plus d'unités fonctionnelles à la fois (et donc rend le temps de calcul plus court), est-ce qu'il ne fera pas monter la consommation électrique du CPU ? :)

En fait c'est exactement le problème que je rencontre parfois avec certaines personnes : on leur explique (par exemple) que le seul moyen de piger où se trouve le goulot d'étranglement dans leur programme n'est plus dans l'algo, mais dans le code asm lui-même (comprendre ce qu'a fait le compilateur, etc.), et ils préfèrent améliorer les constantes de leurs algos plutôt que de se dire « si on faisait ça mieux, ça tiendrait dans les caches d'instruction/de données »...

J'aime bien les notes, ça me permet de ne pas me distraire. Je lis, puis je clique. Plutôt que « je lis, oh tiens un lien, je clique, et du coup j'oublie de lire la fin ».


... De la mauvaise foi ? Où ça ?

« La plupart des utilisateurs de linux connaissent pourtant la notion de dépendances logicielles et savent choisir la version d'un programme qui correspond à leur architecture matérielle et leur distribution. »

Parce que la plupart des linuxiens sont des power users. Ce que je comprends de tout ça, c'est que justement, la cible du binaire est les utilisateurs « normaux » -- c'est-à-dire : les même utilisateurs que sous Windows ou Mac. Ces utilisateurs, ils ont un nom : « mon papa », « ma maman », « ma tante », mais aussi « mes copains technophobes ». Ceux-là on besoin d'un binaire qui juste marche.

En même temps, on parle de 50 Mo à l'ère des PC avec 1 Tio de disque et 4Gio de RAM... Non, je n'ai pas ça chez moi, mais même mon PC vieux de 7 ans a 768 Mio de RAM et plusieurs dizaines de giga-octets ...

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.