About multicore performance

[Nielzie]

32bit and 64bit refer to CPU architecture. This goes well beyond just the amount of RAM that can be addressed. The physical restriction on addressable RAM is the number of address lines on the CPU address bus.

http://en.wikipedia.org/wiki/X86-64#Arc ... l_features is probably a good quick summary.

Yes of course, but technical details aside, 32-bit programs run still just as fast as 64-bit programs on this architecture. The only noticable advantage seems to be the allocation of RAM.

[pljones]

64bit programs generally run faster than 32bit programs on a 64bit machine because they can take advantage of the architecture. 32bit programs see the architecture from an "old world" view point (more or less). It's not just about RAM. It's a whole different way of running a program.

So, given that the question was about running a 64bit program on a 64bit platform - rather than running a 32bit program on a 64bit platform - that's just as pertinent.

[Crackbaby]

about how much faster?

[Nielzie]

In todays software I think the difference is minimal. The 64-bit version of IE9 was even a lot slower then the 32-bit version on Windows 7 64-bit. That's because it was compiled with a Jit compiler or something.

It always depends on the application (coding/compiling) but I never noticed any increasement in speed on any of my software applications between the 32-bit or 64-bit versions.

Perhaps I only noticed with 7-zip when compressing huge files, but I guess that's also particularly memory related.

Probably in future applications the speed difference between 32/64-bit versions will grow when apps will use more complex code. But then again, processor clock speeds will increase too with every new cpu.

[pljones]

Here's a real world test.

Take a 48 minute 26 second, three track project, mix down to a single audio file, then compress to ogg. Host OS: Win7x64. MuLab: 5.0.41. ffmpeg: 20130306-git-28adecf static.

Mixdown: 32bit: 18s -|- 64bit: 46s
Compress: 32bit: 2m50s -|- 64bit: 2m05s

So 64bit was 17 seconds quicker on this in total. ffmpeg was compiled using GCC 4.7.2, which may be why it takes fuller advantage of the x86_64 instruction set. I don't know what compiler MuLab is built with.

[Nielzie]

Thanks

Hmmm interesting to see that the mixdown with MuLab 32-bit in your example was significally faster than in MuLab 64-bit.

Maybe Jo has an answer to why that is?

[mutools]

Strange test results indeed. I have no idea, except that the encoder may be very much optimized for specific architectures? I assume that the 64 bit system was a slower system or with less cores or with other audio setup. (smaller blocksize/higher samplerate)

[sl23]

I asked John T. Haller (PortableApps.com) about the difference between 32/64bit and this was his answer.

Not Much Difference

For most computing tasks, there's not really a ton of difference between the two. On Windows, the biggest benefits of 64-bit are at the OS level since you get access to more RAM (4GB for 32-bit vs 192GB for 64-bit on Windows Pro 7 or up), the virtualization extensions (better VM performance) in the newer CPUs, and No eXecute bits (mark areas of RAM as not able to execute for better protection). None of these apply directly to apps, though.

What they can get apps is access to more than 2GB of RAM and/or better performance. The thing is, most apps don't need 2GB of RAM or even close to it. The exceptions being video editing, editing very large image files, or working with large sets of data for processing and similar endeavors.

On the performance side, the difference between 32-bit and 64-bit isn't much in most cases. You'd think it would be. It's double the bits so it must be double the performance, right? Well, no. It does improve some CPU-limited operations of applications when working with the wider bit-path can help. But, even with an app that is totally CPU-limited, the performance gains are modest.

7-Zip, for example, which is doing lots of intensive compression algorithms is CPU-limited. But the 64-bit version only yields a performance gain of up to ~7% in testing. And then even only on some files. But, since some people compress GBs of data with 7-Zip, we thought we'd dual mode the app (32-bit and 64-bit in one package). The fact that it's a small app also factored in.

Realistically, you won't even notice the difference in normal operation of regular apps. You're likely looking at no performance gain in most of them. Or, at least, no noticeable one. Even 7-Zip's "large" difference between the two is only noticeable when working with very large compressed filed.

Unless you have specifically run into a problem that requires you to use 64-bit, you don't *need* to use 64-bit. Very, very few things need 64-bit.

A ton of 64-bit apps lag their 32-bit counterparts because they aren't taking advantage of what 64-bit offers. A ton of others offer a 32-bit and 64-bit version even though the 64-bit version offers nothing that users actually need. And then others make proper use of 64-bit.

[pljones]

Strange test results indeed. I have no idea, except that the encoder may be very much optimized for specific architectures? I assume that the 64 bit system was a slower system or with less cores or with other audio setup. (smaller blocksize/higher samplerate)

All on the same PC and OS, all tests run through twice with the second scores taken (to make sure any disk load times were reduced as a factor). The only differences being the bittage of MuLab and the bittage of ffmpeg. As I say, GCC is well known for making a good job of optimising code for specific architectures, so I'm not at all surprised ffmpeg does better on 64bit, as it should.

I could also run a simpler test on ffmpeg more similar to the workload through MuLab, i.e. simply trying to convert from WAV to WAV...

I asked John T. Haller (PortableApps.com) about the difference between 32/64bit and this was his answer.

That's a good summary. The architecture is faster but whether it's noticeably faster varies with the workload and, as pointed out earlier by Nielzie, can run slower if a compiler produced slow 64bit code.

[mutools]

I had a completely other result:

Mixing down Dream Of The Piano demo using MuLab 5.0.41 on a Win 7 64 bit system:

MuLab 32 bit took 34 sec.
MuLab 64 bit took 16 sec.

I double checked the test. When i double-checked i copied the 64 bit MuLab.exe into the 32 bit MuLab folder (renamed as MuLab64.exe) then ran both exes (not simultaneous of course) from the same setup folder so to make sure they were sharing the same setup.

[pljones]

Different tests will have differing results but that's more the kind of result I'd expect when more than a straight mix of three audio streams is being done, which is all I was testing on. I didn't think of trying the exes from the same folder but that's a good point: despite trying to make sure my settings were the same, that would ensure it. I have to say, the particular test I ran felt unusually slow, too, for M5-64!