All right, all right! Interim decision regarding qualified Object methods

[Michel Fortin]

On 2012-07-12 11:41:46 +0000, "bearophile" <bearophileHUGS at lycos.com> said:

> Andrei Alexandrescu:
> 
>> The issue is template code bloat. My impression from being in touch 
>> with the C++ community for a long time is that virtually nobody even 
>> talks about code bloat anymore. For whatever combination of industry 
>> and market forces, it's just not an issue anymore.
> 
> There is no proof that template bloat won't be a problem in D (I 
> remember the first version of the D Objective-C bridge failing because 
> of code bloat, the second version seems to require changes in the D 
> language).

I don't think templates were the culprit for the D/Objective-C bridge. 
Code bloat was, but that's something that was inherent to the design of 
the bridge. The bridge was using mixins extensively, and while I did 
everything I could to use regular non-mixin templates (because those 
can be reused when the template arguments are the same), it wasn't 
enough. In fact, given that all the wrapper functions written using 
mixins were virtual (so you could override them, which is quite a 
feature!) it meant they all needed to be instantiated even though they 
were not used anywhere.

There's actually no way I could have reduced code bloat significantly 
even by writing all the code by hand in the most optimized way. Not 
unless I abandoned the capability to override functions, but that'd 
make the bridge almost useless.

One thing that might have helped is if the linker could have striped 
all the classes that were not used in the final executable, something 
it couldn't do because all module info refers to them. But that 
wouldn't have helped with the compilation speed, which was becoming the 
second problem not far behind code bloat.


>  And it seems L1 code caches of CPUs aren't growing a lot (so I suggest 
> to not ignore having lot of code to swap in and out of those 32 kbytes).
> 
> So maybe it will be useful to introduce in D some means to attack the 
> code bloat problem from several sides at the same time.
> 
> Some time ago I have suggested one of such weapons, the @templated() 
> that allows to select what parts of a struct/class are templated 
> regarding to what template arguments (it's a refinement of an idea of 
> Stroustrup).
> 
> Another weapon to attack the problem is introducing in the DMD back-end 
> an optimization (already present in LLVM, but I think not used on 
> default), merging of functions with the same body (leaving just a jump 
> as the body of the removed function, to keep their function pointers 
> distinct).

Both desirable things, but I don't think those would have much impact 
on the D/Objective-C bridge.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/