IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Pour ou contre le multithreading dans les moteurs 3D ?

Votants
75. Vous ne pouvez pas participer à ce sondage.
  • Pour

    72 96,00%
  • Contre

    3 4,00%
Développement 2D, 3D et Jeux Discussion :

Que peut apporter le multithread au développement de jeux ? [Débat]


Sujet :

Développement 2D, 3D et Jeux

  1. #261
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    113
    Détails du profil
    Informations personnelles :
    Localisation : France, Sarthe (Pays de la Loire)

    Informations forums :
    Inscription : Avril 2007
    Messages : 113
    Points : 99
    Points
    99
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Si tu démontre ton antécédent par rapport au brevet, tu peux continuer à travailler avec. C'est le principe universel valable dans le monde entier.
    Oui, sauf que si Epic (par exemple, hein) annonce qu'il maîtrise l'algo et dépose un brevet (celui que je n'aurais pas déposé par principe, dans cet exemple), j'aurais le droit d'utiliser mon droit d'antériorité pour faire mon propre moteur... Pas de Pb...
    Déjà je perd Epic comme client, pas cool. En plus je suis en concurrence avec le leader des moteurs de JV... Autant dire que pour m'en sortir je vais avoir du mal...
    Concernant mes clients potentiels, je peux plus vraiment leur vendre un super avantage concurrentiel...

  2. #262
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Citation Envoyé par Fraggy Voir le message
    Oui, sauf que si Epic (par exemple, hein) annonce qu'il maîtrise l'algo et dépose un brevet (celui que je n'aurais pas déposé par principe, dans cet exemple), j'aurais le droit d'utiliser mon droit d'antériorité pour faire mon propre moteur... Pas de Pb...
    Déjà je perd Epic comme client, pas cool. En plus je suis en concurrence avec le leader des moteurs de JV... Autant dire que pour m'en sortir je vais avoir du mal...
    Concernant mes clients potentiels, je peux plus vraiment leur vendre un super avantage concurrentiel...
    S'ils veulent reprendre ton principe (si ce n'est pas déjà le cas), ils le feront. Il suffit qu'il ne le disent pas et voilà.

  3. #263
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    113
    Détails du profil
    Informations personnelles :
    Localisation : France, Sarthe (Pays de la Loire)

    Informations forums :
    Inscription : Avril 2007
    Messages : 113
    Points : 99
    Points
    99
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    S'ils veulent reprendre ton principe (si ce n'est pas déjà le cas), ils le feront. Il suffit qu'il ne le disent pas et voilà.
    Clairement, mais alors tu ferais quoi à ma place, tu déposerais un brevet ou pas ?

  4. #264
    Membre émérite
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 537
    Points : 2 548
    Points
    2 548
    Par défaut
    Vive ma physique quantique : http://www.opensparc.net/opensparc-t2/index.html

    nan mais qu'est ce qu'il faut pas lire comme anneries.

    Quand au thread, ce n'est pas un topic pub ACCLib, merci. Parceque parler de comment marche un truc mais qu'on peut pas savoir comment il marche merci bien. Les jolis graphiques sans aucune spécification du protocole de test c'est vraiment super fiable aussi !

    Je suis impressionné.

  5. #265
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    113
    Détails du profil
    Informations personnelles :
    Localisation : France, Sarthe (Pays de la Loire)

    Informations forums :
    Inscription : Avril 2007
    Messages : 113
    Points : 99
    Points
    99
    Par défaut
    Citation Envoyé par deadalnix Voir le message
    Vive ma physique quantique : http://www.opensparc.net/opensparc-t2/index.html

    nan mais qu'est ce qu'il faut pas lire comme anneries.

    Quand au thread, ce n'est pas un topic pub ACCLib, merci. Parceque parler de comment marche un truc mais qu'on peut pas savoir comment il marche merci bien. Les jolis graphiques sans aucune spécification du protocole de test c'est vraiment super fiable aussi !

    Je suis impressionné.
    C'est sur, ça dérape
    En plus y a déjà un thread dédié à acclib...

    Vincent, les autres questions posez les sur l'autre thread http://www.developpez.net/forums/d67...deo-parallele/

  6. #266
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Citation Envoyé par deadalnix Voir le message
    Vive ma physique quantique : http://www.opensparc.net/opensparc-t2/index.html

    nan mais qu'est ce qu'il faut pas lire comme anneries.
    quel rapport avec le sujet ?

    Citation Envoyé par deadalnix
    Quand au thread, ce n'est pas un topic pub ACCLib, merci. Parceque parler de comment marche un truc mais qu'on peut pas savoir comment il marche merci bien. Les jolis graphiques sans aucune spécification du protocole de test c'est vraiment super fiable aussi !
    parler de Acclib est tout de même en rapport avec le sujet puisqu'il s'agit d'une bibliothèque pouvant visiblement apporter un partage de taches équitable dans un moteur orienté jeux vidéo

    si tu veux parler d'autre chose en rapport avec le sujet tu es le bienvenu

    edit : au fait
    Citation Envoyé par Fraggy Voir le message
    ps : au fait, le xeon 7400 est un proc 8 coeurs
    Intel n'a aucun processeur avec plus de 6 coeurs physiques à l'heure actuelle
    le xeon 7400 est un cpu 6 coeurs sans SMT (donc 6 threads)
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  7. #267
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Si, ils en ont, mais ils n'arrivent pas à le produire, d'où les 6 coeurs

  8. #268
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Si, ils en ont, mais ils n'arrivent pas à le produire, d'où les 6 coeurs
    s'ils n'arrivent pas à le produire, alors ils n'en ont pas
    les Xeon série 7000 sont des dual-core peryn mis côte à côte
    Intel "fusionne" les dies de 2 coeurs pour créer des quad ou des sextuples coeurs
    sauf que cette technique a ses limites tout simplement
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  9. #269
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Non. Ils ont en pré-production un vrai 8 coeurs basé sur le Nehalem. Là où les 8 coeurs ne sont pas opérationnels, ils en font un 6 coeurs, faisant donc ce qu'ils avaient critiqué chez AMD il y a un an.

  10. #270
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    je ne sais pas si on parle de la même chose alors
    parceque les Xeon 7000 sont des peryn basés sur l'architecture core, pas des nehalem basés sur l'architecture core i7
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  11. #271
    Membre actif

    Inscrit en
    Février 2009
    Messages
    200
    Détails du profil
    Informations forums :
    Inscription : Février 2009
    Messages : 200
    Points : 235
    Points
    235
    Par défaut La réalité dépasse l'affliction
    J'ai découvert votre réflexion après un post indépendant sur le même sujet:
    http://www.developpez.net/forums/d76...hreads-moteur/

    Il me semble (c'est un constat dénué de toute forme d'agressivité) que plusieurs confusions, ou plutôt conséquences des intoxications d'un marketing astucieux, sont à l'œuvre dans de nombreux posts:

    Si la théorie permet d'échafauder une "vision" mutithread physique des "nouveaux" µp (je ne parle pas pour le moment des coprocesseurs graphiques) le pragmatisme voudrait que l'on vérifie en situation les gains réels en performances et, s'il y en a, mettre en évidence les lieux réels de ses gains. Pour faire simple, "Un µp tient, vaut mieux que deux threads tu l'auras" .

    A lire plusieurs, il semblerait que déterminer sois même les cœurs utilisés, l'affinité des threads et "blinder" les niveaux de priorités avec, par exemple, les API bien connues:
    AvSetMmThreadCharacteristics
    SetProcessAffinityMask
    SetThreadPriority
    SetThreadAffinityMask
    suffise à augmenter les performances en partageant un travail qui serait sagement parallélisé à notre convenance .

    Je suis hélas désolé d'avoir à le dire:
    Ce n'est absolument pas vrai, ni vérifié en pratique. Toutes les mesures indiquant le contraire.
    En un mot, plus direct: "C'est totalement faux."

    Je m'explique:
    Les fondeurs savent que les codeurs ne connaissent pas grand chose (rien d'agressif dans leurs constatations) aux mécanismes qu'ils mettent en place et ne souhaitent donc pas voir leurs productions dénigrées simplement parce que le code n'est pas performant.
    Leurs technologies sont donc prévues pour être les plus libres possible (indépendantes) de la qualité du code (ne tombons pas dans la caricature, je n'ai pas dis "totalement" indépendant, ce serait me faire un vilain procès ).

    Donc, moins le code interfère avec une architecture bien conçue, plus il a de chances de tourner efficacement.
    En français courant: Chacun son boulot et les vaches seront bien gardée, "vaches" étant mis pour performances, évidemment.

    Pourquoi ne pas pratiquer des benchmarks pragmatiques:
    Temps réellement passé dans chaque thread par rapport au temps global d'utilisation du µp.
    Cela permet des mesures prenant en compte les changements de contextes et les générations des nouvelles interruptions que vous avez décidé de générer de manière unilatérale (sans laisser faire le µp).
    J'ai bien peur (en fait, soyons clair: "Je suis sûr de mes affirmations") que les comparaisons multihread µp VS multithread organisé via code présenteront immanquablement le même constat:

    Le µp gère ça bien mieux que mon code…

    Le µp sait "démonter" et "remonter" des commandes issues d'un même bloc de code ; la vision par thread étant une vision de codeur et non d'électronicien, le µp n'a de profondeur (d'ensemble) de vue que l'instruction suivante, précédente et leur liens contextuels.

    Les diverses informations des constructeurs, qui tiennent plus de la vulgarisation que du transfert de technologie (ne soyons pas irréalistes ) présentent souvent les choses sous une forme graphique qui ne précise pas si la gestion des threads est sous le control du codeur ou de l'exécuteur (l'électronique)…
    Le but étant de montrer que le multiplexage se fait au niveau temporel et non plus au niveau des tâches proprement dites et qu'il y a un gain mesuré en échelle de temps (c'est bien là l'astuce marketing ).

    Tout ce que nous vivons et ressentons se mesure en échelle de temps constant: Une courbe de fonction, les sens (variations d'intensités dans le temps) etc. Donc, faire varier le temps dynamiquement reviendrait à modifier la courbe de perception.

    Tant que le temps reste à granulation constante, nous arrivons à maintenir cohérents nos raisonnements de codeurs.
    Avec une granulation temporelle dynamiquement variable, ces raisonnements montrent leurs limites dans le domaine qui n'est plus le leur:
    La logique programmée.
    Les logiques câblées ou locales étant forcément plus rapides que les logiques programmées ou distantes, les gains seront donc obtenus en favorisant les opérations les plus locales et les moins contextuelles possible.
    Cette stratégie est celle de tous les µp depuis maintenant plusieurs décennies et la multiplication des cœurs ne change rien à celle-ci. Ne pas s'y conformer n'apportera que des pertes et en aucun cas des gains.
    Le rôle du codeur étant de générer la stratégie la plus proche de celle utilisée par sa cible électronique et non pas de parier sur une forme de vue de l'esprit sans aucun rapport avec le pour "qui" il code.

    Pour résumer:
    - Vous codez pour une électronique conciliante, certes, mais pas dénuée d'orientation et de performances liées à celle-ci.
    Il est donc primordial de favoriser l'orientation par rapport à la conciliation: Ne pas chercher à tirer l'électronique vers le code mais bien plutôt de faire le contraire en appuyant ce dernier pleinement sur elle.

    - Les threads sont une vue de l'esprit pour le compilateur et non une réalité pour le µp.

    - Vous obtiendrez de bien meilleurs résultats en repensant votre stratégie et votre architecture globales, comme cela à été souligné brièvement par plusieurs dans ce topic, cad en désolidarisant "totalement" les tâches les unes des autres et en les rendant non bloquantes.

    - Tous les coprocesseurs (sauf cette stupide FPU) sont fondés sur ce principe. Ils sont les réelles threads physiques de votre plate-forme cible.

    - Une vision plus matérielle permet de mieux saisir que la mise en parallèle de sérialisations est la bonne méthode: Lancer des séries process hardware réels en même temps. Le hardware possédant, la plupart du temps, une file d'attente vidangeable (cas des GPU, cartes audio, µp…).

    Je vous renvoie à l'autre post cité en entête pour un exemple parmi tant d'autres.

  12. #272
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Citation Envoyé par Rémi Coquet Voir le message
    Pour résumer:
    - Vous codez pour une électronique conciliante, certes, mais pas dénuée d'orientation et de performances liées à celle-ci.
    Il est donc primordial de favoriser l'orientation par rapport à la conciliation: Ne pas chercher à tirer l'électronique vers le code mais bien plutôt de faire le contraire en appuyant ce dernier pleinement sur elle.

    - Les threads sont une vue de l'esprit pour le compilateur et non une réalité pour le µp.

    - Vous obtiendrez de bien meilleurs résultats en repensant votre stratégie et votre architecture globales, comme cela à été souligné brièvement par plusieurs dans ce topic, cad en désolidarisant "totalement" les tâches les unes des autres et en les rendant non bloquantes.

    - Tous les coprocesseurs (sauf cette stupide FPU) sont fondés sur ce principe. Ils sont les réelles threads physiques de votre plate-forme cible.

    - Une vision plus matérielle permet de mieux saisir que la mise en parallèle de sérialisations est la bonne méthode: Lancer des séries process hardware réels en même temps. Le hardware possédant, la plupart du temps, une file d'attente vidangeable (cas des GPU, cartes audio, µp…).

    Je vous renvoie à l'autre post cité en entête pour un exemple parmi tant d'autres.
    C'est pas que je ne suis pas d'accord avec toi, c'est plus que je nuancerai certains propos.
    Dans le cas des coeurs qui se partagent la mémoire, OK, l'affinité n'est pas forcément pertinente; En revanche, avec plusieurs processeurs, fixer la localité du processus ainsi que de sa mémoire AUGMENTE les performances. Je parle bien de processus ici.

    Le thread n'est pas qu'une vue de l'esprit du compilateur (d'ailleurs, lui ne sait pas ce que c'est du tout, pour le coup, c'est plus l'OS), c'est une réalité pour plusieurs types de CPUs, tous ceux qui ont du SMT. Les coprocesseurs ne peuvent pas être les threads de la plateforme cible. Mais je pense que tu voulais dire qu'il faut les encapsuler dans des threads (et pourquoi tu considères la FPU comme un cas à part, et pas les ALUs ?)

    Comme je l'ai dit au début, pour le reste, je suis d'accord avec toi

  13. #273
    Membre actif

    Inscrit en
    Février 2009
    Messages
    200
    Détails du profil
    Informations forums :
    Inscription : Février 2009
    Messages : 200
    Points : 235
    Points
    235
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Dans le cas des coeurs qui se partagent la mémoire, OK, l'affinité n'est pas forcément pertinente; En revanche, avec plusieurs processeurs, fixer la localité du processus ainsi que de sa mémoire AUGMENTE les performances. Je parle bien de processus ici.

    Le thread n'est pas qu'une vue de l'esprit du compilateur (d'ailleurs, lui ne sait pas ce que c'est du tout, pour le coup, c'est plus l'OS), c'est une réalité pour plusieurs types de CPUs, tous ceux qui ont du SMT. Les coprocesseurs ne peuvent pas être les threads de la plateforme cible. Mais je pense que tu voulais dire qu'il faut les encapsuler dans des threads (et pourquoi tu considères la FPU comme un cas à part, et pas les ALUs ?)
    Si tu as plusieurs µp réellement et TOTALEMENT indépendants, effectivement les goulets d'étranglement se déplacent...

    Mais j'ai bien peur qu'il n'y ait que très peu chances que tu ne te retrouves à coder pratiquement dans ce cas de figure et la portabilité d'un tel code serait inférieure à zéro (ce qui n'est intéressant que dans le cadre d'une machine dédiée).

    Je comprends tout à fait ce que tu désires préciser avec la "connaissance" de l'OS mais dans le cas très pratique d'un codeur qui utilise un compilateur (ce qui arrive régulièrement souvent) son seul interlocuteur, au niveau de la compréhension avant génération du code réel, est le compilateur
    Or c'est bien lui qui va organiser les blocs de codes selon une série d'algos et d'options plus moins performantes.
    L'OS, lui, ne fait que proposer la vue de l'esprit et enfin, la seule "connaissance" qui puisse trancher est celle du µp cible. Ci celui-ci n'est pas construit pour fabriquer le découpage du code en segments paralléliseables, toutes les formes d'OS, de compilateur ou de délires via bibliothèques n'y changeront vraiment rien.

    Je pense que nous sommes aussi d'accord sur ce point là.

    La vieille technologie SMT ne change rien au fond du problème: Aucune accélération ne sera obtenue en fixant, via code, le cœur utilisé par un processus.
    Faire tourner le même code sur deux µp différents au niveau de cette technologie, produira des performances positives mais fixer les processus sur des cœurs par différentiation au niveau du code ne produira que des ralentissements dans tous les cas.

    Un bonne vieille mesure ne fera que confirmer ce propos évident.

    Maintenant, il est clair que les fabricants d'outils de développement ne vont pas se tirer une balle dans le pied mais continuer d'utiliser les phobies et les réflexes de base comme leviers d'intoxication efficaces.

    Les coprocesseurs sont tout à fait utilisables comme des threads physiques: Le simple fait d'envoyer du code à deux électroniques indépendantes crée, de facto, deux threads (c'est exactement le principe de n'importe quel µp multi-cœurs). Les encapsuler dans des threads logicielles n'apporte rien, si ce n'est une lenteur supplémentaire et quelques nouveaux conflits.

    La FPU souffre de vieux problèmes de synchro qui sont à l'origine de 3D Now! et SSEx.

  14. #274
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Points : 20 970
    Points
    20 970
    Par défaut
    Citation Envoyé par Rémi Coquet Voir le message
    Si tu as plusieurs µp réellement et TOTALEMENT indépendants, effectivement les goulets d'étranglement se déplacent...

    Mais j'ai bien peur qu'il n'y ait que très peu chances que tu ne te retrouves à coder pratiquement dans ce cas de figure et la portabilité d'un tel code serait inférieure à zéro (ce qui n'est intéressant que dans le cadre d'une machine dédiée).
    Pas dans le milieux des jeux, en revanche dans d'autres milieux, ça arrive fréquemment (dotn le mien )

    Citation Envoyé par Rémi Coquet Voir le message
    Je comprends tout à fait ce que tu désires préciser avec la "connaissance" de l'OS mais dans le cas très pratique d'un codeur qui utilise un compilateur (ce qui arrive régulièrement souvent) son seul interlocuteur, au niveau de la compréhension avant génération du code réel, est le compilateur
    Or c'est bien lui qui va organiser les blocs de codes selon une série d'algos et d'options plus moins performantes.
    L'OS, lui, ne fait que proposer la vue de l'esprit et enfin, la seule "connaissance" qui puisse trancher est celle du µp cible. Ci celui-ci n'est pas construit pour fabriquer le découpage du code en segments paralléliseables, toutes les formes d'OS, de compilateur ou de délires via bibliothèques n'y changeront vraiment rien.

    Je pense que nous sommes aussi d'accord sur ce point là.
    +1
    Citation Envoyé par Rémi Coquet Voir le message
    La vieille technologie SMT ne change rien au fond du problème: Aucune accélération ne sera obtenue en fixant, via code, le cœur utilisé par un processus.
    Faire tourner le même code sur deux µp différents au niveau de cette technologie, produira des performances positives mais fixer les processus sur des cœurs par différentiation au niveau du code ne produira que des ralentissements dans tous les cas.

    Un bonne vieille mesure ne fera que confirmer ce propos évident.

    Maintenant, il est clair que les fabricants d'outils de développement ne vont pas se tirer une balle dans le pied mais continuer d'utiliser les phobies et les réflexes de base comme leviers d'intoxication efficaces.
    Complètement d'accord.
    Pour moi, l'affinité n'a d'intérêt que si on fixe aussi la mémoire, et donc c'est en multi-processus.
    Citation Envoyé par Rémi Coquet Voir le message
    Les coprocesseurs sont tout à fait utilisables comme des threads physiques: Le simple fait d'envoyer du code à deux électroniques indépendantes crée, de facto, deux threads (c'est exactement le principe de n'importe quel µp multi-cœurs). Les encapsuler dans des threads logicielles n'apporte rien, si ce n'est une lenteur supplémentaire et quelques nouveaux conflits.
    OK, tu pars donc d'un traitement asynchrone (parfois, on a du synchrone, auquel cas, on doit encapsuler).
    Citation Envoyé par Rémi Coquet Voir le message
    La FPU souffre de vieux problèmes de synchro qui sont à l'origine de 3D Now! et SSEx.
    Des problèmes de synchro ? S'il y avait des problèmes de synchro, on aurait changé le modèle depuis longtemps. Sans compter que la FPU est compatible IEEE, ce qui n'est pas toujours le cas des autres systèmes. Tu veux peut-être plus parler du mécanisme sous-jacent, basé sur une pile et des mots de 80bits ?

  15. #275
    Membre actif

    Inscrit en
    Février 2009
    Messages
    200
    Détails du profil
    Informations forums :
    Inscription : Février 2009
    Messages : 200
    Points : 235
    Points
    235
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Pas dans le milieux des jeux, en revanche dans d'autres milieux, ça arrive fréquemment (dotn le mien )
    Tout est possible en dehors du cadre de ce topic qui, il me semble, limite le débat à celui, très particulier, du jeu (qui n'est pas directement le mien non-plus).
    Pour moi, l'affinité n'a d'intérêt que si on fixe aussi la mémoire, et donc c'est en multi-processus
    Le lieu, les moyens de partage de la mémoire, ne jouent pas sur l'électronique mais uniquement, par le biais de lOS, sur des mécanismes de limitations ou de protection de ce dernier. La performance des "threads" réelles est obligatoirement liée aux capacités électroniques de la cible, c'est pour cela que je parle de vues de l'esprit. Les threads logicielles n'étant qu'un argument marketing amusant dans le principe si ce n'est triste dans la vision qu'il engendre dans la tête de nombreux codeurs…
    OK, tu pars donc d'un traitement asynchrone (parfois, on a du synchrone, auquel cas, on doit encapsuler).
    Deux traitements synchrones ne peuvent en aucun cas être multitâches mais pour le mieux sérialisés et prendront toujours plus de temps en générant un peu plus de conflits. Là encore, le marketing du multitâche a fait ses dégâts non seulement dans le grand publique mais dans la production de concepts fantasmagoriques…
    Des problèmes de synchro ? S'il y avait des problèmes de synchro, on aurait changé le modèle depuis longtemps. Sans compter que la FPU est compatible IEEE, ce qui n'est pas toujours le cas des autres systèmes. Tu veux peut-être plus parler du mécanisme sous-jacent, basé sur une pile et des mots de 80bits ?
    Le fait que la FPU utilise un LIFO travail en 32 64 et 80 bits ne change pas grand chose (IEEE n'est qu'une forme de représentation qui n'a pas grand chose à voir avec la taille des données).

    Le problème de synchronisation de la FPU est tout à fait visible à travers des instructions comme fwait ou finit. Il est impossible de travailler avec la FPU sans la re-synchroniser d'une manière ou d'une autre avec la partie integer du µp.

    Multitâches, n'a de sens que si tous les processus sont asynchrones, non-bloquants, et réalisé sur des électroniques indépendantes. Ce que j'appelle vues de l'esprit concerne toute la "partie molle" restante

Discussions similaires

  1. Que peut on utiliser à la place des popup
    Par david42 dans le forum Général JavaScript
    Réponses: 6
    Dernier message: 14/02/2006, 09h21
  2. [UML] Que peut-on vraiment faire avec ces logiciels ?
    Par pugnator dans le forum Outils
    Réponses: 6
    Dernier message: 07/12/2005, 12h31
  3. Que peut-on faire avec une vue ?
    Par Invité dans le forum Décisions SGBD
    Réponses: 8
    Dernier message: 20/10/2005, 12h13
  4. [Securité]Que peut-on faire contre un décompilateur?
    Par Hannappel dans le forum Langage
    Réponses: 3
    Dernier message: 02/10/2005, 13h36
  5. Réponses: 1
    Dernier message: 27/05/2005, 10h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo