Discussion :

[progfou]

Bonjour tout le monde !
En lisant cet article :
http://www.osc.edu/hpc/manuals/ia64/...g/linux120.htm

Je suis tomb� sur cette phrase :

As an example, suppose that a function uses local variables i and j as subscripts into a 2-dimensional array. They might be declared as follows:

int i, j;

These variables are commonly used together. But they can fall in different cache lines, which could be detrimental to performance. You can instead declare them as follows:

__declspec(align(8)) struct { int i, j; } sub;

The compiler now ensures that they are allocated in the same cache line. In C++, you can omit the struct variable name (written as sub in the above example). In C, however, it is required, and you must write references to i and j as sub.i and sub.j.

Lorsque je n'appelle mes variables que i ou j, le compilateur me dit ne pas les conna�tre, et je suis oblig� d'�crire sub.i et sub.j.

O� est l'astuce ?
Merci d'avance !

[Charlemagne]

Je comprends pas vraiment ton probl�me.

Mais sache que les donn�es de la pile sont g�n�ralement align�es par les bons compilateurs, ce qui n'est g�n�ralement pas le cas des donn�es dynamiques allou�e avec 'new' ou 'malloc'.
Voici ce qu'en dit la doc de fftw (qui commence � dater).

On the Pentium and subsequent x86 processors, there is a substantial performance penalty if double-precision variables are not stored 8-byte aligned; a factor of two or more is not unusual. Unfortunately, the stack (the place that local variables and subroutine arguments live) is not guaranteed by the Intel ABI to be 8-byte aligned.

Recent versions of gcc (as well as most other compilers, we are told, such as Intel's, Metrowerks', and Microsoft's) are able to keep the stack 8-byte aligned; gcc does this by default (see -mpreferred-stack-boundary in the gcc documentation). If you are not certain whether your compiler maintains stack alignment by default, it is a good idea to make sure.

Unfortunately, gcc only preserves the stack alignment�as a result, if the stack starts off misaligned, it will always be misaligned, with a disastrous effect on performance (in double precision). To prevent this, FFTW includes hacks to align its own stack if necessary, so it should perform well even if you call it from a program with a misaligned stack. Currently, our hacks support gcc and the Intel C compiler; if you use another compiler you are on your own. Fortunately, recent versions of glibc (on GNU/Linux) provide a properly-aligned starting stack, but this was not the case with a number of older versions, and we are not certain of the situation on other operating systems. Hopefully, as time goes by this will become less of a concern.

[progfou]

Ca signifie que les allocations issues de new ne seront pas align�s, en tout cas, pas n�cessairement ?

[Charlemagne]

Et oui, malheureusement.
C'est con, mais c'est comme �a...
J'ai l'impression que tu n'as en fait qu'une chance sur 16 pour que 'new' renvoie une adresse align�e � 16 octets!

Voici mon impl�mentation d'une allocation align�e (et de l'allocateur correspondant) qui marche sous pas mal de syst�mes

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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
43
44
45
46
47
48
49
50
51
52
53
54
55
#if (defined(__ICL) || defined(_MSC_VER) || defined(__ICC))
  #include <fvec.h>
  inline void *aligned_malloc (size_t size, size_t align=16)  {  return _mm_malloc(size,align);  }
  inline void  aligned_free   (void *p)                       {  return _mm_free(p); }
#elif defined (__CYGWIN__)
  #include <xmmintrin.h>
  inline void *aligned_malloc (size_t size, size_t align=16)  {  return _mm_malloc(size,align);  }
  inline void  aligned_free   (void *p)                       {  return _mm_free(p); }
#elif defined(__MINGW32__)
  #include <malloc.h>
  inline void *aligned_malloc (size_t size, size_t align=16)  {  return __mingw_aligned_malloc(size,align);  }
  inline void  aligned_free   (void *p)                       {  return __mingw_aligned_free(p);             }
#elif defined(__FreeBSD__)
  #include <stdlib.h>
  inline void* aligned_malloc (size_t size, size_t align=16) {  return malloc(size); }
  inline void  aligned_free   (void *p)                      {  return free(p); }
#else 
  #include <malloc.h>
  inline void* aligned_malloc (size_t size, size_t align=16) {  return memalign(align,size); }
  inline void  aligned_free   (void *p)                      {  return free(p); }
#endif
 
 
template<class T, int N=16> class alignment_allocator
{
  public:
    typedef T value_type;
    typedef size_t size_type;
    typedef ptrdiff_t difference_type;
 
    typedef T* pointer;
    typedef const T* const_pointer;
 
    typedef T& reference;
    typedef const T& const_reference;
 
  public:
    inline alignment_allocator() throw() {}
    template <class T2> inline alignment_allocator(const alignment_allocator<T2,N>&) throw() {}
 
    inline ~alignment_allocator() throw() {}
 
    inline pointer       address(reference       r)       { return &r; }
    inline const_pointer address(const_reference r) const { return &r; }
 
    inline pointer allocate(size_type n) { return (pointer)aligned_malloc(n*sizeof(value_type),N); }
    inline void deallocate(pointer p, size_type) { aligned_free(p); }
 
    inline void construct (pointer p,const value_type& val)  { new (p) value_type(val); }
    inline void destroy   (pointer p                      )  { p->~value_type();         }
 
    inline size_type max_size() const throw() { return size_type(-1)/sizeof(value_type); }
 
    template<class T2> struct rebind { typedef alignment_allocator<T2,N> other; };
};

Il est envisageable de surcharger les d�finitions de 'new et 'delete'.

[loufoque]

Sur toutes les impl�mentations x86, new retourne une donn�e align�e sur 8 bytes il me semble...

[Charlemagne]

peut-�tre bien. J'ai jamais v�rifi�.
En tout cas ce n'est pas align� sur 16 octets en r�gle g�n�rale.

[loufoque]

Normal, il n'y a pas besoin d'aligner sur 16 octets.

C'est uniquement utile pour les instructions vectoris�es, qui ne sont pas g�r�es par le C++ standard.

[Charlemagne]

Et alors, je disais bien que 'new' n'alignait pas les adresses sur 16 octets.
Qu'il aligne sur 8 ou sur 1 octet, on s'en moque.
Progfou attendait une solution pour les aligner sur 16. Tu veux en proposer une?

[loufoque]

Et tu lis �a o� ?
Il demande uniquement de l'alignement sur 8 octets.

[Charlemagne]

OK, j'avais suppos� 16 car j'ai l'habitude d'utiliser les instructions vectorielles.
Effectivement je vois pas trop l'int�r�t de mettre des instructions suppl�mentaires pour aligner sur 8 octets, a fortiori si, comme tu le dis, le compilo le fait d�j�.
Qu'il se r�f�re � la doc de fftw que je site plus haut, c'est ce que j'ai de plus clair sur les questions d'alignement.