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

Quote:

---

Originally Posted by Chris_1980

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 )

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

Quote:

---

Originally Posted by Chris_1980

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 :

Quote:

---

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.

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.

Quote:

---

Originally Posted by grumpy

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 ?

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

Quote:

---

Originally Posted by Chris_1980

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.

Quote:

---

Originally Posted by manasij7479

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

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.

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.