Discussion :

[screetch]

pourquoi juste tu fais pas ta simulation sans le rendu??

[Mat.M]

L'introduction
Ca fait pas mal d'année que je travaille sur le problème en collaboration avec lsong et je propose aujourd'hui notre solution. Notez que cette solution ne fonctionne que dans un cas très particulier, dont le jeu vidéo 3D temps réel fait parti. Ce n'est pas une solution pour toutes les applications !!!

La bibliothèque de calculs multithread en question est utilisable dans les moteurs de physique et les moteurs d'affichage 3D.
Je poste ici les résultats de mes tests de performances

Euhh d'accord mais ou peut-on la télécharger cette bibliothèque je suis neuneu moi ?
Tu nous donnes des graphiques donc il faut te croire là-dessus mais on ne peut même pas faire nos propres tests !

quand j'ai dis "qu'un processeur à 4 coeurs n'est pas aussi puissant que 4 processeurs" c'est pour illustrer ce que tu précises ensuite dans ton post : pb de memoire cache commune (ou pas) etc...

un système quadri processeur n'apporte pas nécessairement de performances pour un jeu vidéo
Un tel système c'est bon pour les serveurs ( genre CPU Xeon ) ou bien notamment pou le traitement de la vidéo ( compression )
J'ai bossé dans une société qui avait un système à base de Xeon pour encoder des films.
Maintenant un système à 4 CPU n'apportera pas bcp de performances parce que soit par hardware il faut répartir les taches sur chaque processeur ou bien par logiciel ( via l'OS ) ce qui sera plus long.

qu'est-ce qui fait qu'un processeur à 4 coeurs (physiques sous entendu) n'est pas aussi puissant que 4 processeurs ?

Parce que pour la raison citée précedemment ; la carte-mère possède un controleur spécial je crois bien il faut toute un design de l'électronique particulier donc cela n'apporte pas forcément plus de rapidité au contraire
Un système à plusieurs CPU c'est bien pour lancer en parallèle plusieurs taches qui requiérent des calculs complexes comme la simulation météorologique par exemple mais pas pour du quasi temps réel comme un jeu vidéo.
En éléctonique on apprend que plus la distance que doit parcourir les électrons d'un composant à un autre est réduite plus leur vitesse est accélérée ( c'est logique ) bref l'information binaire 1 ou 0.
Donc c'est pour cela qu'on a inventé les supra-conducteurs, les composants électroniques...comme les diodes , transistors..
Et c'est pour cela qu'Intel a élaboré cette technologique multicoeurs parce que l'intégration à haute échelle ( Very Large Scale Integration en anglais ) est plus élevée.
Pour un CPU à plusieurs coeurs c'est des distances de quelques microns alors que sur une carte mère avec 2 ou 4 CPU ce sont des mm voire des cm ..!

http://fr.wikipedia.org/wiki/Int%C3%...e_%C3%A9chelle

en anglais c'est plus complet :
http://en.wikipedia.org/wiki/VLSI

http://en.wikipedia.org/wiki/Montecito_(processor)

[Mat.M]

4.34 !!!!!
j'hallucine c'est quasiment identique a ce qu'on trouve sur les bench independant pour les applications naturellement parallelisable !
on fera un post sur le site web pour ceux que ca interesse.



Vincent

Ce graphique me fait vraiment sourire ! tu oses comparer les performances de cette bibliothèque AccLib avec Crysis par exemple un jeu qui nécessite des mégas de mémoire et de ressources.
C'est facile de battre Crysis en performances avec cette bibliothèque dont tu parles si tu affiches juste 3 cubes texturés à l'écran !

En plus comment peux-tu savoir que Crysis lance n nombre de threads ? As-tu le code source du moteur de Crysis

[Fraggy]

Euhh d'accord mais ou peut-on la télécharger cette bibliothèque je suis neuneu moi ?
Tu nous donnes des graphiques donc il faut te croire là-dessus mais on ne peut même pas faire nos propres tests !

je sais, j'en suis désolé
la démo, les sources de cette démo, sont disponibles en test et évaluation gratuite, mais uniquement pour les prospects... si ton entreprise est intéressée par le produit qu'elle prenne contact avec moi sur www.acclib.com
J'ai fais une série de vidéo pour rassurer un peu : http://www.acclib.com/2009/01/perfor...balancing.html

un système quadri processeur n'apporte pas nécessairement de performances pour un jeu vidéo

oui, tu entendras la même chose sur les processeurs multicoeurs... J'ai demandé à Intel une workstation dual proc xeon (8x2 = 16) en test (ca fait bien 1 mois mais je crois que ça existe pas encore :p) pour vérifier mes hypothèses... mais a priori vu que j'ai un gain significatif sur du HT, je pense obtenir sensiblement le même genre de gain sur du multiprocesseurs

[Fraggy]

Ce graphique me fait vraiment sourire ! tu oses comparer les performances de cette bibliothèque AccLib avec Crysis par exemple un jeu qui nécessite des mégas de mémoire et de ressources.
C'est facile de battre Crysis en performances avec cette bibliothèque dont tu parles si tu affiches juste 3 cubes texturés à l'écran !

Tu confonds performance pure et gain de performance
Je crois que ni toi ni moi nous avons la moindre idée du travail que les développeurs de crysis ont accompli pour en arriver là. Ils sont compétents et bon dans leur domaine, clairement :p

C'est une question d'outil, de méthode. Ils utilisent malheureusement une méthode qui "scale" mal... c'est a dire que si tu fais tourner leur jeu sur un 32 coeurs il va marcher pareil que sur 3 coeurs...
Je compare ce qui est comparable : le gain de perf quand on augmente le nb de thread sur un processeur multicoeurs HT (dans ce graphique c'est un core i7)

en plus j'ai pas de cubes texturés, c'est juste des cube en fil de fer :p

[Fraggy]

Et c'est pour cela qu'Intel a élaboré cette technologique multicoeurs parce que l'intégration à haute échelle ( Very Large Scale Integration en anglais ) est plus élevée.
Pour un CPU à plusieurs coeurs c'est des distances de quelques microns alors que sur une carte mère avec 2 ou 4 CPU ce sont des mm voire des cm ..!

il y a des avantages a faire du multicoeur, mais à priori c'est pas pour améliorer la vitesse de transfert d'info entre chaque coeur :p
Je pense que la principale raison est économique.

Lorsqu'Intel c'est lancé la dedans quand il s'est aperçu que dépasser 4 Ghz est devenu impossible/trés difficile (pb de dissipation de la chaleur) et qu'il est finalement plus rentable que faire 4 fois 2 Ghz = "8 Ghz like" !!!

[Mat.M]

C'est une question d'outil, de méthode. Ils utilisent malheureusement une méthode qui "scale" mal... c'est a dire que si tu fais tourner leur jeu sur un 32 coeurs il va marcher pareil que sur 3 coeurs...

Faut-il conclure alors que les CPU avec n coeurs n'ont pas d'intérêt pour le jeu vidéo ? ( c'est un autre débat )
Et qu'est ce que peut faire de plus ta bibliothèque pour avoir un gain de performance dont tu parles ?

[Mat.M]

Lorsqu'Intel c'est lancé la dedans quand il s'est aperçu que dépasser 4 Ghz est devenu impossible/trés difficile (pb de dissipation de la chaleur) et qu'il est finalement plus rentable que faire 4 fois 2 Ghz = "8 Ghz like" !!!

Je suis d'accord Ok mais en quoi alors AccLib va accroite plus de performances et faire comme si le CPU "tournait" à 4Ghz et plus ? ( je sais je suis neuneu et hargneux )

[Fraggy]

Faut-il conclure alors que les CPU avec n coeurs n'ont pas d'intérêt pour le jeu vidéo ? ( c'est un autre débat )

voir l'autre thread sur que peut apporter le multithread au JV :p
http://www.developpez.net/forums/d60...oppement-jeux/
- Perso je SAIS que oui.
- D'autre PENSES que oui (généralement les joueurs ou ceux qui n'ont pas les mains dans le cambouis, mais pas seulement).
- Alors que d'autres PENSES que NON (ceux qui s'intéressent de près, ceux qui vont vers les GPU pour améliorer leurs JV)

Et qu'est ce que peut faire de plus ta bibliothèque pour avoir un gain de performance dont tu parles ?

Ma bibliothèque utilise une méthode globale de parallélisation orientée données et offre un système d'interfacage relativement simple pour les app existantes.
Ce type de parallélisation promet une linéarisation des gains de performance ce qui est le principal intérêt d'ACCLib...

On pourrait dire que le vrais pb n'est pas la (on est a 4 coeurs, c'est pas si grave d'être bloquer a 2/3x), le vrais pb vient du fait que les méthodes de parallélisation utilisées dans le JV sont tellement complexes (demande des compétences/formation/embauche) et difficile à mettre en place (les bugs de parallélisme c'est un peu comme des morpions...) qu'une solution simple et robuste comme ACCLib devient une alternative vraiment intéressante :p

[Fraggy]

en quoi alors AccLib va accroite plus de performances et faire comme si le CPU "tournait" à 4Ghz et plus ? ( je sais je suis neuneu et hargneux )

Un JV aujourd'hui c'est méthode fonctionnelle et data parallélisme systématique.

Fonctionnel :
Pour faire simple on découpe les fonctions du jeu en 3D, IA, physique, etc... et on fait tourner ca en paralléle (méthode asynchrone) ou on fait un paquet de 3 threads et chacun bosse sur une copie privée des données a affichée (méthode synchrone)
pour ceux que ça intéresse : http://www.acclib.com/2009/02/about-...lel-model.html, http://www.acclib.com/2009/02/data-parallel-model.html
Ces méthodes sont également utilisés dans SMOKE.
Je précise, elles marchent, dans le sens ou elle apporte des performances (3x/2x suffisent aujourd'hui). Le pb c'est que lorsqu'on aura 32 coeurs, on ne pourra pas plus s'en servir que d'un 4 coeurs
Elles ne "scalent" pas.

Data parallélisme systématique :
tu cherches et tu modifies le code source de ton application pour paralléliser tout ce qui l'est openMP, cilk++, TBB, pthread sont utilisables dans ce cadre. Ca ameliore un peu le fonctionnement de la méthode fonctionnelle mais c'est pas la joie (voir le pb des tailles de job, http://www.acclib.com/2009/02/why-use-acclib.html, en bas de l'article)


ACCLib n 'utilise pas ces modèles de parallélisation, on a pris au mot l'auteur de cet article (http://www.gamasutra.com/view/featur...me_engine_.php), on n'utilise pas le modèle fonctionnel car "The current trend seems to be towards creating engine components that use some internal form of parallelization. While this allows engine developers to not worry about threading issues, it may leave large parts of the program sequential, which results in poor performance."
On a mis en place une méthode de parallélisation globale orientée data qui ne nous a pas déçu jusqu'a présent :p
->Je pense même que ça va marcher sur du multiprocesseur, c'est dire :p

Fraggy

[Matthieu Brucher]

6x sur un i7 c'est pas 140% de plus mais 50%
le i7 est un "quad core", 4 coeurs physiques, donc :
- théoriquement tu pourrais booster une appli à 4x, si on considère les 30% que l'HT peut t'apporter d'après le gars qui t'a répondu ça fait 5,2x
- en pratique tu devrais quand même au moins dépasser les 4x et tendre vers les 5x

mais le gain dépend beaucoup de la façon dont les données sont partagées entre les différents threads
et pour un moteur de jeu c'est plus difficile de s'approcher du 5x vu qu'il y a beaucoup d'éléments à coordonner
mais je suis persuadé que vous pouvez faire mieux

Le gain pour de l'HT dépend de plusieurs choses :
- Est-ce que les unités de calcul sont peu occupées ?
- Si oui, on peut espérer un gain que si la bande passante mémoire n'est pas complètement utilisée.

Mais elle est linéaire quand on en sera a 512 coeurs, c'est ça qui comptera )) . (Note que je perds pas espoir d'améliorer le gain de performance :p).

Faut arrêter de rêver. Quand tu augmentes le nombre de coeurs ou le nombre de thread gérables, tu augmentes la probabilité de contention au niveau cache et mémoire. C'est d'autant plus valable sur une application SMP.

[EDIT]
//Le processeur lui même d'abord, un quadcoeur c'est pas aussi puissant que
//4 processeurs :p
Le système même que multiple coeur, demande du temps de synchro au processeur lui même (accès aux caches, transfet de données d'un coeur à l'autre...) ce qui explique le décrochage par rapport à la courbe bleue

Au contraire, c'est meilleur car les superviseurs de cache peuvent optimiser les contentions directement dans le cache au lieu d'envoyer la donnée en mémoire puis de demander à chaque coeur de la recharger si la ligne de cache est mauvaise.

je dirais qu'il est facile de faire un quadcoeur moins rapide qu'un système a 4 processeurs monocoeur. Je parlais en fait de mon foutu Q6600 "quad" coeur qui n'est en fait qu'un 2 foi dualcoeur et qui lui est moins puissant qu'un 4x processeur monocoeur équivalent en architecture (caches etc...)

Tu vois, ça c'est typiquement le contraire. Ton processeur est en fait 2 dual-coeurs. Un vrai quadcoeur est largement plus performant car le cache est partagé, le système mémoire peut être optimisé, ...