View Full Version : Xvid on Quadcore (Faster than Dualcore?)
JnZ
6th August 2007, 16:30
you can try DivX or NeroDigital. They all support multicores, or if you have time and have some coding skills, help the xvid devs implementing better multithreading algorithms.
Yeah I've got some coding skills, but I'm afraid not skills of this type. :) I have only few idea how today's video codecs works. Changing VFW interface for XviD? Not problem. But changing some core code...this soudns like a joke for me now. :D But I try make some serious tests and try compile latest CVS XviD binaries, maybe this helps.
Nero or DivX? I'm litlle bit skeptic with DivX codec, but maybe I try it both and post results.
JnZ
7th August 2007, 08:27
So I make some real tests with every promising codecs (codec that seems supports multicore encoding). There are the results:
-------------------------+-----------------+-----------------------+--------------+
Codec | X2@2500MHz | 2 x Opt285 (2600MHz) | Quad speedup |
-------------------------+-----------------+-----------------------+--------------+
x264 r.667 | 15 fps (95%) | 32 fps (95%) | 113 % |
XviD 1.2-127 (MSVC05) | 20 fps (80%) | 27 fps (50%) | 35 % |
DivX 6.6.1 | 24 fps (80%) | 32 fps (50%) | 33 % |
Nero Digital | 45 fps (95%) | 46 fps (50%) | 2 % |
Nero Digital AVC | 23,5 fps (95%) | 23,8 fps (50%) | 1 % |
FFDshow MPEG-4 | 20 fps (95%) | 27 fps (50%) | 35 % |
-------------------------+-----------------+-----------------------+--------------+
Number in brackets is CPU usage during encoding process
Hmm, it seems that any of these codecs (except x264) can't prosper advantage of quad core machine. Only x264 and with full potencial.
Another thing. Maybe problem can be in Quad encoding machine graphic card. It's Voodoo 3, which maybe don't have real video overlay, so maybe this is maybe the problem I think. x264 runs in console, but other codecs not. I remove graphic card from my machine (Gf7600) and put it to the Quad machine and we will see.
Manao
7th August 2007, 08:39
It's Voodoo 3, which maybe don't have real video overlay, so maybe this is maybe the problem I thinkI strongly doubt that.
The figures you're getting with Xvid, DivX, FFDShow are consistent.
Those with Nero Digital AVC are a bit strange though. What version of ND are you using ? Because it should scale better than that.
JnZ
7th August 2007, 10:17
Those with Nero Digital AVC are a bit strange though. What version of ND are you using ? Because it should scale better than that.
I use nero Recode v. 2.3.7.0.
Anyway, I try change Voodoo 3 for Gf7600 and every codec run's at similar speed, so graphics card isn't the problem.
Every codecs don't have problem to stress dualcore, but in quadcore case, only x264 can stress it almost to 100%. Almost double speedup is noticeable also with encoding HDDVD's to x264, which runs about 7fps. At DC it runs about 3,5fps.
Developers maybe tests their codecs with duals, but no with quads...this "time" not come yet, maybe if quads becomes more avilable for ordinary people, it maybe changes.
Inventive Software
7th August 2007, 10:57
Those are slow encoding speeds you're getting... you doing HD encoding per chance? ;)
JnZ
7th August 2007, 11:03
Those are slow encoding speeds you're getting... you doing HD encoding per chance? ;)
:D no...coz I use almost insane settings...and I know why ;) I have almost 60 own HDrips...
Sharktooth
7th August 2007, 12:54
Weird... nero recode should be MUCH faster than that.
Have you set the number of threads in the encoder options (expert mode) to 4 on the opteron box?
JnZ
7th August 2007, 13:22
Weird... nero recode should be MUCH faster than that.
Have you set the number of threads in the encoder options (expert mode) to 4 on the opteron box?
I expect much more speed too. Maybe I use not good source (not ordinary DVD, but FFV1 lossless source). So I check ordinary DVD backup and report then.
Inventive Software
7th August 2007, 15:23
FFV1 doesn't have particularly fast decode speed (though it is faster than MSU Lossless ;)). Convert it to another lossless codec with faster decode speed, HuffYUV or Lagarith for instance, or (at a push) uncompressed file and see what difference that makes.
Mutant_Fruit
8th August 2007, 05:42
I just want to post some facts about X264 and it's ability to utilise an 'octcore' machine before more fud is spread about what is and isn't possible. These results should be applicable to quadcores too. i.e. x264 can utilise a quadcore to 80+% efficiency under certain circumstances.
http://forum.doom9.org/showpost.php?p=995797&postcount=114
EDIT: Just in case people get bogged down with all those numbers, clip3 with 7 threads and threadpool patch 3 gave a CPU utilisation of 740% on an 8core.
Sharktooth
8th August 2007, 12:08
I think the problem is with xvid and not with x264...
we all know x264 has a more efficient threading model and it scales really well.
JnZ
8th August 2007, 12:25
I think the problem is with xvid and not with x264...
we all know x264 has a more efficient threading model and it scales really well.
I think problem is with major todays apps, I try 7-zip, wich supports MT, but same problem, only 50% usage. Todays apps have "false" multicore support I think, dualcore ready, but quad not. :)
Sharktooth
8th August 2007, 12:49
I think problem is with major todays apps, I try 7-zip, wich supports MT, but same problem, only 50% usage. Todays apps have "false" multicore support I think, dualcore ready, but quad not. :)
What version of 7-zip? The latest (currently 4.51b) lets you specify the number of threads in the options...
JnZ
8th August 2007, 13:36
What version of 7-zip? The latest (currently 4.51b) lets you specify the number of threads in the options...
Ou I didn't notice that. So with 4.52b nice results:
http://img161.imageshack.us/img161/9202/x2ka4.gif (http://imageshack.us)
1 x X2 (2 x 2500MHz)
http://img165.imageshack.us/img165/2529/o285ei3.gif (http://imageshack.us)
2 x Opteron 285 (4 x 2600MHz)
So compression 2244KB/s vs 4627KB/s and decompressing 38286KB/s vs 80666KB/s.
Considering this, nice results. But with 4.42 stable version I achieve only 50% on quad. It seeems that quad machines slowly goes to mainstream segment...and developers accept them, but slowly.
Mutant_Fruit
9th August 2007, 20:38
I think the problem is with xvid and not with x264...
That's all i wanted to hear. You see, originally you were claiming the slow speeds were due to architectural problems in 'fake quadcores'. I'm glad you've realised that in fact it is a problem with xvid and not a problem inherent in 'fake' quadcores.
Sharktooth
10th August 2007, 03:31
Well, i said it is a combination of those 2 factors.
Mutant_Fruit
10th August 2007, 05:09
I think problem is with major todays apps, I try 7-zip, wich supports MT, but same problem, only 50% usage. Todays apps have "false" multicore support I think, dualcore ready, but quad not. :)
I wouldn't quite go as far as saying they have false multi-core support. Even x264 can't max out an 8core under all circumstances. For example, clip 3 gave a max CPU usage of nearly 750%, very close to the theoretical limit, yet clip 1 gave a max of 350% which is shockingly bad for an 8core machine. You might look at the figures from clip 1 and say "oh god, that 8 core computer sucks, the CPU architecture is awful", or you might say "Oh god, x264 sucks, it's multi-threading is awful".
The problem actually is that many tasks are inherently serial. You can't do B until you've done A. Therefore (as a rule of thumb) you will never get linear speed increases as cores increase, and (as can be seen in several benchmark apps), you simply get no increase at all as you add cores. File compression using the .zip compression algorithm might simply be one of those tasks that cant be easily multithreaded.
Sharktooth
10th August 2007, 14:32
Parallelizing an algorithm isnt always easy.
In some circumstancies you cant just get better results until you re-design the whole thing (usually breaking the compatibility with past implementations).
|sawo|
26th October 2007, 07:12
There is no need to redesign anything.Even if intel release today completely new acrchitecture its still up to the software developers to use it.I have seen benchmark results of the new 'true' quad-core processors - units provided by intel for testing (that means the unites are slightly better than the ones you will get at home) and i can say that the new 'true' quad's are less than 10% faster (my Q6600 clocked at 3500mhz can beat pretty easy one of the new 3000mhz quad's with very noticable difference)
So dont expect miracles with the new quad core processors there will be some improvements, but the software developers still need to do their job on both today's C2Q and the ones that will come soon.
And please DONT mention Adobe - these lamers cant even release 64bit flash player(after years of no progress they forced the users to develop their own GPL flash player), not to mention multi threading apps....
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.