On 2012-07-12 11:41:46 +0000, "bearophile" <[email protected]> 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
[email protected]
http://michelf.com/
