2010-04-12 6 views
0

Mon professeur a découvert cette expérience intéressante de convolution de noyau 3D linéairement séparable en utilisant SSE et OpenMP, et m'a donné la tâche de comparer les statistiques sur notre système. L'auteur revendique une accélération folle de 18 fois de l'approche en série! Peut-être pas toujours, mais nous attendions au moins 2 à 4 fois plus de temps sur un Intel Dual Core.OpenMP + SSE ne donne aucune accélération

http://software.intel.com/en-us/articles/16bit-3d-convolution-sse4openmp-implementation-on-penryn-cpu/#comment-41994

Hélas, nous avons pu trouver exactement pas speedup. Le code série fonctionne toujours mieux, avec ou sans OpenMP. J'utilise Linux, et j'ai observé une certaine tendance ... quand aucun autre processus n'est en cours d'exécution sur le système, après un certain temps, le loadavg commence à augmenter, et l'utilisation du% CPU tombe.

Un autre faux positif probable que j'ai rencontré accidentellement ... J'ai démarré le programme, puis immédiatement mis en pause. Ensuite, j'ai couru sur fond avec bg, et j'ai vu une accélération de plus de 2. Cela arrive tout le temps!

Tout conseil serait génial.

Merci, Sayan

+2

Etes-vous sûr que votre vitesse de processeur est le goulot d'étranglement? – Mene

+1

Désolé d'exclure une partie essentielle. J'envoie juste deux choses au programme, le XYZSize et le nombre de fois que le programme devrait fonctionner. Donc sur un dual core avec 4 Go de RAM, si je passe 1024X1024x1024 pour des valeurs entières, la limite de 4 Go est atteinte. Peut-être est-ce la raison pour laquelle la chose étrange se produit avec le% CPU et l'augmentation de loadavg. Mais même pour des valeurs plus petites, comme 16,32,64 ou 256 (le programme accepte XYZSize en multiples de 8), il n'y a absolument aucune accélération. –

Répondre

2

Vous avez vraiment besoin de profiler votre programme pour identifier les goulots d'étranglement. Vous devez également regarder l'optimisation d'une manière plus «holistique». Vos problèmes de performances peuvent être liés à une conception médiocre, à un codage médiocre, à des limitations de bande passante mémoire et à une foule d'autres problèmes, qui ne seront pas traités par des micro-optimisations telles que SIMD au lieu du code scalaire. Commencez avec un profil (utilisez un outil comme Zoom pour cela) et travaillez à partir de là.

0

Eh bien, j'ai tâtonné un peu, puis essayé ce qui suit: J'ai compilé le programme en utilisant l'option -O0 (pas d'optimisation) et obtenu une accélération de 2 presque pour presque toutes les valeurs XYZ. Je pourrais aussi voir que 2 threads sont utilisés sur mon dual core (auparavant, il n'en utilisait qu'un seul). Mais maintenant, quand je supprime les pragmas OpenMP, je ne pouvais voir aucune accélération, cela me dérange, car SSE devrait être en mesure d'accélérer considérablement les choses. Donc, cette accélération pourrait être entièrement attribuée à OpenMP, il faut savoir pourquoi SSE échoue. Quelqu'un m'avait dit que si les opérations sont triviales (peut-être le poids que ce mot met en avant est discutable car il diffère d'une personne à l'autre), en utilisant SSE garners aucune accélération. Mais j'ai écrit un petit programme, qui calcule sqrt (i)/i pour i_max_size = 64000 ..... et la version SSE a donné une accélération de 3.5 ~ 4.0. Je publierais plus après, une fois que j'ai trouvé la cause première.

+0

Eh bien, j'ai en quelque sorte eu la raison. Il existe un commutateur de compilation -fmpmath = unité qui décide si les calculs à virgule flottante seront transformés en sse ou en i387. Pour les machines x86, il est configuré par défaut sur sse. http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02119.html –