It seems to me that your code copies from one memory destination to another one.

There is no calculation or anything else. I think I heard that the speed of copy actions can't be improved by SSE very much.

What task do you want to achieve? Is it only copying?

Depending on the context, you should consider adding restrict qualifier (BYTE *restrict...) and aligning the destination. This might be done more efficiently with SSE4.1 or AVX, but might still require.#pragma vector always.  If the loop is long enough or being executed by enough threads to take advantage of nontemporal store, you would need to so specify e.g. #pragma vector aligned nontemporal

>>...
>>The speed just improve a little bit. Where are things going wrong?...
>>
>>int n;
>>__m128i tmp;
>>for ( n=0; n >>{
>> tmp = _mm_load_si128( ( __m128i * )pY );
>> _mm_store_si128( ( __m128i * )pD, tmp );
>> pD+=32;
>>pY+=16;
>>pU+=8;
>>pV+=8;
>>}

Here are a couple of notes:

- If your data set is greater than 256KB a data prefetching, if properly applied (!), could improve performance ( please see Intel Software Optimization Manual )
- Verify in a Debugger that a C++ operator ( __m128i * ) is not used when passing pointers to data for intrinsic functions
- Usage of another pair of intrinsic functions _mm_stream_ps and _mm_load_ps could outperform your current SSE implementation

>>...I heard that the speed of copy actions can't be improved by SSE very much...

I'll give you a number and it is ~9%. Is it significant or not? I think that for real-time applications even a 0.5% improvement could be considered as a very good thing ( sorry for a small deviation... ).

Please take a look at some recent results which demonstrate how a correct application of _mm_prefetch improves performance of copy operations: http://software.intel.com/en-us/forums/topic/352880

>>>I'll give you a number and it is ~9%. Is it significant or not? I think that for real-time applications even a 0.5% improvement could be considered as a very good thing ( sorry for a small deviation... ).>>>

Yes for example in video rendering.

Цитата:

Sergey Kostrov wrote:

>>...I heard that the speed of copy actions can't be improved by SSE very much...

I'll give you a number and it is ~9%. Is it significant or not? I think that for real-time applications even a 0.5% improvement could be considered as a very good thing ( sorry for a small deviation... ).

Please take a look at some recent results which demonstrate how a correct application of _mm_prefetch improves performance of copy operations: http://software.intel.com/en-us/forums/topic/352880

Ah this is quite interesting, I did not know about the prefetch operations and that the improve performance.

With "not very much" I referred to SSE SpeedUp of 2 or 4 (double of float) which most of the time can only be reached if computations are involved.

Hi Christian,

>>...Ah this is quite interesting, I did not know about the prefetch operations and that the improve performance...

Please take a look at Intel Software Optimization Manual if interested to learn more about it ( there a couple of really good examples with prefetch instruction ).

Best regards,
Sergey

>>tried prefetch but no obvious improvement. Checked the asm code generated there are only two statements of
>>load and store. no problem. By replacing _mm_store_si128 to _mm_stream_si128 I watched 0.5% improvement.

Thanks for these details. A 0.5% improvement actually matches to my old numbers when I didn't use prefetch properly. Here are a couple of more tips:

- Do you have April 2012 edition of Intel 64 and IA-32 Architectures Optimization Reference Manual? I wonder if you looked at Chapter 7 'Optimizing Cache Usage'?
- Warm your data before processing ( it is a very simple procedure )

A small example that demonstrates how _mm_prefetch could be used ( take into account sizes of L1, L2 and L3 cache lines of your CPU ) is as follows:
...
// Some initializations
...
RTint iPageSize = 4096;
RTint iCacheLineSize = 32;
...
for( RTint i = 0; i < iNumOfBytes; i += iPageSize )
{
RTint j;

for( j = i + iCacheLineSize; j < ( i + iPageSize ); j += iCacheLineSize )
{
_mm_prefetch( ( RTchar * )pvSrc + j, _MM_HINT_NTA );
}
...
// Processing of some data
...
}
...

Note: A 9% improvement was achieved when copying a data set of ~1MB in size

On Sandy Bridge or Ivy Bridge, AVX nontemporal doesn't necessarily accelerate an application beyond 128-bit nontemporal.  Cache lines remain at 64 bytes.  If you have optimized code which depends on store bandwidth for earlier architecture, it may be sufficient for Sandy Bridge.

>>...Intel may be better to present developers the cycle number for each instruction of a processor in different conditions.
>>So software developers can estimated what code clips can be optimized. For example, the cycle number of
>>MOVNTDQA in L1 cache, L2 cache, L3 cache, in DDR3, .etc.

Absolutely agree with that point of view and Intel published clock cycle numbers for many instructions. However, some instructions are not on the list. It looks like MOVNTDQA is not on the list ( please correct me if it is not true ).

Цитата:

Sergey Kostrov wrote:

>>...Intel may be better to present developers the cycle number for each instruction of a processor in different conditions.
>>So software developers can estimated what code clips can be optimized. For example, the cycle number of
>>MOVNTDQA in L1 cache, L2 cache, L3 cache, in DDR3, .etc.

Absolutely agree with that point of view and Intel published clock cycle numbers for many instructions. However, some instructions are not on the list. It looks like MOVNTDQA is not on the list ( please correct me if it is not true ).

Agner's CPU documentation also has plenty information about the instructions cpi.

By the way, Intel IPP library has a set of highly optimized functions for convertion of a RGB image to and from an YUV format image. Take a look at ippiYUVToRGB_xx_xxx functions if interested.

>>>C language can not bring true optimization in some cases>>>

Yes that's true.I think that true optimization can be achieved with the help of assembly language or inline assembly.C still lacks some some features which can be easily achieved with the machine code.

>>...I solved the problem...

Thanks for the update. I see that when it comes to the performance several techniques / tricks can be combined, like code optimization(s) ( unrolling ), application of new sets of SIMD instructions and correct usage of L1, L2 and L3 cache lines of some CPU ( ideally a 3-layred Loop Blocking optimization technique has to be used but it gets really complicated in a multi-threaded environment ).