Ogg Vorbis acceleration project, Is it dead? Options

[lvqcl]

I took my old compiles and also compiled the sources with SSE4.1 instruction set. Then I took an album (57m 37s) and encoded it. Results (encoding time, in seconds):

32 bit:
SSE - 89.5 s
SSE2 - 72.2 s
SSE3 - 73.2 s
SSE4.1 - 72.1 s

64 bit:
SSE2 - 67.1 s
SSE3 - 66.5 s
SSE4.1 - 66.1 s

BTW, I also tested original Lancer from http://homepage3.nifty.com/blacksword/index.htm

SSE - 57.7 s
SSE2 - 53.2 s
SSE3 - 53.1 s

SSE2 MT - 35.9 s (71.6 s total process time)
SSE3 MT - 36.2 s (72.3 s total process time)

[eahm]

Pink Floyd - The Wall 1:21:09 (CPU specs: http://i46.tinypic.com/110lytc.png)

(q5.0)

oggenc2.87-1.3.3-generic: Total encoding time: 0:29.874, 162.99x realtime

oggenc2.87-1.3.3-x64: Total encoding time: 0:17.067, 285.30x realtime

oggenc2.87-aoTuVb6.03-generic: Total encoding time: 0:31.949, 152.40x realtime

oggenc2.87-aoTuVb6.03-x64: Total encoding time: 0:18.236, 267.01x realtime

oggenc2.87-aoTuVb6.03-LancerSSE: Total encoding time: 0:18.330, 265.64x realtime

oggenc2.87-aoTuVb6.03-LancerSSE2: Total encoding time: 0:18.096, 269.07x realtime

oggenc2.87-aoTuVb6.03-LancerSSE3: Total encoding time: 0:18.439, 264.07x realtime

oggenc2.87-aoTuVb6.03-LancerSSE3_x64: Total encoding time: 0:13.994, 347.95x realtime

-

qaac_1.38 (V82): Total encoding time: 0:20.374, 238.99x realtime

NeroAACCodec-1.5.1 (Q0.48): Total encoding time: 0:19.313, 252.12x realtime

lame3.99.5 (V2): Total encoding time: 0:19.344, 251.71x realtime

lame3.99.5-64 (V2): Total encoding time: 0:17.643, 275.98x realtime

This post has been edited by eahm: Jul 12 2012, 00:56

[lvqcl]

It seems that older versions (that require Intel DLLs) were faster than current. Also, SSE2_OLD version is as fast as before. (misconfigured compiler?..)

[john33]

It seems that older versions (that require Intel DLLs) were faster than current. Also, SSE2_OLD version is as fast as before. (misconfigured compiler?..)

The SSE2_OLD is actually configured in the same way as the SSE2 compile. Both are ICL 12.1 compiles. The only difference is that the OLD was compiled within VS2008 and the other within VS2010.

[Brazil2]

The only difference is that the OLD was compiled within VS2008 and the other within VS2010.

Heh, newer doesn't always mean better

[Destroid]

After finally getting the 64-bit machine operational, I have some benches to add here (running i5-2600K [OC], 8GB, WinXP x64 SP2):

OggEnc 2.87 aoTuV b6.03 Lancer builds (-q 3 [126.2 kbps])
SSE2 ........ 74.13x
SSE2 old ... 98.84x
SSE3 ........ 74.13x
SSE3 x64 .. 107.83x

[lvqcl]

Could you test also SSE version?

This post has been edited by lvqcl: Jul 22 2012, 12:47

[IgorC]

After finally getting the 64-bit machine operational, I have some benches to add here (running i5-2600K [OC], 8GB, WinXP x64 SP2):

i5 2500k or i7 2600k?

[Destroid]

Ok, the results using Vorbis -q3 running on i5-2500K (OC'ed), 8GB, WinXP x64 SP2.

The encode rate and bitrate numbers come from the binaries themselves. To help make sense of which version I was running I included the binaries' date-stamps.

CODE

john33 (OggEnc 2.87 aoTuV b6.03, average bitrate 126.2 kbps, all builds Lancer except *)
----------------------------------------------------------------------------------------
Generic* 40.2072 05/04/2011
P4* 65.8952 05/04/2011
SSE 71.8857 07/04/2012
SSE2 74.1321 07/04/2012
SSE2 (old) 98.8428 07/04/2012
SSE3 74.1321 07/04/2012
SSE3 x64 107.8285 07/04/2012


lvqcl Lancer (OggEnc 2.87 aoTuV b5.7, average bitrate 118.6 kbps)
------------------------------------------------------------------
SSE 87.8602 02/20/2012
SSE2 118.6113 02/20/2012
SSE2 x64 131.7904 02/20/2012
SSE3 112.9632 02/20/2012
SSE3 x64 124.8540 02/20/2012

Blacksword Lancer (OggEnc 2.83, aoTuV b5, average bitrate 118.0 kbps)
---------------------------------------------------------------------
SSE 120.112743 11/09/2006
SSE2 131.673327 11/09/2006
SSE2 MT 200.035978 11/09/2006
SSE3 131.330713 11/09/2006
SSE3 MT 199.766456 11/09/2006

This post has been edited by Destroid: Jul 22 2012, 18:46

[lvqcl]

oggenc "02/20/2012" is based on aoTuV 5.7, not 6.03

[Destroid]

Fixed.

I got pretty confused with this many binaries.

[Destroid]

(Time expired editing above post while typing...)

FYI, I noticed the SSE binary in the aoTuV b5.7 bundle (post #121) declared itself b6.03. Because the bitrate is consistent with the other compiles in the bundle I'm guessing it's just a typo.

It's worth mentioning that Vorbis doesn't have drastic bitrate variance when compiler options change. When I posted the average bitrate in the above table it really means each individual file had the same bitrate, respective of the builder+compiler.

[lvqcl]

FYI, I noticed the SSE binary in the aoTuV b5.7 bundle (post #121) declared itself b6.03.

...That's strange. Thank you for the info.

[AshenTech]

I was wondering if somebody whos got gcc could give us a compile with AVX or AVX+sse4/4.2a to test on bulldozer based chips.

apparently they fixed the AVX support with newer gcc versions http://www.primegrid.com/forum_thread.php?id=3912

would be interesting if it where possible to see how AVX would effect encode speeds if at all (cant wait for them to also have FMA support)

thanks in advance to whoever gives us an avx build to play with

[sheh]

Are the AoTuV b6.03 sources from post #117 mixed with Lancer?

For decoding only, are there major quality/bugfix differences between the current libvorbis/vorbisfile and what the latest "original" Lancer was based on (from late 2006)?

[lvqcl]

Are the AoTuV b6.03 sources from post #117 mixed with Lancer?

Yes, but I tested only encoding part of these sources, and I'm not sure that decoding works properly.

For decoding only, are there major quality/bugfix differences between the current libvorbis/vorbisfile and what the latest "original" Lancer was based on (from late 2006)?

See http://svn.xiph.org/trunk/vorbis/CHANGES (original Lancer is based on libvorbis 1.1.2).

[sheh]

It seems there are decoding related changes since then. Also things like "Corrections to the specification" or "Fix a numerical instability in the edge extrapolation filter" which I don't know if are relevant or not. So staying with an old version isn't a good idea.

How did you do the merge? Comparing Lancer against AoTuV 5, then AoTuV 5 to 6, or libvorbis (and co.) 1.1.2 to 1.3.3, and patching in in unchanged parts?

Did you try creating new SSE code? If there are clear cases of calculations done on arrays, is it necessarily difficult?