speed of low-level C funcs: example of memmove

[Cliff Hudson]

If you take a look at the implementation of memmove (grab the std C lib
source) you'll see a rather optimized assembly loop which is very smart
about doing machine-word aligned moves, and using processor block-copy
instructions.  I suspect that is the reason you see the difference.  For
smaller data sets, you won't see as much gain, if any, because it can't take
advantage of those other semantics to the same degree.

- Cliff

On Sat, Apr 9, 2011 at 10:17 AM, spir <denis.spir at gmail.com> wrote:

> On 04/09/2011 07:08 PM, spir wrote:
>
>> Hello,
>>
>> To insert of delete an array slice, I tried to use C's memmove, thinking
>> it
>> would be far faster than "manually" copying bit per bit (by any kind of
>> magic).
>> But I still wrote a D versions just to check what the actual speed gain
>> is. To
>> my great surprise, the C-memmove and D-manual versions perform *exactly*
>> at the
>> same speed (considering measure imprecision).
>> Note: this remains true when elements are bigger; speed slows down slowly
>> (eg
>> dchar's take only 1/3 more time).
>>
>
> Correction: memmove can be from 5 to 10 times faster on big arrays. For
> instance, with 1_000_000 char array:
>
>
> void chrono () {
>    char[] s;
>    d_time t;
>    enum N = 100;
>
>    // C memmove
>    s = ("0".mult(1_000_000)).dup;
>
>    t = getUTCtime();
>    foreach (_ ; 0..N) {
>        s.shiftEndPartC(3,5);
>        s[3..5] = "--";
>        s.shiftEndPartC(5,3);
>    }
>    t = getUTCtime() - t;
>    writefln("C time: %s", t);
>
>    // D manual
>    s = ("0".mult(1_000_000)).dup;
>
>    t = getUTCtime();
>    foreach (_ ; 0..N) {
>    s.shiftEndPartD(3,5);
>    s[3..5] = "--";
>    s.shiftEndPartD(5,3);
>    }
>    t = getUTCtime() - t;
>    writefln("D time: %s", t);
> }
>
> --
> _________________
> vita es estrany
> spir.wikidot.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20110409/44dabc53/attachment.html>