From: Lassi Tuura (lassi.tuura_at_[hidden])
Date: 2007-08-12 17:42:42
Thanks for your comments; I hope this responds to you all. I very
much agree with David's words.
For background, most developers in our project program purely as a
means to an end; they are not software engineers and don't usually
get a kick from discovering a cool new C++ or ABI feature. When they
can focus on their problem at hand, and not on the language and the
tools, we have done well. Programming languages, libraries or
compilers prone to lead to mistakes reduce their efficiency. Our
code base is some millions of lines of code, a complete built
distribution is in the ballpark of 4 GB and 1000 shared libraries.
We process large quantities of data, at present the code runs flat
out on thousands of cores every day, soon on a much larger number of
cores. So you may understand my ideas of performance consequences
are rather concrete; I am aware others have different constraints.
I'd posit template metaprogramming is a means to an end, another tool
to get the compiler churn out code and help developers focus on
problems interesting to them. It's definitely a tool I am pleased to
have in my toolbox. However regardless of the languages and
constructs used, I'll look at code maturity, maintainability,
features and performance delivered per byte of object code, and
factors such as build time or ability to debug the code. Like any
tool, templates presently have some concrete strengths and
weaknesses. I'll rejoice with you as compilers, linkers and run-
times get more clever about templates. In the mean time we'll push
for (substantial) economies by seeking a remedy to these present
weaknesses. To us it is really not a question of whether there is
bloat or not; it seems we can produce objective hard data with
What interests me most in the template bloat is that the awkward
practical consequences are a result of fairly innocuous use of the
language and the libraries, mostly in style taught in the best C++
text books and programming courses available. It is not even badly
designed templates, and I would not be comfortable blaming just the
tools either. Our tool chain actually does a decent job for a single
shared library, about as good as any other as far as I know. I don't
really know of production-quality whole program optimisers capable of
processing hundreds of megabytes of machine code originating from
several programming languages, or tools that give us a whole new
class of liberty for physical packaging, or quality tools capable of
combining C++ language level analysis and run-time feedback data.
Pointers would be welcome.
With the technology at hand today, it is difficult _not_ to make a
lot of mistakes: bloat your code by 10+%, pass a 100'000-element map-
of-vectors-of-vectors by value, accidentally instantiate the same
template into hundreds of shared libraries, have a working set of 50
shared libraries for a particular "unit of work", or have orders of
magnitude too many relocation entries in a shared library. Even the
top programming and platform experts will sweat blood and tears to
identify and analyse the issues, let alone devise practical
remedies. There seems to be room for some novel thinking and tooling
in this area. Of course not every project deals with such issues.
Like you, we do the best we can to improve the classes and the tools,
but we really need to look at the reality in the eye as we do that.
Some of us spearhead the technology for tomorrow, but it takes wisdom
to know what is the right technology for the hordes behind, for the
numerous different project circumstances.
PS. Please understand I am not picking on templates for the fun of
it. I am an engineer, a practitioner. I am as aware of the benefits
of well-designed advanced templates as I am of the weaknesses. We
recently introduced expression templates into a key algorithm. The
change had been resisted for years; careful analysis of the
performance costs of the "old-fashioned" code finally overcame the
main technical and political arguments and we begun the migration.
We are pretty unanimously pleased with the result. The costs
associated with the templates may in due course produce similar
migration advice. It could be investment into custom tooling,
changes to our programming idioms, and other avenues.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk