   Alignment issues in VS debug mode
  Hello,first the code then the question :)__declspec( align(16) ) class Vector3{public:float x, y, z, _pad;...methods...}class Camera{...various members...Vector3 mPos;Vector3 mLook;Vector3 mRight;Vector3 mUp;....}Now, printing the addresses of the Vector3 variables in one instance of the class camera they are correctly 16 bytes aligned IF i'm not debugging.If i'm debugging they are not 16 byte aligned and consequently all the code that use SSE instructions that assumes that we have 16 bytes alignment (like movaps) FAILS...clearly.IS there a reason why visual studio don't align the Vector3 members to a 16 byte boundary when i debug?PS: the problem happens NOT when i'm in debug mode but when i debugging both in Debug/Release mode.Thanks a lot,David   
  How are you allocating Camera? If it's part of array, or a single instance, then you need aligned malloc. If allocated on stack, it might not be properly aligned either.For this reason, SIMD is preferably used for processing large number of elements, so that data can be managed and processed in bulk, often in SoA arrangement.   ;  PS: the instance of Camera is dinamically allocated using the operator new.Maybe thats the problem. The operator new in fact allocates without concerning about alignments...And consequently even if i declared the class Vector3 to be 16 byte aligned it will be not aligned inside the dinamic allocated memory.So what i have to do? I have to allocate all the dynamic objects that uses Vector3 using _aligned_malloc? And organize the Vector3 variables inside such classes in a way that they are poperly aligned manually?in the example that i wrote in the previous post, if I do:Camera* pCamera = (Camera*)_aligned_malloc(sizeof(Camera))it should work but now everyone that uses my math library have to do such things?!?! it's not very practical...Plus the Vector3 members in every class that uses them have to be organized in a way that are 16bytes alignedfor example:if i declare a class likeclass Vector3User{int i = 0;Vector3 mVec;}Vector3User* ptr = (Vector3User*)_aligned_malloc(sizeof(Vector3User))it will not work anyway because mVec will be not aligned anyway...There is not a simple way use a 16byte aligned class?Thanks a lot I'm desperate :)))   ;  There's a bunch of people going about, screaming about stuff like "OO sucks". They are the ones who have to worry about alignment and similar issues.There is also a reason why C (or C with classes) is still preferred over modern C++ in some contexts.I assume you have thoroughly read and understood this, or equivalent for the compiler of your choice. A very brute force solution to the problem is /Zp16, but that may waste a lot of memory.Quote:the instance of Camera is dinamically allocated using the operator new.Maybe thats the problem.Yes, it is. only aligned_malloc provides custom alignment guarantees.Quote:Camera* pCamera = (Camera*)_aligned_malloc(sizeof(Camera))But camera is not a POD, which means that the above does not invoke constructor.Quote:Plus the Vector3 members in every class that uses them have to be organized in a way that are 16bytes alignedYes. Hence the SoA, arrays and heap alignment. Aligning members is a pain and wastes memory. SIMD is "single operation, multiple data", so it works best when single operation is applied to as many values as possible.Quote:but now everyone that uses my math library have to do such thingsWhy are you writing your own math library, when there are SIMD-capable ones out there? Have you at least considered looking at their design choices?   ;  Malloc or new will return an address aligned to a 4-byte boundary (because we're on a 32-bit system), not in a 64-bit system.The __declspec is only guarantying you the data inside Camera is 16 byte aligned assuming the starting address of Camera is also 16-byte aligned. If you create it with malloc (or new) instead of using the stack, you lose that assumption.If you're just starting with your application, I suggest to use a specially overloaded new operator://Pair 1void* operator new (size_t size, size_t alignment ) throw(...){void *p = _aligned_malloc( size, alignment );if( !p )throw std::bad_alloc();return p;}void operator delete (void *ptr, size_t alignment ) throw(...){_aligned_free( ptr );}//Pair 2void* operator new( size_t size, const std::nothrow_t&, size_t alignment ) throw() // pair 2{void *p = _aligned_malloc( size, alignment );return p;}void operator delete (void *ptr, const std::nothrow_t&, size_t alignment ) throw(){_aligned_free( ptr );}//Pair 3void* operator new [] (size_t size, size_t alignment) throw(...){void *p = _aligned_malloc( size, alignment );if( !p )throw std::bad_alloc();return p;}void operator delete [] (void *ptr, size_t alignment ) throw(...){_aligned_free( ptr );}//Pair 4void* operator new [] ( size_t size, const std::nothrow_t&, size_t alignment ) throw(){void *p = _aligned_malloc( size, alignment );return p;}void operator delete [] (void *ptr, const std::nothrow_t&, size_t alignment ) throw(){_aligned_free( ptr );}Then to use it://#define new new(16) \   Use this to force _all_ new's//#define delete delete(16) \   Use this to force _all_ delete's#define aligned_new new(16)#define aligned_delete delete(16)Camera *camera = aligned_new Camera();aligned_delete camera;That should work (I haven't tested it thoroughly).You can also force "new" to use 16 byte too. This is useful if you're using the STL library (std::vector, std::list, etc) with SIMD dataNever mix aligned_delete with delete.More info on overloading new operator:http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=40http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=379http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=380CheersDark SylincEdits: Added aligned_delete and some more explanations   