[sldev] Processor Optimizations (Windows)

[Dirk Moerenhout]

In the past I've done some things in regards to optimising C/C++ code
for better performance. For optimal results you also need to have C++
code that is begging to be optimised. Some parts already are fine,
some do need some reordering. Hardest part for a project like this is
that its very large. That leaves a lot of room for improvement but
it's very hard to find what will yield the most benefit.

Your proposal to turn on SSE for all parts may yield unsatisfactory
results as a lot of the code is not ready to be turned into SSE
instructions.

I compile on VS 2005 C++ Express so whatever I dig up will apply to
the VS 2005 C++ compiler. I can't guarantee you can reproduce it on
the VS 2003 one or that it'll be always equally applicable to other
platforms/compilers. It's for example possible that a certain code
rewrite allows VS 2005 to replace slower instructions with faster ones
while on VS 2003 it may have no effect at all.

Note though:
In general rewritten C++ will benefit any architecture. Especially
changes like the reconstruction of loops like what I had in the patch
for VWR-881. No compiler will do that for you and the benefit applies
to any architecture.



I'll try at first to see if there are things we can easily change for
all possible CPU's, be it compiler options or small restructuring. SSE
optimisations are out for now as the Athlon didn't have it and the
higher speed versions can run SL.

Where possible I'll also check how gcc handles the reordering. The
math libraries for example can be easily test compiled to assembler
using Cygwin or minGW.


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
>