• Dmitry Olshansky (37/37) Oct 26 2012 Finally got to this: http://d.puremagic.com/issues/show_bug.cgi?id=8349
• Damian (6/45) Oct 26 2012 These should definitely be put into the language!! but they'd

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

Finally got to this: http://d.puremagic.com/issues/show_bug.cgi?id=8349

Half way through it become obvious to me that we'll have similar 
problems with memcpy and it's ilk every time somebody optimizes bit-wise 
copy/move/find.

More then that I think that we lack a specific set of low-level 
functions that cover all of C's mem* functionality.
(The focus is on fast primitives.)

Currently there are obvious gaps:
memset ---> cast(ubyte[]) + array ops
memcpy ---> cast(ubyte[]) + array ops (also breaks with overlap)
...so far so good...
memmove ---> ???
memchr ---> cast(ubyte[]) + std.algorithm.find is *not* good enough

(in fact std.algorithm.find arguably could use memchr to greatly 
optimize some specializations (!) )

Why don't we just use C's ones?
a) CTFE-ability, alternatively we can just hard wire all of common libc 
functions into CTFE
b) more generality and/or flexibility, e.g. despite it's speed memchr 
can't search for ushort or uint
c) safer, as it would operate on slices of _typed_ arrays, not pointer + 
number of _bytes_

So I propose the following set of low-level tools for inclusion into 
Phobos or druntime:

 system:
//bitblit, doesn't call destructors/postblits
//also can be used to forcibly move structs
void rawCopy(T)(const(T) src, T dest);

//same, but also works with overlapped memory chunks
void rawTransfer(T)(const(T) src, T dest);

//fast search, bitwise comparison only
void rawFind(T)(const(T)[] src, const(T) needle);

Well the above is a sketch. Maybe I'm digging in the wrong direction and 
this stuff just needs to be somewhere among compiler's intrinsics.
(so that it can do some magic if the size is known in advance etc.)

-- 
Dmitry Olshansky

"Damian" <damianroyday gmail.com> writes:

On Friday, 26 October 2012 at 21:25:22 UTC, Dmitry Olshansky 
wrote:
 Finally got to this: 
 http://d.puremagic.com/issues/show_bug.cgi?id=8349

 Half way through it become obvious to me that we'll have 
 similar problems with memcpy and it's ilk every time somebody 
 optimizes bit-wise copy/move/find.

 More then that I think that we lack a specific set of low-level 
 functions that cover all of C's mem* functionality.
 (The focus is on fast primitives.)

 Currently there are obvious gaps:
 memset ---> cast(ubyte[]) + array ops
 memcpy ---> cast(ubyte[]) + array ops (also breaks with overlap)
 ...so far so good...
 memmove ---> ???
 memchr ---> cast(ubyte[]) + std.algorithm.find is *not* good 
 enough

 (in fact std.algorithm.find arguably could use memchr to 
 greatly optimize some specializations (!) )

 Why don't we just use C's ones?
 a) CTFE-ability, alternatively we can just hard wire all of 
 common libc functions into CTFE
 b) more generality and/or flexibility, e.g. despite it's speed 
 memchr can't search for ushort or uint
 c) safer, as it would operate on slices of _typed_ arrays, not 
 pointer + number of _bytes_

 So I propose the following set of low-level tools for inclusion 
 into Phobos or druntime:

  system:
 //bitblit, doesn't call destructors/postblits
 //also can be used to forcibly move structs
 void rawCopy(T)(const(T) src, T dest);

 //same, but also works with overlapped memory chunks
 void rawTransfer(T)(const(T) src, T dest);

 //fast search, bitwise comparison only
 void rawFind(T)(const(T)[] src, const(T) needle);

 Well the above is a sketch. Maybe I'm digging in the wrong 
 direction and this stuff just needs to be somewhere among 
 compiler's intrinsics.
 (so that it can do some magic if the size is known in advance 
 etc.)

These should definitely be put into the language!! but they'd 
have to be
100% reliable for me to adopt them over C equivalents.

unit std.memory anyone?