[sldev] Processor Optimizations (Windows)

[Dirk Moerenhout]

James,

any news on those CPU statistics? :) It would be really useful to get
a good idea of what people are using. If we see that nearly all chips
have SSE we could use some SSE on a conditional basis if the SSE code
including conditions is faster than the generic code. This'll off
course make execution on non-SSE a bit slower as they'll still get to
run generic code + branching.

lltrunc() is a good example. The specially crafted fast code still
gets beat by a normal cast in VS2005 on Athlon 64 XP. VS2005 does seem
to use SSE for this regardless of whether you've enabled it but it
proves that current CPU's don't like old tricks that much.

Some of the easy things we can do is optimisation for the many calls
that have been lazily written. llceil code for example could be
replaced by:
return -llfloor(-f);
In that way it'll just take the (optimised) code from llfloor and add
2 sign changes. On Athlon 64 XP the above code results in 3x the speed
compared to using C++'s ceil. I know it's not called a lot it's not
hard to make it better.

There should be tons of changes possible in the math code and several
of those functions do get called quite a lot. Advantage is that they
are small and hence it's easy to do some regression testing on the
code snippets outside the SL source tree.

On 6/6/07, James Cook <james at lindenlab.com> wrote:
> > I was just running around sims with all stuff enabled (I really don't
> > want to spend much time on this as it's unlikely that anything like
> > a major change in project settings will ever make it into the SL build),
>
> Don't give up on compiler options!  I would happily accept a patch that
> changed compiler optimization options, especially if there were
> benchmark results to demonstrate the benefits.
>
> Keep in mind though that we have to support many different processor and
> OS combinations.  Steve may have more recent stats on what chips our
> users are actually using, but I would be a little nervous, for example,
> deciding to drop support for PIII chips without a solid benchmark.  We
> don't really want to be doing multiple Windows builds internally.
>
> I would be curious about benchmarks where SSE code generation was turned
> on for all files.
>
> James
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>