64-Bit WoW; A technical examination simplified!

**Inflik** · 01-30-2012 12:39 PM

This was originally posted on Mmo-champion, I thought it was a good insight in the performance increase many of us may get when the switch over to 64bit happens. Especially for 25man raiding. Theoretically we can see upwards of an 80% performance increase in 25man raiding with 64bit clients.

--------------

With the 64-bit client on it's way, i thought now would be a great time to do a rundown on the differences and hopefully show how it'll affect WoW. Many people have the interpretation that 64-bit will be awesome for performance. I want to explain why this is correct, and at the end, i want to show why it may or may not turn out that way.

This might get pretty technical at times but i've simplified it wherever possible. I'll be honest and admit some of the math may be wrong (the values themselves are correct though) so corrections to that are welcome. This article is correct to the best of my knowledge, but due to the technicality of it, i might have made mistakes in some places. I've tried to use examples we can all relate to wherever possible as well.

Be aware this is an extremely long post, and so i wouldn't blame you if you wished to only read certain parts of it. I've split up the sections with headers. Each section is still quite long, but there wouldn't be sufficient explanation if i shortened them. The last 2 are of most interest for the general populace i dare say, but for the technically minded among us, the first 2 are there as well.

The technical stuff
Going from 32 to 64 in code varies in difficulty. For some programs, it's easy and for others, it's a nightmare. Here's where they differ in terms of data types (i'll put the simplified version below that);

string
class instance
class reference
interface
Ansi String
Wide String
Unicode String
procedure pointer
dynamic array
Pointer Ansi Char
Pointer Wide Char
Pointer Char
Native Integer
32-Bit: 4 bytes.
64-bit: 8 bytes.
Extended floats are (x32: 10 bytes, x64: 8 bytes)

Essentially, strings, pointers, classes and certain types related to numbers (floats and NativeInt.) all change between 32 and 64. However, a lot of string processing functions and procedures don't change much at all. For example, Blizzard would write a procedure or function that reads a string. However, they can choose which string to read through the use of variables, so something like this (the below isn't technically correct, but it demonstrates the basics);

Code:

function ReadString(TheString : String) : String; begin TheString := ReadStringFromFile; end;

And they'd call that with something like this;

Code:

Ability120_String := ReadString(Ability120);

Therefore, instead of changing several thousand different pieces of code related to each string, they'd just change the "ReadString" function to be 64-bit compatible. This is one of the basic tricks that programmers use, and it's something that everyone who get's into it would learn as a basic practice. It reduces the overhead and size, at the expense of being unable to make specific changes without that change affecting everything that calls that function. If that's too much to understand, think that if you bake a cake, you can only put certain ingredients into it, and the whole cake is affected, but if you bake buns/cupcakes, you can put different ingredients into each one.

Pointers are everything. A string is just a pointer to a string. An integer is just a pointer to a value. As it's name suggest, it simply points to where some data is stored. Using them in their "pure form" is generally considered an advanced to expert level topic but using them in their "accessible" form is something every programmer does whether they know it or not.

A class is simply an object. The simple way of putting this, is "something you can see and/or interact with on the screen". Classes aren't always visible to the end-user, but i want to keep it simple. A button on screen is a class. A text box is a class. In WoW terms, the whole 2D interface is a class. The 3D viewport is a class, but the objects within the 3D space typically aren't classes, they're models (in the traditional term of "3D Model"). The code to render the world and "arrange the objects" within the world is a class.

Integers, as you may be aware, are just numbers. Floats are numbers but with a decimel place. Generally, a float is considered more precise and can store a larger range of numbers in the same amount of data. However, processing a float is more difficult than processing an integer thus it's slower.

The technical numbers
WoW is built upon numbers. I'm not talking 1's and 0's as you'd think, i'm talking ranges of numbers.

For 32-bit, the minimum size of an integer is -2147483648, and the maximum is 2147483647. For those struggling, that's more than 2.1 Billion at the top end. The minimum is obviously -2.1 Billion. Interestingly, and not completely unexpected, is that dividing that maximum number by 1048576 (which is 1024*1024, where 1024 is essentially where it ticks over into a new format, for example 1024MB is 1GB) gives us 2048.

Look familiar? It should. Ever heard people spouting about a 2GB memory limit for programs? This is partially where it comes from. Technically, you can access up to 3GB by using the LARGE_ADDRESS_AWARE header, and on a 64-bit OS, even 32-bit programs can access 4GB of memory, but these are all choices, and as such, shouldn't be taken into consideration for the purpose of this explanation. They're not "the norm" here.

In 64-bit, you have the ranges of -9223372036854775808 to 9223372036854775807, or -9.2 quantacillion to +9.2 quantacillion. Essentially, the range of 64-bit numbers is 4294967298 (almost 4.3 Billion) times that of 32-bit. Yes, i did just break your Windows calculator (assuming you're on "standard" mode). If we divide our 9.2Qc by 1048576, we get 8796093022207, which is 8 TB. This is the memory limit that a program can address in 64-Bit (while 64-bit address itself is 8 Exabyte [1 Exabyte is 1024 Petabytes, and 1 Petabyte is 1024 Terabytes] but that's a null point).

Essentially, if you wanted to use all the available memory for a 64-bit program, you'd need to use the capacity of the HDD's in VERY high end machines. I have 8TB of space on my HDD's (4x2TB). I run some SSD's as well, but let's completely ignore those. The average machine has 500GB/0.5TB - 1TB of space. This is the maximum amount that a program could access in 64-bit if it was memory. In fact, 64-bit is so massive that you could provide a unique value for every single byte in my system and you'd STILL not have even made a dent in it. Let me put it as a percentage for you. If i was to assign a unique value for every byte on my 8TB of space, i'd have only used up 0.000095% of the values available to 64-bit.

To show you how absolutely extraordinary 64-bit is, let's bring our Galaxy, the Milky Way, into it. There's estimated to be 100,000,000, or 100 Billion, stars in our galaxy. There's enough values in 64-bit to assign 92,233,720 (92 billion) different numbers to EVERY SINGLE STAR!

Now, although extraordinary, you're limited by what Windows allows, since outside of server products, you can "only" have a maximum of 192GB memory. All you need to understand is that the higher capability of your "64-bit" processor is good for software built to take advantage of it. The potential for it could be classed as infinite if you wish, but the definition of infinite varies from person to person.

This is all well and good, but how does this affect games?
For many games, it doesn't have a massive effect. Where it truly comes into it's own is memory access. You see, being limited to 2GB is fine for games at the moment. It'll even be fine for quite some time. However, eventually we'll come to a point where we need to break past this barrier. Outside of games it already makes a major difference, but we're not here to discuss those.

However, for the actual code inside an application, there's some major potential to speed up your programs.

I said earlier that WoW is based on numbers. Remember all those different data types earlier such as Pointer, Integer, String, etc? Let's bring those into the conversation again. Imagine you've got a road. It's 1 lane for each direction. Typically, it moves at an acceptable speed both ways. Let's say we have 6 cars on one side, named "S", "T", "R", "I", "N", and "G", something like this;

They're going along the road. They run one behind the other. They are blocks of data. Strangely, the other side of the road has no cars. Ignore that. I want to keep things simple. If you want to, imagine there's other cars doing the exact same thing on the other side of the road.

Now, imagine what'd happen if we were to double the amount of lanes on each side, but didn't impose any laws on which lane you should be in;

Now you can see they've split into 2 lanes each. Thus, those same cars/blocks of data can get to where they're going at the same speed, but more will arrive at the same time. The ones at the front will arrive at the same time, but the ones past the halfway mark will arrive in twice the time. The cars themselves move at the same speed, but there's less in each lane, reducing congestion and thus you can push data or cars along the road 2 at a time. The length of the journey is the same, you just didn't need to overload 1 lane with all the cars. Therefore, the journey is the same for each car, but the cars at the back will arrive in half the time in the 64-bit road compared to the 32-bit road.

Let's put this in WoW terms. 1 of those cars is 1 integer, float, pointer, string, or class. The combat log goes through hundreds of thousands of these during the average 25-player raid fight. Instead of sending them 1 at a time through the game, it sends it 2 at a time. Of course it does this incredibly fast so 1 seconds worth could be thousands of these values. This effectively reduces the congestion on the CPU. A lot of things related to WoW being heavy on the CPU is down to the combat log. Even in cities, every time someone does something such as cook something, or cast a spell, it's going down in the combat log. In raids, you're getting your system spammed with these numbers.

How much difference will it make/I want my cookies now!
This is something i can't answer. I can't make any calculations based on it because i don't know exactly what optimisations have been made.

Theoretically, in raid combat, you could see up to an 80% improvement in FPS. There's always some overhead that means you won't see it double. There's also the variables such as exact raid composition, right down to what proc items they're using, and of course which boss you're actually fighting. Realistically, i don't truly know what to expect. I expect it to all be good either way.

For people playing on massive resolutions >1080p, or those with hundreds of addons (derp?), or both, being able to beat the memory limit of being 32-bit and having access to more than 2GB will help stop crashes. However, the potential for a performance increase is there.