Bryan Kadzban wrote: > If I remember, I'll try to transcode 10-20 minutes' worth of MPEG2 > video to xvid (MPEG4) on both architectures. Both tests will run > under the same 64-bit kernel, but one will be a 32-bit process and > the other will be 64.
OK, the test was the following: I catted data from my TV card (encodes to MPEG2 in hardware) to an mpeg file for 20 minutes. Then I ran transcode on that file to convert it to xvid4. I ran the tests twice. First, the 64-bit test ran fine. But when I ran the 32-bit test, it decided it wanted to mute the audio -- so to make the tests the same, I disabled audio processing in both tests (using the arguments "-y mpeg2,null -x xvid4,null"), and ran them both again. Results from the first 32-bit, second 64-bit, and second 32-bit tests are below: 1) 32-bit, audio not turned off, but it decided to mute: encoding frames [000000-035932], 40.70 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real 14m42.927s user 19m33.863s sys 0m36.278s 2) 64-bit, audio turned off: encoding frames [000000-035932], 40.22 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real 14m53.887s user 19m9.208s sys 0m35.318s 3) 32-bit, audio turned off: encoding frames [000000-035932], 40.66 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real 14m44.144s user 19m33.503s sys 0m37.031s Summary: 32-bit code runs in less wall-clock time, but more actual CPU time. This is a dual-core system, and something decided to schedule the 32-bit processes differently, which made their work get done faster. This is also why the FPS numbers are higher for 32-bit: the FPS numbers are frames per wall-clock second. It's also why real time is below user time: the work was split between cores (100% of one core and about 30-50% of the other, with the 100% core switching every couple of minutes as the tasks got swapped). If I used a single-core system, 32-bit would have taken more time under both real and user. But only slightly more time: the differences are only ten wall-clock seconds over 14 minutes (1.1%), or 20 CPU seconds over 20 CPU minutes (1.7%). This is probably well below the level of statistical significance, although I don't remember much statistics, so I can't do any significance tests on the numbers. (The system time is a couple seconds faster on 64-bit also, but I think that's because no translation from 32-bit to 64-bit was required inside the kernel for the 64-bit process. Over 20 minutes of read and write syscalls, this adds up.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
