Antoine a écrit 5722 commentaires

Que veux-tu faire avec 16 ALU par coeur (sauf SMT) ? La majorité du code est beaucoup trop séquentiel pour exploiter un tel nombre d'unités en parallèle.

Honnêtement, je ne vois pas trop où j'ai vraiment joué avec le feu. Enfin, fait des choses qui sortent de l'ordinaire.

Ça sort de l'ordinaire pour 99,99% des utilisateurs, disons.

Ensuite pour ce qui est de jouer le feu, je répondrais : utiliser btrfs (ou même jfs), bidouiller du RAID avec de vieux disques fatigués (et disparates ?), vouloir tout régler à coup d'installation de Gentoo en mode power-user qui grille les étapes...

Ton point de vu n'a rien de raisonnable et équilibré pour bon nombre de personnes.

C'est parce qu'elles sont déraisonnables et déséquilibrées !

Disons qu'avec un OS comme FreeDOS, on se croit facilement quelques années en avance.

Les GPU ont déjà plusieurs milliers de shader.

Oui, les GPU existent déjà, et on voit bien qu'il y a très peu de tâches qui profitent d'un portage vers le GPU.

Cela diminuerait la pression sur la mémoire si plus de registre était disponible.

Je ne comprends pas trop l'intérêt. Le stockage de valeurs temporaires sera toujours en cache, il n'y a donc pas de pression sur la mémoire.

Quand tu as 2000 cœurs à ta disposition, du moment que tu as suffisamment de tâches à effectuer en parallèle, même s'il y a des dépendances, il suffit de « penser grain fin ».

Ah, c'est tout bête, pourquoi n'y a-t-on pas pensé auparavant.
Sérieusement, dans quelle situation as-tu 2000 tâches à effectuer en parallèle ? Je parle de tâches qui bouffent du CPU, pas qui attendent qu'une I/O s'effectue.

je pense que le monsieur ne se rend pas du tout compte de ce qui va être proposé et des contraintes dont il va falloir jouer pour arriver à produire des puces réellement dotées de centaines ou milliers de coeurs.

Quel est l'intérêt exactement d'avoir des centaines ou milliers de coeurs ? Il n'y a quasiment pas d'applications qui vont passer à l'échelle, de toute façon.

La tendance actuelle montre que le nombre de coeurs va augmenter lentement plutôt que rapidement, les constructeurs en profitant pour ajouter des possibilités d'exécution à chaque coeur, pour grossir les caches et pour intégrer de plus en plus de fonctions système (autrefois dévolues aux chipsets).

Pas du tout ? Va falloir limiter la taille des données d'entrée :)

Cela revient juste à remplacer une randomisation (aléatoirisation ?) par une autre, non ?

Puis, même si elles sont publiques, cela permet à google/... de lire le contenu lorsqu'elles arrivent et de faire du ciblage.

Oui, la définition même de « public » c'est que tout le monde peut y accéder. Tu viens de le découvrir ?
(Il est vrai ce ne serait pas du genre de Google d'indexer du contenu public sur Internet, et qu'ils ont bien besoin de lire tes mails pour avoir accès à ces mailing-lists)

Si cela te pose problème, la solution la plus simple est de débrancher le câble Ethernet (si tu utilises du sans-fil, tu peux écraser le chipset avec un marteau et plonger le tout dans un bain d'acide). N'oublie pas de supprimer ton compte Linuxfr, au cas où Google essaierait de faire du ciblage intelligent avec tes commentaires (ce serait un peu transformer le plomb en or, mais on ne sait jamais).

La question est justement si tu ne fais pas confiance au serveur hébergeant le webmail.

Tu ne lui fais pas confiance, mais tu lui demandes quand même de relever tes mails à ta place ? C'est un peu, pour rester poli, idiot non ?

Je ne vois pas l'intérêt d'aller mettre un webmail (ni tout autre service manipulant potentiellement des informations privées) sur un serveur dans lequel on n'a pas confiance. Sans compter qu'en général le webmail est fourni par l'hébergeur de mails, et celui-là tu as intérêt à lui faire confiance.

Certes, une fois que l'attaque est connue, tu peux faire ce qu'il faut pour la contourner. Mais dans ce cas, tu fais pareil avec une table hash en limitant par exemple le nombre d'éléments insérables (solution PHP). Ou bien tu aléatoirises le hachage (solution Perl, et je crois qu'on se dirige vers ça côté Python).

Avec le même genre d'arguments, un tri à bulles est préférable à un tri rapide parce que le tri à bulles, lui, est toujours lent. La bonne solution est plutôt de s'assurer que l'algo de tri ne peut facilement dégénérer, sans être d'emblée non plus en O(n**2).

Le sujet de la dépêche, c'est le temps de construction de la table de hachage, pas la recherche puisqu'on n'ira jamais chercher des paramètres qui sont envoyé mais qu'on n'avait pas prévu de chercher.

Ben si tu veux détecter les doublons, la construction implique de rechercher une clé avant de l'insérer.

Et pour chaque accès aux valeurs il faut se farcir la recherche dans la table en question (hachage du nom recherché, puis recherche). Ces opérations sont bien plus coûteuses que si s'était "rangé en vrac", à condition de ne pas avoir trop de valeurs.

Oui, bien sûr. Et comme ça un attaquant peut profiter du fait que les recherches sont en O(n). C'est quoi le sujet de la dépêche déjà ?

Au fait, pour le côté "bien plus coûteux que si c'était rangé en vrac" :

$ ./python -m timeit -s "vars=['a', 'b', 'c', 'd']" "vars.index('c')"
10000000 loops, best of 3: 0.155 usec per loop
$ ./python -m timeit -s "vars={'a':1, 'b':2, 'c':3, 'd':4}" "vars.get('c')"
10000000 loops, best of 3: 0.0751 usec per loop

Déjà avec 4 entrées, la table hash est deux fois plus rapide que la table "en vrac".

le programmeur, sachant qu'il n'y a pas de table de hachage, les fourre dans une qu'il construit pour l'occasion et le tour est joué

Oui, tiens, c'est une bonne idée ça, de laisser le programmeur se faire chier à reprogrammer sa propre table hash, correctement optimisée, à chaque occasion. Laisse-moi deviner, tu es aussi contre la gestion automatique de la mémoire parce c'est aussi simple d'appeler free() au bon moment ?

En fait tu voudrais que les langages haut niveau ressemblent au C, mais à ça il y a une solution très simple : programme en C. Problème résolu :-)

Par exemple, si ma valeur est un uint32_t, il me faut l'allouer sur le tas pour qu'il persiste.

Non, tu le convertis en void*.
(ça ne marche pas si les pointeurs font moins de 32 bits, mais bon)

Contrat d'administration, gestion et animation de forum
blablabla
Le Client souhaite confier à M Jadot qui l’accepte, la mission de d’administrer, de gérer et de modérer le forum officiel mettant en relations les membres des communautés francophones gravitant autour des produits conçus par le Client, notamment la distribution Mandriva Desktop.

Donc tu es bel et bien payé par Mandriva, mais tu ne l'as jamais dit au-dessus bien que tu trollasses copieusement fisses la subtile promotion de l'entreprise Mandriva.

Je ne suis pas sûr de voir le rapport. OpenMP est très spécialisé par rapport à la quantité d'usages du C.
Sinon, je suis d'accord, MS devra bien se mettre à la page un jour, mais quand ?

Et ce n'est pas parce que certains grincheux ont décidé que seule la norme C89 compte que ça va rester ainsi.

N'empêche que si on vise la compatibilité Windows (et ses outils natifs, pas cygwin ou mingw), on est obligé de se limiter peu ou prou à C89.

C'est un peu un running-gag cette histoire de disparition de Mandriva, j'ai l'impression de lire ça tous les ans depuis que je sais que cette distribution existe (et Mandrake avant elle).

Il ne faut pas leur en vouloir, ils n'ont pas assez de ressources pour payer des humoristes professionnels.

Oui, donc il y a un client concret et un deuxième client potentiel, et ils sont tous deux également concurrents de Mozilla. Pas de craintes à avoir.

Je sais bien que les riches peuvent avoir mauvais goût, mais j'espère quand même que les Rolls sont un peu mieux finies que KDE.

Pour Python, c'est simple, à peu près personne n'est payé pour bosser dessus.
(on peut considérer que certains développeurs de PyPy, qui sont universitaires, bossent dessus dans le cadre de leur boulot ; faudrait leur demander pour avoir plus de précisions)

GNOME Shell utilise 500Mb de RAM chez moi, je vois pas ce que ça a d'excessif

Intéressant...

J'espère au moins que tu ne t'es pas endetté sur 25 ans pour acheter ton Gnome Shell...

Gnome Shell est vraiment un bel outil, avec beaucoup de potentiel

C'est comme les agents immobiliers, quand ils te parlent d'un appartement à fort potentiel, ça veut dire que tout est à refaire.
Le jour où Gnome Shell sera devenu irrémédiablement invivable, il sera "idéal pour un jeune couple".