Bryan Kadzban wrote: > 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.)
Thanks Bryan. That is a very interesting result. It's only one data point, but it tends to confirm other reports that I have seen that 64 bit processing isn't significantly faster for most tasks. If you are running a server with > 4G Ram and very large data sets (i.e. a large database) the additional memory address size would be a definite advantage. Also if you are doing very compute intensive tasks such as solving systems of differential equations (e.g. computational fluid dynamics), 64-bit processing can make a difference. Until I see a need, I'm going to stick with 32-bit computing. YMMV -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
