Discussion :

[ZeMike]

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

[dourouc05]

Salut,

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.

[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

[dourouc05]

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.

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.).

[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

[dourouc05]

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.