Bruce Dubbs wrote: > 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.
Or, running a render farm. raytrace rendering of individual frames for an animation sequence is also very intensive. The higher the quality the more calculations per pixel needed. I have seen single frames require upwards of 48 hours to render on 32 bit systems, the same image takes < 24 hours on 64 bit. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
