When can we get the 64-bit version of C#?

[Star Watchman, of Yeshua (OP)]

Hello,

When can we get the 64-bit C# version of Aurora? I want to be able to build massive, massive, mega ships without limitations with like integers n stuff

Thanks

Sal

[Steve Walmsley]

Hello,

When can we get the 64-bit C# version of Aurora? I want to be able to build massive, massive, mega ships without limitations with like integers n stuff

Thanks

Sal

Could you help me by highlighting which data types have higher max values in 64-bit vs 32-bit?

[Zap0]

C# is a language that isn't compiled directly for a cpu architecture but compiles into an intermediate stage which is then ran by a virtual machine, just like java, to be platform independent. That also guarantees that the data types used are always the same size: an int is always 32 bit, a long always 64.

That said, you compiling Aurora into a 32 bit exe does come with the hard limit of 3-4 GB memory. Just loading my rather large 1.11 game I clock in at 650 MB occupied.

[Star Watchman, of Yeshua (OP)]

Hello,

When can we get the 64-bit C# version of Aurora? I want to be able to build massive, massive, mega ships without limitations with like integers n stuff

Thanks

Sal

Could you help me by highlighting which data types have higher max values in 64-bit vs 32-bit?

um double, long, er um bigInteger

That's what I can think of off the top my head

(Lol you troll me too hard, some more memry would be cool)

[alex_g]

An argument could be made for small performance improvements when converting to a 64 bit binary:

• Exception handling setup for 64 bit Windows binaries is resolved at compiled time, versus 32 bit where they're setup at runtime
• The CPU has access to a larger instruction set allowing the compiler to optimize operations on large data structures better

I doubt these changes would have a visible impact on performance though.

These were just on the top of my head.

[Droll]

From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay. At that point 64-bit probably becomes much more economical since memory requirements would go up.

On the other hand multithreading would also boost it significantly although it would be much harder to achieve without breaking everything at this point in development.

[TMaekler]

From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay.

Wasn't one of the big changes of C# that all data is loaded into RAM?!? I don't think that has changed back to VB6 data handling, hasn't it?

[Jorgen_CAB]

From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay.

Wasn't one of the big changes of C# that all data is loaded into RAM?!? I don't think that has changed back to VB6 data handling, hasn't it?

I'm very sure the game only interact with the DB when you load or save the game. I can easily rename the DB and continue to play the game so I doubt the DB is needed for general gameplay.

[StarshipCactus]

I doubt the gain in performance would be worth the effort involved.

[TheTalkingMeowth]

If everything were done using 64 bit integers, the minimum distance could be decreased dramatically!

Assuming everything is signed, 32bit integers can represent up to 2^31. At 10,000km spacing, that gives us a max distance from the center of the coordinate system (presumably the primary) of 2.3 lightyears. It's probably reasonable to want to be able to go at least a lightyear, so no less than 5000 km spacing is appropriate.

With 64bit signed integers, if we want to go 1 lightyear out, we can use a spacing of about 1mm.

Using 64bit integers, a game could theoretically track the exact impact position of every weapon battery based on the direction they were fired and the position of the weapon on the ship. Though, honestly, I might go with floats anyway since my expectation is that computers have more FPUs than integer units and so it would possibly be faster. And 64 bit floats have plenty of precision at reasonable distances. But I haven't tested it in detail.

[nuclearslurpee]

If everything were done using 64 bit integers, the minimum distance could be decreased dramatically!

Assuming everything is signed, 32bit integers can represent up to 2^31. At 10,000km spacing, that gives us a max distance from the center of the coordinate system (presumably the primary) of 2.3 lightyears. It's probably reasonable to want to be able to go at least a lightyear, so no less than 5000 km spacing is appropriate.

With 64bit signed integers, if we want to go 1 lightyear out, we can use a spacing of about 1mm.

Using 64bit integers, a game could theoretically track the exact impact position of every weapon battery based on the direction they were fired and the position of the weapon on the ship. Though, honestly, I might go with floats anyway since my expectation is that computers have more FPUs than integer units and so it would possibly be faster. And 64 bit floats have plenty of precision at reasonable distances. But I haven't tested it in detail.

I'm fairly sure from my explorations of the DB that distance is not limited by the integer size. Coordinates in the DB are stored as floats, and the actual space between ships is not constrained to being a multiple of 10,000 or any other value as far as I know (maybe 1 km). The 10,000 km minimum range is mostly an abstraction for gameplay purposes as well as a small compromise for some degree of realism (as literal 0 km range never occurs).

[QuakeIV]

It would be better from a long term perspective to compile for 64 bit since thats basically the standard at this point, but if we aren't bumping up against the memory limit then there is no pressing need.  I am kindof surprised to hear that Steve didn't directly deny the 32-bit allegations in his first post, because by default visual studio would generally compile a 64 bit application at this point so I assumed thats what Aurora was.

Its not really a special effort as far as I know at this point to move from 32 bit to 64 bit unless the software became really entrenched in some weirdness that doesn't work with 64 bit addresses.

[Steve Walmsley]

Hello,

When can we get the 64-bit C# version of Aurora? I want to be able to build massive, massive, mega ships without limitations with like integers n stuff

Thanks

Sal

Could you help me by highlighting which data types have higher max values in 64-bit vs 32-bit?

um double, long, er um bigInteger

That's what I can think of off the top my head

(Lol you troll me too hard, some more memry would be cool)

Doubles and longs (a bigint is the same as a long) are exactly the same in 32-bit and 64-bit. In C#, they are 8 byte data types that are unaffected by the compilation into 32-bit or 64-bit .

64-bit allows you to address more memory but it doesn't change any data types. Unless you use that extra memory, then 64-bit can be slightly slower than 32-bit due to the extra overheads. I've tested Aurora in both 32-bit and 64-bit and 32-bit is slightly faster, which is why I released on that format. I can change a single field in the compilation options and make a 64-bit version that is identical.

[Steve Walmsley]

From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay. At that point 64-bit probably becomes much more economical since memory requirements would go up.

On the other hand multithreading would also boost it significantly although it would be much harder to achieve without breaking everything at this point in development.

The game only accesses the DB on load and on save. Everything executes in RAM only.

Multi-threading isn't useful because the game executes most actions in order, not simultaneously, because those actions depend on knowing other actions. For those things that could be executed simultaneously, such as orbital movement or detection, they are very fast anyway so adding the complexity of Multi-threading only really adds scope for hard-to-track bugs.

[Jorgen_CAB]

From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay. At that point 64-bit probably becomes much more economical since memory requirements would go up.

On the other hand multithreading would also boost it significantly although it would be much harder to achieve without breaking everything at this point in development.

The game only accesses the DB on load and on save. Everything executes in RAM only.

Multi-threading isn't useful because the game executes most actions in order, not simultaneously, because those actions depend on knowing other actions. For those things that could be executed simultaneously, such as orbital movement or detection, they are very fast anyway so adding the complexity of Multi-threading only really adds scope for hard-to-track bugs.

It would be interesting to know what is the main thin that slows down the game... my games usually slow down to 4-5 seconds and stay there for a rather long time. I don't think this is an issue or anything just would be interesting to know for future optimisation what is the main thing that slows down the game?