Update on the D-to-Jai guy: We have real problems with the language

[Steven Schveighoffer]

On 11/27/22 4:29 AM, FeepingCreature wrote:

> 3. But also if we're talking about number of instantiations, `hasUDA` 
> and `getUDA` lead the pack. I think the way these work is just bad - 
> I've rewritten all my own `hasUDA`/`getUDA` code to be of the form 
> `udaIndex!(U, __traits(getAttributes, T))` - instantiating a unique copy 
> for every combination of field and UDA is borderline quadratic - but 
> that didn't help much even though `-vtemplates` hinted that it should. 

I avoid hasUDA and getUDA unless it's a simple project. If I'm doing any 
complex attribute mechanisms, I use an introspection blueprint, i.e. 
loop over all the attributes once and build a struct that has all the 
information I need once. There's not a simple abstraction for this, you 
just have to build it.

> I really think the primary issue here is just that D gives you a hundred 
> tools to dig yourself in a hole, and has basically no tools to dig 
> yourself out of it, and if you do so you have to go "against the grain" 
> of how the language wants to be used.

But really this is kind of how you have to deal with D templates. I 
think we are missing a guide on this, because it's easy to write D code 
that looks nice, and doesn't compile with horrible performance, but will 
add up to something that is unworkable.

There's bad ways to implement many algorithms. There's also ways to 
implement algorithms that assist the optimizer, or to help performance 
by considering the hardware being used. For sure there's a lot less 
attention paid to what is "bad" in a template and CTFE, and what 
performs well. The wisdom there is not *conventional* and is not the 
same as regular code wisdom. I think we can do better here.

> DMD is fast. DMD is even fast for what it does. But DMD is not as fast 
> as it implicitly promises when templates are advertised, and DMD does 
> not expose enough good ways to make your code fast again when you've 
> fallen in a hole.

Yes, I think we need more tools to inspect what is taking the time, and 
we need more guides on how to avoid those. Understanding where the cost 
goes when instantiating a template is kind of key knowledge if you are 
going to use a lot of them.

Phobos does not make this easy either. Things like std.format are so 
insanely complex because you can just reach for a bunch of 
sub-templates. It's easy to write the code, but it increases compile 
times significantly.

I still have some hope that there are ways to decrease the template cost 
that will just improve performance across the board. Maybe that needs a 
new frontend compiler, I don't know.

-Steve