I'm just thinking out loud here but is there a reason this game is 32 bit? It seems like Tynan is severely limiting its potential by not going 64 bit... If it was 64 bit, even the fact that it hasn't been optimized for multiple colonies would still make it possible since it would be able to use much more memory. Is this maybe planned for the future?
Making the game 64-bit is pretty much 5 minutes, switch the build target and hit compile.
But we wouldn't benefit from it, and neither would Tynan. I'm sure he doesn't want the memory usage to go past 4GB, since it would push the system requirements past what many players are using successfully today. And we wouldn't benefit from it because RimWorld has little need for more memory. Games that seriously benefit from large amounts of memory are using many very large textures.RimWorld is not. Much of RimWorld's memory usage is game data structures, and making these structures larger directly harms performance.
The right fix for A16's memory usage is to reduce it, trimming the fat. There is likely a lot of low hanging fruit, since Tynan hasn't needed to focus on it before, so it shouldn't be a hard problem to solve.
Pardon me? You're asserting a player running several concurrent colonies wouldn't benefit from having more RAM? I find that at least a little difficult to believe; at some point, it has to matter, would it not?
And if it's as easy as flipping a compiler toggle, as you say, I kind of fail to see the problem with offering both. Hell, offer it with no additional support, if you must -.-' . It's not like running contiguous colonies is encouraged at the moment, anyhow, right?
Yes, that is exactly what I'm asserting. A16 RimWorld is not actively working harder in order to constrain memory usage. It does not unload textures and load new textures from disk. It doesn't load anything from disk at all during game play (except background music in some cases, and that's both very light and easily cached by the OS). It's not compressing anything. Using more memory just for the sake of using more memory actively harms performance; more memory means more paging, more TLB misses, more L3, L2, and L1 cache misses. And when you need to use a 64 bit address space to get that memory, the problem is even worse; now all your pointers are twice the size. The 'Thing' class (one of the more common objects in RimWorld) would grow by over 50%; now everything that uses Thing (which is pretty much everything) is slower just because we might want to use more than 4GB of RAM, never mind the cost of actually using that much. RimWorld doesn't do much (maybe not any) 64-bit math, and already agressively inlines performance critical code paths; it benefits fairly little from the x64 instruction set.
The only users that would benefit from a 64 bit build are the ones experiencing out of memory crashes. The rest would, at best, have a performance neutral experience while consuming more system resources, and at worst see significantly worse performance. Offering a second build is giving users a false choice - there's one right answer, giving people the opportunity to choose otherwise implies that there is an important difference, creating confusion and leading people to make the incorrect choice. Even if the second version is offered "without support", it still creates a support burden simply to explain to users which build they should use.
Quote from: Zhentar on December 24, 2016, 05:12:32 PM
The only users that would benefit from a 64 bit build are the ones experiencing out of memory crashes.
As one of the users experiencing out of memory crashes regularly (lots and lots of mods), I'd really like a 64 bit build! :P
you won't benefit due to CPU single thread bottleneck, please read techdocs.
Quote from: LordMunchkin on December 25, 2016, 02:33:30 AM
Quote from: Zhentar on December 24, 2016, 05:12:32 PM
The only users that would benefit from a 64 bit build are the ones experiencing out of memory crashes.
As one of the users experiencing out of memory crashes regularly (lots and lots of mods), I'd really like a 64 bit build! :P
Me too!!!!!!!!!!!!!!!!!!!!!!
We want 64bit.
4 GB is too small.
Quote from: RawCode on December 25, 2016, 09:38:12 AM
you won't benefit due to CPU single thread bottleneck, please read techdocs.
Did you mean to post in a different thread or something? This is about memory usage.
Quote from: OFWG on February 08, 2017, 09:07:41 PM
Quote from: RawCode on December 25, 2016, 09:38:12 AM
you won't benefit due to CPU single thread bottleneck, please read techdocs.
Did you mean to post in a different thread or something? This is about memory usage.
read tech docs first if you don't understand how and why?
I have seen references to the single thread bottleneck before. That I am honestly curious why we have in this day and age anyways. IIRC very few processors anymore are single threaded.
And no please understand I am not being snippy. I truly am curious why this is a single thread game and don't have the technical knowledge to know on my own.
Writing code that can do multiple things at the same time is, generally speaking, hard. I've personally written multi threaded processing routines a number of times at my job, and it remains a last resort when we absolutely cannot get adequate performance in a single thread. If you make mistakes, you end up with random data corruption. Debugging that data corruption can be quite challenging because it happens at random; you can't just set a breakpoint where it goes wrong because you don't know when and where it will go wrong, and hooking a debugger or adding logging code can change the timing just enough that it stops happening. If it was even happening for you in the first place; the particular timing may not ever line up on your own system in the first place. You have to work harder, and think more carefully when you write the code the first time, and any time you touch it afterwards. One time, I had logs proving one of my customers was getting a particular error in an area that was just a couple hundred lines of code. I spent three straight days trying to reproduce the issue, and poring over the code searching for any possible logic error. I never reproduced it, my testers could never reproduce it, and I couldn't ever find the problem, and I ended up shipping a patch that just locked far more than could possibly need it (even things that were guaranteed to be atomic). They stopped complaining so it must have done the job without hurting performance too much.
If you can plan things things out to be almost completely independent, then it's generally not too hard to get two separate things going at once. In fact, Unity is actually dual threaded, with a second thread doing some of the graphics work. But RimWorld isn't rendering intensive so that doesn't help us much, and the stuff RimWorld actually spends its time on is very tightly interdependent.
wow that was a very quick and completely informative answer, TY very much Zhentar
Quote from: Zhentar on December 24, 2016, 05:12:32 PM
Yes, that is exactly what I'm asserting. A16 RimWorld is not actively working harder in order to constrain memory usage. It does not unload textures and load new textures from disk. It doesn't load anything from disk at all during game play (except background music in some cases, and that's both very light and easily cached by the OS). It's not compressing anything. Using more memory just for the sake of using more memory actively harms performance; more memory means more paging, more TLB misses, more L3, L2, and L1 cache misses. And when you need to use a 64 bit address space to get that memory, the problem is even worse; now all your pointers are twice the size. The 'Thing' class (one of the more common objects in RimWorld) would grow by over 50%; now everything that uses Thing (which is pretty much everything) is slower just because we might want to use more than 4GB of RAM, never mind the cost of actually using that much. RimWorld doesn't do much (maybe not any) 64-bit math, and already agressively inlines performance critical code paths; it benefits fairly little from the x64 instruction set.
The only users that would benefit from a 64 bit build are the ones experiencing out of memory crashes. The rest would, at best, have a performance neutral experience while consuming more system resources, and at worst see significantly worse performance. Offering a second build is giving users a false choice - there's one right answer, giving people the opportunity to choose otherwise implies that there is an important difference, creating confusion and leading people to make the incorrect choice. Even if the second version is offered "without support", it still creates a support burden simply to explain to users which build they should use.
While you raise some good points against a 64bit version, you aren't telling the whole story, either.
Modern processors employ quite an arsenal of predictors, especially for memory accesses, which are quite good at their job when you are using predictable memory access patterns. If done well, more memory means about the same amount of TLB/L3/L2/L1 misses (or sometimes those numbers even decrease).
Yes, your pointers are twice the size compared to 32bit. However, you shouldn't really be chasing pointers in performance critical code (unless you really can't avoid it), as those are the cause for said TLB/L3/L2/L1 misses. If that 'Thing' class (your example) consists of more than 50% pointers, it means that there are some performance and software architecture issues right there. (This problem is independent from 32bit vs 64bit.) I know, it's the "OOP way" to have pointers and references to every object everywhere, but sometimes this isn't the "right" approach (especially when you are considering high performance applications like games). But I digress...
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.)
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.
I can't really disagree with your final argument, though: Providing multiple versions has some burden when trying to direct your users to the correct one. That said, you could still have the 32bit version as default and only direct them to the 64bit version (with warning labels!) if the 32bit version has problems or a user is explicitly looking for it.
Finally, I really hope that the Rimworld code base isn't as bad as to warrant your grim outlook on a 64bit version. And remember: This is all speculation until we can measure the difference ;)
(I really hope I wasn't too aggressive in the representation of my arguments. I don't have anything against you personally ;) )
@XeronX:
Games are wonderfully complicated programs that try to do many things at the same time. But in order not to stumble across their many parallel tasks, they need to synchronize at certain points. These synchronization points can be rather expensive (computationally speaking).
One of these synchronization points is usually when sending info to the graphics card driver about which elements should be drawn (as this data really should not be in a corrupted state!). This is sometimes called the "single thread bottleneck", as there can normally only be one thread talking to the graphics driver (yes, there are some exceptions, but those just shift the real point of synchronization around). Other threads can of course work on other stuff like playing sounds or updating the game state - but the frame rate (and therefore the perceived update rate) is still mostly dependent on the one thread that has the most computationally expensive work to do between synchronization points.
What Zhentar wrote about the difficulty of writing correct multithreaded programs is also relevant ;) FYI: Just checked in task manager, my currently running Rimworld instance uses 53 threads!
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. 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. 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).
Now for this game. I don't have any sources but I could make some 'educated' guesses.
-If the software is CLR compliant (I read somewhere most of it is in C#/.NET?), making a 64-bit version is indeed as easy as a compiler switch. Data types are independent from 'bit-ness' afaik. It's not like unmanaged C++ (and C ofc.), where you have primary data types that are dependent on the architecture word size.
-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.
-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.
-I'm asserting the video performance (even on large maps) is not what's slowing down the game. It's the AI that calculates the game state. Larger colonies don't use more textures per-se, just a bunch of them more often than 'once' on the map. But they do have more interacting colonists, larger raids, more animals, etc. An abundance of them makes the game crawl. I have a three-colony world with more than 100 pawns total. Even when my main colony is in the 'background' and the small mining colony is displayed where I'm strip-mining a map for materials with 10 colonists to be able to expand the main colony, I can't increase the game speed any more than I can not while the main colony is displayed. Single-speed is all I have that's usable, and even then I get regular stutters. Double-speed makes pawns jump all over the map (seems to be a cosmetic thing). Triple speed is just like singe speed but with a slide-show effect.
Usually if I play for about an hour, then get into memory issues. Earlier if I loaded a save half way. The world map stops being displayed properly, texts from item tables in trade or caravan selection start to disappear. Making a save or autosave gives out-of-memory errors. Usually it's not long thereafter the game crashes and I see a clean up of swapped out memory blocks (noticable by a few minutes of 100% SSD activity) and a decrease of ~4GB of actual in use random access memory in the task manager. Sometimes I get a dialog popup with directions to a debug log, sometimes the process just segfaults and all resources are dropped.
I know it isn't 'usual', how I play the game. But if it weren't for the 4GB memory limit, and a bit more available processing speed (running a AMD phenom here, quad-core but per core not that performant) the game would be absolutely playable. Actually it already is, because I keep loading that save ;) and expand my colonies a bit more.
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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!
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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).
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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?
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.
Quote from: hoffmale on February 09, 2017, 12:55:07 AM
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.
Quote from: hoffmale on February 09, 2017, 12:55:07 AM
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.
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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:
lock(objA) { lock(objB) }Thread 2:
lock(objB) { lock(objA) }Quote from: Miridor on February 09, 2017, 03:35:28 AM
-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.
Quote from: Bozobub on February 09, 2017, 11:12:22 AM
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 (https://ludeon.com/forums/index.php?topic=30114.0)
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.
Quote from: hoffmale on February 09, 2017, 09:49:36 AM
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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!
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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).
Quote from: Miridor on February 09, 2017, 03:35:28 AM
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.
Quote from: Zhentar on February 09, 2017, 01:30:59 PMThe 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 (https://ludeon.com/forums/index.php?topic=30114.0)
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..?
Quote from: RawCode on February 08, 2017, 09:14:06 PM
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?
Dwarf Fortress went 64bit, so ... textures? huh?
64bit is simply better. go for it.
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
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 ;D.
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.
Get tired of RAM-limits. Vote for 64bit, even if it won't be mainstream and well supported.
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!
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.
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.
Quote from: FalconBR on February 21, 2017, 08:05:53 AM
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?
Quote from: Wex on March 10, 2017, 01:39:55 PM
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.
According to the steam hardware survey, 95% of users are running a 64 bit OS. 32 bit is the niche at this point.
http://store.steampowered.com/hwsurvey
Quote from: Zhentar on February 09, 2017, 01:30:59 PM
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 (https://ludeon.com/forums/index.php?topic=30114.0)
Unfortunately your fix, even though is good, is not enough.
Apparently, the game is not meant to be to be played with mods nor the biggest map nor more than one colony.
To me, Tynan failed at the planing stage of his game.
Wow, excellent conversation. Finally, some people who understand the concept of trade-offs. 64-bit (amd64) programs do have their downsides.
I'm a little surprised though that Rimworld
ever gets memory constrained. Those mods must be very intensive. My current save (only moderately modded, heh) is using about 650 megs in Task Mangler....which is a bit higher than I expected, but not enormously so.
That being said, I'm
also surprised there isn't an
unsupported 64-bit version. I rebuilt my own programs (C99+OpenGL) for 64-bit targets when I installed Visual Studio 2015, and had absolutely no problems whatsoever (aside from a slight run time increase of about 3-5%). I generally use semi-enhanced INI-style files to store data (above basic INI/CFG-level complexity, but below XML), which gets rid of almost all the bugaboos of variable datatype sizes (and I'd never store an actual pointer-type. I use relative offsets in binary formats, if applicable). XML-based apps shouldn't have much difficulty either, as it's also a text/binary conversion.
I'm no C# expert, but I seem to recall that it's datatypes use fixed sizes anyways (int is always 32-bit, long is always 64-bit, IIRC), even if someone were audacious enough to use a binary file.
Quote from: OFWG on March 10, 2017, 02:27:56 PM
According to the steam hardware survey, 95% of users are running a 64 bit OS. 32 bit is the niche at this point.
http://store.steampowered.com/hwsurvey
I'd like to point out that a large percentage of these users are 4GB of RAM or less (35%), or 8GB of RAM or less (overall something like 60-70%). They're actually at high risk of ending up in swap even from the memory pressure from 32-bit processes. NB: I switched the stats to be Windows-specific for this data for simplicity's sake.
Putting a 64-bit OS on a machine like that is like putting a Ferrari emblem on your Pontiac Fiero and pretending that you have a supercar. Or hooking it up to an 18-wheeler's trailer and pretending you have a transport truck.
They should have stayed with a 32-bit OS (
especially the 4-and-unders -- which included an alarming number of 2GB systems). Also it baffles me why people spend $700 on a video card and $30 on memory. The $500 card has 92% of the performance of the $700 one (and is only about ten percent as likely to explode/catch fire), and would let them have 16 gigs easily (or Moar™, possibly. I'm not current on memory prices).
Extra unused memory is used in pager/memory-protected type OSes as disk cache, so it
never goes to waste unless you store all of your data on
floppy disks.
IIRC, Unity's the limiting factor. It either doesn't have 64-bit support, or doesn't have it officially, or else it's a very early stage build that isn't stable at all - I forget which it is, but it's not ready to be the framework for a 64-bit RimWorld.
Edit - Here's what I was thinking of, although there's a chance it's out of date by now:
https://ludeon.com/forums/index.php?topic=9773.msg98407#msg98407
Somebody on steam suggested this 4GB patch http://www.ntcore.com/4gb_patch.php In case somebody dares to try it.
I haven't tested it though, i have no colony running as of late, (scrapped my colony because of an out of memory error and some weird shite, who would have thought).
Quote from: milon on March 11, 2017, 06:28:48 PM
IIRC, Unity's the limiting factor. It either doesn't have 64-bit support, or doesn't have it officially, or else it's a very early stage build that isn't stable at all - I forget which it is, but it's not ready to be the framework for a 64-bit RimWorld.
Edit - Here's what I was thinking of, although there's a chance it's out of date by now:
https://ludeon.com/forums/index.php?topic=9773.msg98407#msg98407
Klei Entertainment's new game Oxygen Not Included uses Unity, and is 64-bit only. So I assume that comment is out of date now. (although I have no idea how many problems, or not, would occur in shifting a stable 32-bit Unity game to a stable 64-bit Unity game.)
Quote from: faltonico on March 12, 2017, 05:03:16 AM
Somebody on steam suggested this 4GB patch http://www.ntcore.com/4gb_patch.php In case somebody dares to try it.
I haven't tested it though, i have no colony running as of late, (scrapped my colony because of an out of memory error and some weird shite, who would have thought).
IIUC (although I'm not a programmer, so my understanding is not going to be 100% accurate), that 4GB utility is designed to make programs LAA (large address aware), and is designed primarily to benefit programs that are limited to 2GB RAM (due to not being LAA). So given that RimWorld regularly uses upto ~3.5-4GB RAM on people computers (and starts becoming unstable as a result), and that it uses Unity (which AFAIK is LAA), then it is probably unlikely that that utility will do anything for RimWorld. (although I've used that utility myself several times for other games, and can't recall it ever breaking one of them. Not sure if it helped any of them though, but it didn't break any of them either. So that's something).
The following link seems to represent a good summary on 32-bit memory issues (although again, a programmer might have a different opinion on whether it is a "good summary" or not). http://wiki.tesnexus.com/index.php/2-4GB_game_memory_limits_and_solutions
there is another unity game that has both 32 bit and 64 bit versions (and is by a smaller developer( but still larger that ludeon studios) called payload studios) called terratech, currently terratech has issue when strting a game on 32 bit, but on 64 bit (even with the 32 bit exe) works fine. I think that terratech is using unity5 but do not actually know.
Quote from: Calahan on March 12, 2017, 06:15:48 AM
... given that RimWorld regularly uses upto ~3.5-4GB RAM on people computers (and starts becoming unstable as a result) ...
Normal 32 bit programs can only use 2GB hard maximum, and on Windows more like 1.6GB because of I/O buffers and other housekeeping memory use. The 'upper' 2GB of the address space within each process is reserved for the system to use. LAA programs can use some of that, in practice about 1GB IIRC.
I definitely would not expect a non-LAA program that's been hacked to use large addressing to work without problems though.