bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE: Re: [Bug-gnubg] gnubg sse problems on non-sse cpu's


From: Massimiliano . Maini
Subject: Re: RE: Re: [Bug-gnubg] gnubg sse problems on non-sse cpu's
Date: Mon, 10 Apr 2006 10:40:45 +0200

>The nueral net code does not use any sse2 or sse3 instructions,
>so the evaluation code won't gain anything by using the -sse2 or
>-sse3 switch. However, the compiler can find some places on it's
>own where it uses sse3 or sse3 instructions with this flag set.
>If that's the case, you will exclude some users.
>
>I actually believe you should only compile the vital files with
>-sse if you want a general build. (that neuralnet.c and eval.c)

That would be easy to do. But does it means that if I compile ONLY
neuralnet.c and eval.c with -msse, the resulting executables should
work in SSE mode on SSE processors and in non-SSE mode on non-SSE
processors ?

As pointed out by Christian, the only way to have a generic code
would be to :

- have "critical" functions duplicated in separate files, like
crit_code_sse.c and crit_code.c (e.g. NeuralNetEvaluate in
crit_code.c and NeuralNetEvaluate128 in crit_code_sse.c)

- compile everything with -mnosse, crit_code_sse.c with -msse (if
compile option USE_SSE is true)

- have calling code like in eval.c :

      #if USE_SSE_VECTORIZE
            if (SSE_Supported())
                  NeuralNetEvaluateFn = NeuralNetEvaluate128;
            else
      #endif
            NeuralNetEvaluateFn = NeuralNetEvaluate;

[for clarity I would write if (SSE_Supported()==1) ...]

This way it wouls also be easy to have specific sources for non-SSE,
SSE1, SSE2, SSE3 (provided somebody can write down some code that
detects if the specific feature is supported).


MaX.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]