The latest version, IPP 7.0 does support Atom specific optimization, so you can expect performance improvement for JPEG operations (or resize) comparing with simple C implementation. As a one of common tips which can improve performance on modern processors is partitioning data in the way to get benefits from data locality (almost all modern processors can access data resided in cache much faster than from main memory). IPP functions do that trick inside and appllication may aslo would like to apply the similar technology on top of primitives. For example, let's consider the workload which use several IPP calls (color-conversion, data type conversion, some arithmetic operation and backward data type conversion)
1. big enough buffer with RGB image of Ipp8u data type 2. conversion of RGB to YUV with storing rresults in outputbuffer 3. conversion of Ipp8u to Ipp32f in order to apply some complicated math processing on data - again additional buffer with Ipp32f data 4. some arithmetic operations on 32f data 5. conversion back to Ipp8u data type
When implemented in naive way, just applying IPP functions step by step will introduce many intermediate buffers and as a result trashing data in processor cache at every single step
Recommended way is to process this by chucks (for example by slices) and by varying slice size it is always possible to find a particular chunk size which maximize the performance.
Please note that it is kind of general consideration. Certainly each case should be considered separately.
By the way, the next IPP update (7.0.2 which is coming soon) and will have some additional Atom optimization.
Could you please provide a little more details on resize RAW images? Do you mean RAW image format produced by some digital cameras?