[speex-dev] Notes on 1.1.4 Windows. Testing of SSE Intrinics Code and others

[Aron Rosenberg]

Jean-Marc,

         Good catch on the debug mode. After compiling the same code in 
release mode it does appear to be using all the registers correctly. Give 
us a few days to integrate our run-time flags into 1.1.4 and I will let you 
know how are testing turns out.

Aron Rosenberg
SightSpeed

At 08:54 PM 1/21/2004, you wrote:
> > 1. Compile Error with regular mode (FIXED_POINT undefined) at lsp.c 
> line 104
> >       static inline spx_word16_t spx_cos(spx_word16_t x)    . VS6 does 
> not like
> > the inline keyword here. Removing it allows compiling.
> >
> >     same with cb_search_sse.h  line 34.
>
>It seems like your compiler simply doesn't like "inline". I suggest
>doing a -Dinline= which is what autoconf does when it detects that the
>compiler doesn't understand the inline keyword.
>
> > 2. Compile Error with quant_lsp.c  line 55.  M_PI is undefined. Either it
> > needs to be included in that file or placed in a header.
>
>I'll fix that.
>
> > 3. denoise.c doesn't seem to be in tar.gz, it is in the visual studio
> > project file though.
>
>The project file isn't up-to-date (I've never even compiled Speex in
>Win32). The file's been renamed to preprocess.h
>
> > We ran the SSE intrinics code through some test on windows over here and
> > all I can say is - it sucks. A room filled with Monkeys could generate
> > better SSE code. Having stated that let me describe why.
>
>You mean a room filled with monkeys could generate a better compiler? :)
>
> > We use Visual Studio 6, SP5 with the processor pack as the main 
> development
> > platform. For some unknown reason, it decides that it only ever wants to
> > use XMM0 for its SSE operations. If it is dealing with a two paramater SSE
> > call, then it will use XMM1, but thats it. Between succesive calls, it
> > won't keep things in an xmm register, even if the next call is using it.
>
>I just checked with gcc. gcc uses all of the xmm registers available
>(should check on an Opteron, which has 16 of them). Overall, enabling
>SSE can give up to 30% improvement (20% is typical).
>
> > To check this, I converted some of the MMX code in our regular application
> > to intrinics and it does the same thing, only uses mm0 and mm1. It 
> actually
> > runs slower than a c code version of the same function.
>
>Well, there's always the option to use gcc to generate the assembly for
>the few SSE functions.
>
> > Now, this could be different on Visual Studio .NET and .NET 2003, but that
> > is what happens with Visual Studio 6. Just so you understand, I am pasting
> > below some of the generated SSE code for the fir_mem2_10 function. I got
> > this by compiling the speexenc and loading it up in the debugger.
>
>Yes, that code sucks. Bad. Actually, I can get the same kind of code by
>turning the optimizer off in gcc (-O0). Maybe you've got it turned off
>too (I think VS is unable to optimize in debug mode, is that right?).
>Oterwise, VS really sucks.
>
>         Jean-Marc
>
>--
>Jean-Marc Valin, M.Sc.A., ing. jr.
>LABORIUS (http://www.gel.usherb.ca/laborius)
>Université de Sherbrooke, Québec, Canada

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.