Faire Vectoriser une boucle avec icpc

La vectorisation automatique, ca fait des années que le sgens bossent dessus et c'ets tout sauf trivial. La plupart des problèmes viennent du faites que cette passe d'optimsiation est faite sur le representation intermedaire du code. Or, arrivez la, on a perdu trop d'info le plus souvent.

Dans NT² on a résolu la chose en fournissant des briques de bases vectorisée au niveau fonction. Ensuite soit tu arrives a t'en sortir via les matrix basées sur des Expression Tempaltes, soit t'as une formalisation générique de vecteur SIMD que tu peux manipuler de manière tarnsparente.

En tout cas, penser que le compilo peut tout, c'ets assez optimiste :s

Citation:

---

Envoyé par Joel F

En tout cas, penser que le compilo peut tout, c'ets assez optimiste :s

---

Il est bien capable de le faire pour le Fortran, pourquoi pas pour le C++ sachant que c'est le même backend ?

Citation:

---

Envoyé par Matthieu Brucher

Il est bien capable de le faire pour le Fortran, pourquoi pas pour le C++ sachant que c'est le même backend ?

---

Le fortran a une notion de array natif qui transparait dans le RI (je pense).
A pres, ca fait longtemps mais, de tete, me semble que la gestion de la mémoire du FORTRAN evite assez bien les aliasing foireux.

Citation:

---

Envoyé par Joel F

Le fortran a une notion de array natif qui transparait dans le RI (je pense).
A pres, ca fait longtemps mais, de tete, me semble que la gestion de la mémoire du FORTRAN evite assez bien les aliasing foireux.

---

C'est même plus fort que ça, la norme interdit l'aliasing entre arrays. Ce qui permet ainsi de très souvent vectoriser sans se poser de questions, dès que les conditions sont réunies.

Citation:

---

Envoyé par reptils

C'est même plus fort que ça, la norme interdit l'aliasing entre arrays. Ce qui permet ainsi de très souvent vectoriser sans se poser de questions, dès que les conditions sont réunies.

---

Et normalement, le restrict permet d'être dans les mêmes conditions en C/C++.

il y a quant même une nette différence entre un comportement natif pour le Fortran et une interprétation de Template/inline/restrict pour le C++... la preuve c'est que si c'était aussi simple, il arriverait à me vectoriser ce truc :cry:

Citation:

---

Envoyé par reptils

il y a quant même une nette différence entre un comportement natif pour le Fortran et une interprétation de Template/inline/restrict pour le C++... la preuve c'est que si c'était aussi simple, il arriverait à me vectoriser ce truc :cry:

---

c'est exactement ça.

Citation:

---

Envoyé par JolyLoic

Détrompes toi... Après tous, c'est plus dans les domaines scientifiques que par exemple dans la gestion qu'on a besoin des perfs que peut apporter le C++.

Pas mal de contributeurs au standard sont liés à des universités ou à des labos (fermilab par exemple). Ils n'ont peut-être pas le même poids que les fabricants de compilateurs ou de bibliothèques standard, mais parmi les représentants des utilisateurs, ce sont probablement les plus nombreux.

Et depuis peu, il y a au sein du comité de normalisation une groupe d'intérêt autour du calcul scientifique qui s'est formé, avec comme but de promouvoir des modifications du langage ou des bibliothèques standard dans ce sens. Par contre, ce groupe étant récent, je ne crois pas qu'il ait eu des impacts concrets. .

---

Intéressant.
Mais dans ce cas comment interpréter l'absence de restrict en C++0x ?

Restict est pourtant mandaté par le C99, déjà implémenté par tous les compilos C++ de l'univers, et, d'après ce que j'ai pu comprendre de certains post sur ce forum, c'est un pré-réquis majeur pour pouvoir faire du calcul numérique sérieux en C++ ?

Citation:

---

Envoyé par reptils

il y a quant même une nette différence entre un comportement natif pour le Fortran et une interprétation de Template/inline/restrict pour le C++... la preuve c'est que si c'était aussi simple, il arriverait à me vectoriser ce truc :cry:

---

Pas dans mon esprit si on se base sur l'arbre créé par le front end. Il reste sans doute dedans des éléments qui n'ont pas lieu d'être dans notre cas.

Bon...
j'ai trouvé une partie de la réponse. Déjà si on rajoute dans la ligne de compile -ansi-alias, les choses se passent beaucoup mieux.

Un truc du style:

Code:

---

1 2 3

for(i=min;i<=max;++i) array_copy(i)=2*array(i)+1;

---

se vectorise.
Et un truc du style:

Code:

---

1 2 3

for(i=min;i<=max;++i) array_copy(i)=array(i);

---

Est interprété en _intel_fast_memcpy.

Maintenant je suis tenté de monter en complexité pour si on peut faire des choses plus complexes en 3D...

Je pensais que l'option était activée par défaut... C'est dingue parce que ce sont tout de même les règles du langage !

la réponse à ta se trouve dans ce que m'a livré un boss de intel:

Citation:

---

-ansi-alias informs the compiler that it should assume your program doesn't violate the standard typed aliasing rules. It's the same as gcc -fstrict-aliasing, which is a default for gcc. It means that you would not require restrict keyword when there are no 2 pointers of compatible type in parameter list, and also permits optimization of operations on arrays of arrays a[][].
Presumably, the reason for not setting it as a default is that one major Windows compiler doesn't perform optimizations based on the aliasing rules.

---

OK, je vois. Effectivement, c'est le type aliasing que je considérai comme actif par défaut car il y a eu plusieurs articles sur le sujet. Ca m'apprendra à mieux regarder les arguments qu'on peut placer, et c'est quelque chose que je vais m'assurer d'avoir mis dans mes codes lundi matin !

petite question:
du coup je veux tester la montée en puissance de mon merdier...

en fait ce je souhaite faire c'est définir un template de plus pour les classes Array_2d ou Array_3d:

Code:

---

1 2 3 4 5 6

template<class T, class Order> class Array_2d { .... };

---

je sais qu'on ne peut pas faire spécialisation partielle de méthodes, mais j'aimerais un operator() qui agisse en fonction de mon paramètre template Order qui peut être C_Order ou F_Order des structures vides mais qui permettent de différentier le comportement pour avoir la contiguité en i ou j.

Je ne vois pas comment faire?

fais du tag dispatching

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

struct col_major {}; struct row_major {};   template<class T, class Order> class Array_2d { public:   value_type& operator()(int r, int c) { return access(r,c,Order()); }   value_type operator()(int r, int c) const { return access(r,c,Order()); }   private:   value_type& access(int r,int c, col_major const&) { return /* code column major */; }   value_type& access(int r,int c, row_major const&) { return /* code row major */; }   value_type access(int r,int c, col_major const&) const { return /* code column major */; }   value_type access(int r,int c, row_major const&) const { return /* code row major */; } };

---

Ca ou du SFINAE ? J'aime bien utiliser un enable_if dans un cas pareil.

Ce n'est pas vraiment son cas d'utilisation primordiale, la tu veut dispatcher du code, pas prunner des surcharges invaldies. En plus, le SFINAE ne prends pas dans le cas de méthode d'instance templates si il porte seulement sur les paramètres de la classes en elle même.

Le Tag Dispatching n'a de toute façon aucun impact au runtime, tout étant résolu et inliné à la compilation.

Citation:

---

Envoyé par Joel F

fais du tag dispatching

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

struct col_major {}; struct row_major {};   template<class T, class Order> class Array_2d { public:   value_type& operator()(int r, int c) { return access(r,c,Order()); }   value_type operator()(int r, int c) const { return access(r,c,Order()); }   private:   value_type& access(int r,int c, col_major const&) { return /* code column major */; }   value_type& access(int r,int c, row_major const&) { return /* code row major */; }   value_type access(int r,int c, col_major const&) const { return /* code column major */; }   value_type access(int r,int c, row_major const&) const { return /* code row major */; } };

---

---

ça me semble bien ça... je vais tester et voir si le compilo s'en sort et arrive à me vectoriser mes expression avec cette micro sur-couche, sinon j'imposerai le fortran style.

Merci Joel.