Skip to main content

Topic: Ogg Vorbis acceleration project (Read 132064 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • lvqcl
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #175
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
  • [*][*][*][*][*]
Ogg Vorbis acceleration project
Reply #176
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
  • Last Edit: 11 July, 2012, 07:56:24 PM by eahm

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #177
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
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #178
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.
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

  • Brazil2
  • [*][*][*]
Ogg Vorbis acceleration project
Reply #179
The only difference is that the OLD was compiled within VS2008 and the other within VS2010.

Heh, newer doesn't always mean better

  • Destroid
  • [*][*][*][*][*]
Ogg Vorbis acceleration project
Reply #180
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
"Something bothering you, Mister Spock?"

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #181
Could you test also SSE version?
  • Last Edit: 22 July, 2012, 07:47:01 AM by lvqcl

  • IgorC
  • [*][*][*][*][*]
Ogg Vorbis acceleration project
Reply #182
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
  • [*][*][*][*][*]
Ogg Vorbis acceleration project
Reply #183
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: [Select]
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
  • Last Edit: 22 July, 2012, 01:46:10 PM by Destroid
"Something bothering you, Mister Spock?"

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #184
oggenc "02/20/2012" is based on aoTuV 5.7, not 6.03

  • Destroid
  • [*][*][*][*][*]
Ogg Vorbis acceleration project
Reply #185
 Fixed.

I got pretty confused with this many binaries.
"Something bothering you, Mister Spock?"

  • Destroid
  • [*][*][*][*][*]
Ogg Vorbis acceleration project
Reply #186
(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.
"Something bothering you, Mister Spock?"

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #187
Quote
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
  • [*][*]
Ogg Vorbis acceleration project
Reply #188
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
  • [*][*]
Ogg Vorbis acceleration project
Reply #189
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
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #190
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
  • [*][*]
Ogg Vorbis acceleration project
Reply #191
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?

  • AshenTech
  • [*][*]
Ogg Vorbis acceleration project
Reply #192
any chance of a compile with FMA support? 

we cant get an intel compiler build with AVX support because intels compiler blocks non-intel chips from getting AVX code paths sadly, but FMA could have a beneficial effect on encode performance I would think

Ogg Vorbis acceleration project
Reply #193
Can we hope to see Oggenc Lancer Build based on aoTuV beta6.03 unified with Xiph.Org's libvorbis1.3.4?

  • hidn
  • [*][*]
Ogg Vorbis acceleration project
Reply #194
Quote
Ogg Vorbis acceleration project, Is it dead?

Yes. As vorbis himself. Xiph developing another codec "opus". Welcome, new abandonware. For people who support vorbis nothing remains except "thanks". Fate of many open source projects, lack of interest.

Tuning is boring? Start new project.
  • Last Edit: 01 June, 2014, 09:53:33 AM by hidn

Ogg Vorbis acceleration project
Reply #195
Quote
Ogg Vorbis acceleration project, Is it dead?

Yes. As vorbis himself. Xiph developing another codec "opus". Welcome, new abandonware. For people who support vorbis nothing remains except "thanks". Fate of many open source projects, lack of interest.

Tuning is boring? Start new project.



How about wide hardware support? I'm not sure if the opus will get it even in next 2 years. That's nonsense (to close Vorbis project). Also AFAIK Opus has more targeting onto low latency and low bitrate (of course not without a cost of quality loses for simple file encoding at medium bitrates).
  • Last Edit: 01 June, 2014, 01:59:25 PM by Steve Forte Rio

  • skamp
  • [*][*][*][*][*]
  • Developer
Ogg Vorbis acceleration project
Reply #196
1) Ogg Vorbis works very well in its current iteration;
2) Codec support these days is probably more software than "hardware".
See my profile for measurements, tools and recommendations.