3 ms·
"memcpy should be fast" you know memcpy is my 'classical' example of why you should never trust library code to be well optimised. its almost always a dumbass
by jheriko 13y ago
"memcpy should be fast"
you know memcpy is my 'classical' example of why you should never trust library code to be well optimised. its almost always a dumbass byte-by-byte copy - its pretty much the worst case performance unless you go out of your way to slow down your implementation.
the speed improvement from good register usage and appropriate cache hints was >35% the last time i had to do this (iirc against the VS 2008 implementation)
MS provided a special memcpy variant for 360 that did this for you using the PPC dcb* instructions and good use of the wider registers.
- eliasmacpherson 13y agoAm gobsmacked by the differences in benchmarks: http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_memory_quickly#Benchmarkresultsndashcompiledwithoptimizations http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_... http://software.intel.com/en-us/articles/memcpy-performance http://software.intel.com/en-us/articles/memcpy-performance
- jheriko 13y agothis looks pretty recent, good to know that memcpy is improving (maybe). i suspect the reason icc is winning so hard is exactly what i mention - cache hints and good register usage. the things is that stuff isn't new... its much more than 10 years old now. no memcpy implementation has an excuse to be that slow under any compiler imo. i'd imagine the intel guys will make use of this stuff because its why they put it in the hardware to start with... :) incidentally, as a complete tangent, really great bunch of guys to work with if you get the chance - at least in my experience. a definite passion for and focus on performance in a serious way. :)
- EpicEng 13y agoI did say "should" :D