[boost] Re: call_traits vs type_traits

From: Andy Sawyer (boost_at_[hidden])
Date: 1999-11-30 15:06:08

On 30 November 1999 14:31, Howard Hinnant wrote:

> John Maddock wrote on 11/30/99 7:57 AM

> >;by reference:
> >?live16441_at_16: ; EAX = out, EDX = n, ECX = t
> >@361:
> >        mov       ebx,dword ptr [ecx]
> >        mov       dword ptr [eax],ebx
> >        add       eax,4
> >
> >;by value:
> >?live16442_at_16: ; EAX = out, EDX = n, ECX = t
> >@365:
> >        mov       dword ptr [eax],ecx
> >        add       eax,4
>
> My x86 assembly is a little rusty.  I don't see the loop (where is EDX
> getting decremented?).  If this is the loop body and you've edited out
> the loop, then the by-value looks like a very big win to me for this
> platform.  Is this with optimizations turned on?

 I'm going to assume that John's compiler generates the same code for
the loop control for both constructs. Even if it doesn't' then the
by value code is going to give a _huge_ win on [current] x86 processors,
since there can't be a cache miss for writing a value from a register.
 Whilst in the simple case, the by ref. version is unlikely to miss more
than
once on the 'load' ("mov ebx,dword ptr[ecx]"), it's not beyond the realms
of possibility that an interrupt/context switch might happen whilst the loop
is executing, which could potentially invalidate the entire cache, at least
as far as this code is concerned.
 Of course, it's possible to generate (or at least write by hand) _much_
faster code for an Intel CPU than this, in this specific case (using
REP STOSx ), but I don't know how many compiler optimisers are currently
that smart. (But then again, what we're doing here is trying to "design in"
optimiser hints, isn't it? :-)

 A thought occurs, however: if 'T' is "volatile int", i.e. we're
instantiating

fill_n1( volatile int *, std::size_t, const volatile int& );
and
fill_n2( volatile int *, std::size_t, const volatile int  );

[Not, you understand, that I'm sure it works that way...]
The there are massive semantic differences. (Not that I'm suggesting
that anybody might do such a thing, you understand)

(Now, do excuse me. There's some cover over there, and I'm going
to run for it... :-)

Regards,
 Andy
--
Andy Sawyer, Technical Director, Sufficiently Advanced Technology Ltd.
mailto:andys_at_[hidden]        ICQ:14417938        http://www.morebhp.com