"Librairies" SSE ?

Version imprimable

05/11/2009, 13h13
ZeMike

"Librairies" SSE ?

Bonjour à tous,

je ne sais pas si je tape au bon endroit dans le forum, je tente ...

je développe actuellement un modèle numérique en physique (lasers). Pour cela, j'ai un jeu d'équations numérisées qui n'est pas très compliqué mais que je dois évaluer très souvent. Les temps de calculs sont ennormes avec mon code écrit en C++ (pas trop moche je pense) : entre 3 et 10 h pour arriver au résultat qui m'intéresse.

je n'ai pas utilisé les fonctions de parallélisation (genre tbb de intel) car de toute façon je dois réaliser plusieurs simulations en parallèle, j'en lance une par coeur et çà me va bien. J'ai 2 xéon 2 coeurs, je lance donc 4 simulations en même temps.

En revanche je me demandais si des technologies du type SSE (toutes versions) ne me permettraient pas d'accélérer les temps de calcul. Seulemente voila, je ne sais pas ce qu'il est possible et les documentation semblent assez obscures. Est-ce que quelqu'un aurait une expérience de développement via SSE et pourrait m'expliquer le genre de choses que l'on peut accélérer en utilisant ces technologies ? Avec si possible quelques indications sur ce qu'il faut faire pour l'exploiter en langage C ? (librairie particulière ?)

Merci,
Mike
05/11/2009, 13h22
dourouc05

Salut,

Citation:

Envoyé par ZeMike

En revanche je me demandais si des technologies du type SSE (toutes versions) ne me permettraient pas d'accélérer les temps de calcul. Seulemente voila, je ne sais pas ce qu'il est possible et les documentation semblent assez obscures. Est-ce que quelqu'un aurait une expérience de développement via SSE et pourrait m'expliquer le genre de choses que l'on peut accélérer en utilisant ces technologies ? Avec si possible quelques indications sur ce qu'il faut faire pour l'exploiter en langage C ? (librairie particulière ?)

SSE, toutes versions confondues, sont des jeux d'instructions processeurs. En d'autres termes : un processeur qui supporte SSE pourra utiliser une instruction XUZ en un seul cycle, tandis qu'un autre processeur (sans support SSE) devra effectuer trois cycles : un pour l'instruction X, un autre pour U et un dernier pour Z. En un mot, c'est de cela dont il s'agit.

Je ne pense pas qu'il soit possible de l'utiliser directement en C, vu que ces instructions sont plus du niveau assembleur. Normalement, les compilateurs actuels sont capables de générer du code prévu pour ces jeux d'instructions et de mieux les utiliser.

Si cela ne suffit pas, tu peux t'orienter vers des librairies de calcul prévues pour les performances (et qui donc utilisent beaucoup de SSE pour les processeurs uqi les supportent en assmelbuur). Par exemple, en opensource, GNU GMP (utilisé par GCC, par exemple, mais incompatible avec Visual Studio), ou bien Intel MKL, mais payant et closed source.
05/11/2009, 15h02
ZeMike

Merci pour cette réponse. En clair vu du C, SSE n'est qu'une optimisation via le compilateur. J'avais pensé qu'il y avait des instructions au niveau du C, je me souviens sur PowerPC G5 avoir vu trainer des choses sur de l'utilisation d'instructions vectorielles (via le C) implémentées dans le FPU, mais ca ne concerne probablement pas les processeurs Intel et SSE ?

Une librairie Math comme MKL que j'utilise parfois ne résoudrait pas mon problème car je n'utilise pas une technique numérique particlière (FFT par exemple), ce sont vraiment mes équations et le nombre d'itérations qui sont en cause. Il faudrait peut-être que je vois pour passer mes équations en assembleur alors, mais j'ai du mal à situer quel gain de temps je peux avoir par rapport à du gcc ou du icc avec toutes options d'optimisation activées.

Encore merci,
Mike
05/11/2009, 17h00
dourouc05

Citation:

Envoyé par ZeMike

Merci pour cette réponse. En clair vu du C, SSE n'est qu'une optimisation via le compilateur. J'avais pensé qu'il y avait des instructions au niveau du C, je me souviens sur PowerPC G5 avoir vu trainer des choses sur de l'utilisation d'instructions vectorielles (via le C) implémentées dans le FPU, mais ca ne concerne probablement pas les processeurs Intel et SSE ?

Je viens de jeter un coup d'oeil dessus, et en effet SSE ne concerne que l'assembleur.

Citation:

Envoyé par ZeMike

Une librairie Math comme MKL que j'utilise parfois ne résoudrait pas mon problème car je n'utilise pas une technique numérique particlière (FFT par exemple), ce sont vraiment mes équations et le nombre d'itérations qui sont en cause. Il faudrait peut-être que je vois pour passer mes équations en assembleur alors, mais j'ai du mal à situer quel gain de temps je peux avoir par rapport à du gcc ou du icc avec toutes options d'optimisation activées.

Il me semble que tu vas passer beaucoup plus de temps à réécrire tes équations en assembleur qu'à patiemment les optimiser. De plus, une fois que tu les auras réécrites, le code ne sera sûrement pas optimal, et tu seras bon pour une passe d'optimisation dans un langage plus bas niveau, donc moins compréhensible. Au final, tu vas passer beaucoup de temps pour faire aussi bien ou un peu mieux que ce que le compilateur fait de ton code C.

Une solution serait plutôt d'aller voir du côté de ces équations : peux-tu les réécrire différemment, pour que ce soit plus facile à calculer ?

Si tu peux passer ces équations en calculs massivement parallèles et que tu as vraiment besoin de performances (le gras n'est pas mis là pour faire joli), tu peux envisager de passer au GPGPU, mais il faudra alors que tu repenses entièrement tout tes algorithmes pour tirer profit de l'architecture plus spécifique des GPU. Comme l'assembleur, cela te prendra un temps fou, mais le résultat pourrait être meilleur que ce que l'assembleur te permettrait d'avoir (à condition que tu arrives à bien paralléliser tout ce qu'il faut, que tu gères bien la mémoire, etc.).
05/11/2009, 17h11
ZeMike

Hello,
l'écriture de mes équations est déjà optimisé (enfin raisonnablement, y'a rien qui soit calculé 2 fois par exemple). Ce que tu suggères est de passer à du calcul distribué, c'est bien çà ? L'aspect parallélisation j'ai déjà fait et ce code est facile à paralléliser. Je voulais simplement savoir si je pouvais optimiser le temps de calcul en utilisant par moi meme des technologies intégrées dans les processeurs, il semble que tout soit déjà fait par le compilateur.
Merci pour cet échange,
A+
Mike
05/11/2009, 18h43
dourouc05

Citation:

Envoyé par ZeMike

Ce que tu suggères est de passer à du calcul distribué, c'est bien çà ? L'aspect parallélisation j'ai déjà fait et ce code est facile à paralléliser. Je voulais simplement savoir si je pouvais optimiser le temps de calcul en utilisant par moi meme des technologies intégrées dans les processeurs, il semble que tout soit déjà fait par le compilateur.

Je parlais de GPGU, soit le calcul sur processeur graphique. Je ne sais pas ce que tu as chez toi, mais les premiers GPU à supporter NVIDIA CUDA (la solution GPGPU sauce NVIDIA) ont 240 coeurs, ce qui permet de faire 240 calculs simultanément (en gros). C'est pour ça que c'est très important que la tâche soit fortement parallélisable.

Concernant les CPU, le compilateur ne fait pas tout, loin de là, mais fait énormément de ce qui est possible. Il est toujours possible de faire mieux à la main, mais à grands renforts de temps et de maîtrise de l'assembleur du processeur cible. En général, les compilateurs qui donnent les meilleurs résultats sont ceux d'Intel, et il faut bien préciser quel type de processeur tu utilises pour qu'il puisse l'exploiter au maximum.

Aussi, si tu reposes sur certaines parties de la libc, tu es dépendant de leurs performances. Et l'implémentation n'est pas toujours idyllique.

Tu peux encore aider le compilo en ajoutant quelques mots-clés bien choisis : Les variables (FAQ C), par exemple. Il y a aussi les petites différences en i++ et ++i. Mais tout ça ne rapporte pas grand chose au final.

Dernière idée : si tes calculs n'occupent pas l'entièreté de chaque coeur, tu peux envisager de distribuer tes tâches dans les coeurs pour les remplir au maximum.
05/11/2009, 23h59
ZeMike

ok, je ne dispose pas de ce genre de chose mais j'ai vu que ca existait, notamment des choses comme Cuda et Open CL si j'ai bien tout suivi. Je suis surpris de "l'équivalence" qui est faite à 240 coeurs de calcul ... Mais je devrais pouvoir paralléliser jusqu'a ce niveau en particularisant un peu le code. Je vais garder cette idée dans un coin de ma tête, je reste surpris par le chiffre de 240 par rapport à un dual core d'intel par exemple.

Sinon actuellement, le shell m'indique que chaque coeur de mes 2 bixeon est pris à 100% par le calcul.

Merci encore, il va falloir que je regarde ce que l'on peut faire avec ces coeurs issus des cartes graphiques. Ca se programme en C ces choses la ? Il faut un compilateur spécial ?
06/11/2009, 15h38
dourouc05
Citation:

Envoyé par ZeMike

ok, je ne dispose pas de ce genre de chose mais j'ai vu que ca existait, notamment des choses comme Cuda et Open CL si j'ai bien tout suivi. Je suis surpris de "l'équivalence" qui est faite à 240 coeurs de calcul ... Mais je devrais pouvoir paralléliser jusqu'a ce niveau en particularisant un peu le code. Je vais garder cette idée dans un coin de ma tête, je reste surpris par le chiffre de 240 par rapport à un dual core d'intel par exemple.

Merci encore, il va falloir que je regarde ce que l'on peut faire avec ces coeurs issus des cartes graphiques. Ca se programme en C ces choses la ? Il faut un compilateur spécial ?

En général, il est dit qu'il est plus facile de coder avec CUDA, mais il n'est utilisable que sur des GPU NVIDIA. OpenCL est supporté plus généralement (NVIDIA pour Windows et Linux, tous les GPU pour OSX 10.6).

Un GPU est constitué d'énormément de coeurs, mais à plus faible fréquence (ils oscillent entre 500 Mhz et 1 Ghz). Un CPU a moins de coeurs mais plus rapides. Cela est voulu par l'utilisation principale du GPU (le calcul graphique).

OpenCL est un supplément au C, tout comme CUDA, mais CUDA supporte encore bien des avantages du C++ (tout sauf les avancées du modèle objet, à peu près). Tu dois utiliser un compilateur spécial, qui produit de l'assembleur pour le GPU (PTX chez NVIDIA), qui est assez différent de ce qui existe pour les CPU. Les compilateurs sont livrés avec les SDK (en tout cas chez NVIDIA). Si tu veux commencer le GPGPU avec CUDA, regarde ces quelques liens (en français) :