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.