MPC-HC 64 bit slower than 32 bit (MPEG)

[Maksee]

Hi,
for my laptop having AMD Athlon X2 Dual-Core 2100 Caspian (M320) and Windows 7 64 bit Home premium I downloaded MediaPlayer Classic Home Cinema 64 bit. Noticed that a sony demo 1080 mpg (30 fps) could not be decoded successfully, it managed to keep up with about 24 frames per second (internal filter used). But when I downloaded 32 bit version, it started to show this demo flawlessly with 30 fps and not full CPU load.

Is it a known issue? Is it related to the core MPC code or some between-architecture calls for some filters? I have no problem using 32-bit version, but knowing such things can help taking this into account in future

Thanks in advance,

Max

[Mangix]

yes, the 64-bit version of MPC-HC is known to be slower. It's recommended to use the 32-bit version since it's faster and more compatible with everything like quicktime and such...

[Scoty]

Why is the 64Bit slower?

[nurbs]

Maybe less handwritten 64bit assembly in the decoders?

[clsid]

MPC itself has little to none assembly. But ffdshow and MPC's internal ffmpeg decoders do. And yes, those contain a smaller amount of optimized assembly code in 64-bit builds.

[Maksee]

And yes, those contain a smaller amount of optimized assembly code in 64-bit builds.

I still don't understand. If architecture is x86-64 (http://en.wikipedia.org/wiki/X86-64), who is the bad guy? All 32-bit instructions are working, so all optimizations for 32bit architecture should work either. Or MSVC can generate "worse" instructions in specific cases for 64 bit architecture?

[LoRd_MuldeR]

Decoders are highly optimized code, in order to provide good playback performance. And the best performance is still achieved with hand-optimized assembler code. Even the best compilers with all their fancy auto-optimizations can't generated code that is as fast as a hand-optimized code written by one of the assembler gurus. However assembler code written for the x86 architecture -- and 99% of all assembler code written for PC software in the last three decades was developed for x86 -- doesn't run on amd64 (aka "x86-64") automatically. So when we built a software for amd64 instead of x86, we must either port all the assembler code to amd64 manually -- which may be a though task and a lot of work -- or we simply disable all the assembler code that won't run on amd64 yet. Disabling the assembler code means that we fall back to the plain C code, which will be much slower than the highly-optimized assembler code, even if compiled for amd64.

BTW: It is correct that all "instructions" of x86 are still available on amd64, but the ABI (Application Binary Interface) has changed significantly between 32-Bit and 64-Bit - at least on the Microsoft Windows platforms. As far as I know, this is one major reason why assembler code written for x86 cannot be ported to amd64 easily. Furthermore "inline assembly" is no longer supported by MSVC for 64-Bit, which means that all existing inline assembly must be disabled/replaced when compiling amd64 binaries with MSVC. That's another huge pitfall for 64-Bit performance, when porting existing applications...

[nurbs]

Furthermore it doesn't necessarily work across operating systems either. From what I read here 64bit assembly written for linux won't work on windows without changes and vice versa.

[LoRd_MuldeR]

Furthermore it doesn't necessarily work across operating systems either. From what I read here 64bit assembly written for linux won't work on windows without changes and vice versa.

That's also because of Microsoft Window's weird 64-Bit ABI (Application Binary Interface), which apparently is very different from the rest of the world :rolleyes:

[Maksee]

BTW: It is correct that all "instructions" of x86 are still available on amd64, but the ABI (Application Binary Interface) has changed significantly between 32-Bit and 64-Bit - at least on the Microsoft Windows platforms. As far as I know, this is one major reason why assembler code written for x86 cannot be ported to amd64 easily.

You're probably right, even though documents like Optimizing Applications on 64-bit Windows for AMD64 ... (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_AMD64_PortApp.pdf) promises very much (easy, faster and so on), I think that reality bites. I like a very short sentence in this document about the fact that MMX extensions no longer works, SSE and up only supported. MMX itself indeed is very old, but if one once made some optimization and it suddenly no longer works, it is much easier to disable optimization whatsoever