64 bit?

[Bozobub]

Once again, multithreading has almost nothing to do with total RAM usage, which is OP's issue.  Yes, the game obviously CAN benefit from more RAM.  LAA (Large Address Aware) simply is not enough, at least with the colony expansion possibilities now present.

Is it possible that people will experience slowdowns and other issues?  Of course.  It's also possible they will see new, unusual errors.  But, as noted above, a good number of folks are hitting a "hard wall", as the game completely runs out of memory; would you argue this is superior?

If support is a problem, simply tell users there is no additional support for the 64-bit version, "use at your own risk", and enforce that policy.  Problem solved.

[Zhentar]

Also, while it's true that the 64bit and 32bit instruction sets don't differ much if you aren't using 64bit math and the additional registers (!), just using 64bit basically allows you to assume the presence of other CPU features (like the SSE2 instruction set), as some modern 64bit OSes (windows *cough*) require those for their 64bit version. (yes, there might be some very old 64bit CPUs or some very exotic 64bit Linux platforms that don't support those features, but those can still use the 32bit version.)

The additional registers aren't that big of a deal. Going from 8 to 16 sounds amazing, but in reality your CPU has hundreds of physical registers that it maps them to so it can maximize out of order execution in either mode, so you already get much of the performance benefit you would expect to gain from the added ISA registers.

Unity 5 (and maybe earlier versions as well) already requires SSE2, so the presence of those features is already assumed.

Also, you're just contradicting your earlier point ("Using more memory just for the sake of using more memory actively harms performance") with your remark about aggressively inlining: Sometimes, you can speed up execution by using more memory. In the case of inlining, that means using more memory for instructions, thereby saving the overhead of a function call. In other cases it could mean using look-up tables, memoization and/or other dynamic programming techniques.

No, you're misunderstanding my point there (looking back, it's not very clear, so understandably so). More memory does not inherently mean more performance; it only means more performance if it's a result of making a more-memory-better-performance tradeoff. And RimWorld's code already does that in the places where it makes sense; it has not been held back in order to constrain memory consumption.

In certain modern languages like C#, Golang  and Java, or when using modern utility libraries, multithreading really is nothing compared to doing it the 'old' way. And, mind you, I did both. Used PThreads in Linux and Windows native applications, written multithreading code in managed .NET with bound partly native C++ libraries and currently writing multithreading database import/export/conversion software in Golang, multithreading microservices using C++, boost and the Casablanca REST SDK.... I've seen pretty much all of it, except for embedded.
However, the ease of just declaring a Go-routine or Java Thread, not having to mess with 'real' pointers (with a memory address attached to it) in a language, because there aren't and most of the time not having to care about accessing shared data (and if concurrent writes are a thing, built-in sync or mutex functionality is easy to use) can have other drawbacks, like stubborn garbage collectors that won't free data until the very last and hog memory.

...

-Managed C#/C++ doesn't have 'real' pointers. You have managed objects, everything goes through garbage collection and threading is quite 'easy'. For concurrent data write-access, built-in mutex classes suffice. Let me know when you see anything that could cause a hard lock. Dining philosophers is still a thing.

You're right that more advanced, higher level languages make writing multi threaded code much easier. But they also make writing single threaded code much easier, so I don't know that there's that much of a relative benefit (and unfortunately for RimWorld, Unity uses an old version of Mono that only supports .NET 3.5, so we can't use any of the nice threading features added in .NET 4) . And the hardest part of writing multi threaded code isn't using a mutex, it's putting the mutexes in the right places (which is hard). And it's not just a matter of not trying to write to the same place at the same time; reading a data structure while another thread modifies it can be just as bad, reading inconsistent/incomplete data structures and ending up in states that are supposed to be impossible and crashing or corrupting game data.

Deadlock is trivial.
Thread 1:

Code Select Expand

lock(objA) { lock(objB) }
Thread 2:

Code Select Expand

lock(objB) { lock(objA) }

-In a multi-colony game it should be very easy to run each colony in its own thread. The only places you'd need synchronisation is for inter-colony interaction (caravans departing/arriving, drop pods and the global timer so colonies don't 'drift'), selection from the world-pawn pool in case of concurrent raids and some interface elements (the colonists overview and messages list).
-In a single colony game you may at leas be able to separate controlling the video output and the AI. Video output only needs to -read- the game state and display all elements on screen accordingly.

A significant portion of the work done each tick is at the world level, not the map level. And even within the map-level logic, there is some interaction across maps (e.g. pawn thoughts/memories involving things at the other colony). There is some potential for threading, but it would be a substantial amount of work and long term support burden for relatively little performance benefit. Simply optimizing the operations that take too much time would likely achieve the same goal with far less development time.

Is it possible that people will experience slowdowns and other issues?  Of course.  It's also possible they will see new, unusual errors.  But, as noted above, a good number of folks are hitting a "hard wall", as the game completely runs out of memory; would you argue this is superior?

The superior solution is to fix the memory issues that cause out of memory crashes.

Incidentally, if you're experiencing out of memory crashes while caravanning, or late game slowdowns, you should check out Zhentar's Experimental Performance & Memory Fixes

[Mrshilka]

Many people playing modded games have been crashing Rimworld due to running out of memory since back in A10, I wish I could feed the game as much ram as it wanted.

[danielee]

There is a reason why manual allocate/deallocate, if done right, gives you better performance, and why you'd rather use pointers than have multiple copies of 'same' data. And that's also when it gets tricky because you have to do manually in code what's already automated away for about a decade.

Well, the main reason why manual memory management can get you better performance is having the absolute control about where in memory you create your objects (so you can abuse the hardware prefetching mechanisms). Of course, the control alone doesn't do anything, to really gain measurable improvements you need to layout your data structures in a cache-friendly way to help the prefetcher do its thing (arrays/object pools can really help with that).
Contrarily, having to jump through main memory every time you access a new object (that isn't in an array or similar contiguous memory region) basically sets you up for cache misses every time you access that object!

Managed C#/C++ doesn't have 'real' pointers. You have managed objects, everything goes through garbage collection [...]

But every reference to a managed object is basically a "fancy" pointer under the hood (even though you can't really manipulate it). So just accessing an object requires you to dereference a pointer (which can point anywhere the GC/runtime thinks appropriate).

Many CS students I speak nowadays don't even know what a pointer is, let alone the benefits and possible dangers of using them, until they get in their third year. And only if they pick specific advanced subjects like Algorithms or Networking and Operating systems (with mandatory lessons in 'classic' C).

Interestingly, I am a CS student, and those subjects you mentioned were mandatory in 2. to 4. semester at my university in Germany (minus lessons in C, the only language we were taught in any way was Java - so people had to figure out any other language used on their own...). Yes, most of my fellow students aren't always comfortable using pointers, but they really should know their dangers!

I guess you are speaking from an American point of view?

No, we also learn pointer in US. No idea where that came from.

[Bozobub]

The superior solution is to fix the memory issues that cause out of memory crashes.

Incidentally, if you're experiencing out of memory crashes while caravanning, or late game slowdowns, you should check out Zhentar's Experimental Performance & Memory Fixes

No matter how much you "optimize" you can never be sure you have enough RAM, depending on the specific game in question, including mod environment.  Are you under the impression you understand ALL mods, including those that haven't been written yet..?

It really is this simple:  A good number of users are hitting a nasty OOM (Out of Memory) "wall", and have for quite some time before A16 (as seen here and via a simple forum search) which is far more RAM-hungry than previous iterations; a 64-bit environment would obviously help quite a bit, assuming you have more than 4 GB of RAM (which most people these days do).  A 64-bit build is also MUCH easier to field (flip a compiler toggle, mostly) than any optimizations could ever be.  If optimization ever makes a 64-bit mode obsolete — which, in my experience with games in general, isn't particularly likely — you can easily deprecate that build.

Again, there is literally (almost) zero downside to creating an unsupported 64-bit build, beyond hypothetical idiots who use it, then whine.  Are you under the impression Tynan is incapable of ignoring idiots..?

[OFWG]

read tech docs first if you don't understand how and why?

I've been a professional developer for 20 years, but please do try to school me

64 bit is related to memory usage, not CPU. You're thinking of multiple core maybe?

[Lightzy]

Dwarf Fortress went 64bit, so ... textures? huh?

64bit is simply better. go for it.

[harpo99999]

from my reading, the 64 bit relates to the maximum register width and data bus width, and aslo had an indicator for the maximum addressable RAM(but again her the motherboard and bios have even more effect on determining the maximum ram addressable, but also again from my reading and understandings, the RAM modules still store in 8 bit widths(this might be wrong) so the ram sticks have to receive 64 bits of data then send it into the chips as 8 bytes, and when reading has to assemble the 8 bytes to one buss width packet

[Bozobub]

Specifically, 32-bit programs are normally limited to 2 GB of address space — RAM and pagefile together — with LAA (Large Address Aware) programs able to use up to 4 GB.  A 64-bit process (on a 64-bit OS, of course) can easily occupy 16 TB of address space, given you are rich enough to own hardware it can run on .

You can't run 64-bit processes on a 32-bit OS but you can run both 32- and 64-bit processes on a 64-bit OS, hence the reluctance to adopt a 64-bit build; it can greatly increase support demands, as it can be an entire new, parallel trunk. if you let it.

[ambivalence]

Get tired of RAM-limits. Vote for 64bit, even if it won't be mainstream and well supported.

[FalconBR]

I remember this same discurssion in planetside 2 developer fórum...
The truth is: the development should have started from a 64 bits since day 1, It took a long time before they realized the problem... The base game runs fine at 32 bits, but after one year of development of extra content (now in year 5) they realized the mistake of limiting the engine to 32! Hell, BF 3 is 2 years older and It already was 64 bits only and nobody who really wanted to play complained about It!
This is a plague in all Bethesda games... Several mods, like rimworld wanna be, and a memory limit making everyone unhappy! Fallout New Vegas is the best, the community patched it to 64 bits!

[ambivalence]

I guess, I won't play the game until it become 64bit. There's too many must-have mods to play with; the community seems to make a lot more useful stuff than ordinary updates, so it's impossible to run the game normally for now. Personally, I cannot even open the modlist, because it crashes lacking memory. Yeah, it's beta-access and so on, it also would be fair to tell me «get the f~ out of here then», but, you know, it's XXI century, 3gb limit is the thing to left in 2000's. Once you've played with all the best mods, you cannot forget it and play vanilla – that's how a human mind works.

Developers, please, do something.

[Wex]

And all the people with an old computer can no longer play.
Great.
Paying for a game that you can't play is a recipe for disaster; and if you could, but something made it unplayable, it's a *hitstorm brewing.
Keep it 32.

[BlackSmokeDMax]

I remember this same discurssion in planetside 2 developer fórum...
The truth is: the development should have started from a 64 bits since day 1, It took a long time before they realized the problem... The base game runs fine at 32 bits, but after one year of development of extra content (now in year 5) they realized the mistake of limiting the engine to 32! Hell, BF 3 is 2 years older and It already was 64 bits only and nobody who really wanted to play complained about It!
This is a plague in all Bethesda games... Several mods, like rimworld wanna be, and a memory limit making everyone unhappy! Fallout New Vegas is the best, the community patched it to 64 bits!

Going by what modders have said in this thread, going 64 bit would not help, and have given technical reasons as to why. Why is it you are assuming that would automatically help?

[Calahan]

And all the people with an old computer can no longer play.
Great.
Paying for a game that you can't play is a recipe for disaster; and if you could, but something made it unplayable, it's a *hitstorm brewing.
Keep it 32.

IIUC, people in this thread are asking for a 64-bit version / support for a 64-bit version, not exclusivity. I'm pretty sure that Tynan is well aware of the number of people who play the game on 32-bit machines, and so if (and IMO it's a huge gigantic IF) a 64-bit version ever does appear, I personally don't see any scenario where it precludes continued support for the 32-bit version.