David Megginson writes:
>
>Tony Peden writes:
>
> > To get the equivalent of tieing to object methods, a 
>once-per-frame data
> > copy is necessary.  Did your testing take this into account? 
>
>No, I was just testing access time.  I checked in some optimizations
>that skip a lot of unnecessary code when the value is held internally,
>so the differences are even greater now.
>
>Here are some tests I just ran, for 100,000,000 accesses of a double
>property (I ran each on a few times then picked the most typical user
>time; there was little variation anyway):
>
>  Tied to object methods: 5.880 sec
>  Internal (access only): 2.870 sec
>  Internal (1:1 get:set ratio): 3.74 sec
>  Internal (10:1 get:set ratio): 3.07 sec
>
>Even when I copy the property value once for every access, it's much
>faster than tying to methods.  When I set once for every 10 accesses
>(probably typical for the more popular properties), there's almost no
>additional overhead.

You have to be real careful with 'synthetic tests' in that one of the
primary factors influencing the 'test' is whether or not the data
remains in the 'cache'.  Repeatedly calling the same 'test' without
all of the 'normal code' in place will often give you very quick
results that does not necessarily reflect what would happen 
during normal program run.

Of course your tests may not have this problem :-)

>I am trying to find ways to optimize tied methods, but I haven't found
>any way yet to handle them without excessive indirection, because of
>the necessity of instantiating a template for each different
>class/type combination.  I should be able to get tied pointers working
>as fast as internal methods, though, if we decide to keep those.

In my experience the following scenario often helps

On entering a complex code block force all external pointers into
the 'cache' by making local copies, then only use these local copies

The same trick is often true for data

In any case optimizing for the 'cache' is tricky business but
if and when you can actually get all of your code / data to
reside in the cache the results can be spectacular

Also when wondering whether or not 'inlining a function' is
worthwhile or not it is hard to beat coding it both ways and 
looking at the actual assembly code generated for each

gcc $OPT_FLAGS -S

Cheers

Norman


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to