[boost] Templates and code bloat (Re: [intrusive] Interface for ...)

From: Lassi Tuura (lassi.tuura_at_[hidden])
Date: 2007-08-12 17:42:42

Dear all,

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  
relative ease.

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.

Best regards,
Lassi

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.