32-bit vs. 64-bit tutorial

Memory

Let's start by explaining the fundamentals of memory. RAM (random access memory) is a very fast memory, which is used to store all currently running applications and the associated data needed. In our case this would relate to blocks of audio data, D.A.W. software & related programs, virtual instruments and samples etc. If there is not enough RAM memory available to store all of this data, the O/S (operating system) can 'swap' part of it onto the hard drive and load it back into memory when needed. However this swapping comes at a cost - speed.

RAM is not the fastest memory in the computer, in fact it is relatively slow compared to the processor speed. First there is 'cache' memory, which is similar to RAM, but is in much closer proximity to the CPU. While RAM is connected to the CPU via wires several centimeters in length, called a 'system bus', cache memory is usually integrated inside the CPU itself. Unfortunately, it is also more expensive than RAM, so it is usually only supplied in batches of just a few megabytes. Cache is situated between the CPU and RAM, so when looking for data, the processor visits the cache first and only accesses the RAM when the information it needs is not present in the cache.

The fastest memory in the computer is called the 'register', which is actually as fast as the CPU itself. Most work is done inside it but its size isn't measured in gigabytes, megabytes or even kilobytes. You only have a few hundred bytes, with the actual amount defined by the CPU architecture.

Do you really need more memory?

32-bit systems can address up to around 3GB of memory. This limit must suffice for the whole system and all running applications, otherwise something will get swapped. In addition, there is another limitation for separate applications - usually 2GB. This 3GB limit still seems generous, but besides actual samples it will also contain all executables and temporary files etc. After all these are taken into account, you probably have around 1.5GB free for your project.

Is this enough? Well it usually is, so let's look at an example of a large audio project. Let's say that our project needs 3GB of RAM. 1GB of this will be taken by up by executables and temporary structures and so is effectively lost. The remaining 2GB contains the data to be loaded from your hard drive. This data is usually compressed, so we could estimate that with lossless audio compression and the structures needed for random access, we would need to load about 1GB from the disk. Even though modern hard disks have become a lot faster, with fragmentation and simultaneous operations, a fair estimate of the fastest loading speed would be around 50MB per second. Therefore loading all the data will take 20 seconds. Add to this the time to compute the temporary structures, and even with an 8-core processor, it will take 25 seconds to load.

25 seconds to load a project! Do you really want to wait that long? Well, sometimes you don't have a choice, but this scenario does highlight the disadvantages of using so much memory.

Why have 64-bit architectures been developed?

Frankly, not for audio. The main reason for development was to meet the continuously increasing demands from servers. Unlike D.A.W. programs, which are basically the exclusive main applications when working with audio, servers process hundreds of requests at once using terabyte databases. They also access the data in a virtually random order, so it is necessary to keep as much of the data in memory as possible.

Now that 64-bit processors have been developed for servers, why not use them in other applications as well? Memory was a major issue for developers back in the days of 16-bit architectures. With the arrival of 32-bit systems, speed became the priority and so we started wasting memory until eventually the limit was reached. With the advent of 64-bit machines, the same situation has happened once again. So now we need lots of memory for audio, video, games etc...

Do you need to go 64 bit? It's probable that within 5 years most computers will be running 64-bit operating systems and therefore most of the applications will also be 64-bit. Until then, can you manage without upgrading? We cover some key details below to help you decide.

What do you need to "be 64-bit" ?

First of all you need a 64-bit compatible processor, almost all of them are 64-bit these days. With the exception of the high end server based "Itanium" processor (which you aren't likely to come across), all of them are also backward compatible with 32-bit architecture, so it is not uncommon to see notebooks running 64-bit processors with a 32-bit operating system installed.

Secondly, you need a 64-bit operating system, Windows Vista/7/8/10, Mac OS 10.6 are all now available as 64-bit. Next you require 64-bit applications. This is where it gets much more complicated since many hosts are only 32-bit. If you run a 32-bit application in a 64-bit operating system, the CPU is switched to 32-bit mode with only a minimal performance degradation, which we will cover later.

Finally you also need 64-bit plugins. Well, that's not completely true. When the developers were switching to 64-bit hosts, they couldn't release them immediately, because people still needed to use their plugins, which didn't exist for the 64-bit platform. To overcome this issue they had to develop so-called 'bridges' first. A bridge is a separate application that runs between a particular plugin and the host. If the host needs something from the plugin, it creates a request, which the system scheduler switches to the bridge. It is the bridge that actually asks the plugin to carry out the operation, and then gives the data back to the host. Pretty complicated, isn't it?

With bridges everything becomes much more complicated, slower and less reliable. Therefore we strongly suggest using bridges only if there is no other choice. If your plugins are mostly available as 32-bit only, and you are not running out of memory, then the advice would be to stick with a 32-bit host even if the host itself is available as 64-bit.

The golden rule is - if you use a 32-bit host, use 32-bit plugins. If you use 64-bit host, use 64-bit plugins.

x32 vs. x64

Now we can finally get to the 32-bit versus 64-bit architecture question. For the purposes of this tutorial we won't be considering 16-bit platforms, since they are basically now obsolete (even washing machines now use 32-bit processors!).

We will also use the identifier x64, for referring to 64-bit architecture, and similarly x32 for 32-bit architecture.

Does x64 improve audio quality?

No, x64 is the way the processor works internally. It has nothing to do with actual computations. For example, processing audio often requires multiplication, so the processor contains several 'multiplication' units and uses them when needed. It doesn't matter if it is in 32-bit or 64-bit mode, it will eventually use the same unit to get the correct result.
Do not switch to x64, if you think that your music will sound better! It won't.

Memory

There's no doubt that x64 can utilize more memory, after all, this is the reason for its development. But is this extra memory used effectively?

Everything is bigger

Firstly, x64 code is much bigger than x32 code. By code we mean the executables, and instructions for the processor. It stands to reason therefore that your applications themselves will also be much bigger, and since they need to stay inside memory (though this is slightly simplified), they will occupy more space. You may recall that the cache is fast but small while RAM is slow and big. So when an application is running, it is loaded from memory into the cache. However, the bigger the code is, the less of it can fit into the cache and so it must be continually loaded all over again!

With 64-bit you also need 8 bytes to uniquely identify any place in the memory, called an 'address', whereas with x32, an address only has 4 bytes. This difference may seem insignificant, but modern applications contain huge amounts of addresses. So again, with x64 systems you have more memory at your disposal, but you must also use much more of it.

Finally the x64 processors need everything to be "64-bit aligned", which means if something, a number for example, is actually smaller than 8 bytes, it will be rounded up to use 8 bytes regardless. This makes the process faster, but once again we have lost some memory.

Virtual address space

This next issue is a little more involved and may be a little harder to understand.

Modern operating systems use 'virtual address space'. When an application is accessing a part of the memory, because of technical reasons, it doesn't actually know which part of the memory it is addressing. Only the operating system and processor holds this information. We can take 'page swapping' as an example. When there is not enough memory available for an application, the system locates something that is currently stored in memory but has not been used for some time, moves it to the hard disk, and gives that memory to the application. This can occur in just about any part of the memory and it's even possible that every time the application touches data, it is stored at a different location! Therefore all of the data in memory can become progressively more fragmented, but how does the CPU know what each address means?

In x32 systems there is a small database for these memory addresses and both the CPU and the system know its structure. So every time the system needs to access the memory, it looks at the database and knows where the data actually is. If the data is not present in the memory, because the operating system has 'swapped it' onto the hard disk, then it generates an interrupt and the operating system fixes it (moving another of memory to disk and loading the required data back into memory).

In x64 the situation is much more complex. The 64-bit space is just too large to be stored in a small database, so the designers had to use an alternative approach. The result was to use something called a 'TLB' (a translation lookaside buffer) which is a small hash-table, that acts like a cache. The TLB contains only the most recently used addresses, so every time an address is not found in it, an interrupt must be generated to force the OS to fix it. On one hand, accessing the TLB is faster than accessing the small database found in x32 systems, but the interrupts are much more frequent and interrupts do take quite a lot of processing power.

Performance & CPU features

The x64 system also delivers some new features and while some of them have been forced by the bigger memory requirements of the 64-bit platform, there are many more that offer improvements over x32.

Overall OS performance

Operating systems use the same CPU features as applications. With Windows we haven't noticed any performance improvement or degradation when switching to 64-bit although the loading may be slower, because the system is bigger. You can try this for yourself because with Windows 7 and 8 you are able to install both x32 and x64 editions from a single DVD.

With macOS it seems that 10.6 (64-bit) is faster than 10.5 (32-bit). However big changes in macOS performance were also noted over time, which is probably caused by the system getting untidy and progressively more fragmented. If you notice a gradual degradation in performance, a possible solution may be to reinstall the OS. That aside, it is possible that 10.6 uses the system resources slightly better than 10.5.

Registers

x64 architecture has more registers than its x32 equivalent and because all computations are performed inside registers, theoretically, the more of them you have, the better. However, if you are running in 32-bit mode, even if it is a 64-bit processor, it can still use only the x32 set of registers. Additionally, when running x64, the compiler generating the application code must carefully allocate and use the registers, and that's not exactly simple. So it seems that despite the existence of a bigger set of registers there is usually little or no performance gain.

Calling convention

Try to imagine modern applications as huge blocks of black boxes that need to talk to one another. The way they communicate is by a predefined communication protocol, so that the black boxes understand each other. This protocol is called a 'calling convention'.

For example, a plugin's front end 'GUI' (graphic user interface), is created by a black box, which draws it. Now this black box may need to call upon another black box to draw lines, so every time it needs to draw a line, it must send instructions to this other black box on what kind of line it needs to draw. And that's the calling convention.

While in x32 most data has been transmitted by memory, in x64 this becomes highly ineffective, so this task is done using registers if possible. And that is of course much faster.

Running 32-bit applications on x64

As mentioned previously, it will take some time before everything is available as 64-bit, especially on the Apple platform. Until then, it's inevitable that from time to time we will need to run some 32-bit applications. So the question is, is this a problem?

If we look at what happens when running a 32-bit application on x64, we see that the CPU is switched to the so-called 32-bit compatibility mode, in which it behaves as any 32-bit processor. However the system is constantly switching between applications a lot, approximately several thousand times per second. This switching is called 'scheduling'. Every time the scheduler switches from one application to another, it may also need to switch the CPU mode back and forth between x64 and x32 which will invariably take some time. So far though, this extra time seems negligible.

Another consideration is that each application needs to call the operating system, because it needs to utilize some services from it. But because the operating system is 64-bit, these calls must first be translated from 32-bit to 64-bit and then run through a 'dispatcher'. Fortunately, this currently doesn't seem to cause any significant overhead either.

The conclusion is, that it is perfectly fine to run 32-bit applications on 64-bit operating system. If any slowdown does occur, it will be minimal.

Conclusion

x64 has several advantages over x32, but there are also some issues to be aware of. When it comes to performance, there isn't much difference between them. A 64-bit system can however access all of your memory and that should be the only reason for you to make the switch to x64. When using a 64-bit host, you should also use 64-bit plugins and vice versa. x64 has nothing to do with audio quality. It is perfectly fine to run 32-bit applications on 64-bit operating system.

Now that we have covered the main differences, you will be better informed to make a more informed decision as to whether or not you want to or indeed need to make the switch.