A Better MMX/SSE enabled memcpy ?

[Mutilated1]

I'm working with an imaging application that currently needs to load into memory at one time about 64 MB of images. Well due to some changes that are going to be made, the memory requirement is expected to increase eight to ten-fold.

Performance is already something of an issue, and is expected to get worse when the memory requirement increases.

My application I'm working with uses some legacy code that uses many unnecessary memcpy()s where copying a pointer would work just as well. I plan to change this at my first opportunity. I fully expect that this should solve most of the problem.

But because the memory requirement is going to change and I'm going to be processing 8-10x the amount of data in the near future I am looking for a way to get the most performance from the remaining unavoidable memcpy()s as I can. Profiling indicates that memcpy is responsible for the bulk of the time spent where my performance problems are most noticeable.

What I would like to do is locate an existing or create a new MMX/SSE enabled memcpy() function and allow my application to use it instead.

Do you know of any MMX/SSE enabled memcpy functions, or have any advice on how to implement one ?

Thanks for taking the time to read this and offer your advice.

[Hobson]

Hello

Here you can find 3 ways to optimize memcpy. Gain may be not as good as you except, but its worth to take a look.
You could also check here, especially links at the bottom.

Hob

[Mutilated1]

Thanks, thats what I'm using.

There is a performance improvement, and while you're right its not as great as I had hoped, unfortunately I will have to settle for whatever I can get.

Thanks!

[0xC0000005]

I, too, doubt that memcpy is slowing down your application. memcpy is already written in highly-optimized assembly language - the source code is supplied with Visual Studio in MEMCPY.ASM.

It's quite complex because it accounts for situations such as overlapping buffers, and also optimizes for speed by copying DWORDS rather than BYTES wherever possible.

I think that if you study this code you will find that as written it is very efficient and not worth changing.