3 ms·

LOL, That's a fucking joke! "If the source and destination overlap, the behavior of memcpy_s is undefined." Wow, way to improve things microsuck! It's not li

LOL, That's a fucking joke! "If the source and destination overlap, the behavior of memcpy_s is undefined." Wow, way to improve things microsuck! It's not like anyone has ever mistakenly used memcpy on overlapping buffers....

deleted 13y ago
[deleted]
quotemstr 13y ago
You can use memmove_s, you know.
EpicEng 13y ago
The same is true for memcpy ya know... that's what memmove is for. Perhaps you should make sure you know what you're talking about before bashing others ("others" who are probably far more experienced than yourself).
- tedunangst 13y ago
  Eh, I believe that was his point. If you're going to go to the trouble of building a safe memcpy with no sharp corners, don't leave the overlapping buffer razor blade sticking out. Perhaps you should settle down.
  - EpicEng 13y ago
    Hmmm... well perhaps I did miss that, but your (his?) suggestion is a terrible idea. memcpy should be fast. Checking for overlap slows it down. Want to allow for overlap? Use memmove, that's what it's there for. I don't want to have to roll my own optimized version of memcpy when I know that I don't need any special handling or error checking.
    - 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 ago
        Am 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 ago
        this 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 ago
        I did say "should" :D

deleted 13y ago

[deleted]

quotemstr 13y ago

You can use memmove_s, you know.

EpicEng 13y ago

The same is true for memcpy ya know... that's what memmove is for. Perhaps you should make sure you know what you're talking about before bashing others ("others" who are probably far more experienced than yourself).

tedunangst 13y ago
Eh, I believe that was his point. If you're going to go to the trouble of building a safe memcpy with no sharp corners, don't leave the overlapping buffer razor blade sticking out. Perhaps you should settle down.
- EpicEng 13y ago
  Hmmm... well perhaps I did miss that, but your (his?) suggestion is a terrible idea. memcpy should be fast. Checking for overlap slows it down. Want to allow for overlap? Use memmove, that's what it's there for. I don't want to have to roll my own optimized version of memcpy when I know that I don't need any special handling or error checking.
  - 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 ago
      Am 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 ago
        this 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 ago
      I did say "should" :D