ED 64bit? Not according to Task Manager

In the recent newsletter it talks about the Cobra engine being fully 64bit.

I'm running on a quad core i7 in boot camp with Windows 8.1 64bit.

Yet the few times ED hangs on me and I've had to kill the process in Task Manager it says 'Elite Dangerous (32 bit)'

do I have it wrong or do I have to change something?
 
The current client is 32 bit. Whether to compile the client for 64bit or 32bit is something Frontier is considering. There are advantages and disadvantages to both.
One of the programmers, Mark Allen, has given us some information about this.

Internally we have full support for 64 bit client builds (several of us develop on them by choice). Whether we'll ship that for the client in Alpha 4.0 I don't know - there are reasons for and against, but for now that's a discussion I'll leave well alone ;).

What I wanted to say: Being on a 32-bit OS doesn't stop us using the benefits of 64 bit where they matter (for now). Specifically I'm talking about 64 bit floating point maths, which you need the precision of to represent the sheer scale of things in space. Seriously, it's nuts.

Doubles (64-bit floats) are perfectly fine on 32 bit machines - they've been used for years. The processor will handle each 32-double vs 64-native slightly differently, but the precision & results we achieve are the same. There's performance trade-offs, but contrary to popular belief 64-bit is not strictly faster - for example doubling the size of your data types has serious impacts on memory bandwidth!

Where 64-bit flat out wins is memory - that 2GB (sort of) memory limit for 32 bit processes is much harder to get around :p, though it's not a problem we're running into atm so there's no drive to switch there. I suspect there will be in future though :).
 
Last edited:
In the recent newsletter it talks about the Cobra engine being fully 64bit.

I'm running on a quad core i7 in boot camp with Windows 8.1 64bit.

Yet the few times ED hangs on me and I've had to kill the process in Task Manager it says 'Elite Dangerous (32 bit)'

do I have it wrong or do I have to change something?

When FD refer to the Cobra engine being 64 bit, they're talking about the size of the floating point variables that the engine uses rather than the compilation of the code. In this case the difference is in whether you have a playable galaxy thats a few hundred thousand kilometres across or a few hundred thousand light years across.

A program can be compliled as 32bit (which is dictated by the size/capability of the registers in the target processor architecture) and use 64bit maths (which is determined by the amount of memory allocated to variables within the software) or any combination of the two.
 

Robert Maynard

Volunteer Moderator
The Intel 8087, the distant ancestor of the floating point units in modern CPUs (back in the day you had to add a maths co-processor if you wanted hardware floating point!), was introduced in 1980 - so we've had the capability to use 64-bit hardware floating point for a very long time, even predating 32-bit capable PC CPUs. Software solutions were used for PCs without a co-processor and were cripplingly slow by comparison.
 
What I am still unsure is the performance difference of a 32 bit build vs a 64 bit build running on the same 64 bit machine. I understand the advantages and drawbacks of 64 bit, but what I feel is often neglected when discussingg comparisons is what kind of overhead does a 32 bit process have when run on a 64 bit OS, and how that compares to a 64 bit process on the very same machine.

I am not so much concerned about memory footprint itself, but actual, raw performance in terms of FPS, and my hunch so far has always been that on a 64 bit OS, a genuine 64 bit process would come out slightly on top.

And then, on a completely unrelated note, I am of the opinion that 32 bit ought to die out sooner or later anyway, and gaming machines theses days always come with Win7/8 64 bit because, well, even the cheaper ones sport 8GB RAM now; I won't be surprised if Windows 9 does not even get a 32 bit version at all.
 
Lots of great info here - thank you all.

My imac has 32gb ram, so definitely looking forward to 64bit client!

Hopefully it won't just be a maths / space issue and the game will run better - although graphically it's running full screen at 2560x1440 with everything at max and except for the known alpha slowdowns it's exceptionally smooth.

Frontier know how to code - that's for sure!
 
The only real advantage of having a 64bit OS is the addressable memory available. From a CPU point of view it doesn't really matter. There are other considerations to but generally that is the main difference.

With a 32bit OS you are limited to 4GB of RAM (less on Windows, something like 3.2GB, as the rest is used by the kernel).

I would assume FD have built ED in mind so it will fit in that memory space, however at some point there may be a requirement for more than that, so at some point 64bit may be at least optimal if not a requirement.

By then though most users will be on a 64bit OS, and the standard memory most users will have will be 8GB minimum anyway, so I don't think it will be that much of an issue.
 
When FD refer to the Cobra engine being 64 bit, they're talking about the size of the floating point variables that the engine uses rather than the compilation of the code. In this case the difference is in whether you have a playable galaxy thats a few hundred thousand kilometres across or a few hundred thousand light years across.

Exactly, just because a program is compiled to target a 32bit CPU architecture, that doesn't mean it can't still use 64bit numbers internally. Cobra is a 64bit engine that in the current releases is compiled as a 32bit application.

Why 64bit numbers are important is precision of location.

Floating point numbers are interesting in that the magnitude of the number is not limited, but the precision reduces as the magnitude increases. What this means for a space game is that if the Sun were 0,0 on a 32bit coordinate system you might get meter level accuracy at Mercury, accuracy to within ten meters at Earth and accuracy to within a kilometer at Pluto.

The gameplay implication of that would be that dogfighting around Pluto would become impossible. Ships would jump around from one kilometer level accuracy point to another.

Using 64bit accuracy for the coordinate system doubles the accuracy of numbers that can be stored 32 more times. That means that precise coordinates can be stored over a range of about a light year.

The distances and accuracies here are suggestive, the actual figures will depend on the implementation inside the engine.
 
Floating point numbers are interesting in that the magnitude of the number is not limited, but the precision reduces as the magnitude increases. What this means for a space game is that if the Sun were 0,0 on a 32bit coordinate system you might get meter level accuracy at Mercury, accuracy to within ten meters at Earth and accuracy to within a kilometer at Pluto.

The gameplay implication of that would be that dogfighting around Pluto would become impossible. Ships would jump around from one kilometer level accuracy point to another.

Correct me if I am wrong, but doesn't instancing get round this? In a multi-player session a P2P 32-bit local environment should offer more than sufficient accuracy for combat and other interaction.

Edit: Mind you, I am all for a 64-bit client and hope FD offers one.
 
Last edited:
Yeah, I think ED uses at least a two-tier coordinate system, one for the overall simulation and a more precise one relative to the current frame of reference (and the 500m/s speed limit always applies to the second coordinate system). Probably there are even three tiers, one for the entire galaxy, with Sagittarius A* as the origin, one for each star system with the star (barycenter in multiple systems) at the origin, and one for each frame of reference, with whatever major object there is (e.g. space station) or even just a point in empty space as the origin.

Still, the star system and galaxy tiers would most likely benefit greatly from 64 bit precision, I once read that they ran into similar problems in Kerbal Space Program, and there they only ever have a single and -compared to our real solar system - small system. (Afaik they solved it by making the active ship the origin of the coordinate system, and therefore achieve maximum accuracy in its vicinity at all times, but this approach is only feasible in a singleplayer environment.)
 

Mark Allen

Programmer- Elite: Dangerous
...doesn't instancing get round this? In a multi-player session a P2P 32-bit local environment should offer more than sufficient accuracy for combat and other interaction.

Yes and no. We do indeed use a local 32-bit space for a lot of the time. However to keep the precision issues under control this local space moves as you get far away from it, and has to interact with other player's ideas of what local space is over the network. I won't go into details, but it's that part that needs the 64-bit precision!

For reference, a 32 bit float has 23 bits of "precision" of which you can usually assume the last few are lost to rounding errors. 20 bit precision is a reasonable estimate (it's not precise, depends which ops you're performing) which means for distances of a kilometre you have an accuracy of about a millimetre at best.
 
The Intel 8087, the distant ancestor of the floating point units in modern CPUs (back in the day you had to add a maths co-processor if you wanted hardware floating point!), was introduced in 1980 - so we've had the capability to use 64-bit hardware floating point for a very long time, even predating 32-bit capable PC CPUs. Software solutions were used for PCs without a co-processor and were cripplingly slow by comparison.

Sorry, I obviously wasn't being clear in what I was trying to say regarding register sizes and CPU architecture. As OriginalBadBoy was saying the difference between architecture in terms of bit size is generally expressed (and has been for over 20 years to my knowledge) as the number of bits of data that can be transferred across its data busses between the various components simultaniously and, to a lesser extent, internally within the components. So a 32bit processor will be using a 32 bit databus and memory addressing limited to 2^32 memory locations (a maximum of 4,294,967,296 separate memory blocks or 4Gb of memory). Moving to 64 bit architecture gives a 64 bit databus and memory addressing that gives a maximum of 2^64 memory addresses that can be used.

In terms of performance, in a practical sense there is next to no difference that we as human beings will notice due to the high clock speeds and multicore/multithreading capabilities of modern processors. In terms of the actual processing power though, with a 32 bit architecture it takes twice as long to move a 64 bit floating point variable from the memory to the processor or vice versa as it would using a 64 bit architecture. The actual calculations inside the processor would be the same as processors now are invariably 64 bit regardless of the size of the data busses.

So there is a speed hit in terms of moving data around 32bit systems compared to 64 bit systems (but that is dependant on whether you're using 32 bit or 64 bit variables) and there is a significant reduction in the amount of data that can be managed within a 32 bit system compared to a 64 bit system but with the current crop of processors all being 64 bit internally that's the only significant difference in terms of performance.
 
Last edited:
Correct me if I am wrong, but doesn't instancing get round this? In a multi-player session a P2P 32-bit local environment should offer more than sufficient accuracy for combat and other interaction.

Edit: Mind you, I am all for a 64-bit client and hope FD offer one.

It depends how seamless you want your gameplay to be. Frontier Elite 2 used lower precision coordinates and got around the problem by using local frames of reference, which is what you're referring to.

The problem there comes when you want to seamlessly transition from one local FOR to another. The coordinates don't map exactly to each other because of precision issues. The result was that sometimes when changing FOR your ship would accelerate off in a random direction.
 

Malicar

Banned
I was pretty surprised to see ESO and FF MMO's are both 32bit. I guess most of the new console ports are also 32bit even though the boxes are sporting 8GB. The PS4 and XBONE OS's are using 3-4GB leaving 4GB Unified Free. Not much when you consider I've been pushing 16GB on this PC for over 3 years now. Time to make some ramdrives for your SSD and what not. Kind of sad I thought the 64 bit erra was finally here and apparently it's only here if you play World of Warcraft :) (Not to be confused with the process you were referring to or anything)
 
Last edited:
Back
Top Bottom