Thread: fastest copy of structure elements

  1. #1
    Registered User
    Join Date
    Apr 2010
    Posts
    79

    fastest copy of structure elements

    Dear all,

    I am wondering if I understand well. In the structure below

    Code:
    struct chromosome{
     double genes[NUM_OF_GENES];
    };
    struct chromosome  old_chrome[NUM_OF_CHROMES],new_chrome[NUM_OF_CHROMES];
    old_chrome[NUM_OF_CHROMES] and new_chrome[NUM_OF_CHROMES]

    are pointing to two different point in memory where they allocate the space to store their instance of the type chromosome.

    Now if I want to copy the elements of the old_chrome to the new_chrome I can redirect the new_chrome to point to the same place in memory as the old_chrome

    So far I am doing this in a for loop:

    Code:
    for (i=0;i<NUM_OF_CHROMES;i++)
           {
             new_chrome[i]=old_chrome[i]; 
           }
    I would be really grateful of any comments on my understanding and moreover If their is a faster way (regarding the process time) to make such a copy.

    Thanks for your time in advance,
    Chris

  2. #2
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    Quote Originally Posted by Chris_1980 View Post
    Now if I want to copy the elements of the old_chrome to the new_chrome I can redirect the new_chrome to point to the same place in memory as the old_chrome
    You could do that with a pointer, but keep in mind that any change in the new will be reflected in the old.. (I don't think you'd want that.)

    Otherwise any way of copying will be linearly timed. (AFAIK)
    Using memcpy will probably give you a boost in performance.
    ( memcpy )

  3. #3
    Registered User
    Join Date
    Apr 2010
    Posts
    79
    Thanks for the quick reply. So after the "for loop" copy the new and old will write at the same point. As a result, if lets say the new_chrome[i].genes[i] is changed by some process after the "for loop", I ll not be able to retrieve the result of the process because by comparison they will be the same.

    Thanks again,
    Chris

  4. #4
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    Quote Originally Posted by Chris_1980 View Post
    Thanks for the quick reply. So after the "for loop" copy the new and old will write at the same point. As a result, if lets say the new_chrome[i].genes[i] is changed by some process after the "for loop", I ll not be able to retrieve the result of the process because by comparison they will be the same.

    Thanks again,
    Chris
    No..
    The old ones will be retained ...when you're copying with the loop.(or with memcpy)
    But if you attempt to circumvent the copying by :
    I can redirect the new_chrome to point to the same place in memory as the old_chrome
    you won't be able to retrieve the old data.

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    If you want to use an idiomatic C++ approach, the copy would be performed using "std::copy(old_chrome, old_chrome + NUM_OF_CHROMES, new_chrome)".

    As to performance compared to memcpy() .... In principle, when copying arrays of basic types (double, etc), std::copy() can be specialised to be as fast as possible. In practice, relative performance depends on quality of implementation of your compiler and library.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  6. #6
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    Quote Originally Posted by grumpy View Post
    If you want to use an idiomatic C++ approach, the copy would be performed using "std::copy(old_chrome, old_chrome + NUM_OF_CHROMES, new_chrome)".

    As to performance compared to memcpy() .... In principle, when copying arrays of basic types (double, etc), std::copy() can be specialised to be as fast as possible. In practice, relative performance depends on quality of implementation of your compiler and library.
    Gotcha ! .. Seeing me post, you thought this was the C++ forum !
    Btw.. can std::copy() do memcpy underneath when given plain arrays? How does it distinguish between an iterator and a pointer ?

  7. #7
    Registered User
    Join Date
    Apr 2010
    Posts
    79
    Again thanks to everybody. However I feel dummy because I cant understand this:
    After the for loop old_chrome[i] and new_chrome[i] point to the same place at the memory. Now (later in the code) if I change members of the new_chrome structure a number of N bytes after the place that both pointers are pointing at will change context.
    If now I try to use the old_chrome[i] pointer I will access what is written in these N bytes (by using the new chrome structure ) and not what was written before the changes. I mean that since what is written in this memory space is accessed by both pointers I cannot compare.
    If the case I tried to describe above is not true could you just give me some details of what I am missing

    Thanks for the time people,
    Chris

  8. #8
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    Quote Originally Posted by Chris_1980 View Post
    Again thanks to everybody. However I feel dummy because I cant understand this:
    After the for loop old_chrome[i] and new_chrome[i] point to the same place at the memory. Now (later in the code) if I change members of the new_chrome structure a number of N bytes after the place that both pointers are pointing at will change context.
    If now I try to use the old_chrome[i] pointer I will access what is written in these N bytes (by using the new chrome structure ) and not what was written before the changes. I mean that since what is written in this memory space is accessed by both pointers I cannot compare.
    If the case I tried to describe above is not true could you just give me some details of what I am missing

    Thanks for the time people,
    Chris
    After the for loop, they do NOT point to the same place, they merely have the same value. (at different places).
    That is what you would want... maintaining two different copies, independent from each other.
    As such the loop is okay and accomplishes what you want.

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by manasij7479 View Post
    Gotcha ! .. Seeing me post, you thought this was the C++ forum !
    Nope. I somehow mistakenly believed I was reading the C++ forum. My mistake, not caused by your post.

    Quote Originally Posted by manasij7479 View Post
    Btw.. can std::copy() do memcpy underneath when given plain arrays? How does it distinguish between an iterator and a pointer ?
    I wouldn't necessarily expect std::copy() to use memcpy(). However, as template instantiation occurs at compile time, the compiler can pick an "optimal" approach by some measure. What it produces may be equivalent to memcpy() .... or at least the instructions used by memcpy() if an array of some basic type is being copied.

    If an iterator is a pointer then, obviously, there is no way a compiler can distinguish between them. However, there is nothing that requires iterators to actually be pointers and, if they are different types, normal function overloading and template instantiation rules apply. std::copy() can also be explicitly specialised in some optimal manner for pointers to basic types - that sort of thing, if done, comes under what I was referring to as "quality of implementation".

    Anyway, better leave the C++ discussion until a thread in the C++ forum.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  10. #10
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    There is always a faster way, but it's not always something that you're going to want to use.
    I.e. you could go deep within the bowels of inline assembly and specify prefetching hints etc. This isn't likely to gain you huge improvements, but it will make a huge impact on the readability and maintainability of your code.

    If you want it faster then your first thought should be to work out how you can simply do less. I cant work that out for you from such a small code snippet.
    Your next thought should be can you reduce memory consumption and therefore increase throughput (I.e. do more with less). In this case switching from doubles to floats could improve the throughput and thus the speed. Better still, you may be able to switch to ints and use fixed-point. It all depends on how you are using the data.
    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"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. MPI_Scatter structure elements
    By Chris_1980 in forum C Programming
    Replies: 0
    Last Post: 06-30-2010, 04:46 AM
  2. giving value to structure elements
    By sarathius in forum C Programming
    Replies: 3
    Last Post: 04-21-2008, 01:24 AM
  3. How to compare structure elements
    By khpuce in forum C Programming
    Replies: 6
    Last Post: 04-10-2005, 11:40 AM
  4. Copy structure elements into byte array
    By irncty99 in forum C Programming
    Replies: 4
    Last Post: 03-15-2005, 01:58 PM
  5. fastest way to copy binary files...
    By Unregistered in forum C++ Programming
    Replies: 6
    Last Post: 06-24-2002, 12:55 PM