new should lower to a template function call

Stefan Koch uplink.coder at googlemail.com
Fri Jul 24 08:58:47 UTC 2020


On Friday, 24 July 2020 at 03:23:07 UTC, Andrei Alexandrescu 
wrote:
> On 7/23/20 2:51 PM, Stefan Koch wrote:
>> On Thursday, 23 July 2020 at 00:47:21 UTC, Andrei Alexandrescu 
>> wrote:
>>> Was thinking about this, see 
>>> https://issues.dlang.org/show_bug.cgi?id=21065.
>>>
>>> One problem I noticed with the current instrumentation of 
>>> allocations is that it is extremely slow. 
>>> https://github.com/dlang/dmd/pull/11381 takes care of that 
>>> trivially and quickly because it takes advantage of defining 
>>> one static variable per instantiation.
>> 
>> As Mathias has already point out in your issue.
>> You are instantiating more templates.
>> 
>> In the _worst_ case this can almost double the number of 
>> template instances.
>> I.E. when the new is inside a template itself.
>
> Not a problem. We must go with templates all the way, it's been 
> that way since the STL was created and there's no going back. 
> All transformations of nonsense C-style crap into templates in 
> object.d have been as many success stories. If anything there's 
> too few templates in there.

You say that, but we have seen problems, for example with the 
mangle-length of huge stringswitch instances.

Shortly after the introduction array comparison was bugged 
because, it could not compare char[] and const char[]. They were 
different types and would compare to false, therefore.

Where are the many success stories?

I haven't read any article about how the templates in druntime 
have helped anyone in great capacity, (to be honest I have not 
looked either).




> When "new C" is issued everything is right there for the grabs 
> - everything! The instance size, the alignment, the constructor 
> to call. Yet what do we do? We gladly throw all that on the 
> floor to call a crummy C function that uses indirect access to 
> get access to those. No wonder -trace=gc is so slow. This 
> entire inefficient pomp and circumstance around creating an 
> object is an embarrassment.

gc tracing is slow because it's not a priority to make it fast.

Every compiler which does inline-ing  properly, can get around 
the indirect calls.


>
> To say nothing about built-in hash tables. It's 2020 and we 
> still use an indirect call for each comparison, right? We 
> should make a vow to fix that until the next Pandemic.
>

The builtin-hash tables, are not cool, true.
But that's not because of cmps.

>> What do you envision the prototype to be like, and why 
>> couldn't that be just a function call to the runtime if a hook 
>> exists?
>
> In the simplest form:
>
> template __new_instance(C)
> if (is(C == class))
> {
>     static foreach (all overloads of __ctor in C)
>     {
>         C __new_instance(__appropriate__parameter__set)
>         {
>             ...
>         }
>     }
> }
>
> This would be a terrific opportunity to fix the perfect 
> forwarding problem.
>

You are aware that this will create a lot of work for semantic, 
yes?

Whereas just emitting a call, would be O(1), fast and most of all,
predictable. Making this a template invites the error messages or 
templates as well.
What if the constraint fails, you get "Could not find a matching 
overload for '__new_instance'".
Whereas a solution which uses a function call, could give a more 
informative error message.

> Further improvements: use introspection to detect if the class 
> defines its own __new_instance, and if it does, defer to it. 
> That way the deprecated feature per-class new makes a comeback 
> the right way.

I wonder why the feature was deprecated in the first place.

Actually it's not very costly to simply allow two ways of 
customizing 'opNew'.
If that were the case one could even do direct comparisons of the 
template vs.
the function approach.

D has always prided itself on giving the decision to the user, I 
don't see any compelling reason not to do it here.

Regards,
Stefan



More information about the Digitalmars-d mailing list