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