Discussion :

[DonQuiche]

Ce que je veux c'est de l'assembleur intel

Ben ouais mais à part quelques postes pour des compilateurs, systèmes d'exploitation ou la sécurité (analyse de code asm)... Ça ne doit pas faire beaucoup d'emplois dans le monde... Et dans presque tous ces cas ce serait 10% d'assembleur et 90% d'autre chose.

En plus le x86 n'apparaît pas comme le meilleur pari pour l'avenir. De nos jours les postes doivent plutôt être pour ARM. Et d'ailleurs pour un programmeur l'ARM est quand même plus agréable.

A la rigueur lance-toi dans la recherche de failles. Postule chez Vupen ou fais-toi un nom et lance un service de conseil.

[Invité]

Dans un monde plein de concurrences, c'est très risqué de se lancer en freelance ou monter sa propre boite ^^

Sinon l'architecture x86 est un peu incorrecte, ce dont tu veux parler c'est de l'architecture pour PC, il y a AMD et Intel, et le x86 désigne le mode 32-bits du CPU, et le x86 est out of date depuis 2006, maintenant, il faut se tourner vers le 64-bits (x64) et jouer avec les dernières ISA extension ^^

Le PC est très loin d'être mort et les ingénieurs d'Intel le prouvent tous les ans: réduction de précision des circuits (année Tick), puis intégration d'une nouvelle extension d'instruction asm (année Tock). https://en.wikipedia.org/wiki/Intel_Tick-Tock

De plus c'est juste de l'architecture cisc que l'on parle et Intel fait tout pour l'intégrer dans de l'IoT, microcontrôleur, ... pour kick l'arch risc, comme le smartphone avec un proc atome (http://www.intel.com/content/www/us/...artphones.html)


Dixit un fanboys d'intel plus sérieusement, j'adore cette entreprise pour ses technologies connues (asm 16-bit, fpu, task management) et mal connue avec avec les ISA extensions, exploitable facilement avec son langage d'assemblage.

[RyzenOC]

En plus le x86 n'apparaît pas comme le meilleur pari pour l'avenir. De nos jours les postes doivent plutôt être pour ARM. Et d'ailleurs pour un programmeur l'ARM est quand même plus agréable.

Pas d'accord, Intel c'est réveillé, et commence sérieusement a concurrencer les processeur ARM, sur le ratio perf/conso.
Dans l'avenir, les smartphones x86/x64 existerons de plus en plus je pense.

Vue les ressources en R&D de Intel, personne ne peut plus les vaincre. Aujourd'hui les atom sont aussi bon que les snapdragon.


Reste encore AMD, avec sont FX9000, qui consomme 500Watt..., on verra l'année prochaine, ce qu'AMD nous propose avec sa nouvelle architecture ZEN.

[Invité]

Vue les ressources en R&D de Intel, personne ne peut plus les vaincre. Aujourd'hui les atom sont aussi bon que le snapdragon.

Pourquoi ? quelles technologies avait de plus les snapdragon de Qualcomm par rapport à http://ark.intel.com/products/family...ssor#@Embedded ? (Date de 2012 et à 47$, c'est cool ça ^^)

Bizarre qu'intel ait stoppé la création d'atom, il faudrait regarder sa roadmap.

Bon l'atom n'a pas d'avx, mais bon, l'extension SSSE3 (plus d'instruction) du jeu d'extension pour gérer le calcul flottant sur des vecteurs 4 * 32-bits ou 2 * 64-bits, est mieux que rien et suffit à gérer facilement là 3D avec:
- (32-bit) xmm0[0] = x
- (32-bit) xmm0[1] = y
- (32-bit) xmm0[2] = z
- (32-bit) xmm0[3] = color ? ^^


(Je sais par vous, mais souvent, ce genre de discussion me donne mal au crâne )

[DonQuiche]

Le PC est très loin d'être mort et les ingénieurs d'Intel le prouvent tous les ans: réduction de précision des circuits (année Tick), puis intégration d'une nouvelle extension d'instruction asm (année Tock). https://en.wikipedia.org/wiki/Intel_Tick-Tock

Ne me lance pas sur les nouvelles instructions : à mes yeux c'est du gaspillage de silicium. Oh, oui, ça sert une fois tous les 36 du mois, c'est super si tu as un problème de calcul arithmétique où tes données sont préalablement gentiment alignées pour être traitées en vectoriel (utiles dans les jeux mais pas critique, et inutile presque partout ailleurs), le décodage AES est formidable si tu as un serveur web et quasiment inutile partout ailleurs, les nouvelles instructions transactionnelles sont super pour un verrou et certains cas dans les SGBD mais inutiles partout ailleurs y compris quand tu as besoin de STM à plus large échelle du fait ce foutu fallback en software.

Alors quand je pense qu'au lieu de tout ça on pourrait avoir uen archi hétérogène avec par exemple 16 bons gros coeurs et 64 coeurs moyens (du Xeon Phi sous stéroïdes et plus orienté task que data)... Je sais bien que les outils de dév n'ont pas suivi (on ne peut pas demander à des êtres humains de gérer un flux complexe de tâches parallèles sans outils de haut niveau pour prévenir les bogues) et c'est seulement avec le C++ 15 que les choses vont ENFIN devenir un peu sérieuses (STM).

Du coup je ne peux pas m'empêcher de voir dans chaque nouvelle instruction un boulet de plus aux pieds du x86 pour l'avenir. Je me plante peut-être cela dit, la micro-électronique n'est pas mon domaine.

De plus c'est juste de l'architecture cisc que l'on parle et Intel fait tout pour l'intégrer dans de l'IoT, microcontrôleur, ... pour kick l'arch risc, comme le smartphone avec un proc atome (http://www.intel.com/content/www/us/...artphones.html)

Il me semblait qu'en interne les x86 modernes sont en fait des RISC. Même si historiquement il s'agissait de CISC et même si le jeu d’instructions reste bien sûr un CISC.

Quant à savoir si le x86 a vraiment des chances à l'avenir je ne sais pas. Mais il n'a pas l'air d'avoir le vent en poupe.

[Invité]

Ne me lance pas sur les nouvelles instructions : à mes yeux c'est du gaspillage de silicium. Oh, oui, ça sert une fois tous les 36 du mois

Hmm, oui c'est sûr quand personne ne fait l'effort de s'intéresser à l'exploitation de ces technologies dans le monde du dev avec des langages de haut niveau, alors là oui c'est un gaspillage, tu as raison.

Sauf qu’allons-y mollo quand même, même si après 16 ans d'existence de la technologie SIMD, on commence à s'intéresser que maintenant (regarde les actus), va savoir pourquoi.

Bon ce n'est pas encore de l'avx 2, de plus tu savais que la lib standard du c++ a été mise à jour avec du sse comparer à la lib C ? et coder avec __vectorcall de même.

Pour s'en rendre compte, je t'invite à regarder l'asm produit par le c++ avec sa lib standard.

Donc je trouve ça un peu aberrant de s'intéresser (compilateurs) en cachette et discrètement aux extensions asm (bon ça reste du sse) , alors qu'on ne le fait pas en intégrale (dans tout le code).

Alors, autant le faire jusqu'au bout et il y a plein d'articles montrant le danger qu'apporte l'avx 2 (512-bit vector) et le fma (opération ultra-complexe) contre le pipeline du gpu: http://www.sisoftware.net/?d=qa&f=cpu_intel_sb http://www.itproportal.com/2012/09/1...vidia-and-amd/ http://www.extremetech.com/computing...-to-nvidia-amd

Il ne faut jamais sous-estimer le processeur central d'un PC et la flopée d'ingénieurs qui le fait évoluer d'année en année, mais que 90% des programmeurs avec les langages de haut niveau, osef intégralement.


Voilà une autre raison pour laquelle je dis qu'il vaut mieux un petit retour aux sources


L'assembleur va se complexifier d'une telle façon avec l'avènement de nouvelle extension tous les deux ans, qu'il n'y aura plus de raison de dire que ce n'est qu'un langage de pacotille.

[nnovic]

Il ne faut jamais sous-estimer le processeur central d'un PC et la flopée d'ingénieurs qui le fait évoluer d'année en année, mais que 90% des programmeurs avec les langages de haut niveau, osef intégralement.

Il y a une raison tout à fait valable à cela: tout le monde n'a pas le même processeur dans son PC. Certains ont des processeurs derniers cris, d'autres non. Des 32-bits, des 64-bits, des Intel, des AMD, ... Certains ont des jeux d'instructions X, Y et/ou Z, d'autres ne les ont pas. Et pourtant il faut que le programme tourne dans toutes les configurations, sans faire exploser les coûts de développement. Donc on se concentre sur le plus petit dénominateur commun, c'est-à-dire les instructions les plus basiques, voire on passe par des artifices comme les machines virtuelles ou les compilateurs JIT pour n'avoir qu'un seul programme qui peut fonctionner partout.

[Invité]

J'en suis conscient de ce que tu as dit et pour la note, tout les proc sur (intel et amd) pc ont était update en x64 mode.

- le sse est present sur 100% des cpu sur pc (https://en.wikipedia.org/wiki/SIMD " Intel responded in 1999 by introducing the all-new SSE system")
- l'avx est present depuis 2012
- l'avx 2 depuis 2014

Bon ça fait court pour l'avx 2, mais je te parie que 70% des pc ont déjà de l'avx, amd le fait aussi idem pour l'avx 2, bref amd se calque sur les technologies d'intel, avec une petite année de retard certes.

Si ce n'était pas le cas que 70% des pc, enfin c'est une théorie, mais c'est forcé qu'il y ait un pourcentage comme celui-là, sinon intel&amd ferrais faillite.


Sinon mise à part le fait de vouloir faire du code portable avec la production d'asm classique, selon le pourcentage de présence d'une technologie sur les proc des pc.
Autant faire plusieurs versions du programme selon la technologie du cpu utilisée, plus simple non ? ^^


Mais la question du passage au 64-bit ne dois plus se poser, bien sûr qu'il faut skip les programmes 32-bit, jusqu'a quand encore ne faire que du 32-bit ? 100% des proc sur pc sur cette terre gèrent le 64-bits

(Sauf peut-être avec certains old school lover)


On est en 2015 et il est grand temps de passer à la vitesse supérieure et ne pas freiner la progression de l'optimisation (au lieu de ne vouloir que s'appuyer sur du multitasking, qui est par ailleurs, du faux parallélisme, l'avx s'en est du vrai ^^) par le simple fait que l'on est anti-asm et contre ses extensions par conséquent.

[troll]
Bon je ne peux m'empêcher de balancer le troll suivant qu’étant donné que l'avx est une techno très complexe, on ne peut le gérer d'une aussi élégante façon qu'en asm

Perso quand je regarde du code avx pondu par icl/mscompiler/gcc, s'en est très loin dans la façon que je gère l'avx moi-même.

D'ailleurs je n'ai jamais vu des compilateurs travailler avec des registres avx, j'ai beau indiquer au compilateur d'utiliser l'avx, mais il se contente à travailler avec du xmm (sse).

[/troll]

[DonQuiche]

Hmm, oui c'est sûr quand personne ne fait l'effort de s'intéresser à l'exploitation de ces technologies dans le monde du dev avec des langages de haut niveau

Mais le problème surtout c'est que ces instructions sont faîtes pour du data parallelism alors que ce que je rencontre moi ce sont des problèmes de task parallelism. Autrement dit quand j'ai besoin besoin de performances c'est presque toujours pour faire mouliner 16 à 256 threads qui traitent des branchements conditionnels à la queue leu leu sur des graphes complexes d'objets. Et pour ça les instructions SIMD sont complètement inutiles. Et les GPU étaient tout aussi inutiles pour ça mais c'est en train de changer.

Crois-moi que lorsqu'il y a un besoin en data parallelism il n'est pas rare de voir le GPU utilisé, ou le CPU via une partie du code écrit en C ou via une structure vector encapsulant l'usage des instructions SIMD. Le problème c'est que ce besoin de data parallelism est rare (et souvent mieux servi par le GPU).

Sauf qu’allons-y mollo quand même, même si après 16 ans d'existence de la technologie SIMD, on commence à s'intéresser que maintenant (regarde les actus), va savoir pourquoi.

Je n'ai pas du tout l'impression d'un regain d'intérêt pour simd.

de plus tu savais que la lib standard du c++ a été mise à jour avec du sse comparer à la lib C ? et coder avec __vectorcall de même.

Je suis au courant et c'est bienvenu mais l'intérêt reste anecdotique pour la plupart des programmes. Ca n'est tout simplement pas adapté aux besoins de la plupart des programmes.

Pour s'en rendre compte, je t'invite à regarder l'asm produit par le c++ avec sa lib standard.

Désolé mais la vectorisation automatique des boucles n'a qu'un intérêt marginal. Pour la grande majorité des applications le gain de performances est si insignifiant qu'il se confond avec le bruit.

90% des programmeurs avec les langages de haut niveau, osef intégralement.

95% des programmeurs n'ont aucun problème de performance et donc aucun intérêt à se pencher sur ces questions. Leur job c'est d'écrire le plus rapidement possible le code le plus maintenable et robuste possible, avec les meilleures fonctionnalités. Et dans ce contexte un code lisible est toujours préféré et préférable à un code optimisé.

Ce qui importe ce sont les 5% restants. Là on a toute sorte de besoins et de réponses. Mais les instructions SIMD ne sont que rarement la bonne réponse ou même une réponse utile.

L'assembleur va se complexifier d'une telle façon avec l'avènement de nouvelle extension tous les deux ans, qu'il n'y aura plus de raison de dire que ce n'est qu'un langage de pacotille.

Personne ne dit que c'est un langage de pacotille, simplement qu'il est inefficace pour exprimer un programme car les sources sont trop longues et obscures. Et les nouvelles instructions ne résoudront jamais cela.

En revanche ils nous sortiront peut-être un jour une bonne solution pour la mémoire transactionnelle.


PS : je te remercie pour tes liens mais deux d'entre eux sont strictement identiques. Et si je suis d'accord sur le fait qu'à terme les archis GPU actuelles ne devraient pas avoir beaucoup d'avenir, la seule alternative viable en termes de calcul c'est un très grand nombre de coeurs. Note d'ailleurs que l'article n'affirmait pas que les performances se valaient, simplement que sur le plan commercial il permettrait à Intel de grapiller des pdm à NVidia. L'avenir leur a donné tort pour l'instant.

[Invité]

Je suis au courant et c'est bienvenu mais l'intérêt reste anecdotique pour la plupart des programmes.

Et là je te pose la question, pourquoi ils n'en font pas de même avec la lib C ?

Enfin tu parles du simd et aucun problème de performances, mais pourquoi ais-je l'impression que c'est le problème #1 des programmeurs informatique ? rien qu'a voir tous les commentaires (forums, irc, newsgroup, actu sur dvp mais il faut aussi chercher les actus sur d'autres sites, ...) sur les diverses technologies existantes, ça fait peur.


Et la technologie avx est là pour aider à contrer ces problèmes de performances.

Désolé mais la vectorisation automatique des boucles n'a qu'un intérêt marginal. Pour la grande majorité des applications le gain de performances est si insignifiant qu'il se confond avec le bruit.

Pas seulement automatiser les boucles, mais aussi reduction du nombre d'instruction du à l'utilisation du data parallelism, donc reduction de taille des programmes en RAM.
Et si tu n'es vraiment pas convaincu, regarde les articles sur l'avx, en anglais bien sûr (ex https://software.intel.com/en-us/art...or-extensions/ https://software.intel.com/en-us/isa...ions/intel-avx http://www.bing.com/search?q=intel+a...onversationid=) ^^
trop méconnu du publique :/

Au pire fait des test de vitesse.
Sinon, pourquoi ne pas coupler le multitasking avec le data parallelism ? ça m'a l'air d'un bon couple

Et les nouvelles instructions ne résoudront jamais cela.

L'espoir fait vivre ^^

En revanche ils nous sortiront peut-être un jour une bonne solution pour la mémoire transactionnelle.

Que veux-tu dire ? l'asm n'a pas d'instruction pour gérée multi-tasking, c'est un mécanisme du CPU (pagination, mémoire virtuelle, TSS gérée avec les registres de configuration du cpu) pour aider l'OS à faire du multitasking pour ses programmes.

Et c'est avec des fonctions de l'API Windows qui est l'API de base à tout programme sur Windows, qu'on arrive à pouvoir utiliser cette fonctionnalité.


Et puis honnêtement, le multitasking est vraiment bien pour l'optimisation, mais que sur système déjà multitaches.
Pourquoi ?
Car les programmes sont executer instruction (prog1's instruction#0) par instruction (prog2's instruction#0), ... dans une pile d'exécution.
Et le temps du cpu est donc partagée pour tous les programmes, et la où un programme à plusieurs sous-programmes exécuter par la file d'attente. Ce programme a donc plus d'instruction executer que sur un programme avec un seul thread.

Le problème est que si plein de programmes ayant plusieurs threads sont exécutés au même moment, alors l'optimisation par multi-tasking ne sert plus à rien, car au final, le taux de temps d'exécution du CPU revient au normal sur tous les programmes dans la file d'attente.


De plus, sache qu'à chaque fois que le CPU saute d'instruction en instruction, il sauvegarde le contexte en RAM, du programme dont l'instruction y est attachée (sauvegarde de tous les registres de travail) et il y en a des registres de travail, pour un programme 64-bit avec avx2, il y en a environ:
21 registres 64-bits
8 registres 80-bits
32 registres 128-bits (xmm)
32 registres 256-bits (ymm) les registres xmm sont mappés dans la partie basse des ymm
32 registres 512-bits (zmm) les registres ymm sont mappée dans la partie basse des zmm
Et j'en oublie probablement comme les registres pour le débogage.

Mais bon, je pense que durant le multitasking, le cpu ne sauvegarde que les registres zmm et répartis les zones basses (256-bits et 128-bits) dans les ymm et xmm.

[DonQuiche]

Et là je te pose la question, pourquoi ils n'en font pas de même avec la lib C ?

Sans doute parce que le crédo du C est la portabilité et que nombre de plateformes n'ont pas d'instructions vectorielles. En C on fait plutôt des pilotes de périphérique, pas du data parallelism. Donc à nouveau les instructions SIMD n'ont a priori rien à offrir.

Enfin tu parles du simd et aucun problème de performances, mais pourquoi ais-je l'impression que c'est le problème #1 des programmeurs informatique ?

Crois-moi, pour la grande majorité des dévs c'est très loin d'être le problème numéro un.

Et quand ça l'est c'est presque toujours à cause d'une erreur d'un dév, et il suffit de corriger cette erreur ou d'utiliser un meilleur algorithme. Les micro-optimisations ne viennent que très loin derrière, très au-delà de ce qui est nécessaire, elles seules ne suffiraient pas à résoudre le problème (gain modeste même dans les cas idéaux), et même dans ce cas il n'est pas dit que les instructions SIMD puissent être utiles. On en revient à leur relative inutilité.

Et les fois où ce n'est pas une erreur du dév ? Alors la plupart du temps c'est parce qu'un composant pourtant hyper-optimisé comme un SGBD est à saturation. Il faut alors changer de solution pour obtenir des gains drastiques.

Pas seulement automatiser les boucles, mais aussi reduction du nombre d'instruction du à l'utilisation du data parallelism, donc reduction de taille des programmes en RAM.

Dans la majorité des programmes les seules opérations arithmétiques réalisées sont des incréments d'indice/pointeur lors des parcours de tableaux, et les accès aux membres. L’arithmétique ne tient pas une grande place. Comme je le disais ce dont la plupart ont besoin c'est de N threads indépendants et partageant leur mémoire pour enchaîner les branchements conditionnels.

Jamais les instructions SIMD ne pourront les aider à cela, ou alors marginalement pour vérifier que tous les éléments d'un tableau sont nuls ou que deux tableaux sont identiques (pour un gain ridicule de 10-20% parce que les accès mémoire alternés sur deux tableaux dominent). Ce n'est pas une question de paresse, de coût, de langage haut-niveau ; nous avons fondamentalement besoin d'une clé à molette et tu insistes pour que nous utilisions un tournevis.

Et si tu n'es vraiment pas convaincu, regarde les articles sur l'avx, en anglais bien sûr

Mais moi je connais très bien tout ça. C'est toi qui ne connais pas nos besoins et qui refuse d'accepter qu'un tournevis n'est pas une clé à molette.

Que veux-tu dire ? l'asm n'a pas d'instruction pour gérée multi-tasking, c'est un mécanisme du CPU (pagination, mémoire virtuelle, TSS gérée avec les registres de configuration du cpu) pour aider l'OS à faire du multitasking pour ses programmes.

Je ne connais pas ton niveau de connaissance sur les problèmes concurrents, donc pardonne-moi si je pars des bases.

Si tu transfères de l'argent d'un compte en banque à un autre, tu dois d'abord retirer l'argent chez l'un et vérifier qu'il est solvable, puis donner cet argent à un autre. Soit on fait les deux opérations, soit on n'en fait aucune, mais il est interdit de s'arrêter en chemin et de débiter l'un sans créditer l'autre. Cet ensemble d'opérations à réaliser complètement ou pas du tout forment une transaction : on fait tout ou on ne fait rien.

Maintenant prenons notre CPU : un thread veut lire ou modifier les lignes de cache 7, 10 et 18. Et il exige que ces écritures ne soient officialisées que si l'opération toute entière peut être complétée sans qu'aucun changement n'ait été fait par un autre thread Aujourd'hui il faut tout un bazar côté logiciel pour verrouiller manuellement les lignes de cache avant chaque lecture/écriture, tenir un journal des changements et éventuellement annuler les opérations en cas d'échec d'un verrouillage. Alors que le CPU, lui, pourrait simplement garder les données modifiées dans son cache en retardant les écritures vers la mémoire centrale (*), et annuler ces écritures si un autre coeur a obtenu un droit d'écriture exclusif vers une de ces lignes.

Intel a récemment ajouté de telles extensions (TSX), boguées. Malheureusement leur modèle est limité par le degré d'associativité du cache et en cas d'échec du matériel il incombe au logiciel d'avoir fait en sorte de pouvoir annuler les écritures, ce qui n'aide pas beaucoup les performances. Il faudrait des changements pus profonds pour faire la véritable bête transactionnelle que j'appelle de mes voeux.


(*) en fait dans le protocole MOESI l'écriture se produit toujours à retardement mais le protocole est séquentiellement équivalent à une écriture immédiate et peut donc être analysé comme tel.

Le problème est que si plein de programmes ayant plusieurs threads sont exécutés au même moment, alors l'optimisation par multi-tasking ne sert plus à rien, car au final, le taux de temps d'exécution du CPU revient au normal sur tous les programmes dans la file d'attente.

Mais en pratique tu as un processus qui domine, celui d'avant-plan. Et ce qu'il veut lui c'est avoir autant de threads que possibles parce que c'est la seule solution possible pour lui.

De plus, sache qu'à chaque fois que le CPU saute d'instruction en instruction, il sauvegarde le contexte en RAM, du programme dont l'instruction y est attachée (sauvegarde de tous les registres de travail) et il y en à des regstres de travaille, la flemme de les compter ce soir ^^

Oui, je connais très bien le coût d'un changement de contexte : 1 à 10µs pour passer d'un processus à un autre et beaucoup moins au sein du même processus (descripteurs de sécurité inchangés). Et ce n'est pas un problème.

[Invité]

Hmm, il faut dire que je ne jamais eu le courage d'implémenter le multitasking dans mon OS, à la fois trop complexe et compliqué à mettre en place, enfin quand on débute, c'est le cas.


Donc je veux bien admettre que la dissociation d'un programme en de multiples processus est un bon investissement pour faire de la grosse opti, car d'un côté j'ai accumulé plus de théorie que de pratique, sur le fonctionnement du processeur et des OS.


Mais à un moment, le coupler avec l'avx, ça ne ferra pas de mal, car imagine si l'avx 1024 ou 2048 ou 4096 sort, un déplacement de 4ko deviendras intéressant, tu ne trouves pas ?
(Bon si les extensions d'avx gardent le cap toutes les années tock (sauf cette année), rdv en 2021 )


Et là nvdia aura vraiment du souci a se faire et peut-être même que ça serra aussi efficace que la technique de multi processus enfant ^^ mais bon rien n'empêche de coupler les deux techniques, enfin perso j'aime pas du tout l'idée d'avoir un programme plus gourmand en instruction que les autres, c'est ... non j'aime pas trop ce design de programmation ^^

!! tous égalitaires en temps d'exécution !!

[jean.charlara]

bien sûr que c'est le c++ lol

[DonQuiche]

Donc je veux bien admettre que la dissociation d'un programme en de multiples processus est un bon investissement pour faire de la grosse opti, car d'un côté j'ai accumulé plus de théorie que de pratique, sur le fonctionnement du processeur et des OS.

De multiples threads, pas de multiples processus.
Créer plusieurs processus n'a d'intérêt que pour la sécurité (navigateurs par ex, pour isoler chaque page et lui conférer des permissions plus restreintes que le navigateur).

Mais à un moment, le coupler avec l'avx, ça ne ferra pas de mal

Mais encore une fois il y a peu de cas où ces opérations arithmétiques vectorielles sont utiles. Comme je l'ai dit la plupart des programmes ne font quasiment pas d'arithmétique explicite. Donc tout ce qui reste ce sont des cas particuliers comme ceux que j'ai cités :

* Comparaison de deux tableaux.
* Recherche de la présence d'un élément nul dans un tableau.
* Accès aux membres de pointeurs stockés dans un tableau.

Dans le premier cas assez rare on est memory bound, donc le gain AVX est insignifiant (disons 10% sur cette opération précise) et relève de la micro-optimisation.

Dans le second cas assez rare on parle là encore d'un gain très insignifiant (remplacer quatre branchements avec une bonne prédiction par une addition vectorielle et un branchement), toujours insignifiant devant les accès mémoire, et impossible dès lors qu'on veut par exemple l'indice de l'élément.

Dans le troisième cas plus courant cela interfère avec le cache : souvent tu vas vouloir travailler d'abord sur le premier objet avant de te préoccuper des suivants. Donc cela peut ralentir ton code.

Et dans les trois cas la vectorisation peut rapidement cesser de devenir intéressante.

, car imagine si l'avx 1024 ou 2048 ou 4096 sort, un déplacement de 4ko deviendras intéressant, tu ne trouves pas ?

Non ça ne me fait pas du tout rêver. ^^

a) Bonjour le loop unrolling ! Tu vas d'abord écrire une boucle traitant par paquets de mille, puis une autre par paquets de quatre pour les éléments restants, puis une autre en scalaire ?!

b) Bien peu de programmes ont l'utilité des opérations arithmétiques sur 4 nombres, alors combien auront des paquets de mille vecteurs gentiment alignés et attendant des opérations arithmétiques ?

c) Les problèmes graphiques ont des cohérence spatiales très particulières, tu veux traiter un carré de 16x16 pixels, pas des lignes de 1024 pixels. La raison en est que tu dois traiter des pixels illuminés par les mêmes lumières et ayant les mêmes textures. Même problème avec le raytracing, tu veux traiter les pixels proches butant sur les mêmes objets parce que ces données sont en cache. Donc tu ne dois pas lire ta texture (compressée) de façon linéaire, donc pas de paquet de mille vecteurs gentiment alignés.

d) De façon plus générale les jeux impliquent des accès aux proches voisins pour les interpolations de texture et des structures particulières pour interpoler les pixels constituant une face. Tout ça relève de circuits spécialisés.

e) Tu penses que c'est mieux avec les applis scientifiques ? Mais celles-ci manipulent des matrices creuses et autres structures de données très particulières qui ne sont pas de gentils paquets de mille vecteurs bien alignés.

f) En pratique les shaders modernes dans les jeux manipulent peu de vecteurs : on calcule un angle ici, une distance là, et après ça ce sont les scalaires (dont les résultats non-alignés des précédentes opérations) et plein de branchements conditionnels.

g) Ce qui compte ce ne sont pas les instructions mais les accès mémoire. Ce n'est d'ailleurs pas un hasard si les GPU sont tout entier pensés comme des bêtes à gommer la latence mémoire.

Les instructions SIMD ne sont vraiment intéressantes que lorsque tu peux garder une opérande dans un registre et la réutiliser tout du long. Le reste du temps le loop unrolling permettait au CPU de mieux anticiper les accès mémoire et le vectorisation permettait ensuite de réduire le nombre d'instructions et leur poids en mémoire. Mais de nos jours le loop unrolling devient néfaste car la gestion des branchement est excellente et le CPU anticipe les itérations à venir.



Bref, ce seraient des instructions trop spécialisées, au bénéfice faible dans le meilleur des cas, inutilisables en pratique.

Et là nvdia aura vraiment du souci a se faire et peut-être même que ça serra aussi efficace que la technique de multi processus enfant

Non, la seule façon dont Intel pourra concurrencer NVIdia sur le plan technique avec un processeur non-spécialisé c'est avec des archis types Xeon Phi basées sur de très nombreux coeurs, et seulement à moyen terme. Et il faudra conserver encore longtemps quelques unités spécialisés. Avec leurs CPU ils peuvent au mieux espérer un jour obtenir des performances potables (mais pas avec de nouvelles instructions vectorielles : 4x32 suffisent).

Cependant ils peuvent peut-être faire du tort commercial à NVidia si les consommateurs ne s'intéressent plus à la puissance graphique. Mais il n'y a aucun signe de cela à ma connaissance et ce serait une mauvaise nouvelle pour l'industrie de voir une solution technique inférieure l'emporter et renforcer un monopole.

[stailer]

@DonQuiche : tu as 4 pouces vert sur un post dont l'argumentaire le plus improbable que j'ai jamais vu fini par :

On ne fonce pas du tout dans le mur : le capitalisme a tellement bien réussi qu'il est en train de se mutiler en créant une société où de nombreux biens ne vaudront plus rien ou presque. C'est formidable, à ce train là dans cinquante ans ne travailleront que ceux qui voudront travailler (et les métiers désagréables devront donc offrir une bonne paye).

Je rappelle qu'à ce jour 1 enfant sur 5 vit sous le seuil de pauvreté : en FRANCE.

Franchement DonQuiche, j'ai du mal à comprendre les 4 crétins qui t'approuvent...

J'en dis pas davantage (pourtant je suis chaud bouillant là ) , en écrivant cette réponse, j'y crois de moins en moins. C'est pas possible, c'était de l'ironie ?

[DonQuiche]

Je rappelle qu'à ce jour 1 enfant sur 5 vit sous le seuil de pauvreté : en FRANCE.

Je rappelle que le seuil de pauvreté est défini relativement à la médiane de la population considérée.

Parmi les enfants des traders de Wall Street 30% vivent sous le seuil de pauvreté de Wall Street.
Parmi les enfants des milliardaires 40% vivent sous le seul de pauvreté des milliardaires.


A part ça ma mère a grandi en France à une époque où les bidonvilles étaient banals, et pour prendre une douche il fallait faire chauffer de l'eau sur la gazinière. C'était une famille moyenne en province, son père ouvrier qualifié et sa mère employée qualifiée, pas une famille pauvre à Paris.

Donc même s'il y a beaucoup de choses qui ne fonctionnent pas correctement, même si les fruits de la croissance de ces dernières décennies ont été très mal répartis et même si le système arrive à bout de souffle avec la concentration croissante des richesses (phase habituelle du capitalisme avant de grands tumultes) qui affecte en particulier le logement, il n'empêche que la capitalisme a incontestablement réussi à rendre les biens plus accessibles et le travail moins pénible, et il va continuer à le faire. Ce ne sont que des faits.

[Invité]

Donc même s'il y a beaucoup de choses qui ne fonctionnent pas correctement, même si les fruits de la croissance de ces dernières décennies ont été très mal répartis et même si le système arrive à bout de souffle avec la concentration croissante des richesses (phase habituelle du capitalisme avant de grands tumultes) qui affecte en particulier le logement, il n'empêche que la capitalisme a incontestablement réussi à rendre les biens plus accessibles et le travail moins pénible, et il va continuer à le faire. Ce ne sont que des faits.

Je suis parfaitement d'accord. Comme le communisme, le capitalisme n'est pas le problème. C'est le fait de pousser le système à fond au point où il en devient vicieux. L'économie devrait être au service de l'Homme, pas l'inverse. Je suis sûr qu'il est possible de rendre le capitalisme plus "Humain".

[nnovic]

[QUOTE=DonQuiche;8296061 il n'empêche que la capitalisme a incontestablement réussi à rendre les biens plus accessibles et le travail moins pénible, et il va continuer à le faire.[/QUOTE]

Pas d'accord. Le travail pénible a juste été délocalisé. Tu ne le vois pas, mais il existe. Il suffit de regarder "zone interdite", "capital", ...
Il y a ce reportage mémorable de Cash Investigation sur les téléphones portables:
http://www.francetvinfo.fr/replay-ma...14_730935.html
Comme tu dis: ce ne sont que des faits...

[DonQuiche]

Pas d'accord. Le travail pénible a juste été délocalisé.

Non, 95% de la population mondiale avait un travail pénible, aujourd'hui ce sont seulement 70%. Et les 70% ont un travail souvent moins pénible que celui qu'ils avaient auparavant. Crois-moi que défricher un champ à la main en plein hiver, prendre soin des bêtes à cinq heures les pieds dans le crottin tous les jours et récolter le blé à la faux sous le soleil cognant d'été ce n'est pas une partie de plaisir !

Il suffit de regarder "zone interdite", "capital", ...
Il y a ce reportage mémorable de Cash Investigation sur les téléphones portables:
http://www.francetvinfo.fr/replay-ma...14_730935.html
Comme tu dis: ce ne sont que des faits...

Je présume que ton reportage traitait de Shenzen. Alors poses-toi une question : pourquoi dans une Chine où règne le plein emploi certains traversent-ils des milliers de kilomètres pour venir travailler à Shenzen ? La réponse est que Shenzen offre d'excellents emplois, très bien payés, et que la région a de belles opportunités. Oui le travail est dur, mais il n'y a pas si longtemps en Chine tout le monde crevait de faim et les campagnes sont encore pauvres. Shenzen est donc très attrayant pour les travailleurs chinois.

Ne t'inquiète pas, dans trente ans tout ça aura disparu et des robots construiront ton téléphone, pendant que les enfants de ces travailleurs officieront trente-cinq heures par semaine dans des supermarchés et des bureaux d'étude, écoutant les uns et les autres leur expliquer que c'était bien mieux avant.


PS : comment peux-tu prendre au sérieux une émission appelée "Cash Investigation" ?! Quant à Zone Interdite et Capital, tu parles d'une référence ! Je connais ces émissions : on y verse dans le sensationalisme et les conclusions convenues, et tout est fait pour te dire quoi penser plutôt que pour te présenter la réalité dans toute sa complexité.

[AoCannaille]

Entre l’aparté sur l'assembleur et maintenant sur le capitalisme, cette discution dévie """légèrement"""