core.traits?

Mike Franklin slavo5150 at yahoo.com
Thu Jan 10 00:47:22 UTC 2019


On Wednesday, 9 January 2019 at 19:25:35 UTC, H. S. Teoh wrote:

> That's an excellent idea.  Have a generic default algorithm 
> that performs reasonably well in typical use cases, but also 
> give the user the power to choose a different algorithm if he 
> knows that it would work better with his particular use case.
>
> Empowering the user -- over time I've come to learn that this 
> is always the best approach to API design.  It's one that has 
> the best chance of standing the test of time.  Fancy APIs that 
> don't pay enough attention to this principle tend to eventually 
> fade into obscurity.

Yes, this is one of the benefits of making `memcpy(T)(T* dest, T* 
src)` instead of `memcpy(void* dest, void* src, size_t num)`.  
One can generate a `memcpy` at compile-time that is optimized to 
the machine that the program is being compiled on (or for).  
druntime could expose "memcpy configuration settings" for users 
to tune at compile-time.

But, then you have to deal with distribution of binaries.  If you 
are compiling a binary that you want to be able to run on all 
Intel 64-bit PCs, for example, you can't do that tuning at 
compile-time; it has to be done at runtime.  Assuming my 
understanding is correct, Agner Fog's implementation sets a 
function pointer to the most optimized implementation for the 
machine the program is running on based on an inspection fo the 
CPU's capabilities at the first invocation of `memcpy`.

There's a lot of things like this to consider in order to create 
a professional `memcpy` implementation.

Personally, I'd just like to put the infrastructure in place so 
those more talented than I can tune it. But as I said before, 
that first PR that puts said infrastructure in place needs to be 
justified, and I predict it will be difficult to overcome bias 
and perception.  Reading the comments in this thread fills me 
with a little more optimism that I'm not the only one who thinks 
it's a good idea. But, we still need dynamic stack allocation 
first before any of this can happen.

Mike



More information about the Digitalmars-d mailing list