On Thursday 11 March 2004 04:33, Sergei Klink wrote:
It should be noted that the 64-bit version is slower than a well configured 32-bit version. For example converting PAL MPEG2 -> MPEG4+MP3 is more than twice as fast in 32-bit mode.
/Henk
And I assume you also can only get win32 dlls support(thus quicktime,etc) from 32bit version(I use 32bit rpms from the apt repository, they seem to be just fine). Btw, I didn't have much luck(=none) getting replies about compilation errors on mplayer-users...Maybe I'll try posting them here someday :) When compiling in 64bit mode, it doesn't seem to really recognize the cpu and doesn't enable even half of the possible extensions...
You're right; If you want to let's say play rtsp:// RealMedia , you need the 32bit version. I am quite sure it is software/technically possible to combine 64bit- and 32bit code in such a way that the users only sees a 64bit process, but there is not much to gain there. If you compile mplayer in 32bit mode using only plain C (so not using i386 assembly versions) but with gcc -march=k8 and do the same in 64bit mode (which is only plain C and arch=k8+ by default) then the 64bit version is roughly about 10%-15% faster than the 32bit version. The real showstopper is the amount of fixed-register 32bit addressing in the assembly accellerators. Although you can get some i386 assembly code to compile in 64bit mode, most parts do not. :( Only the code that uses MMX/SSE intrinsics (xmmintrin.h) is perfectly portable and is the best way to benefit from the extra- and wider registers of the AMD64. If there is anyone that has compiled mplayer (or any other opensource signal processing software) in 64bit mode with a commercial compiler, I'll be very curious to know about the speedups compared to the 32bit version. /Henk