Log in

View Full Version : sdk, command line & dual cpu


Shinobu
27th October 2004, 10:16
i done little test, i think it can be interesting:

test on a 5h12 full anamorphic encode 1-pass
CQ=70% EHQ=85% RACP 96K inloop=0 BFmax=3
(yv12 uncompressed file)

======================================
Dual cpu used:

SDK (preview disabled):

cpu time=5h49m37s
average cpu usage (global)= 80%


Command line:

cpu time=7h03m19s
average cpu usage (global)=78%

======================================
======================================

single cpu used (sample file to speed up te test):

SDK (preview disabled):

cpu time=1h01m37s
average cpu usage = 99%


Command line:

cpu time=1h02m42s
average cpu usage =99%
======================================

so in mono cpu configuration you can choose sdk or commandline apps, but in dual cpu config, sdk is far faster thant commandline.
an other strange thing is that on this settings producer don't consume the full power of dual cpu, but if i set EHQ to the max it consume 99% average cpu ....

++

Sirber
27th October 2004, 12:21
That's quite strange... :confused:

Sirber
27th October 2004, 15:41
Could you bench also on dual with preview enabled? Thanks!

karl_lillevold
27th October 2004, 18:14
Benchmarking with preview is not terribly interesting.. Why? Because preview has a lot of overhead, it was never optimized. The overhead includes color converting from I420 to RGB, then blitting with a non-optimized blit to the screen. For the best encoding performance it is essential to disable preview in the SDK.

Shinobu: This is interesting! and I have no immediate explanation. The codec should be dual threading and doing the same work in both the SDK and cmd line case. Would it be possible to make available the GUI you use, so I can measure on my dual system?

When you measure "CPU time" it can be confusing on a dual system. I assume you mean actual elapsed wall clock time, right?

karl_lillevold
27th October 2004, 18:17
Originally posted by Shinobu

an other strange thing is that on this settings producer don't consume the full power of dual cpu, but if i set EHQ to the max it consume 99% average cpu ....
This is maybe because without EHQ, the overhead (and waiting) of file reading and other operations in Producer is more significant relative to the encoding itself. I am guessing it's just a matter of waiting for data to be input to the codec.

Sirber
27th October 2004, 18:19
Originally posted by karl_lillevold
Benchmarking with preview is not terribly interesting.. Why? Because preview has a lot of overhead, it was never optimized. The overhead includes color converting from I420 to RGB, then blitting with a non-optimized blit to the screen. For the best encoding performance it is essential to disable preview in the SDK.I just want a comparison for the 2 mode avalible in RealAnime. SDK in RealAnime is with preview :) In my tests SDK is 20% slower than CMD on single CPU. I'd like the infos for a dual :o

Shinobu
27th October 2004, 19:05
@sirber
If i use video preview with sdk i'm 40 to 50 % slower.

@Karll
No i use the global cpu time witch is much more accurate than cpu clock (if windows stole cpu for his personnal use, the windows clock run but the cpu time don't move (hope i'm clear))
The gui i use for those tests is my personnal gui updated with last dll, i think all gui without preview will do the same.
i don't think it's a matter of "waiting for data to be input to the codec" because me test HD is a raid zero of 4 drives witch can read at constant speed of 112mo/s and write at constant speed of 89mo/s.

++

karl_lillevold
27th October 2004, 19:19
Shinobu: that's a speedy hard-drive! Then I think the problem is that it is not possible to dual thread all operations... both in the codec and in Producer. For instance color conversion is not dual threaded. However, the operations in EHQ are very well dual threaded. So with EHQ a much larger percentage of the required operations are performed in parallel, and you will get close to 100% CPU. Without EHQ, a larger share of operations are not done by both CPUs and you will not get 100% CPU utilizations.

Hmm, I will use Easy RM Producer then, and run some timings, after I get my dual system fixed.

Shinobu
27th October 2004, 20:25
thanks for the tips but my source was a yv12 uncompressed video so where was no color convertion (am i right?).

++

karl_lillevold
27th October 2004, 20:29
Originally posted by Shinobu
thanks for the tips but my source was a yv12 uncompressed video so where was no color convertion (am i right?).

Not much, no, but there are also internal codec operations that are not done in parallel, but I can not describe these in details here ;)

Sirber
29th October 2004, 17:53
I might add an option to use SDK but with no preview in next version In RealAnime.

Sirber
7th November 2004, 19:05
Just made a test on Lain's computer (P4 3Ghz Prescott, Dual Channel DDR400) with my universal "test.avi" anime sample:

SDK preview enabled: 1:23
SDK preview disabled: 1:18
commandline: 1:09

Encoded with: RealAnime 2.30 alpha 2
Loaded via: avisynth (DShow)
Note: Encoders were on IDLE mode, with focus

Shinobu
7th November 2004, 19:21
your prescot isn't a dual cpu ^^, it can be hyperthread, it's still not dual cpu...

i wait for your "final" 2.30 to tests it on my dual cpu on my test sample ^^.

++

Sirber
7th November 2004, 19:42
Test #2:

Fichier : Opening\Iketeru Futari Opening HQA.avi -- 22.2 mb

SDK avec preview : 5:01 - Memoire entre 800 et 830 mb (50%/50% ram + memoire virtuel)
SDK sans preview : 4:52 - Memoire entre 800 et 830 mb (50%/50% - ram + virtuel)
commandline : 4:12 - Memoire entre 400 et 430 mb (50%/50% - ram + virtuel)