Hi,
On Mon, 2007-10-01 at 14:26 +0200, Marcus Lindblom wrote:
> Gerrit Voss wrote:
> > Hi,
> >
> > On Sun, 2007-09-30 at 11:08 +0200, Andreas Zieringer wrote:
> >
> >> couldn't reproduce this I get the following output with your test program:
> >>
> >> CPU cycles with manual inlining: 758135486
> >> CPU cycles With Pointinterface: 811406783
> >> Ratio: 1.07027
> >
> > Just a quick update, I ran some more test, same compiler options,
> > VS2005:
>
> [snip]
>
> > So more templates are better, I knew it ;-). Ok, I guess we have to do
> > some more tests and have a closer look ;-)
>
> May I mention that the quest for performance is a bit at odds with
> usability?
If you do it right not really, it is really nice if you can write the
following:
// ! r(t+dt)
pos = pos + deltat * vel + (R_CONST(0.5) * deltat * deltat) * acc;
and get:
for(OSG::UInt32 i = 0; i < N; ++i)
{
pos[i][0] +=
deltat * vel[i][0] + 0.5 * (deltat * deltat) * acc[i][0];
pos[i][1] +=
deltat * vel[i][1] + 0.5 * (deltat * deltat) * acc[i][1];
pos[i][2] +=
deltat * vel[i][2] + 0.5 * (deltat * deltat) * acc[i][2];
}
executed without any performance penalty, where vel and acc are
really OSG::Vec3f values. That is actually one of the few things that
makes Fortran beautiful ;-). Ok the usual drawback of really ugly error
messages applies ;-)
> For instance, if you want peak performance, you should not have
> zero-initializing default ctors for vec/pnt classses.
that is true but changing this won't make us any friend ;-)
kind regards,
gerrit
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
