lasher a écrit 2741 commentaires

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.

Oui enfin comme Fortran 77 quoi.


.
.
.


Grmbl. /me repart lire du code écrit il y a moins de 3 ans en Fortran. :-/

Oui alors là par contre je ne suis pas du tout d'accord.

Un compilateur sur une machine Out-of-Order a justement *moins* de boulot à fournir, vu que le moteur OoO matériel se charge de rendre moins moche un code « mal généré ».

Pour donner un ordre d'idée, sur une archi certes quasi-morte, à savoir l'Itanium 2, la qualité du code généré par gcc comparée à celle d'icc [1] est carrément lamentable. Le compilateur d'Intel dans ce cas est en moyenne 3 fois plus performant que gcc. Bien sûr, il y a plusieurs raisons :
1/ Plus de dévs pour gcc/x86 (mais là je renvoie à gcc/PowerPC qui se débrouille plutôt bien, et je suis sûr que l'OoO y est pour beaucoup)
2/ L'Itanium 2 n'est pas une machine très répandue (et pour cause), ce qui est finalement une variation sur 1/. :)

N'empêche : l'Itanium 2 a une architecture VLIW et superscalaire, et dont les seules opérations out-of-order sont liées à la mémoire. Presque tout est laissé au compilateur, et si celui-ci se débrouille mal pour la génération de code, alors le programme résultant sera vraiment mauvais.

Sur x86, l'OoO limite vraiment la casse.

[1] Le compilateur du constructeur (Intel), donc évidemment il y a un avantage net pour ce dernier, qui possède le modèle machine du CPU

Tout à fait, et ça permet ensuite d'être root. C'est une feature très sympathique. :P

Bouais. Pas vraiment. Au moment de l'édition de liens, ton code assembleur est donc lié aux bibliothèques que tu utilises (libc, etc.), et du code supplémentaire est généré par l'éditeur de liens. Sans parler du fait que parfois certaines mnémoniques, pourtant différentes au niveau ASM sont traduite dans le même opcode au niveau binaire.

Je suis tout à fait d'accord avec toi, c'est d'ailleurs pour ça que j'écris tous mes programmes en assembleur. Cependant, il y a encore trop d'abstraction, donc je crois que je vais finir par tout écrire directement avec les opcodes.

Oui, et ? J'ai passé 1 an et demi sur un noyau de calcul. À tout péter, je dois avoir au final 50 lignes « utiles ». Sauf qu'en fait, la moindre modif de code implique une différence importante en termes de perf. Comment tu évalues ça ? :)

Évidemment je fais exprès de prendre un cas extrême. L'autre bout de la chaîne serait du code généré à 90% par un IDE (génération des setters/getters, refactorisation de code semi-automatique, etc.). Sans parler que quand un modèle essaie de parler de « mois-hommes » je pense directement au « Mythical Man-Month » de Brooks.

personne ne regrettera ce truc

J'attends de voir, très honnêtement. Parce que tout de même, OpenMP n'existe pas que pour C++ et C, mais aussi (et surtout ? :) ) pour Fortran. gfortran va-t-il profiter de Grand Central ? Je ne crois pas ... :)

Je ne vois pas comment deux ISA aussi différentes que ia64 et x86_64 pourraient converger.

Ia64 est VLIW+superscalaire, in-order (sauf pour certaines opérations mémoire), là où x86 est superscalaire out-of-order. Le seul truc qui se rapproche "un peu" (mais alors juste un peu) de l'Itanium pourrait à la limite être le Larrabee, mais uniquement parce qu'il s'agit d'un proc superscalaire in-order lui aussi.

Après, si par converger tu veux dire qu'un jour l'ISA x86 aura des instructions prédicatées et qu'on retournera à du many core in-order, c'est bien possible, mais on sera toujours loin de l'ia64 ...

Putain.

« se moque-t-on », bordel.

Un code écrit comme un cochon, même libre, c'est difficile à reprendre. Et pas mal de boites font appel à des prestas pour développer une application en interne (elle peut être libre mais ça ne change rien au fait que la boite l'utilise en interne, par ex). De ce côté-ci, propriétaire ou pas, même si tu as la possibilité d'engager ensuite un autre presta pour maintenir le code, tu es passé d'une servitude à une autre : on passe de « je dépends d'un soft proprio » à « je dépends d'un prestataire précis ». Le deuxième cas est sans doute « moins pire », car si vraiment ça ne va pas, on peut toujours changer, mais ça n'empêche pas que ça coûte cher, voire très cher de faire maintenir un soft. Surtout si ladite boite est la seule à l'utiliser.

Enfin, pour une utilisation desktop, même si je suis d'accord qu'on n'aura pas d'accélération 3D correcte sans le RSX, le Cell peut faire de très belles choses pour ce qui est de l'accélération 2D

A la base la PS3 ne devait pas avoir de GPU, et tout devait être fait avec les SPE. On a sans doute fait remarquer à Sony que c'était déjà assez compliqué à programmer comme ça, sans en plus avoir à gérer tout ce qui est graphique avec les SPE. Donc faire de la 3D avec le Cell c'est tout à fait possible. D'ailleurs, M. Abrash a fait de même pour OpenGL sur archi x86 avec juste SSE (bien entendu dans ce dernier cas c'est beaucoup moins rapide qu'avec une carte graphique, mais c'est utile dans certains cas).

Nous avons 2 PS3 au labo pour nos tests sur Cell. La raison est très simple : si nous voulons acheter des Cell "complets" chez IBM, c'est TRES cher, alors que pour jouer avec l'archi PowerPC PPE/SPE, une console suffit.

Pourquoi "grep" ? Alors que '/' en mode commande sert justement à ça
(ou bien l'utilisation d'*' et de 'n')...

Et puis je vois pas trop ce que tu reproches aux ctags (si ce n'est que le raccourci pour s'en servir n'est pas super adapté aux claviers azerty).

Bof, pas pire que le Vegemite australien ... (Bon ok, j'aime pas non plus :))

Ça veut dire quoi, « trop mal » ?