lasher a écrit 2731 commentaires

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.

Comme tu dis, ces logiciels permettent, mais n'imposent pas. Certes IE 7 corrige quand même (partiellement) le tir, mais il n'empêche qu'au moment où IE s'est mis à faire dans l'activeX (c'est à dire euh ... dès que MS a sorti activeX ? :)), MS a poussé à mort pour que tout le monde intègre cette techno dans ses sites. Idem pour "sa" version de JS. Alors oui, c'est vrai, JS à la base, c'était quand même pas bien brillant, mais c'était « pour tout le monde chez les développeurs ».

Pour la pile TCP/IP bien sûr que si. Ne serait-ce que parce que le matériel en face ne parle que comme ça (routeurs, etc).

Pour le shell, si, aussi. Il s'agit d'une interface entre l'utilisateur et son disque dur par exemple. Sans shell, l'utilisateur (pas le programmeur hein !) n'a aucun moyen d'accéder à son périphérique-disque dur.

Tu t'es relu avant d'avoir bu ? On parle d'OS pour des gens là. Pas pour des geeks.

Euh, d'habitude j'ai tendance à mettre tes posts en "pertinent" (même si je ne suis pas toujours d'accord avec), mais là tu dis une grosse connerie.

La pile TCP/IP, le "shell" (même graphique) qui permet d'accéder aux fichiers, la pile USB, etc., tout ça est nécessaire pour remplir le contrat d'un OS : assurer l'interface entre les périphériques et l'utilisateur.

L'utilisation d'un navigateur web n'est en rien une nécessité pour discuter avec les périphériques.

« [À propos de l'exécution d'un prog dans n'importe quel cas] En Java non plus, cf le maintenant célèbre NullPointerException. »
Pas tout à fait d'accord. Ce qui fait de Java un langage « presque » type-safe (« presque » à cause des types primitifs qui ne sont pas des objets), c'est la garantie que ton programme ne sera pas dans un état « bloqué » / « coincé » (stuck). Quand tu as un null pointer exception, ton programme se termine bien « correctement » (même si la sortie est une erreur). À titre de comparaison en C, comme il n'y a pas de sûreté des types, tu peux te retrouver avec des résultats totalement erronés sans pour autant avoir le moyen de vérifier « facilement » que c'est bien le cas.

« le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore. »

Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).

En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.

Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.

En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.

PHP est déjà d'envergure internationale. C'est un langage très utilisé. N'empêche, quand on parle de scripter des petits trucs hors le Web, j'entends 10 fois plus parler de Python, Perl, ou Ruby que de PHP.

Maintenant, oui, on peut se servir de PHP comme d'un langage de script « générique ». Il n'a juste pas été fait pour ça à la base.