Speex dev - Aug 2004 - Notes on 1.1.4 Windows. Testing of SSE Intrinics Code and others

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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

>          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.
Just a note. With the last optimization I did in cb_search.c, it's no
longer easy to have a run-time SSE flag. The reason is that there is now
data exchanged in _m128 format between some functions (even the layout
of the values changes if you turn SSE on).

        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/20040122/f79ee15c/signature-0001.pgp

Jean-Marc,

         Are you sure that you don't need to add just -msse to enable the 
intrinsics rather than a full fledged -march=pentium3? I did some playing 
around and I can get intrinsics code to compile with -march=i686  -msse on 
linux with that.

         Check out: 
http://groups.google.com/groups?q=enable+gcc+sse+intrinsics&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=ugnh53o8h1bq55%40corp.supernews.com&rnum=1

Aron Rosenberg
SightSpeed

At 10:33 PM 1/21/2004, you wrote:
> >          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.
>
>Just a note. With the last optimization I did in cb_search.c, it's no
>longer easy to have a run-time SSE flag. The reason is that there is now
>data exchanged in _m128 format between some functions (even the layout
>of the values changes if you turn SSE on).
>
>         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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.