32 bit vs 64 bit

• Aug 15, 2015 - 07:27

Hi, gang!!!

It seems that 64 bit CPUs run faster than 32 bit counterpart. I say "it seems that...", because I'm not sure if it is absolutely true.

As I guess, MuseScore is a 32 bit software, because it runs into 32 bit operating systems and it is the same version which runs into 64 bit systems. Up to my limited knowledge, there is not a separate 64 bit version into the download page (maybe I'm wrong).

But, I wonder if there would be some advantage if there would be a 64 bit MuseScore specific version? What we would win? ???

Just a question.

Greetings & Blessings from Chile!!!!!!!

Juan


Comments

Hi,

MuseScore is not per se a 64 or 32 bit software. Currently it's available as a 64 bit binary on Mac OSX, also on several Linux distribution. These packages will only run on an 64bit operating system, running on a 64bit CPU. Virtually all the macs are 64bit so it's ok. On Linux, distribution also provides 32bit builds.

On Windows, the official package is indeed 32 bit. It runs on windows 32 or 64 bit on whatever CPU. There is a non supported 64 bit build for windows too. It runs only on a windows 64bit, running on a 64bit CPU. It's unlikely that it will run faster than the 32bit. The only two reasons we know that make it worth using the 64bit version are:
* MuseScore has a larger amount of memory to play with and that can be handy if you load several big SFZ files (and you have enough memory on your computer)
* Apparently some MIDI keyboard only provide 64bit driver and so can only be used with a 64 bit version of MuseScore.

The difference between a 64 bit and 32 bit processors is....

a) the amount of data they can move in one go.

b) The amount of memory that it can address.

The 64 bit processor can move twice the amount of data that the 32 bit processor can, and it can also address twice the amount of RAM.

This doesn't mean that it will actually run faster than a 32 bit machine as there are other factors to consider such as the width of data I/O busses.

What it does mean is that it will be more accurate when doing floating point calculations as it will work to more decimal places. This has implications in DAW systems, particularly for effects like reverb, and for physical modelling VST effects and instruments.

For an application like MuseScore which, as far as I know, doesn't indulge in hundreds of simultaneous floating point calculations, there is very little difference, other than the quantity of RAM 64 bit can address, as Lasconic has already said.

So the only impact using a 64 bit machine is likely to have on your MuseScore use is the size of soundfont or SFZ you are able to load, or if you are using JACK to route MuseScore MIDI output to a VST.

In reply to by Jojo-Schmitz

Thank you so much for your data, guys!!!

You have been a very great help to my very ignorant and limited mind, hehehehehe!!!

BTW: My old PC (from 2003) is a Pentium 4, 3 GHZ, 64 bit CPU, but I don't have too much RAM (just 2 GB). Would I win something if I changed from a 32 bit Lubuntu version to a 64 bit version? ???

Greetings & Blessings from Curicó, Chile (South America)!!!!!!!

Juan

I doubt that you would gain anything by switching from 32- to 64-bit lubuntu but if you were really concerned about it you could always try dual-booting and doing some benchmark tests. The only reason to switch as I see it would be if you had some software or hardware that exclusively used 64-bit drivers.

In reply to by underquark

I agree with what underquark is saying.

Where you might gain some speed is by doubling the RAM to 4 GB. Which ISTR is the max that a 32 bit processor can address?

Basically the more RAM you can throw at a processor the faster it can operate.

As I hinted before - most bottlenecks are in storage I/O so if your machine is constantly using the swap drive it will run slower than if it can use RAM instead.

In reply to by ChurchOrganist

Thank you, Thank you, Thank you so much for your data!!!!!!!

Now I have a very clear "panorama" about this issue.

I think I will be with the 32 bit system for a while.

Just in case, I don't know (and I don't have) any MuseScore problem because the amount of data involved (I've run the Beethoven Ninth Symphony 4th movement without problems with less than 2 GB of RAM). BUT, Is it possible to reach an "Out-of-Memory" state with MuseScore? ???

Some minor technical notes:

x86-64 has 16 general-purpose registers, while 32-bit x86 only has 8 general-purpose registers. The larger register file helps the compiler avoid some pushes & pops to the stack, which will result in a small speedup.

But, on the other hand, the size of pointers is twice a big in 64-bit builds and compilers may (or may not) increase the size of other types like ints. So datastructures may be slightly larger, which may actually cause a slight slowdown with 64-bit builds due to increase pressure on the cpu's cache.

I doubt those effects will not be human-noticeable. Assuming everything else is equal, then there should be no significant speed difference when running 32-bit musescore vs 64-bit musescore on the same x86-64 machine. As lasconic says, the only need for 64-bit builds is if your midi driver requires it, or it you want to load huge sfz. But, since I enabled the "large address aware" option in the makefiles, future 32-bit builds will be able to access 4GB of space (which is increased from the previous 2GB limit) when run on x86-64 machines, and I've tested that the 32-bit git builds are now able to hold a couple of "huge" sfz when run on x86-64 machine before failing due to exhausting the 32-bit address space. Sometimes it does crash if the call stack happens to overflow first before the memory allocation has a chance to throw a bad_alloc exception (or if the bad_alloc expection is not caught). So yes it is possible to reach an "Out-of-Memory" state with MuseScore.

Some other minor notes. The number of bits in a "float" or "double" has not automatically increased when going to from x86 to x86-64, since both architectures still implement the "x87" float specs, where a "float" is still 32-bit, a "double" is still 64-bit, and a "long double" is still 80-bit. All the declarations of "float" in the code would have to be replaced with "double" or more in order to get better precision for floats. (Interestingly, x87 by default always performs calculation in 80-bit internally, but you'll loose those extra bits when those registers get stored in memory).

A 3Ghz Pentium 4 with 2GB should be fine. Just use the default soundfont and don't have other programs open. If you do run into some lag on large scores, then I would suggest working with smaller scores that you later combine together with the album feature.

In reply to by jotape1960

No. The short answer is that adding more memory will do very little for you unless you sometimes use up all available RAM. If you temporarily run out of RAM, you will likely notice a big slowdown. Otherwise it won't speed up your computer AT ALL, and you will probably derive almost no benefit from adding RAM.

I have not used Musescore for large scores. Nevertheless, it doesn't seem to use a lot of memory. I would be astonished if it used up your available RAM, especially since you have a whole 2 GB.

You can use the System Monitor to see how much programs are using. There are other methods, but I don't want to answer questions about any of them, since the Internet has lots of answers.

One area where RAM might speed up your computer a little is in caching software. You could conceivably notice that a program starts a little faster if the code is already memory-resident, and increasing the amount of RAM may sometimes make a program start a few seconds faster. That's probably not worth rebuilding your computer.

Recently Web browsers and some other Web programs have begun to use prodigious amounts of memory, and they could indeed bring your computer to its knees. If you feed that beast, it will probably use all of memory and demand even more. Feed it if you wish, but it seems pointless to buy more memory just for Musescore.

Do you still have an unanswered question? Please log in first to post your question.