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

[Jean-Marc Valin]

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Ceci est une partie de message numériquement signée.
Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20040121/31cd87f2/signature.pgp