lasher a écrit 2744 commentaires

Bah le problème de la PS3 était que le SDK était tout pourri, de ce qu'on m'a expliqué (j'y ai jamais touché). Bon, il y avait un autre problème aussi. Un mec d'une agence US à trois lettres que je n'ai pas le droit de nommer l'avait relativement bien expliqué devant des mecs d'IBM, Intel, etc. : « Le prochain architecte qui me propose une architecture de processeur sans cache d'instruction et me force à gérer la copie des donnés et des instructions dans les scratchpads, je vais physiquement lui faire très mal. »

C'est marrant, tu as exactement le point de vue du côté hardware : croire que c'est en faisant des améliorations matérielles qu'on arrivera à avoir des performances.

Ce n'est absolument pas ce que je sous-entends. Et je ne dis absolument pas que les mecs du hardware sont les « gentils », et les mecs du soft les « méchants ». Je suis un mec du soft moi-même, et il se trouve que j'ai bossé (et je continue de bosser en fait) beaucoup avec les gens de la compilation, mais aussi avec des architectures pour les processeurs.

Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur, il tique. En gros, l'idée de notre projet est de justement exposer le plus de trucs en hard au logiciel, pour le que le logiciel fasse ce qu'il veut/peut avec. Ensuite, les mecs des compilateurs/runtimes retournent parler avec les architectures/mecs du hard, et leur disent ce qui définitivement nécessite d'être mis en œuvre en matériel, et ce que le logiciel peut faire efficacement sans aide matérielle.

Le point de vue que j'expose est aussi celui de pas mal de chercheurs en compilation : en gros, on a des techniques, on démontre qu'elles fonctionnent soit expérimentalement, du genre « je te donne mon algo, mais pour mes expériences j'ai tout transformé à la main », soit tu fais quelque chose de relativement théorique du genre « tiens, voilà mon algo, qui est en complexité polynomiale, et je fais la preuve qu'il est correct ». De temps en temps, tu as des mecs qui l'implémentent pour de vrai dans leurs compilateurs (heureusement). Mais je dirais que c'est du ⅓/⅓/⅓ en termes de proportions quand tu lis les papiers de recherche. À ceci il faut rajouter que l'implémentation n'est pas nécessairement disponible (parce qu'elle est faite dans un compilateur proprio), ce qui force donc le mec qui veut mettre en œuvre la technique de découvrir par lui-même tout ce qui n'a pas été dit. Parfois, ce qui fait qu'une technique fonctionne bien tient autant à l'algorithme qu'aux subtilités d'implémentation.

C'est par exemple ce qui s'est passé pour le papier sur la forme SSA : le papier était le premier à proposer un algorithme utilisable (i.e. en temps polynomial) pour exploiter SSA. Le truc, c'est que même si tu as trouvé le bon algo, écrire un compilateur nécessite de choisir très soigneusement ses structures de données. Il existe des papiers qui tiennent plus de l'ingénierie que de la recherche, mais qui expliquent comment un algorithme (par ex, mise sous forme SSA, puis faire un « de-SSA ») est équivalent à l'original, mais plus simple, et donc plus facile à implémenter sans bug.

De plus, SSA en elle-même n'est pas une optimisation, mais elle permet d'obtenir une représentation du code qui permet les optimisations plus facilement.

Sinon, les chercheurs en compilation vont bien entendu aussi te dire que les mecs du hardware te sortent des features de leur chapeau, sans forcément penser à « l'interface », ce qui rend la tâche du dév. de compilateur pour le moins ardue (par exemple : toutes les options proposées par l'Itanium en font un processeur — au moins de recherche — génial, mais avec aucun moyen « facile » de les utiliser depuis des intrinsics).

Première raison, c'est que les principaux gains de performance qui ont lieu ne sont pas dû au matériel comme tu le sous-entends mais sont principalement le fait d'avancées algorithmiques (surtout dans le domaine du calcul scientifique auquel se destine le processeur dont nous parlons),

Pour le calcul scientifique, j'ai déjà dit ailleurs qu'entre deux générations de processeurs, il fallait souvent ré-adapter le code pour la nouvelle architecture (les timings étant différents pour certaines séquences d'instruction, la hiérarchie mémoire ayant changé, etc.), ce qui se fait évidemment de façon logicielle. Cependant, surtout dans le cas des x86, oui, la venue des moteurs out-of-order, couplée à la présence de préchargeurs mémoire en matériel fait que, très souvent, il n'est plus nécessaire d'insérer à la main les trucs du genre _mm_prefetch(address).

Enfin, il est évident que le choix de la bonne structure de donnée et du bon algorithme sont les sources fondamentales de performance. Ce qui est aussi évident cependant, c'est que si ton implémentation utilise le « bon » algorithme, mais que les constantes élidées de ton algo en O(N) ou O(N log N) sont trop grosses, au final pour beaucoup des programmes scientifiques en question et qui tournent sur des workstations ou des petits clusters, la différence avec des algos à la complexité moins bonne mais mieux optimisés sera minime. Même sur les gros calculateurs, si ton programme est visiblement mal optimisé, tu risques de te prendre un refus par ses admins, parce que le temps machine est précieux (et que ça bouffe en électricité).

La raison pour laquelle les architectes rajoutent des fonctionnalités en matériel est évidemment qu'elles sont considérées comme utiles par les mecs du soft. Les instructions AltiVec ou SSE sont limitées en termes d'utilité pour les programmes en général, mais pour écrire des BLAS efficaces, si tu n'utilises pas ces instructions sur PowerPC ou x86, tu perds potentiellement entre 20 et 50% de performance (je prends en compte le fait que ton code ne fera pas que des multiplications de matrices).

Deuxième raison, le compilateur ne fait pas tout. Oui, comme tu le dis, il faut avoir un modèle de programmation parallèle, et si le matériel pouvait éviter de figer le modèle, on s'en porterait mieux, ça permettrait de pouvoir tester plein de modèle et de choisir suivant les cas. C'est bien l'algorithmique parallèle qui va amener les principaux gains, et pour faciliter le travail algorithmique, une machine «simple» (au sens où on peut en avoir une abstraction simple, mais elle peut être très complexe en vrai) et prévisible, c'est mieux.

Ben je suis dans un groupe de recherche qui justement cherche à proposer un modèle d'exécution¹ adapté aux manycores. En gros notre but est de fournir une sorte de vision un peu abstraite d'un « assembleur parallèle ». Ensuite, si tu veux continuer à utiliser OpenMP¹, mais qu'il génère notre truc, on est très content aussi (il faut juste quelqu'un qui écrive le compilateur qui va bien …).

Le gros problème est effectivement (comme je le disais dans un commentaire plus haut) un manque de communication entre les fabricants de processeurs/machines parallèles, et les gens des logiciels systèmes (OS, Runtime, compilateurs). La communauté scientifique en prend lentement conscience, à mesure que 50 000 machines parallèles voient le jour, chacune avec leur modèle d'exécution, chacune avec leur modèle de programmation.

[1] Je dis bien exécution et pas programmation. Par exemple, le modèle de von Neumann est un modèle d'exécution séquentiel.
[2] Voilà, ça c'est un modèle de programmation. :-) … Bon, il a aussi un modèle d'exécution, mais c'est pas (trop) important pour le programmeur.

Il y a tout un champ de recherche sur des mémoires locales (caches ou scratchpads) ou même la DRAM qui soient désactivables par morceaux (clockgating ou même powergating) en fonction de ce dont les processeurs ont besoin, justement pour que tu puisses réduire la consommation statique. Intel a récemment publié un papier (il y a ~6 mois ?) qui montre comment utiliser une FPU avec une précision variable pour des FMA, histoire de pouvoir « couper » la partie du bus qui ne sert à rien. Les modes étaient quelque chose du genre 16bits, 32bits, et 64bits si je me souviens bien.

Mon exemple est tiré d'un papier de compilation pour GPU. Il est tout à fait possible que la façon dont j'ai simplifié/représenté le pseudo-code (de mémoire) ne déclenche pas ce comportement tel qu'écrit. Mais c'était réellement l'idée à 1000km d'altitude.

Je suis en train de chercher le papier en question, et dès que je le retrouve, je viendrai donner les références ici.

Je parle en termes de recherche bien sûr, et par exemple les projets auxquels je participe en ce moment ont tous le co-design à l'avant plan : des mecs de la compilation, des mecs des runtimes, des mecs de l'archi, etc., mais aussi des mecs des applications.

L'Itanium 1 (Merced) était compatible x86. Il y avait une couche d'émulation (très lente).

Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus.

Oui enfin c'est un peu facile comme remarque. Pendant environ 20 ans, on a eu droit à la loi de Moore « facile », celle qui transformait « pour une surface donnée, on va doubler le nombre de transistors tous les 18 ou 24 mois » en « on va doubler la fréquence d'horloge des microprocesseurs tous les 18 à 24 mois ». Maintenant qu'on ne peut plus faire ça, on (re)passe au parallélisme (qu'on croyait être la panacée dans les années 70 et 80, et qui avait été déclaré mort et enterré pour l'usage générique dans les années 90 jusqu'en 2005). Donc pendant 20 ans, le hardware grand public accélérait plus ou moins automatiquement l'exécution d'applications, parfois sans même avoir besoin de recompiler. Bien sûr il y avait quelques trucs supplémentaires ici et là (AltiVec, 3dNow!, MMX, puis SSE, AVX) pour écrire des applications qui pouvaient spécifiquement viser certains types de codes (comme les instructions AES pour SSE4), mais globalement tout était pépère pour des applications « grand public ».

Pour les gens qui écrivent des applications dans un environnement où les ressources sont très limitées (en gros les applications de calcul scientifique/calcul intensif et les applications embarquées), chaque nouvelle version d'un processeur a tendance à rajouter son lot de comportements qui perturbent fortement les performances. Comme les compilateurs ont tendance à évoluer relativement lentement, on se retrouve à faire des optimisations à la main, et qui souvent devront être refaites/modifiées pour la prochaine génération de processeurs.

Et la raison pour tout ça, c'est qu'il y a deux facteurs de ralentissement pour l'optimisation automatique de code (en utilisant un compilateur) :

1. Entre le moment où une technique/un algorithme/etc. pour l'optimisation de code est publiée quelque part et le moment où elle est mise en œuvre dans des compilateurs en production, il se passe environ 10 ans. Le hardware n'y est pour rien. Par exemple, une version efficace de la représentation de programmes sous forme SSA (Static Single Assignment) a été proposée en 1989. Elle a été mise en œuvre dans des compilateurs de prod' vers 1997 si je ne me trompe pas (dans open64 de SGI), et dans GCC pas avant la v3.5, soit vers 2003-2004.
2. Entre le moment où le hardware expose de nouvelles fonctionnalités, que ce soit des instructions vectorielles (MMX/SSE/AVX), l'utilisation de prédicats pour exécuter du code spéculativement (sur processeurs Itanium ou ARM), les instructions de préchargement mémoire, ou même comme plus récemment, une version limitée de mécanismes de mémoire transactionnelle (sur certains modèles du Haswell d'Intel, ou bien pour les processeurs de Blue Gene Q), et le moment où elle peut être exploitée automatiquement, il se passe entre 5 et 10 ans. Par exemple, la génération automatique d'instructions vectorielles sur GCC a été considérée comme expérimentale jusque vers GCC v4.3 je crois bien (je peux me tromper). Pire, elle reste extrêmement restreinte comparée à l'implémentation d'Intel dans ICC.
3. Bref, le temps qu'un compilateur exploite correctement les features d'une archi, celle-ci a le temps de devenir dépassée (c'est quasiment le cas avec l'Itanium 2 par exemple).

Et oui, il y a un gros effort à faire pour faire communiquer les architectes et les développeurs de compilateurs et autres bibliothèques haute performance. D'ailleurs, un bon moyen d'obtenir des sous pour la recherche aux USA et en UE depuis environ 2009-2010, c'est de parler de co-design, en montrant qu'on associe des mecs du hardware et des mecs du software pour faire un système informatique avec un modèle d'exécution parallèle qui tient la route (càd : une vraie sémantique parallèle, un modèle mémoire qui permette les optimisations tout en assurant que les programmes s'exécutent correctement, et un modèle de synchronisation qui relie modèle de concurrence et modèle mémoire de façon cohérente).

Déjà, il est bon de noter que du à l’architecture, les OS conventionnels ne peuvent tourner sur les 256 cores (l’interconnect ne le supporterai pas).

C'est vrai. En même temps, je ne vois pas pourquoi je voudrais forcément que l'OS tourne sur l'intégralité des cœurs.

Linux tourne sur seulement 4 cœurs, et les autres sont accessibles via une interface particulière, un peu comme on enverrai des shaders sur un gp-gpu ou un firmware sur un microcontrolleur.

Oui, car les quatre cœurs en question sont les seuls à pouvoir gérer les I/O (entre autres).

Donc déjà ça veut dire que vos applications traditionnelles (erlang, go, openmp…) ne vont pas profiter du cluster sans effort.

Oui, il faut utiliser une sorte de dialecte de C/C++ fournit avec le processeur. De ce qu'on m'a dit, programmer efficacement avec n'est pas sans peine. Cependant pour être honnête, c'est aussi vrai pour Cuda/OpenCL/OpenACC/HMPP/ etc. C'est même vrai pour les processeurs Intel/AMD/etc., où sans qu'on sache vraiment quand ni comment, certains aspects micro-architecturaux font qu'une série d'instructions assembleur vont se révéler très efficaces, mais avec la nouvelle version du Core i7 (par exemple), on se retrouve avec une performance unicœur plus pourrie. Pourtant, sur le papier y'a les mêmes specs : 32Kio de L1D, 256Kio de L2, 8Mio de L3 partagé… Sauf que non, le L3 n'est plus un cache avec une file d'attente, il s'agit désormais d'un cache de type NUCA (Non-Uniform Cache Access), donc segmenté, et que désormais la file d'attente est elle aussi segmentée, et … Bref. CUDA est encore pire, car même si on a accès au jeu d'instruction assembleur (PTX), il s'agit d'un langage « virtuel », et d'une carte Nvidia à l'autre la performance d'une séquence d'instructions PTX « optimisante » peut se retrouver « pénalisante ».

Ben en l'occurrence, le Xeon Phi, c'est Larrabee qui arrête de se prendre pour un GPU. :-)

Il y a 50 cœurs sur une carte dédiée pour la première génération (Knight Corner si je me souviens bien), mais la prochaine génération (Knight Landing) devrait être intégrée à un processeur multicœur classique, ce qui réduira évidemment tous les problèmes de latences dus aux transferts sur port PCI. Après, reste à savoir si le premier essai d'Intel sera mieux fichu que celui d'AMD avec le fusion (apparemment ça va mieux avec l'archi utilisée pour la PS4 et la Xbox One).

Le prix est relativement élevé, mais c'est quelque chose d'attendu. Un autre processeur manycore, Tile64 (produit par Tilera, une boite fondée par un prof au MIT), coûte dans les ~12000$ (ça inclut la chaîne de compilation basée sur gcc, la carte d'extension, etc.). Le MPPA est plus ou moins dans le même ordre de prix si je me souviens bien. Il ne faut pas oublier que les processeurs type Alpha étaient aussi très très chers comparés aux x86 dans les années 90.

Le problème est évidemment lié au volume de production. Au début seuls les gens qui ont un réel besoin de ce genre de processeurs (effectivement, les organismes de type CEA/DAM, DCRI, l'armée en règle générale, etc.) peuvent se permettre d'acheter ces trucs. Mais si ces processeurs ont un succès « significatif » dans ces niches, on peut espérer voir des versions plus « grand public » et plus faciles à produire en masse.

Pour aller dans ton sens : je l'ai déjà dit ailleurs, mais les deux « gros » compilateurs pour Itanium 2 sont icc et gcc. Le premier a mis deux ou trois générations avant de générer du code ultra optimisé (à partir d'icc v9.1 en gros, le code devient vraiment bon, avec une bonne exploitation des techniques de pipeline logiciel, la if-conversion, etc.). Le deuxième (gcc donc) génère du code entre deux et dix fois plus lent qu'icc. Pourtant, le modèle machine est bien mieux décrit pour IA64 que pour x64 ou ia32 (c'est nécessaire, vu que le compilateur doit générer tout le code statiquement).

Et en fait, si on regarde les techniques proposées pour accélérer le code sur VLIW, on trouve tout un tas de « contournements » de l'aspect statique pour la génération de code. On peut citer par exemple les techniques de « trace scheduling » (trop complexe à implémenter la plupart du temps) et surtout de « superblocks » et « hyperblocks ». L'idée derrière tout ça est de faire de la compilation guidée par profilage (profile guided optimization) :

1. On compile une première version du binaire et on l'exécute sur un petit jeu d'entrées représentatives.
2. Après avoir instrumenté l'exécution de ce mini-run, on recompile le code en y ajoutant des annotations.
3. Durant la compilation, on va générer plusieurs versions du « chemin chaud » (hou, je préfère la V.O. : « hot path »), ou si on préfère un autre terme, du « chemin critique » en termes de temps passé à calculer. L'idée est de profiter des capacités de spéculation sur les données et sur le contrôle de l'Itanium pour statiquement prédire « prise » l'une ou l'autre branche d'un if/else. La plupart du temps, si le code n'est pas trop irrégulier niveau contrôle, la spéculation sera une chose positive. Pour les rares cas où ça ne l'est pas, on doit rebrancher sur le code original, et « rejouer » toute la partie de code qui avait été spéculée. Évidemment, si on ne se trompe que de temps en temps, le surcoût est négligeable. Si on a mal effectué le profilage, ou si le code est trop irrégulier (ce qui est le cas des codes type compression de donnée, dont le comportement dépend fortement des entrées par exemple), cette optimisation va ruiner les performances.
4. La techniques des hyperblocks est similaire à celle des superblocks, mais rajoute en plus la if-conversion (et là, je renvoie à un truc que j'avais écrit cet été en promettant une suite pour « bientôt » — haha, la bonne blague).

Bref, bien qu'il existe tout un tas de techniques de compilations pour statiquement utiliser au maximum les unités fonctionnelles d'un processeur (VLIW ou pas), ces dernières ont toutes des désavantages liés au fait qu'il faut faire du profilage de code sur tout un tas d'entrées différentes pour avoir une optimisation qui marche « au mieux » dans le cas moyen. Les gens de Firefox (ou Chrome, ou…) peuvent le faire en partie grâce aux informations remontées par les PC d'utilisateurs qui indiquent quel genre de pages ils visitent, etc., ce qui fait que les fermes de compilation peuvent prendre en compte ce genre de trucs, et effectuer de la PGO (profile-guided optimization). À moins de faire de même pour tous les softs utilisés (avec les risques liés à la vie privée que cela comporte, sans parler du flux constant d'information qui ira vers le net et qui accompagnera toute exécution de n'importe quel soft — y compris ls ? ;-) ), ça risque d'être un peu compliqué.

Hum, je suis d'accord avec tes réponses, mais je trouve le « problème » attribué aux VLIW un peu bizarre. Je veux dire, tant que le codage des instructions est le même (en gros, tant que ton VLIW prend le même nombre d'instructions dans une instruction longue), je ne vois pas en quoi il y a un problème de compatibilité binaire. Il y a eu au moins 3 versions de l'Itanium 2, et toutes ont été compatibles au niveau binaire.

Ça dépend pas mal du constructeur. Les cartes Nvidia sont « SIMT » (Single Instruction, Multiple Threads), divisés en blocs de (par exemple) 32 threads. Il y a pas mal de limites (avec des contournements à la con pour les éviter). Par exemple, si j'ai le code d'un thread qui dit :

if (condition) {
    // code
} else {
    // code
}

Tous les threads d'un warp (d'un bloc) vont devoir passer par le if et le else. Donc même si un seul thread doit traiter le else, tous les autres threads doivent l'attendre. Le contournement est de récrire le code de cette manière (approximativement):

if (condition) {
    // code
}

if (!condition) {
    // code
}

Ainsi on procède successivement à l'appel de deux if et là, ça marche. Oui, c'est couillon, mais c'est comme ça (ou en tout cas ça l'était jusqu'à il y a 2 ans …).

Les GPU de Nvidia ont aussi des mécanismes qui favorisent les accès séquentiels à la mémoire (en gros, si les accès sont tous séquentiels en VRAM, alors la performance est maximale car en gros les données sont « cachées »; sinon, il faut effectuer une sorte d'opération de « gather/scatter », ce qui ralentit considérablement l'exécution des threads).

Les GPU d'AMD/ATI sont légèrement différents. Il y a bien une séparation en blocs, mais cette fois on a plutôt affaire à des CPU « VLIW » (very long instruction word), chaque instruction longue pouvant traiter jusqu'à 4 « instructions courtes » (ou peut-être 5). Et là il s'agit plus d'un « vrai » mode SIMD.

La France a toujours commercé avec ses voisins. Aujourd'hui elle commerce moins avec l'Allemagne qu'avant l'UE d'ailleurs

Source ? À ma connaissance, le premier partenaire européen de la France, c'est l'Allemagne.

Il n'en reste pas moins que quand tu entends "sale arabe", quelqu'un t'impose cette distinction que tu la souhaites ou non.

Oui, bien entendu, comme quand tu entends "sale Blanc"

Je n'ai jamais entendu « sale blanc ». Par contre, j'ai déjà entendu dire « négro », « youpin », etc.

Il faut prouver que l'étranger a des compétences ou aptitudes que les candidats Français ne pouvaient pas remplir ou pas aussi bien. Tu es au courant?

Je ne sais pas d'où tu sors ça.

Moi je sais : de la loi française sur le travail des étrangers en France.

La collègue dont je parle plus haut, et dont j'ai raconté les mésaventures il y a bientôt 2 ans a été refusée pour un boulot qui demandait clairement des compétences très pointues, et difficiles à trouver. Depuis, comme le gouvernement Hollande a rétabli la liste des « métiers en tension » au niveau d'avant la circulaire Guéant de Mai 2011, elle a pu retrouver un boulot (après un bref passage par mon labo pendant 1,5 an) en France. Elle a eu un accord de principe par sa boite en Janvier 2013, mais n'a pu obtenir son permis de travail que vers Juin, à cause de la montagne de justificatifs (entre autres, montrer que les compétences demandées — très bonne connaissances en micro-architecture, mais aussi très bonnes compétences en analyse et optimisation de performance par exemple — n'étaient pas disponibles « aisément » dans la région géographique concernée, au niveau requis) que sa boite a dû fournir pour pouvoir la faire venir en France.

La plupart de l'immigration en France et dans les pays riches en règle générale s'effectue soit « très bas », soit « très haut », c'est-à-dire : soit des métiers « de merde » (parfois littéralement) que peu de gens veulent effectuer; soit des métiers qui demandent de fortes compétences (par exemple : une de mes anciennes collègues, de nationalité algérienne qui a une thèse en calcul haute performance). La plupart des métiers « entre les deux » sont bien occupés par les Français, car on n'a pas besoin de gens de l'extérieur pour les occuper.

[…] La France c'est un concept auquel on adhère ou pas. […]

C'est d'ailleurs une des composantes-clé de la définition de nation : on fait partie d'une nation donnée lorsqu'on adhère à sa culture et son histoire, son système de lois (ce qui ne veut pas dire qu'on ne va pas essayer de le changer par moments), et en général vivant sur le même territoire.

Ça me paraît évident que Mamadou qui vient de débarquer du Mali et à qui on donne des papiers français est moins français que Dupont qui l'est depuis dix-sept générations.

Mon père, hongrois, connaissait mieux l'histoire, la littérature et la culture françaises quand il est arrivé en France à ~26-27 ans que bien des Français (« de souche ») de son âge.

Je vis aux USA depuis quelques années. J'ai sans doute lu plus de livres sur l'histoire des USA, leur système éducatif, etc., qu'un américain « de base ». Je corrige les étudiants thésards avec qui je bosse sur leur grammaire/orthographe en anglais. Et pourtant, je ne suis pas américain de nationalité.

Ce que je trouve rigolo, c'est que d'un point de vue culturel, je crois qu'il y a plus de chances qu'un immigrant venant du Bénin (j'en connais quelques uns) ont sans doute plus en commun culturellement avec tout un tas de français « de souche » que moi : ils sont chrétiens (catholiques); ils ont reçu une éducation héritée du passé colonial de la France (le système scolaire est calqué sur le système français); malgré un accent prononcé, ils parlent un français excellent; etc.

Mais je rajoute tout de suite que pour l'État, il ne doit pas y avoir de distinction entre ces deux Français.

… Et du coup, ça invalide ta formule qui dit qu'il existe des Français « plus français » que d'autres. Soit on est français, avec les mêmes droits et devoirs qu'un autre, soit pas.

Non, je ne suis pas raciste ! Le racisme est une idéologie qui affirme la supériorité d'une race sur les autres (nazisme, judaïsme, etc.). Je ne crois pas du tout à cela.

Le judaïsme n'affirme absolument pas qu'ils sont supérieurs aux autres, d'une part. Les juifs religieux affirment qu'ils appartiennent au peuple élu, et qu'ils prient le seul « vrai » dieu. Cependant, même si c'est difficile, il est tout à fait possible de se convertir au judaïsme. Chez les libéraux, ça va prendre une petite année je dirais, alors que chez les orthodoxes, ça peut durer cinq ans. Dans tous les cas, une fois converti, un juif fait aussi partie du peuple d'Abraham, et du coup du « peuple élu ». Il est l'égal des autres, puisqu'accepté par la communauté.

Bref, mettre le judaïsme au même plan que le nazisme, c'est écœurant. Dans un cas, il y a tentative d'extermination systématique d'un ensemble de personnes au prétexte qu'ils sont un « peuple inférieur »; dans l'autre, on a un ensemble de personnes¹ qui affirment faire partie d'un club d'élite et très fermé de gens élus par le dieu qu'ils prient… mais qui ne cherchent pas à exterminer quiconque.

[1] Je laisse aux enculeurs de mouches le soin de décider s'il on peut parler de « peuple juif », ou juste de « juifs » en terme de groupe de religieux, etc.

[À propos de l'élection d'Obama] Lis les journaux de l'époque de son élection, tu verras par toi-même que la plupart des journalistes le considéraient comme noir.

L'important pour les médias US n'était pas qu'Obama fut noir, mais bien qu'il fut « non-blanc ». Pendant les primaires des démocrates, les deux candidats en tête étaient Barack Obama et Hillary Clinton. Qu'Obama ou Clinton gagne, dans tous les cas, ça aurait été salué unanimement, soit parce que le premier homme non-blanc (avec des origines Kényanes) était élu, soit parce qu'il s'agissait d'une femme.

Les États-Unis sont un ensemble d'états qui sont à la fois très progressistes : la présence de femmes d'influence dans les partis politiques et au gouvernement, et la mixité ethnique le démontrent bien; et aussi ultra-réactionnaires : la liberté totale d'expression¹ permet aussi d'exprimer des opinions qui cherchent à s'exprimer comme l'énoncé de faits. Il y a du profilage ethnique aux USA, à cause de ce fameux pragmatisme pratiqué par les anglo-saxons. Cependant, c'est en train de leur revenir en pleine gueule : à New-York City, il y a eu récemment une levée de boucliers sur la procédure dite de stop-and-frisk, car les policiers visaient en très grande majorité les gens dont la peau était, disons, plus foncée que celle d'autres citoyens. Ça me fait penser à la plupart de mes potes (parisiens, même pas banlieusards), nés en France, avec une culture française, mais qui ont le malheur d'avoir la peau un peu trop dorée, qui pourront témoigner qu'ils ont tous subi plusieurs contrôles d'identité au cours de leur vie, simplement à cause de leurs vêtements et de leur couleur de peau, sans autre « provocation » que de traîner … au bas leur immeuble, dans leur quartier.

La raison pour laquelle aux USA on pose des questions sur l'ethnie à laquelle les gens appartiennent est donc (selon moi) à la base purement pragmatique : on veut savoir quelle proportion telle ou telle population occupe tel ou tel poste, a besoin de telle ou telle aide, etc. Manque de bol, si l'intention est louable, elle reste assujettie aux problèmes liés aux statistiques : elles décrivent (parfois très bien) les phénomènes sociaux, mais considèrent le tout sous une forme « comportementale » / de « boite noire ». C'est aussi entre autres ce qui a conduit à la discrimination positive (« affirmative action »), pour rééquilibrer la donne envers les populations noires et hispaniques dont on considère que le traitement par le gouvernement US (massacres, esclavage, etc.) a empêché le développement économique, culturel, etc.

Du coup par exemple, les statistiques peuvent décrire que la majorité de la population noire vivant à New-York a déjà fait l'objet d'au moins une enquête pour des crimes et délits². Évidemment, pour reprendre le « stop-and-frisk » évoqué précédemment, c'est la raison invoquée par les flics à NYC. Dit comme ça, on pourrait croire que c'est de bonne guerre, si les noirs sont en majorité ceux qui commettent des délits, alors … Sauf que ! Si on rajoute que la plupart de ces gens vivent sous ou autour du seuil de pauvreté, dans des endroits insalubres, avec des boulots de merde, et aucune couverture santé, tout à coup, l'image change pas mal. De même qu'en France dans les années 60-70 on a parqué les immigrants dans des barres d'immeubles moches et sans réels espaces de détente, à NYC, une grande partie de la population noire vit à Harlem, dans le Bronx, etc. — bref, pas à Manhattan ou Brooklyn, respectivement occupés par les yuppies ou les bobos locaux.

De même, concernant l'_affirmative action_, il serait sans doute préférable de réformer cette dernière sur des critères purement économiques (niveau de revenus, etc.), ce qui permettrait d'inclure toutes les ethnies, quelle que soit l'origine de la personne qui bénéficie de ces aides — au moins pour ce qui est des bourses d'études³.

[1] Que j'apprécie beaucoup, soit dit en passant, malgré les défauts que je dénonce.
[2] Je dis ça au pif, je n'ai aucun chiffre.
[3] Cependant à ma connaissance, la plupart sont offertes sur des initiatives privées, et donc l'état US n'a pas vraiment de contrôle sur comment elles sont attribuées.

Pourquoi ne pas faire comme pour PLEIN d'applications sous Linux/Windows/Mac, à savoir : avoir une option réglages avancés et réglages de base ?

C'est si compliqué de tester avant de raconter n'importe quoi ?

Potentiellement oui. :-) Tu as testé avec une application ou bien en tentant de programmer toi-même ? Dans le premier cas, il faut trouver une application qui ne demande pas d'accès au tél met en pause en cas de réception d'appel; dans l'autre il faut programmer le machin. :)

Ah oui ?

C'est tout naturellement que les gens recherchent des voisins qui leur ressemble, c'est humain et universel. On ne peut donc pas le leur reprocher. Et tes voisins, ils sont comment ?

C'est rigolo ça. Mes voisins quand j'étais en Île de France, dans le 93, c'était d'un côté un collège privé catho, de l'autre une station essence. Les gens que j'avais en primaire et maternelle, puis plus tard au collège avaient des origines en Afrique (Cameroun, Algérie, Maroc, etc.), en Europe de l'est (Espagne, Pologne, Italie, etc.), et avaient aussi TOUS un point commun : ils étaient nés en France, et étaient donc — comment dire, ah, oui ! — français. Lorsque j'ai bougé à Paris pour le lycée, c'était à peu près la même population, dans des proportions différentes. Les voisins qui « me ressemblaient » avec qui je trainais étaient des français dont les parents étaient des immigrés algériens, ou des enfants d'immigrés portugais, ou immigrés vietnamiens, etc. Pourquoi ? Parce que nous partagions tous le même goût des comics/manga/bédés, des jeux vidéos, et de certains types de musique. Point.

Aujourd'hui, aux USA, mes voisins sont principalement chinois, pour certains français, beaucoup sont aussi colombiens, d'autres américains, etc. Et pour le coup, je ne parle pas d'origines, mais bien de nationalités : je vis dans une ville universitaire, où la diversité est énorme.

Tu as l'air de parler comme si les gens choisissaient tous d'habiter à côté des gens qui leur ressemblent. En pratique c'est évidemment faux : les gens vont d'abord là où ils peuvent se le permettre (vis à vis du boulot, du temps de transport, de l'école, etc.). Ensuite, oui, il y a des histoires d'affinités, et avoir une certaine culture en commun fait qu'on peut vouloir se rapprocher de certains types de population. Mais tu crois vraiment qu'un « noir catholique » a plus en commun avec un « noir musulman » plutôt qu'avec un « blanc catholique » ?