lasher a écrit 2738 commentaires

... Et proposent aussi des menus sans porc pour permettre aux enfants de juifs et musulmans de pouvoir manger à la cantine le midi.

Dans la constitution US, y'a juste marqué que tout homme a le droit de défendre sa famille, pas qu'il peut acheter une bombe thermo-nucléaire.

« Ils se trompent de cible ? ils visent trop large ? ils s'en branlent. »
Forcément, puisqu'ils ont récupéré les magasines des toutous et des madames dessous.

La norme du C dit qu'il y a promotion d'entier vers flottant si au moins l'un des opérandes en présence est lui-même un flottant. Comme en plus il n'y a pas de garantie sur l'ordre des opérations (sauf si on met des parenthèses), ça s'applique à toute l'expression.

Entierement d'accord sur ton second point cela dit.

Et moi pas. :-)
Je me sers de langages de script pour prototyper pas mal de trucs. Pas forcément une grosse appli monstrueuse, mais le temps que je gagne à développer ces trucs (et parfois à faire de mes petits scripts des modules qui re-servent à mes collègues) fait gagner un temps fou en dév. Après, il y a aussi des fois où je fais un rapide prototype en Perl, et ensuite je code le truc pour de bon en C (parce que par exemple, j'aurai besoin d'avoir une bibliothèque qu'on puisse directement appeler).

Malgré tout, des langages comme Ruby ou Python, qui ont tout un tas de très bons mécanismes intégrés au langage, sont tout à fait viables pour faire des applis « sérieuses ». [1] Faut-il être plus vigilant du fait que ce sont des langages à typage dynamique (par exemple) ? Pas sûr, après tout, Python fait dans le typage fort, et renvoie des exceptions et tout ce qui va avec comme les autres langages de haut-niveau.

Après quelques mois de dév Java, j'ai eu au contraire l'impression inverse : le langage est tellement rigide qu'il force à faire des contorsions pas possible là où parfois il existerait des raccourcis tellement pratiques. Mais c'est le prix à payer pour un typage fort et statique, je suppose, et aussi au fait que je devenais aigri à devoir faire du Struts/Hibernate/JBoss/JSP/JSP/JSP. Surtout JSP en fait.

Quand je suis retourné à faire du Perl par la suite, tout un tas de choses compliquées en Java me semblaient quand même vachement plus simples à accomplir avec Perl.


[1] Perl aussi selon moi, mais j'avoue avoir beaucoup de mal avec la façon dont Perl gère la programmation orientée objet, du coup je ne programme que de bêtes modules pas OO.

Il ne s'agit pas forcément de cas si particuliers que ça. Par exemple, les compilateurs sont très bons pour optimiser du code avec des accès réguliers à la mémoire (et le matériel aide aussi quand il peut). Si on doit y rajouter les indirections dues aux objets (accès aux méthodes et membres des classes), tout un tas de if, etc., on peut perdre le compilateur. Même si le branchement est prédit non pris au bout d'un moment, il y a un certain nombre limité de branches qu'il peut conserver en mémoire.

De plus dans le cas de code scientifique par exemple, typiquement un solveur itératif, il n'est pas rare d'avoir des accès de type

for (i=1; i<m ; ++i) {
____for (j = 1; j < n; ++j) {
________v1[i][j] += a + (v1[i][j-1] *v1[i][j+1]) + b + v1[i-1][j] * v1[i+1][j] + ...;
}

Bien entendu il s'agit d'un code factice, mais l'idée est là. On a même des cas où plusieurs vecteurs se mélangent. Dans ce cas précis j'ai pris un tableau 2D, donc le terme de « vecteur » n'est certes pas le meilleur, mais c'était pour illustrer mon propos.

Concernant mon post précédent, je faisais 2 remarques, orthogonales l'une de l'autre :
1/ Un langage n'est pas obligé d'imposer une seule façon de traiter les structures de données, pour tout un tas de raisons (et je prenais C++ en exemple, qui propose les deux mécanismes, à cause de certains problèmes de perf); de plus même si le langage n'impose qu'une seule façon (« Java »), il n'est pas dit que ce soit la seule bonne façon de faire, et la façon de gérer cela par d'autres langages n'est pas nécessairement moins mauvaise : tout dépend des objectifs qu'on se fixe.

2/ Concernant Ruby spécifiquement, renvoyer nil (ou undef en Perl) n'est pas nécessairement une mauvaise chose, et je parlais du fait que parfois j'ai une sortie « imparfaite » de mes scripts Perl, mais « suffisamment bonne » pour que je puisse quand même me servir de ces résultats, ne serait-ce que partiellement (je me sers beaucoup de Perl pour analyser la sortie de fichiers au format CSV ou pas très loin du CSV dumpés par mes programmes, et adapter les données à mes besoins). Par exemple, à cause d'une erreur de ma part, le script peut avoir raté une ligne (je n'avais pas prévu un certain type de format de ligne, et du coup mon script ne sait pas le gérer), mais le calcul en lui-même n'est pas forcément faux pour le reste des autres lignes du fichier que je veux traiter. Dans ce cas je préfère un warning qui me dit que je divise par 0, que j'essaie de faire des trucs avec une variable non-définie, etc, mais que le programme continue de tourner pour pouvoir quand même espérer détecter une tendance par exemple, plutôt qu'avoir un programme qui s'arrête parce que euh, ben, « Y'a une exception, là, et je sais pas quoi en faire, donc je stoppe tout. ».

Tout ce que je voulais dire, c'est que si (par exemple hein) en C++ on a décidé de proposer les deux méthodes, ce n'est pas pour rien. Il y a des fois où la performance *est* importante, et les exceptions se mettent en travers. Et au final, la réflexion concernait le fait qu'il n'y a pas de solution unique, et que le « tout exception » n'est pas forcément quelque chose de voulu ou de souhaitable. Tout dépend l'état d'esprit dans lequel on programme.

[à propos des exceptions] Certes, ca va ralentir un peu les perfs.
Non. Si tu fais un accès dans une boucle, ce n'est pas « un peu ». Alors c'est sûr, si tu comptes parcourir tout le tableau/la liste/le vecteur/etc, il vaudrait mieux utiliser un itérateur, mais parfois, on ne peut pas (la variable d'induction sert pour indexer d'autres structures, etc).

Qu'on soit bien d'accord je suis à fond pour l'utilisation de langages de haut-niveau, avec tous les mécanismes modernes qu'ils peuvent procurer, et ce le plus souvent possible. Mais il y a des fois où ils se mettent en travers de la performance, car trop présents implicitement. Dans ces cas-là, j'aimerais pouvoir « désactiver » certaines fonctionnalités (par exemple en utilisant v[i] à la place de v.at(i) en C++ :-) ) qui font que mon programme ne va pas assez vite (après avoir fait du profiling, vérifié que je ne faisais pas de la micro-optimisation pour rien, etc, bien entendu). Avant de passer à du « pur C » ou encore pire, de l'assembleur, j'aimerais bien que le langage, ou plutôt l'environnement, me laisse désactiver certains mécanismes qui me semblent superflus dans une région de code bien précise.

La façon de faire de Ruby pour l'accès aux tableaux est très semblable (identique ?) à ce que fait Perl. Quand je code en Perl, je suis conscient de ça, et c'est pour ça que j'ai les warnings à fond tout le temps, parce que l'implicite, c'est bien, mais je préfère avoir l'interpréteur qui continue de faire tourner mon code, mais qui m'avertit quand j'ai des valeurs indéfinies qui sont quand même utilisées. Ça ne bloque pas mon programme pour autant (même si souvent ça le rend "faux", ie le warning n'était pas prévu), mais parfois l'erreur que j'ai introduite n'est pas grave, au sens où le résultat que je recherche est quand même là. Bon évidemment, je finis toujours par tomber sur un cas où ça va sérieusement m'empêcher d'avancer dans mon boulot, et je dois bien arriver à faire taire ce #@! d'interpréteur qui m'avertit que je gruike un peu trop ... et donc changer mon code. :)

Concernant les NullPointerException, la différence, c'est que même en C où un programme pourrait tout à fait continuer longtemps avant de planter tout en donnant un résultat erroné, avec un pointeur NULL, ton programme plante, et c'est tout (et en ce qui me concerne, je ne fais que du C ou presque, et si j'ai un segfault, au moins je sais qu'il y a une erreur, et j'ai un point de départ pour la trouver). On aura donc du mal à la capturer. :-)

Ce que tu me decrit la, c'est exactement la List de java.
Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.

D'un autre côté, en C++, quand tu utilises un objet de classe vector, tu as deux accès possibles :

1) v.at(i), où v renverra une exception si tu fais un dépassement, et
2) v[i], où aucune exception ne sera levée, mais qui va bien plus vite en terme de latence d'accès aux éléments du vecteur.

Il n'y a donc pas de réelle « bonne façon de faire » pour des tableaux dynamiques. Parce que les exceptions c'est très bien, c'est très pratique et tout, mais à en foutre partout, on finit par plomber les perfs à cause des indirections, de l'effet « goto » qui force à se référer plus ou moins constamment à la doc (« le "goto" c'est maaaaaaaaaaaaaaal, fais plutôt des exceptions ! »), etc.

Il y a une grosse différence : Torvalds et Stallman ont décidé dès le départ de faire du logiciel libre. Red Hat (qui n'est pas à mettre sur le même niveau, vu qu'il ne s'agit pas d'une personne physique) aussi. On ne peut pas en dire autant de Sun. Combien de temps avant qu'ils ne se disent que ce serait finalement pas mal de libérer la jvm ? Et Solaris ? Bref, je ne vois pas trop le rapport. La GPL a ses spécificités, certes incompatibles avec la licence BSD (ou ses copines), mais il s'agit d'un problème « idéologique » sur la définition de liberté.

La CDDL a (selon moi bien sûr) été créée uniquement pour empêcher Linux (qui est clairement le plus sérieux concurrent à l'Unix de Sun) d'intégrer « en l'état » les softs qui l'utilisent. Je ne critique pas le choix de Sun, qui se tient d'un point de vue « stratégique » : ils n'empêchent pas les OS « mineurs » (à l'exception d'OS X, certes) de l'utiliser, mais seulement le plus gros concurrent en face.

Cela étant dit je ne critique pas le choix de Sun, et je compte bien installer OpenSolaris d'ici peu sur ma machine (j'ai tout un tas de trucs à tester sur certains réglages systèmes qu'il permet et que ne permet pas -- encore ? -- Linux). Mais quand quelqu'un se moque de MS parce qu'ils ont fait « leur propre licence », je me permets juste de rappeler que des boites qui jusqu'à il n'y a pas longtemps faisait tout autant de propriétaire que MS ont aussi les leurs.

Oui d'ailleurs, si on va par là, les fameux dtrace et zfs de chez Sun que tout le monde loue tant ont une licence libre mais incompatible avec la GPL. Sun n'agit pas "mieux" que MS sur ce point. De plus, Pour obtenir une libération de java (pas encore tout à fait libre d'ailleurs, si ?), il aura fallu attendre plus de 10 ans. Pour C# et .Net, MS a quand même été plus rapide.

Tu n'es qu'un nazi du commentaire.

Mmmh, il est pas dans la même catégorie que les orang-outang ? (ooooook)

Est-ce que c'était véritablement le but avoué de Microsoft lorsqu'ils ont mis ce système en place, ou bien juste un effet de bord plutôt « heureux » ?

On est bien d'accord, je parlais de calculs très réguliers, qui se passent bien, et pour lesquels le fait de dérouler comme un malade apporte une super performance (incidemment, sur Core 2, dérouler beaucoup n'est pas spécialement une bonne idée).

D'accord aussi pour la question des instructions prédicatées. Maintenant avec les VLIW on a quand même eu droit à tout un tas d'algos « spécifiques » pour la transformation de code (supertraces/superblocs/hyperblocs entre autres). La plupart du temps, elles nécessitent assez de mémoire pour en profiter (car on doit générer beaucoup de versions différentes des mêmes blocs d'instructions initiaux), mais sur une machine telle que l'Itanium 2 (surtout le Montecito, avec ses 1 Mo de L2I) ce n'était pas trop un problème.

Ça n'empêche pas que sur une machine out-of-order, les codes « pourris » -- ie dont le code machine/assembleur a été mal ordonnancé, l'allocation des registres pas forcément bien fichue [1] se débrouillent pas trop mal, mais les codes bien fichus en pâtissent...


[1] Bon ok, sur x86, avec ses 16 registres généraux et ses 16 registres SSE donc très spécialisés, c'est pas forcément le plus simple pour l'alloc des registres.

Bon ok, l'Itanium est mort. En plus, si en calcul flottant l'Itanium 2 est une machine de guerre, en entier il faut bien avouer que c'est tout pourri. Maintenant je me permets de faire une petite prédiction : avec l'arrivée du Larrabee et des processeurs "many core" en règle générale, je prédis que les systèmes d'exécution dans le désordre vont plus ou moins disparaître (ça prend plein de place, ça consomme plein d'énergie, etc...). Et là, Intel va ressortir des cartons tout ce qu'il a fait sur l'Itanium et son exécution dans l'ordre pour les compilateurs. Ce ne serait d'ailleurs pas forcément un mal, vu que pour le moment, même en cherchant à faire du mieux qu'on peut, sur un core 2 @ 2GHz, avec potentiellement 8 GFLOPS / coeur, si on arrive à faire 6 GFLOPS, on est déjà très content (j'ai jamais vu mieux). 75% des perfs crête c'est quand même pas génial, comparé aux 95% d'un processeur VLIW couplé à un bon compilateur.

C'est simple, entre un algo et son implémentation, à peu près 120932409 choses changent. Par exemple, beaucoup d'algos parallèles sont inefficaces en pratique (en tout cas sur un grand nombre de processeurs ou de coeurs) parce qu'ils supposent une synchro entre tous les processeurs à chaque étape. C'est très vite très lourd et ça ralentit beaucoup le tout.

Une implémentation efficace d'un algo -- qui plus est parallèle -- va devoir finir par tenir compte de certains aspects matériels. Par exemple, les préchargeurs matériels sur les processeurs sont une mâne providentielle pour beaucoup d'usages, mais peuvent provoquer une perte de performance, car ils peuvent introduire en grande quantité du trafic de cohérence de cache inutile.

De toute façon le multicore est là pour rester, car l'équation concernant la dissipation thermique n'est pas prête d'être révisée. Donc pas la peine de rêver : pour les cinq à dix prochaines années au moins, on va manger du multicore. Autant se faire à la loi d'Amdahl (et à son pendant, celle de Gustafson). Grosso modo, elle dit ceci :

Pour une implémentation parallèle de la résolution d'un problème et une taille des entrées donnés, on a

Accélération = 1 / (Par/Nproc + 1-Par),
où Par = le temps pris par la totalité du code parallèle, 1-Par est la part purement séquentielle, Nproc est le nombre de tâches parallèles exécutées concurremment.

Pour faire simple, si j'ai parallélisé mon code à 80% (0.8), et que j'ai 16 processeurs/coeurs, on a :

Accélération = 1 / (0.8/16 + 1-0.8) = 4

Gustafson est un peu plus optimiste et rappelle que nous allons bosser sur des problèmes de plus en plus gros avec la même machine, et que donc si on fait grossir la part du problème, ce qui faisait avant 80% de parallélisation fera sans doute 85, 90% ou même plus.

Dans tous les cas, un algo parallèle a tous les problèmes d'un algo séquentiel, avec en plus la part de communications et la contention sur les ressources "rares" (bus mémoire[s], entrées/sorties, etc).

[comparaison power et powerpc] ... c'est comme dire x86-AMD != x86-INTEL

Euh non. Vraiment pas. Le POWER n'a vraiment pas la même dissipation thermique que le powerpc. D'ailleurs, dans les calculateurs de type Blue Gene, on utilise des PowerPC de faible fréquence, et pas des POWER 6 à 4 GHz...

POWER != PowerPC

Hé ho, laisse-nous un peu le temps de faire les outils ! :-)
Grâce à tout ce merdier multicore, je pense que j'aurai du boulot pour encore quelques années.

Les outils qui gèrent le multicore existent pourtant en partie, mais malheureusement ne sont pas libres : DDT et Total View par exemple (qui ont aussi plein de défauts) sont des debuggers fait exprès pour les programmes parallèles (ils comprennent même MPI et OpenMP).

gdb gère les threads POSIX, et DDD (qui a récemment repris son dév) est capable d'en tirer parti.

C'est pas encore la joie, mais ça avance. Il existe tout un tas d'outils pour analyser la mémoire (ValGrind et Acumem [non-libre] sur x86 par ex).

C'est loin d'être suffisant, mais je pense qu'il faudra encore 5 ans mini pour avoir des outils utilisables par des non-experts pour trouver les bugs ET améliorer les perfs. Mais ça va venir, nécessairement.

L'alpha avait quand même un léger problème de dissipation thermique ...

En pratique, les processeurs x86 ont une micro-architecture RISC derrière le gros bidule CISC que tout le monde voit. Il y a énormément de registres qui sont gérés directement par le matériel, et qui sont non-adressables par le programmeur ou le compilateur. Il n'y a donc pas « moins » de registres que sur les autres processeurs.

J'aimerais savoir comment tu peux dire que le PowerPC et le POWER ont des moyens de développement inférieurs à ceux du x86, quand on sait qui est derrière (IBM).

Pour info, Stanford, ils se permettent de payer une misère leurs doctorants, parce que « plus tard grâce au prestige que cette Université vous apporte, vous gagnerez le gros lot -- et puis de toute manière, grâce à ce fameux prestige, si ça vous plaît pas, y'en a un autre à qui ça ira ». Et bizarrement, à l'Université d'état du Texas, le salaire du doctorant est double.

Même aux États-Unis il y a de grosses disparités. De plus il y a des regroupements qui sont effectivement faits (Paris-Sud, etc.), mais il faut aussi laisser le temps à ceux-ci de devenir « réels » : on part d'une situation morcelée (des univ. partout), et il faut que chaque PRES se consolide.

Sauf que Gnome et KDE ont globalement un look & feel, et des fonctionnalités "de base" proches (on a juste un problème de fonctionnalités -- ou plutôt d'absence de fonctionnalité, dans le cas de Gnome), alors que d'autres WM ont tendance à se vouloir plus minimalistes, ou bien avoir des comportements qui s'éloignent de ceux auxquels Gnome/KDE nous ont habitués.

Sans parler du fait que quelque part Linus a dû trouver ça marrant d'aller voir dans le code et passer quelques dizaines de minutes à faire son patch.

Pour Ethernet c'est "obligatoire", si on considère que Ethernet recouvre à la fois la couche physique et la couche liaison (ce qui est le cas).

Pour les routeurs, je prenais cet exemple car, SI, il existe des implémentations hardware de TCP/IP (ou parfois c'est mis en firmware), et du coup, ceux-ci ne savent pas parler autre chose. Si tu veux que ton OS puisse communiquer efficacement, il faut nécessairement que TCP/IP soit géré "nativement".

Concernant le shell, graphique ou pas, il faut bien que tu puisses dialoguer avec ton disque. Que je sache, si tu en fais une application "externe", tu déroges au côté "mon OS doit me permettre de dialoguer avec mes périphériques".

Donc même si on peut parfaitement refaire le monde ("ls" et ses copains par exemple), il me semble qu'il est du domaine de l'OS d'en fournir un en standard.