topic Deprecated in place functions in Intel® Integrated Performance Primitives

Deprecated in place functions

Aviv_N_ — Tue, 24 Dec 2013 09:58:24 GMT

Hi all,

I'm have been using IPP for many years. Recently I have upgraded from v6.0 to v8.0, and now I have to deal with the deprecation issue announced in v7.1.

My problem is with the deprecated in place functions (Mainly in "ipps" but also in "Ippi"). It is unclear (I have searched for a long time) if it is safe (In terms of result correctness) to replace a deprecated in place function with an out of place function. The problem is that destination buffer is same as one of the source buffers so writing to the output while performing calculations maybe unsafe (In terms of result correctness).

Can any one help me with this? I need to replace a lot of code and I need to know if it is safe to replace an in place function with an out of place or do I have to write results into a different buffer?

Hi,

Igor_A_Intel — Tue, 24 Dec 2013 13:19:33 GMT

Hi,

in IPP 8.1 (will be available on the web on ww06 2014) deprecation message removed from all ipps in-place functionality (based on customers' feedback). The same is planned be done for ippi domain in the nearest future.

regards, Igor

Hi,

Simon_B_ — Sun, 29 Dec 2013 10:20:57 GMT

Hi,

It's always good to know if an inplace function is less efficient than non-inplace. maybe the option of having a compilation warning if a more efficient option or flavour is available.

Hi Simon,

Igor_A_Intel — Wed, 15 Jan 2014 11:00:31 GMT

Hi Simon,

it's difficult to say which version is more efficient - its always depends on a pipeline where some particular function is used. For simple pixel-wise operations (that don't require some pixel neighborhood) in most cases and sizes that fit into cache it doesn't matter either it is in-place operation. or out-of-place. If size is rather big and src+dst size is greater than L3 cache - I guess it's clear that in-place operation will be faster. For rather complex operations that require pixel neighborhood (for example any filtering operation) - the in-place operation can be implemented only via additional internal temporal buffer - so for sizes less than cache size in-place operation may be slower than out-of-place. So it depends on many factors, on particular pipeline and decision can't be done statically at compilation stage.

regards, Igor