64-bit vs 32-bit

Bryan Kadzban bryan at kadzban.is-a-geek.net
Mon Mar 26 19:31:43 PDT 2007


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.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20070326/b7dee2f1/attachment.sig>


More information about the lfs-dev mailing list