www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - copying memory in phobos

reply "Mike" <none none.com> writes:
I ran accross the following code in phobos std.array:

void trustedMemcopy(T[] dest, T[] src)  trusted
{
     assert(src.length == dest.length);
     if (!__ctfe)
         memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
     else
     {
         dest[] = src[];
     }
}

Why two different implementations for copying memory (i.e. memcpy 
vs. dest[] = src[])? Why not use dest[] = src[] exclusively.

Thanks for the help,
Mike
Apr 08 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Mike:


 Why two different implementations for copying memory (i.e. 
 memcpy vs. dest[] = src[])? Why not use dest[] = src[] 
 exclusively.


Because currently you can't use memcpy at compile-time.

Bye,
bearophile
Apr 08 2014
parent reply "Mike" <none none.com> writes:
On Tuesday, 8 April 2014 at 10:04:01 UTC, bearophile wrote:

 Mike:


 Why two different implementations for copying memory (i.e. 
 memcpy vs. dest[] = src[])? Why not use dest[] = src[] 
 exclusively.


 Because currently you can't use memcpy at compile-time.

 Bye,
 bearophile


I understand that.  But why is dest[] = src[] not good enough for 
run-time?
Apr 08 2014
parent reply "ketmar" <ketmar ketmar.no-ip.org> writes:
 I understand that.  But why is dest[] = src[] not good enough 
 for run-time?


'cause some compilers (gcc, for example) has memcpy() as 
'intrinsic' and generates better inline code for it sometimes. 
it's just a small hint for compiler backend, and faster code is 
good, isn't it? ;-)
Apr 08 2014
parent reply "Mike" <none none.com> writes:
On Tuesday, 8 April 2014 at 11:56:43 UTC, ketmar wrote:

 I understand that.  But why is dest[] = src[] not good enough 
 for run-time?


 'cause some compilers (gcc, for example) has memcpy() as 
 'intrinsic' and generates better inline code for it sometimes. 
 it's just a small hint for compiler backend, and faster code is 
 good, isn't it? ;-)


a[] = b[] causes the compiler to generate a call to _d_arraycopy, 
and _d_arraycopy calls, you guessed it, memcpy!  (verified with 
GDC 4.8.2)  So, there is no performance benefit calling memcpy 
directly.  It's going to be called anyway.

I'm beginning to believe that, at least in the code I posted, 
memcpy can be replaced by the array syntax, removing a dependency 
on the C library.
Apr 08 2014
next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 04/08/14 14:35, Mike wrote:

 On Tuesday, 8 April 2014 at 11:56:43 UTC, ketmar wrote:

 I understand that.  But why is dest[] = src[] not good enough for run-time?


 'cause some compilers (gcc, for example) has memcpy() as 'intrinsic' and
generates better inline code for it sometimes. it's just a small hint for
compiler backend, and faster code is good, isn't it? ;-)


 
 a[] = b[] causes the compiler to generate a call to _d_arraycopy, and
_d_arraycopy calls, you guessed it, memcpy!  (verified with GDC 4.8.2)  So,
there is no performance benefit calling memcpy directly.  It's going to be
called anyway.


'memcoy' being a built-in compiler intrinsic means that when the compiler
sees a 'memcpy' call, it does some checks (eg is the length statically
known and small enough?) and then can generated the copy instructions
directly, instead of calling the lib function.

artur
Apr 08 2014
parent reply "Mike" <none none.com> writes:
On Tuesday, 8 April 2014 at 14:59:35 UTC, Artur Skawina wrote:

 'memcoy' being a built-in compiler intrinsic means that when 
 the compiler
 sees a 'memcpy' call, it does some checks (eg is the length 
 statically
 known and small enough?) and then can generated the copy 
 instructions
 directly, instead of calling the lib function.


Then it could do such magic in the _d_arraycopy function where 
the call to memcpy exists.  I'm still not seeing the motivation 
behind putting this call to memcpy in Phobos.
Apr 09 2014
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 9 April 2014 at 08:24:55 UTC, Mike wrote:

 On Tuesday, 8 April 2014 at 14:59:35 UTC, Artur Skawina wrote:

 'memcoy' being a built-in compiler intrinsic means that when 
 the compiler
 sees a 'memcpy' call, it does some checks (eg is the length 
 statically
 known and small enough?) and then can generated the copy 
 instructions
 directly, instead of calling the lib function.


 Then it could do such magic in the _d_arraycopy function where 
 the call to memcpy exists.  I'm still not seeing the motivation 
 behind putting this call to memcpy in Phobos.


Depending on the type being copied, "a[] = b[]" is not straight 
up "memory copy" it's the actual full assignment, with postblit 
and all. That's why the call we want is *really* memcpy.

The code where you saw this, if I'm not mistaken, is 
"inPlaceInsert" or something of the like. The idea in this code 
is to actually *move* the data, not create *copies* elsewhere.

The array assign is a fallback for CTFE. It's fine in CTFE, 
because we don't care about performance, but it's not the actual 
call we want.
Apr 09 2014
prev sibling parent Mike Wey <mike-wey example.com> writes:
On 04/08/2014 02:35 PM, Mike wrote:

 On Tuesday, 8 April 2014 at 11:56:43 UTC, ketmar wrote:

 I understand that.  But why is dest[] = src[] not good enough for
 run-time?


 'cause some compilers (gcc, for example) has memcpy() as 'intrinsic'
 and generates better inline code for it sometimes. it's just a small
 hint for compiler backend, and faster code is good, isn't it? ;-)


 a[] = b[] causes the compiler to generate a call to _d_arraycopy, and
 _d_arraycopy calls, you guessed it, memcpy!  (verified with GDC 4.8.2)
 So, there is no performance benefit calling memcpy directly.  It's going
 to be called anyway.


_d_arraycopy does check if the source and destination are of equal 
length and that they don't overlap before calling memcpy.
Although i don't know how much that impacts the performance.


 I'm beginning to believe that, at least in the code I posted, memcpy can
 be replaced by the array syntax, removing a dependency on the C library.


-- 
Mike Wey
Apr 08 2014