<div dir="ltr">On 31 May 2013 23:07, finalpatch <span dir="ltr"><<a href="mailto:fengli@gmail.com" target="_blank">fengli@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I actually have some experience with C++ template<br>
meta-programming in HD video codecs. My experience is that it is<br>
possible for generic code through TMP to match or even beat hand<br>
written code. Modern C++ compilers are very good, able to<br>
optimize away most of the temporary variables resulting very<br>
compact object code, provides you can avoid branches and keep the<br>
arguments const refs as much as possible. A real example is my<br>
TMP generic codec beat the original hand optimized c/asm version<br>
(both use sse intrinsics) by as much as 30% with only a fraction<br>
of the line of code. Another example is the Eigen linear algebra<br>
library, through template meta-programming it is able to match<br>
the speed of Intel MKL.<br></blockquote><div><br></div><div style>Just to clarify, I'm not trying to say templates are slow because they're tempaltes.</div><div style>There's no reason carefully crafted template code couldn't be identical to hand crafted code.</div>
<div style>What I am saying, is that it introduces the possibility for countless subtle details to get in the way.</div><div style>If you want maximum performance from templates, you often need to be really good at expanding the code in your mind, and visualising it all in expanded context, so you can then reason whether anything is likely to get in the way of the optimiser or not.</div>
<div style>A lot of people don't possess this skill, and for good reason, it's hard! It usually takes considerable time to optimise template code, and optimised template code may often only be optimal in the context you tested against.</div>
<div style>At some point, depending on the complexity of your code, it might just be easier/less time consuming to write the code directly.</div><div style>It's a fine line, but I've seen so much code that takes it WAAAAY too far.</div>
<div><br></div><div style>There's always the unpredictable element too. Imagine a large-ish template function, and one very small detail inside is customised of otherwise identical functions.</div><div style>Let's say 2 routines are generated for int and long; the cost of casting int -> long and calling the long function in both cases is insignificant, but using templates, your exe just got bigger, branches less predictable, icache got more noisy, and there's no way to profile for loss of performance introduced this way. In-fact, the profiler will typically erroneously lead you to believe your code is FASTER, but it results in code that may be slower at net.</div>
<div><br></div><div style>I'm attracted to D for the power of it's templates too, but that attraction is all about simplicity and readability.</div><div style>In D, you can do more with less. The goal is not to use more and more templates, but make the few templates I use, more readable and maintainable.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
D is very strong at TMP, it provides a lot more tools<br>
specifically designed for TMP, that is vastly superior than C++<br>
which relies on abusing the templates. This is actually the main<br>
reason drawing me to D: TMP in a more pleasant way. IMO one thing<br>
D needs to address is less surprises, eg. innocent looking code<br>
like v[] = [x,x,x] shouldn't cause major performance hit. In c++<br>
memory allocation is explicit, either operator new or malloc, or<br>
indirectly through a method call, otherwise the language would<br>
not do heap allocation for you.</blockquote><div><br></div><div style>Yeah well... I have a constant inner turmoil with this in D.</div><div style>I want to believe the GC is the future, but I'm still trying to convince myself of that (and I think the GC is losing the battle at the moment).</div>
<div style>Fortunately you can avoid the GC fairly effectively (if you forego large parts of phobos!).</div><div style><br></div><div style>Buy things like the array initialisation are inexcusable. Array literals should NOT allocate, this desperately needs to be fixed.</div>
<div style>And scope/escape analysis, so local dynamic arrays can be lowered onto the stack in self-contained situations.</div><div style>That's the biggest source of difficult-to-control allocations in my experience.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Friday, 31 May 2013 at 11:51:04 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Assuming that you would hand-write exactly the same code as the template<br>
expansion...<br>
Typically template expansion leads to countless temporary redundancies,<br>
which you expect the compiler to try and optimise away, but it's not always<br>
able to do so, especially if there is an if() nearby, or worse, a pointer<br>
dereference.<br>
</blockquote>
</div></div></blockquote></div><br></div></div>