lasher a écrit 2738 commentaires

On dit "oyez". Du verbe ouïr.

Je pense que tu as raison. Il ne faut pas oublier que s'il est vrai que les adresses doublent en taille, mais que pour une application multimédia (DVD, jeu, etc.) par exemple, ce qui consomme le plus de place, ce sont les données, qui elles ne changent pas. La partie purement code et adresses devient anecdotique au fur et à mesure que la somme de données a récupérer grandit.

Bon, the intraweb a l'air de te donner raison. Cependant, je me donne le droit de questionner la réalité et de revenir ici avec plus d'informations.

Breaking news. Alors j'ai pigé. Apparemment il est possible de forcer la FPU x87 à se limiter à 64 bits, alors que pour l’unité SSE, c'est tout simplement pas possible.

Tu peux douter tant que tu veux, ça reste vrai. :) L’unité flottante utilisée par les instructions SSE est sur 80 bits en interne, avec accumulation potentielle si tu peux "pipeliner" les opérations (d'ou une meilleure précision). Sauf que le client de nos partenaires utilisait des machines "vectorielles" NEC qui se contentaient de la norme stricte IEEE, et donc les tests échouaient malgré une précision accrue.

De plus, si tu utilises le compilateur d'Intel (ce qui était mon cas), a partir du moment ou du spécifies -mieee-strict (ou un truc du genre), la plupart des optimisations qui devraient etre legales (puisque + et * sont commutatifs) deviennent "illégales" du point de vue d'icc (justement à cause des problèmes d'arrondis), et icc génère du code x87.

Non non. FPU == 64 bits "purs" là où SSE2+ == 80 bits en interne lors de l’opération.

Si la puce Itanium avait pu émerger, nous aurions du vrai 64 bits sur nos laptops, et on serait dans un monde meilleur.

En attendant, les machines à base d'Itanium 2 ont un double emploi : calcul haute-performance bien sûr, mais aussi table-basse chauffante (quand tu as la version "mini-armoire" et pas un rack).

Les perfs sont moins bonnes. Cependant, parfois, l'important c'est la reproductibilité des résultats. J'ai bossé avec des partenaires industriels qui refusaient mes optimisations parce que l'ordre des opérations sur les flottants n’était plus garanti. En pratique ca n'aurait rien du changer (les instructions SSE2 et plus sont effectuées sur 80 bits en interne), mais du coup la norme IEEE754 sur 64 bits n’était plus respectée, et malgré des résultats plus précis, ils ne pouvaient plus passer les tests de régression de leurs clients... Du coup : FPU.

Je croyais qu'on parlait d’école primaire ... ?

Balancer un lien sur Singleton n'est jamais perdu. Tu considères peut-etre que tout le monde sait en 2011 ce qu'est un Singleton. C'est faux. N'importe qui visitant ce site et regardant les commentaires peut ne pas savoir ce que c'est, et encore pire, avoir une idée confuse de ce qu'est ce pattern. Pour info, les informaticiens qui sont susceptibles de ne pas savoir ce qu'est un singleton sont légion:

• Les gens fraîchement débarqués d'IUT/STS
• Les ingénieurs qui ont fait une école généraliste et qui font dans l'admin système (et pas la prog)
• Les autodidactes
• ...

Pif Gadget et Super Hercule. Mickey magazine. Picsou Magazine et Super Picsou.

** PAN **

Et Titan. Et Nova. Et ...

Et Strange Special Origines !

Et les Recits Complets Marvel ! Et les Top BD ! Aaaah Lug/Semic ... :'-)

C'est faux, il existe un moyen de faire un "sudo" depuis un compte utilisateur normal. Je ne l'ai plus en tête, mais je l'ai utilisé quelques fois quand j'en avais besoin.

Déjà si on pouvait expliquer aux gens qui utilisent toujours sed et awk que Perl fait la même chose avec un seul outil... voila voila...

--> [ ]

Je te rappelle que les BSD avaient de « légers » problèmes légaux à l'époque où Linux était développé. Tu crois vraiment que Torvalds aurait essayé de redévelopper un OS sur son 386 si BSD avait pu être distribué librement à l'époque (indice: il existait des UNICES sous licence BSD qui pouvaient tourner sur 386)¹.

Le développement d'un unix (ou d'un clone dans le cas de Linux) libre était simplement dans l'air du temps. Si Torvalds n'avait pas décidé d'écrire son OS, quelqu'un d'autre s'y serait collé, et ce n'était vraiment qu'une question de mois pour que ça n'arrive.

[1] En pratique peut-être bien que Torvalds l'aurait fait quand même.

Mais il y a dans le libre beaucoup plus que le fait d'avoir le droit de redistribuer le logiciel : C'est l'obligation de redistribuer les sources, et les modifications s'il y en a.

Non. C'est la GPL que tu décrits. Un logiciel libre est juste décrit par la FSF par ses quatre libertés.

Ben oui. Une minorité est capable de peindre (j'en suis personnellement incapable). Une minorité est capable de faire de la vraie plomberie chez elle. Une minorité est capable de faire quelque chose de technique dans un domaine précis en règle générale. Voici la différence: si tu touche un tout petit peu en plomberie (genre t'as eu un problème, t'as vu ton plombier changer le flotteur pour tes chiottes, et en fait t'as pigé que c'était pas bien compliqué), ben tu peux le faire toi-même (ou au moins tenter de le faire) la prochaine fois que tu as un problème de fuite dans tes WC. Avec un logiciel proprio, si tu as un bug, ben tu demandes à l'éditeur de bien vouloir le corriger. Si le bug « intéresse » l'éditeur (ie il a un intérêt financier à le corriger), alors tout va bien pour toi. Sinon, ben tant pis. Avec le logiciel libre, si tu as un problème, ben tu peux aller voir un « plombier » logiciel (un forum, remonter le bug, engager un consultant très cher, etc.). Tu peux aussi tenter de réparer le soft toi-même (parce que tu as vu ton-copain-qui-s-y-connaît le faire, parce que ton contrat avec le consultant spécifiait un rapport détaillé de la procédure de correction de bug, etc). Dans tous les cas, tu as la possibilité de changer quelque chose, ce qui est impossible (soit techniquement, soit légalement) avec le logiciel proprio.

Je ne pirate pas, mais si je me vois imposé une telle taxe, je ne priverai pas de le faire.

Ah ben voilà, tu viens de dire exactement ce que je répète à longueur de temps : je ne pirate en général pas (plus), mais depuis la taxe sur TOUS les supports de stockage + DADVSI + HADOPI, ben je considère que c'est une provocation, donc j'ai tendance à copier bien plus de trucs sur le net (en pratique, j'achète bien plus que je ne pirate, mais c'est une autre histoire).

Non, ce n'est pas une théorie. La possibilité de modifier les sources est très concrète. C'est tout ce que le LL garantit. Je pense qu'ici tout le monde sera d'accord pour dire que la capacité à modifier un logiciel (libre ou pas), elle, réservée aux gens qui savent comment faire (i.e. qui savent utiliser un éditeur de texte¹).

[1] Je sais, l'éditeur ne suffit pas. :) Mais si j'ai envie de modifier la sortie de uname je peux parfaitement rajouter une chaîne de caractère à la con, sans pour autant avoir à comprendre exactement comment le C fonctionne (même si bien entendu si je sais, alors c'est d'autant plus facile).

Ben tu vas deux fois moins souvent voir (Johnny|Les Musclés|blah) mais tu vas voir un opéra. Faut pas oublier que contrairement aux groupes de rock qui n'ont « que » deux à cinq membres en règle générale (y'a toujours des exceptions), un opéra nécessite un orchestre complet, un ensemble de chanteurs/acteurs sur scène, etc.

Bref, y'a aussi l'équivalent des roadies, techniciens/ingés du son, tout ça, comme pour un concert de rock, mais aussi beaucoup, beaucoup de gens en plus à payer. Tout compte fait, 75€ c'est pas cher, je trouve.

Mais ça ne passe pas forcément à l'échelle. C'est pour ça qu'il existe (par exemple) des modèles mémoire (tels Entry Consistency ou Location Consistency) qui ont des contraintes très relâchées en ce qui concerne la façon dont la mémoire est vue au sein d'un système et vis à vis d'un cœur.

Si si, tu déplaces le problème. :) Le problème devient un problème « matériel » où la contention sur les opérations atomiques mène à une baisse de performance en cas de pas-de-bol-itude. En pratique, les algos non-bloquants, et plus généralement les algos "lock-free" garantissent que parmi tous les threads au moins un progresse, mais n'offrent aucune garantie quant à la vitesse d'exécution proprement dite. Il existe tout un tas d'études qui montrent que les algos utilisant des verrous à grain fin vont plus vite que ceux utilisant une méthode lock-free, tout bêtement parce que l'implémentation des verrous fait qu'une bonne partie des opérations peut avoir lieu en cache et pas directement en D-RAM.

Aussi, en pratique, utiliser des opérations atomiques fait gagner (pour une même charge de travail) un facteur 2 (ce qui n'est pas négligeable, j'en conviens), dans le cas où tout est optimiśe aux petits oignons (je peux retrouver des références si tu veux, et je peux aussi te rediriger vers mon collègue qui a écrit un de ces articles). Mais dans la vraie vie malheureusement, les gens ont du mal à correctement implémenter des algos non-bloquants et/ou lock-free. Herb Sutter a même écrit des articles sur le sujet.

Ton code a un problème : tu suppose que *val va être lu depuis la mémoire. En pratique c'est très souvent faux, car le compilateur a tendance à générer un code de ce genre :

# On suppose que debit est stocké dans r3
ld r4, @val # val est une adresse absolue en mémoire, r4 est choisi arbitrairement
sub r4, r4, r3 # r4 -= r3
st @val, r4

C'est approximatif, mais l'idée est là. Entre le moment où le chargement de val dans r4 et le moment où l'on écrit par dessus val, plein de choses peuvent s'être passées — entre autres, un autre thread essaye de faire exactement la même chose.

Oui. Le problème se pose avec tout besoin d'atomicité sur des variables partagées.