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

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

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?

> 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? ;-)

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.

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

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

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.

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.