> si c'est de l'allocation dynamique t'as intérêt à ce que ce soit aligné "de base".
C'est un bon exemple, puisque ce n'est pas le cas: sous linux, malloc renvoie des addresses alignées sur 8 bytes, pas sur 16, donc on a une chance sur deux d'avoir un buffer mal aligné (sous macos par contre malloc renvoie toujours un buffer bien aligné).
Maintenant il y a des situations où avec la meilleur volonté du monde, le compilateur ne peut pas savoir que les addresses qu'il recevra seront bien alignées. Si par ex. ma fonction saxpy fait partie d'une bibliothèque (qu'on pourrait appeler "blas" pour fixer les idées..), eh bien à ce moment que peut faire le compilateur ? gerer tous les cas ? (x bien aligné , mais pas y, x et y bien alignes, etc). Je crois que c'est ce que fait la lib http://math-atlas.sourceforge.net/ , mais ça me semble difficilement envisageable pour un compilateur sinon bonjour le bloat.
[^] # Re: Auto vectorisation
Posté par Troy McClure (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
C'est un bon exemple, puisque ce n'est pas le cas: sous linux, malloc renvoie des addresses alignées sur 8 bytes, pas sur 16, donc on a une chance sur deux d'avoir un buffer mal aligné (sous macos par contre malloc renvoie toujours un buffer bien aligné).
Maintenant il y a des situations où avec la meilleur volonté du monde, le compilateur ne peut pas savoir que les addresses qu'il recevra seront bien alignées. Si par ex. ma fonction saxpy fait partie d'une bibliothèque (qu'on pourrait appeler "blas" pour fixer les idées..), eh bien à ce moment que peut faire le compilateur ? gerer tous les cas ? (x bien aligné , mais pas y, x et y bien alignes, etc). Je crois que c'est ce que fait la lib http://math-atlas.sourceforge.net/ , mais ça me semble difficilement envisageable pour un compilateur sinon bonjour le bloat.