Utilisez le max du processeur sur appli C++

Citation:

---

Envoyé par Joel F

Moi le marketing ^^ j'ai des gens qui s'en charge :o

---

Moi aussi, mais ils me demandent de pouvoir montrer une machine occupée à 100% quand l'utilisateur doit attendre plusieurs heures.

Citation:

---

Envoyé par Joel F

*J'ai* écrit une bibliothèque qui encapsule tous les SIMD existants sous forme de fonctions façon cmath etc... qui travaille sur des objets genre simd::register_<T,N> qui représentent des paquets de N valeurs de types T. Si (T,N) correspondent à un register simd sur une archi donnée, la vectorisatione st automatique. Sinon, on découpe et on utilsie boost::array si besoin. Ca fait bien 5-6 que j'ai pas ecrit d'intrinsic directement autrement que pour ajouter une fonction dans ce machin.

---

D'accord. J'attends avec grande curiosité de voir à quoi elle ressemble.

Citation:

---

Envoyé par Joel F

parce que avant de changer le moteur de ma voiture, j'utilise une bonne huile et un bon carburant ;) Les extensiosn SIMD xont la, c'ets guère le drame a utilisé conceptuellement (pas d'histoire de mutex, de dead race etc) et c'ets un gain de 4 à 16 AVANT MEME de threader. Pour tout dire, SIMD+Thread, en général, sur pas mal d'applis ca suffit à briser la barrière du temps réel ou à rendre utilisable un algo. Ca relativise aussi la nécessité de faire des trucs chelou avec des GPU vu que le gain GPU vs SIMD+Thread depasse rarement 4 ou 6

---

C'est amusant, et ça reflète probablement un historique différent, mais pour moi, qui ai une certaine habitude du temps réel, programmer en parallèle pour la performance ne me fait pas plus peur que ça, alors qu'utiliser des instructions dont le comportement va dépendre de l'architecture cible me semble conceptuellement très difficile.

Et surtout, je ne vois vraiment pas comment modifier mon code pour lui faire entrer des instructions SIMD (peut-être parce que je n'utilise pas des structures comme des matrices ou des images dans mon domaine d'application, contrairement au posteur initial de ce fil de discussion ?), alors que paralléliser mon traitement coule de source. En particulier, je ne vois pas apparaître dans mon code nécessitant une optimisation un même calcul qui se ferait sur plusieurs données en parallèle : ce qui prend du temps, ce sont surtout des tris, par exemple, et je ne sais pas trop dans quelle mesure le SIMD pourrait m'aider là ?

Citation:

---

Envoyé par JolyLoic

Moi aussi, mais ils me demandent de pouvoir montrer une machine occupée à 100% quand l'utilisateur doit attendre plusieurs heures.

---

Les miens n'en sont pas là ^^

Citation:

---

Envoyé par JolyLoic

D'accord. J'attends avec grande curiosité de voir à quoi elle ressemble.

---

Y en a un aperçu dans mon talk à Boost'Con 2010. la partie SIMD en elle même va potentiellement aussi passer à la moulinette Boost et etre soumise pour revue.

Citation:

---

Envoyé par JolyLoic

C'est amusant, et ça reflète probablement un historique différent, mais pour moi, qui ai une certaine habitude du temps réel, programmer en parallèle pour la performance ne me fait pas plus peur que ça, alors qu'utiliser des instructions dont le comportement va dépendre de l'architecture cible me semble conceptuellement très difficile.

---

ca me fait pas peur non plus. Mais en general, je préfére essorer tout le disponible au niveau N avant de voir à coté.

Citation:

---

Envoyé par JolyLoic

Et surtout, je ne vois vraiment pas comment modifier mon code pour lui faire entrer des instructions SIMD (peut-être parce que je n'utilise pas des structures comme des matrices ou des images dans mon domaine d'application, contrairement au posteur initial de ce fil de discussion ?), alors que paralléliser mon traitement coule de source. En particulier, je ne vois pas apparaître dans mon code nécessitant une optimisation un même calcul qui se ferait sur plusieurs données en parallèle : ce qui prend du temps, ce sont surtout des tris, par exemple, et je ne sais pas trop dans quelle mesure le SIMD pourrait m'aider là ?

---

Oui bein entendu, le SIMD n'a de sens que si le parallelisme de donnée est présent dans l'algo. Si tu passes ta vie à trier des structures et à avoir un schéma data-flow global qui se préte au threading, bah je ferais pareil que toi. threading et c'est tout.

Dans le cadre du poste initial, le SIMD a toute ça place.

Note que pour les tris, il doit exister des tris façon Perfect Sample qui se vectorise. Mais ca reste limité au type de base et au paquet de type de base.

Citation:

---

Envoyé par JolyLoic

En terme de parallélisation pour les performances, je pense que TBB est le standard de fait aujourd'hui. Et elle est portable sur moult architectures. Voir http://software.intel.com/sites/prod...ease_notes.txt pour plus d'infos.

---

dommage que les procésseurs sparc et PA-RISC ne soient pas supportées, sinon elle aurait bien pu m'intéresser, je vais donc rester sur du pthread.


Ensuite je ne serais pas si catégorique, d'expériences toutes les lib de thread on leurs avantage et leurs inconvénients. il y'aura forcément des use-case ou TBB sera moins bonne que pthread et vice et versa. les performances vont surtout beaucoup dépendre du design de ton application et des choix d'architectures logiciel.

http://www.drdobbs.com/go-parallel/b...PCKH4ATMY32JVN

J'ai l'impression que ça part un peu en débat SIMD vs multiThread :P.

Pour info, j'ai suivi JolyLoic et j'ai réalisé mon appli en multithread :P, pas que j'ai une dent contre le SIMD mais je ne vois pas du tout ce que c'est :?. De plus passer en multithread paraissait moins compliqué.

J'ai pu monter a 50% de mon proc contre 12% auparavant. Du coup j'ai pu modifier mon algo et faire une recherche de l'ensemble de mes patterns contrairement à un seul avant :ccool:.


Seul bémol (il en reste toujours un :(), ça ne me suffit toujours pas :?, il faudrait que cette recherche de pattern s'effectue plus rapidement. Je ne peux pas monter plus haut dans l'utilisation de mon processeur, donc je crois que je vais me tourner vers la solution de Joel F; tu me conseillerais de regarder quoi pour commencer?

les cours de mon collégue sur le sujet:
http://www.ief.u-psud.fr/~lacas/Teaching/Teaching.html

Apres, si tu as des questions précises, j'y répondrais volontiers.

Citation:

---

Envoyé par Space23

Je ne peux pas monter plus haut dans l'utilisation de mon processeur.

---

Ou alors, passer sur ton processeur graphique (GPU) avec CUDA ou OpenCL si la tâche à effectuer est "très" parallélisable (tu parlais de traitement d'image, donc ça en a le goût :lol:)...

Citation:

---

Envoyé par TNT89

Ou alors, passer sur ton processeur graphique (GPU) avec CUDA ou OpenCL si la tâche à effectuer est "très" parallélisable (tu parlais de traitement d'image, donc ça en a le goût :lol:)...

---

Sauf que non. Si il ne sature pas son CPU, son probleme est memory bound, ce qui donenra des perfs nazes sur GPU ...

Je suis pas sûr qu'il ne sature pas son CPU...
J'ai aussi un Core I7 dans mon portable et il me semble que pour certaines tâches les cœurs virtuels sont stoppés par l'OS (4 * 100% et 4 * 0%) et donc 50% d'occupation seulement...

Si pour l'instant il a fait son code avec pThread, alors l'OS est roi non?

Les tps qui se trouvent sur le site correspondent a quel type de formation et pour quel année? Ca m'a l'air assez balèse tout de même 8O.

De plus je suis pas vraiment convaincu que ça pourrait optimiser mon code. La reconnaissance d'image dans mon prog C++ se fait avec OpenCV. Du coup j'ai pas réinventer la roue c'est openCV qui gère a peu près tout pour moi. SIMD ou SSE c'est plus lorsque on met carrément les mains dans le cambouis et qu'on part de 0 non?

Oui il faudrait recoder OpenCV si tu n'utilises que ses primitives et que tu veuilles l'optimiser... par contre ça doit déjà être bien géré comme lib...

Les cours sont entre BAC+3 et BAC+5 à vu de nez...

En attendant, il existe des choses comme un portage d'OpenCV sur GPU : GPUCV

Citation:

---

Envoyé par TNT89

Je suis pas sûr qu'il ne sature pas son CPU...
J'ai aussi un Core I7 dans mon portable et il me semble que pour certaines tâches les cœurs virtuels sont stoppés par l'OS (4 * 100% et 4 * 0%) et donc 50% d'occupation seulement...

Si pour l'instant il a fait son code avec pThread, alors l'OS est roi non?

---

D'experience (aka pour avoir bosser dessus pendant 2 ans), vu le type d'algo, il ne gagnera rien à passer sur gpu au vu de la latence du bus ...

@Space23: OpenCV est tout sauf implanter correctement. pas mal d'algo sont sous optimaux.

8O

heu, sur des flux vidéo HD décompressés (1920*1200*3 Bytes) et ma carte mobile j'ai du 160Hz en échange(cad aller-retour) quand même...

C'est vraiment aussi lent que ça un bus PCIe?

(ton expérience m'intéresse Joel F parce que je vais passer 2 mois de stage sur ce sujet et 2 flux vidéos HD à traiter en temps réel :aie:)

le decodage/encodage video n'a pas du tout la meme empreinte memoire que de la detection de pattern comme le fait le PO. En gros, l'important c'ets le ratio acces memoire de la carte/calcul. Si tu fais pas au moins 6 FMA par acces memoire, ta carte est sous-exploitée. Et la dessus, tu ajoute le debit du PCIe ...

De la detection de pattern, c'ets d ela correlation dont N² acces memoire pour N(N-1) calcul, soit un ratio proche de 1 ... loupé

En outre, tout le monde fait l'erreur de comparait les perfs des GPUs aux perfs d'un mono-core sans SIMD :o Alors la forcement on a des gains de 100+. Maintenant, tu prends un vrai bench ou tu compares par rapport à un 4-cores + du SIMD sur du float, ton 100+ devient un petit 5+ ...

Donc, ne prenez pas les benchs (surtout ceux de NVIDIA) pour argent comptant. Benchez proprement.

http://www.microsoft.com/france/visi...e-4f939eb77bd8

pour appuyer le discours de Joel F que comparer cpu et gpu c'est débile (vers la fin de la vidéo)

Citation:

---

Envoyé par stardeath

de plus s'amuser à étudier les défauts de cache est très loin d'être évident comparé à mettre un #pragma parallel for.

---

Je rebondis la dessus. C'est pour moi une base tellement basique que ca devraoit etre enseigner à tout ingénieur informaticien. Malheureseument, c'ets pas le cas.

Deja si les gens savait que leur machine A UN CACHE et ce que ca veut dire, ca serait pas mal.

Citation:

---

Envoyé par Joel F

Je rebondis la dessus. C'est pour moi une base tellement basique que ca devraoit etre enseigner à tout ingénieur informaticien. Malheureseument, c'ets pas le cas.

Deja si les gens savait que leur machine A UN CACHE et ce que ca veut dire, ca serait pas mal.

---

le problème, comme je l'ai souligné, c'est que c'est pas de la tarte à comprendre, j'ai compris cette notion de cache (et tous les problèmes que ça entraine) seulement quand j'ai commencé la programmation gpu, et ça seulement il y a quelques mois.

de plus les outils permettant d'étudier réellement ce qu'il se passe, sont très loin d'être facile à utiliser et surtout très cher (vtune par exemple)

La question que je me pose c'est est-ce que SIMD permet de faire autre chose que des calculs vectoriels de petite dimension? (limité au nombre de PU)

Citation:

---

Envoyé par TNT89

La question que je me pose c'est est-ce que SIMD permet de faire autre chose que des calculs vectoriels de petite dimension? (limité au nombre de PU)

---

Attention quand je parle de SIMD, je parle de SWAR, cad utilisez les registres vectoriels du processeur. SSEx fournit 8 registres et Altivec 32. Ces rtegistres contiennent 2,4,8 ou 16 elements scalaires d'un types uniques et se manipulent avec des fonction dédiés. L'avantage sont multiples:

- le banc de registre est séparé des autres (du moins pour Altivec et SSE >= 2)
- les instructions ont leur propre pipeline, souven plus profond que le pipeline scalaire
- la ou float a,b,c; c = a+b prend 1 cycle, vector float a,b,c c = a+b prend un cycle aussi mais travail sur 4 elements simultanement, d'ou la source de parallelisme.

En gros, tout algo data-parallel se prete à la SIMDisation. Au lieu de traiter 10000 elements en 10000 iterations, on traite 10000 elements en 2500 iterations, donc moins de defaut de cache, moins de tour de boucles etc ...

le strucs qui s'y pretent bien sont tt le traitement du signal et de l'image, les calculs numeriques dans des tables, le filtrage numerique, le tri, le calcul de mediane etc.

Citation:

---

Envoyé par Joel F

En gros, tout algo data-parallel se prete à la SIMDisation. Au lieu de traiter 10000 elements en 10000 iterations, on traite 10000 elements en 2500 iterations, donc moins de defaut de cache, moins de tour de boucles etc ...

---

Mais un GPU fait ça en 8 itérations (pour 128 unités de calcul avec chacune leur cache propre)? Où est l'avantage de le faire sur CPU?

la bande passante mémoire qui est genre supérieure au PCIe, le fait de pas sortir du cache etc ... et le fait que la qualité du code généré par CUDA est abyssale (cf les papiers de Volkov sur le sujet)