From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-24 17:45:36
From: Peter Dimov <pdimov_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> > From: Peter Dimov <pdimov_at_[hidden]>
> > > From: "Greg Colvin" <gcolvin_at_[hidden]>
> > > > From: Peter Dimov <pdimov_at_[hidden]>
> > > > > float const pi_f = math::pi;
> > > >
> > > > I think on Noah's system this will result in the value in double const
> pi
> > > > being converted, slowly, at runtime.
> > >
> > > Once, at startup. If this is really a problem, we can (and probably
> should)
> > > add pi_f (and pi_l) to math:: as well.
> >
> > Once in this case. But take away the const and put the initialization
> > in block scope ...
>
> Why should I do that? :-)
Hell if I know, but on Noah's system it would be slow.
> > > The question is, what is the value of providing a generic framework that can
> > > handle types that we don't know about.
> >
> > Well, the advantage of fetching the constants via an
> > inline function is that it is faster,
>
> "Prettier" assembly doesn't mean faster. It might well be faster, or it
> might be slower. I didn't see any timings for a nontrivial program being
> posted?
No, I haven't done any timings. The main point was just that there need
be no overhead for the templates compared to a literal constant. But I
am confident that, ceteris paribus,
mov DWORD PTR _pi_function$[esp+60], 1413754136
mov DWORD PTR _pi_function$[esp+64], 1074340347
will be faster than
mov eax, DWORD PTR _Pi$S188
mov DWORD PTR _pi_constant$[esp+40], eax
mov ecx, DWORD PTR _Pi$S188+4
mov DWORD PTR _pi_constant$[esp+52], ecx
> > and that an more
> > precise implementation might be possible, e.g. with an
> > extension for hexadecimal literals.
>
> More precise implementations are possible:
>
> namespace math
> {
> union _Pi_t
> {
> unsigned char x[8];
> double y;
> };
>
> _Pi_t _Pi = { 0xB8, ... };
>
> double const & pi = _Pi.y;
> }
>
> or whatever other ugly platform-specific hacks are necessary.
That might do it on some platforms, but with so many platforms
I'd hesitate to judge. And I think the above will be even more
likely to force a memory reference. The extra abstraction of
a generic soultion can provide for more flexibility of
implementation.