home information forum contact download/buy sitemap

Plugins
32-bit vs. 64-bit
Bundles
With the advent of cheap multi-core processing and the subsequent arrival of the latest operating
systems to utilize their power, more and more people are demanding 64-bit systems and
Tutorials applications. But how many of us actually understand what 64-bit means?
We try to clear up the confusion by looking at the advantages and disadvantages of each system.
Introduction
Memory
Compression
Do you really need more memory?
Limiters Why have 64-bit architectures been developed?
What do you need to "be 64-bit" ?
Equalizers x32 vs. x64
Does x64 improve audio quality?
Mixing tutorial Memory
Everything is bigger
Mastering tutorial Virtual address space
Performance & CPU features
Stereo expansion Overall OS performance
Analog vs. Digital Registers
Calling convention
32-bit vs. 64-bit Running 32-bit applications on x64
Conclusion

Get social

Memory
Let's start by explaining the fundamentals of memory. RAM (random access memory) is a very fast memory, which is used to store al
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/
(operating system) can 'swap' part of it onto the hard drive and load it back into memory when needed. However this swapping come
at a cost - speed.

MDrummer Large
MDrummer Large is currently the
world's most advanced drum
studio, and contains the most
powerful samplers and
synthesizers. With unlimited
effect pipelines this machine
becomes the hero of drum
machines. Its ultra-powerful
rhythm system is capable of...
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 man
centimeters in length, called a 'system bus', cache memory is usually integrated inside the CPU itself. Unfortunately, it is also mor
expensive than RAM, so it is usually only supplied in batches of just a few megabytes. Cache is situated between the CPU and RAM, s
when looking for data, the processor visits the cache first and only accesses the RAM when the information it needs is not present.
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 bu
it's 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 limi
still seems generous, but besides actual samples it will also contain all executables and temporary files etc. After all these are take
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 t
be loaded from your hard drive. This data is usually compressed, so we could estimate that with lossless audio compression and th
structures needed for random access, we would need to load about 1GB from the disk. Even though modern hard disks have become
lot faster, with fragmentation and simultaneous operations, a fair estimate of the fastest loading speed would be around 50MB pe
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 doe
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. Unlik
D.A.W. programs, which are basically the exclusive main applications when working with audio, servers process hundreds of requests a
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 i
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 issu
for developers back in the days of 16-bit architectures. With the arrival of 32-bit systems, speed became the priority and so we starte
wasting memory until eventually the limit was reached. With the advent of 64-bit machines, the same situation has happened
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 therefor
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-bi
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 XP/Vista/7, Mac OS 10.6 are all now available as 64-bit. Next you require
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-bi
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, the
couldn't release them immediately, because people still needed to use their plugins, which didn't exist for the 64-bit platform. T
overcome this issue they had to develop so-called 'bridges' first. A bridge is a separate application that runs between a particula
plugin and the host. If the host needs something from the plugin, it creates a request, which the system scheduler switches to th
bridge. It is the bridge that actually asks the plugin to carry out the operation, and then gives the data back to the host. Prett
complicated, isn't it?

With bridges everything becomes much more complicated, slower and less reliable. Therefore I strongly suggest using bridges only i
there is no other choice. If your plugins are mostly available as 32-bit only (which is almost always the case on the Mac OS fo
example), 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
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 ofte
requires multiplication, so the processor contains several 'multiplication' units and uses them when needed. It doesn't matter if it is i
32-bit or 64-bit mode, it will eventually use the same unit to get the correct result.
Do not switch to x64, because you think your music will sound better :).

Memory
There's no doubt that x64 can utilize more memory, after all, this is the reason for it's development. But is this extra memory use
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 t
reason therefore that your applications themselves will also be much bigger, and since they need to stay inside memory (though thi
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
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 th
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 onl
has 4 bytes. Moreover, since you will rarely exceed the 2GB limit, the 4 bytes of each address will actually contain some relevant data
This difference may seem insignificant, but modern applications contain huge amounts of addresses. So again, with x64 systems yo
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 smalle
than 8 bytes, it will be rounded up to use 8 bytes regardless. This makes the process faster, but once again we have lost som
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 technica
reasons, it doesn't actually know which part of the memory it is addressing. Only the operating system and processor holds thi
information. We can take 'page swapping' as an example. When there is not enough memory available for an application, the
locates something that is sat in memory and has not been used for some time, moves it to the hard disk, and gives that memory t
the application. This can occur in just about any part of the memory and it's even possible that every time the application touche
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 ever
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 presen
in the memory, because the operating system has 'swapped it' onto the hard disk, then it generates an interrupt and the operatin
system fixes it.

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 t
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
interrupt must be generated to force the OS to fix it. On one hand, accessing the TLB is faster than accessing the small database foun
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 th
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 I didn't notice any performance improvement o
degradation when switching to 64-bit although the loading may be slower, because the system is bigger. You can try this for yoursel
because with Windows 7 you are able to install both x32 and x64 editions from a single DVD.

With Mac OS X it seems that 10.6 (64-bit) is faster than 10.5 (32-bit). However big changes in Mac OS X performance were also note
over time, which is probably caused by the system getting untidy and progressively more fragmented. If you notice a gradua
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 it's 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 onl
the x32 set of registers. Additionally, when running x64, the compiler generating the application code must carefully allocate and us
the registers, and that's not exactly simple. So it seems that despite the existence of a bigger set of registers there is little or n
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
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 nee
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 i
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-bi
compatibility mode, in which it behaves as any 32-bit processor. However the system is constantly switching between applications
lot, approximately several thousand times per second. This switching is called 'scheduling'. Everytime the scheduler switches from
application to another, it may also need to switch the CPU mode back and forth between x64 and x32 which will invariably take som
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
'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 b
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 muc
difference between them. A 64-bit system can however access all of your memory and that should be the only reason for you to mak
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
It is perfectly fine to run 32-bit applications on 64-bit operating system.

Now that we have covered the main differences, it is up to you to make a more informed decision as to whether or not you want to o
indeed need to make the switch.