Thread: memcpy() or for loop? What's faster?

  1. #1
    Registered User
    Join Date
    May 2008
    Location
    Australia
    Posts
    230

    memcpy() or for loop? What's faster?

    Hi, I'm just wondering what would be a faster operation. I can either use a for loop like so:

    Code:
    char a[1024];
    char b[1024];
    
    for (int i = 0; i < 1024; i++)
       a[i] = b[i];
    Or, I can do it like so:

    memcpy(a, b, 1024);

    And if I needed to start at a certain position I can use an offset added to the address:

    memcpy(a, b+offset, 1024-offset);

    So, what would be faster? I'm also interested in WHY, so if you know fill me in .

    Thanks!
    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.

  2. #2
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    Probably memcpy(). If it's just simply implemented, it'll just be a for() loop. If there is some optimization, then it will probably have it.

    1) Use memcpy(), if that's what you're doing. Note that you can't do this for classes though -- you'll need std::copy(), since the class's copy constructor must be invoked.
    2) If you do a performace analysis and find that memcpy() is a bottleneck, only then think about optimizing it.
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  3. #3
    Registered User
    Join Date
    May 2008
    Location
    Australia
    Posts
    230
    Quote Originally Posted by Cactus_Hugger View Post
    Probably memcpy(). If it's just simply implemented, it'll just be a for() loop. If there is some optimization, then it will probably have it.

    1) Use memcpy(), if that's what you're doing. Note that you can't do this for classes though -- you'll need std::copy(), since the class's copy constructor must be invoked.
    2) If you do a performace analysis and find that memcpy() is a bottleneck, only then think about optimizing it.
    Thank you for your reply. Looks like I'll be sticking to memcpy then.
    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Do you know there is something wrong with your for loop?

    The for loop will simply copy the data one int at a time. A dumb implementation of memcpy will copy it one byte at a time. Even a smart implementation will begin with code to make sure the respective alignment of data is such that int copying can take place.

    memcpy() may or may not imply a function call.

    A smart compiler may be able to partially unroll the loop for maximal efficiency.

    A dumb programmer might mistakenly use memcpy() when they should have in fact used memmove() instead. This kind of bug can be hard to spot.

    The for loop will always "do the right thing" in a C++ program. As Cactus_Hugger points out, you have two methods of doing the same task, so at some point you're bound to make the wrong choice and not realise it (not immediately anyway).
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    The larch
    Join Date
    May 2006
    Posts
    3,573
    1) Use memcpy(), if that's what you're doing. Note that you can't do this for classes though -- you'll need std::copy(), since the class's copy constructor must be invoked.
    It is quite likely that your std::copy uses memcpy if the types (container and contained type) support it and a simple loop if not.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  6. #6
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Salem View Post
    Do you know there is something wrong with your for loop?
    OK, I'm a bit stumped. What's wrong with that for loop?
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by cpjust View Post
    OK, I'm a bit stumped. What's wrong with that for loop?
    The only thing wrong with that for-loop is that it has a hard-coded 1024 constant in there when it should be sizeof(a)/sizeof(a[0]) or other such similar element-counting macro, or a named constant which is also used in the array size declarations.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #8
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    Quote Originally Posted by cpjust View Post
    OK, I'm a bit stumped. What's wrong with that for loop?
    The whole "it does one thing and does it well" principle. Your function's job is not to copy objects/memory -- that's the job of std::copy or memcpy(). If there is optimization to be had, it should be done in those respective functions. Furthermore, both are shorter, codewise, and better show the intent of the code.
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  9. #9
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    When I said "wrong", I meant what is wrong with the performance of it which you hope that memcpy would magically fix for you?

    If you want better performance, then design a better algorithm that doesn't involve so much copying.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    The for loop will simply copy the data one int at a time.
    Those are char arrays. It will copy one byte at a time.

    A dumb programmer might mistakenly use memcpy() when they should have in fact used memmove() instead. This kind of bug can be hard to spot.

    The for loop will always "do the right thing" in a C++ program.
    The overlap issue of memcpy vs memmove is present when you code as a raw for loop, and just as hard to detect.

    memcpy might be a clearer way to express your intent. It really says, "copy the memory over there". Whereas the for loop says, "for each integer in this array, copy it to the same position in that other array", and it's up to the programmer to decode this to the same meaning as the memcpy.

    I say std::copy is the best solution, because it does the right thing in almost all situations (not if the end of of the source overlaps the beginning of the target), expresses intent clearly, and is well optimized by implementers.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 14
    Last Post: 06-28-2006, 01:58 AM
  2. memcpy() faster?
    By Yasir_Malik in forum C Programming
    Replies: 18
    Last Post: 04-13-2006, 12:15 AM
  3. Memcpy(); Errors...
    By Shamino in forum C++ Programming
    Replies: 4
    Last Post: 03-24-2006, 11:35 AM
  4. memcpy with 128 bit registers
    By grady in forum Linux Programming
    Replies: 2
    Last Post: 01-19-2004, 06:25 AM
  5. memcpy
    By doubleanti in forum C++ Programming
    Replies: 10
    Last Post: 02-28-2002, 04:44 PM