memory alignment uncertainties

memory alignment uncertainties

Following my initial experiments with the IPP I'd like to tie down some uncertainties about the default alignment of system memory allocation calls. I'm working in 32 bit windows.

1) malloc(). As far as I can tell, as it would not seem to be documented,the MS malloc will allocate using 16bit alignment.
Is that enough for all SIMD instructions?
In a separate thread I see

"currently we have just wrappers for C run time malloc/free, with adding allocation of aligned memory blocks...."

which implies that it isn't?
But when I look at the iPPiSample file ithas the function "void CIppiImage::AllocateData() " that appears to use "malloc()" to allocate bitmaps. So it doesn't use a wrapper? Is it "walking wounded"?
But on the other hand, the ProcessorPack for VS6 adds the aligned versions of malloc().
Someone please explain the apparent "contradictions".

2) CreateDibSection(). I have no idea how this might allocate memory for DIBs. Is is always safe to use it? [Somehow I imagine it must be or the graphics drivers would break even if the user code did no SIMD work?]

Dave Turnbull

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


1) It is better to use 16-bytes aligned memory blocks (or even 32-bytes aligned) just for performance reasons on modernprocessors. So, IPP does contains wrappers functions for malloc which do return aligned memory blocks. But it is possible to use even not aligned memory in IPP - only performance will suffer from it.

2) I belive it is safe to use memory allocated with CreateDIBSection call. If there were any problems with that - the world should definetely know about it already.


Leave a Comment

Please sign in to add a comment. Not a member? Join today