On 12/07/2012 15:20, Michel Fortin wrote:
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.
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a big
deal for any modern computer, not even for most cell phones now.
