memory alignment uncertainties

Deleted_U_Intel — Tue, 03 Aug 2004 04:50:58 GMT

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?]

Thanks

Dave Turnbull

Re: memory alignment uncertainties

Vladimir_Dudnik — Tue, 03 Aug 2004 15:42:33 GMT

Hi,

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.

Regards,

Vladimir

topic Re: memory alignment uncertainties in Intel® Integrated Performance Primitives

memory alignment uncertainties

Re: memory alignment uncertainties