Re: No templates for performance?

From:

BGB <cr88192@hotmail.com>

Newsgroups:

comp.lang.c++

Date:

Sat, 26 May 2012 11:37:15 -0500

Message-ID:

<jpr0s8$lkl$1@news.albasani.net>

On 5/26/2012 12:22 AM, Ian Collins wrote:

On 05/26/12 05:00 PM, BGB wrote:

On 5/17/2012 2:29 PM, Jorgen Grahn wrote:

On Thu, 2012-05-17, Juha Nieminen wrote:

Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:

Instead, we either instantiate code with all possible
combinations of template parameters (code bloating in its best)

Ok, I have decided to not take seriously anybody who uses the term
"code bloat" to describe templates. It's just a myth that people keep
repeating like parrots, with little actual evidence.

Yes. I'm very tempted to start trying to refute claims from Pavel and
S.L. in this thread ... but then I do a reality check. Templates
(writing new ones, and especially using the standard library's
containers and algorithms) are one of the cornerstones of modern C++.

Put differently, if I want C, I know where to find it.

FWIW, even in C, there is a "sort-of" analogue:
multi-line macros.

for example (grabbing something from some of my own code):
#define BVT_JMPCC_BODY(ty, cc) \
ty *u, *v; \
if(cur->data) \
{ \
BVT_PopXY_Ty(ty, u, v); \
if((*u)cc(*v)) \
{ \
BVT_FreeUV_Ty(ty, u, v); \
return((BSVM_ThreadOp *)(cur->data)); \
} \
BVT_FreeUV_Ty(ty, u, v); \
return(cur->next); \
} \
cur->data=(void *)BSVM_Thread_GetOpJumpTarget(ctx, cur, cur->i); \
if(cur->data) { return(cur->fcn(ctx, cur)); } \
else { *(int *)-1=-1; } \
return(cur->next)

note that this macro in turn invokes several other macros, ...
and contains a self-destruct mechanism...

in this case it was being used fairly effectively, and the logic would
likely have been repeated either via a macro or via copy/paste anyways
(macros ended up used frequently in the region of code in question).

great fun...

Also a great way to bloat the code!

yeah, but in this case it was likely inescapable.

the macros were mostly needed for adding a lot of "statically typed"
logic to my script VM / interpreter, which replaced a lot of slower
dynamically-typed execution paths.

the logic above was actually for a lower-performance variety of jumps,
there was a faster variety, but it involved 2 functions per jump (to
eliminate the first "if()", one function would replace itself by the
other). in this case, leaving an unnecessary 'if' in the execution path
was seen as acceptable, since the branch predictor usually got it right
in this case (the 'if' body would always execute except the for the
first time a given conditional jump was seen in a given block).

(the faster version was used for unconditional jumps).

not that all of the code is written this way (it is actually fairly
uncommon in-general).

With function templates the compiler can choose whether or not to inline
them. With macros, there isn't any choice to be made.

yes, however:
this code was C, and C doesn't have templates;
they were being invoked specifically (so, it was fairly deliberate that
they would be inlined);
....