Multi-core support

[Fluffy (l2032)]

the cause is the non-multi-core support engine.

How do you know this to be the root cause and not e.g algorithms that simply don't scale well?

Not to mention that going multicore rarely, if ever, gives linear increase in games. I'd be extremely surprised if Rimworld running on 4core/8virtual core CPU would get 2x faster than running singlethreaded.

Thank you! I've been trying to say this for ages.

[StorymasterQ]

It's the pathing algorithm, isn't it? It's hard to (probably not can't) piecemeal that kind of algorithm, therefore it's hard to (not can't) be parallelized, and therefore hard to (not can't) work in multi-core.

So there are a lot of "not can't"s in the discussion, it's just so hard (or will take much effort that could have gone to other things) that Tynan might as well make a new game.

What other algorithms are the probable causes for the hardness (not inability) of multi-core?

[Fluffy (l2032)]

Generally speaking, games are relatively hard to parallelize, especially when a lot of the systems are interconnected. Because when system A is connected to system B, A has to wait for B to finish before it can proceed. Thats a potential slowdown, and it also makes the code immensely more complicated because you need to figure out exactly what needs to happen first, and what could potentially be done at the same time. So the challenge is to devise some way to 'break' the game into components that can run separately, and when and where these components need to wait for each other. Even if that is realistic, you still have to actually code it.

I work in computational statistics, specifically with simulations. These are generally quite easy to parallelize, as I'll typically run a couple of thousand repetitions of the same problem. The repetitions don't depend on each other, so each can just proceed in its own leisurely pace. In a situation like this, you can actually get very close to a X times speed up, where X is the number of cores. If I were to require that each repetition use the outcome of the last repetition as a starting value, I couldn't parallelize at all - thats the other end of the spectrum. Games lie somewhere closer to the latter situation.

[RawCode]

captain obvious thread...

HEY I WANT MY CAR TO FLY PLZ FIX!!!!!111111
Are you mad bro?
PLEASE DO IT I REALLY WANT!!!!1111
car initially not designed for this
PLEASE!!!111
if you want to fly get a plane
BUT I WANT TO FLY IN MY CAR111

[isistoy]

loll : ]]

[Haplo]

...

*grin* I like this

[Vas]

I'd be extremely surprised if Rimworld running on 4core/8virtual core CPU would get 2x faster than running singlethreaded.

How exactly do you come to this conclusion?  Lets say you have a 4 core machine at 3.6GHz like mine.

Single Core/Thread: Game starts to lag behind because you have a massive base, it's too much data for one core to handle.  Everything gets queued up to run in proper logical order of events.  Game slows down to handle that slowdown in processing queue.

MultiCore/Thread: Game is able to offload some work to different threads.  Thread 1 handles temperature changes.  Thread 2 handles pawn hauling jobs.  Thread 3 handles Pawn Cleaning jobs including snow and calculates whee they should go next each job.  Thread 4 handles pawn hunger and tiredness levels, beauty calculations and other such.  Thread 5 handles mental levels and thought defs.  Thread 6 handles power grid states.  Thread 7 handles random event calculations.  Thread 8 handles Animals and Plants on the map.  Game runs at normal/fast speeds because there is nothing waiting in line to be executed.

And don't give me that bullshit about buying a single core 10GHz CPU in order to play games.  No.  Unacceptable.  This game is one of those that has too much data for a single core to process.



It really sucks everyone here has taken up to trolling the community for requesting multi-core support all the time.  Out of all the things, Z-Levels, Multiplayer, "3D", this has been the most realistic request/suggestion ever.  It's sad Tynan is letting you people troll others for suggesting it.  I mean wow.  Even he must know by now his game has too much data to process on a single thread and should be considering trying to get to a system that supports multiple threads.  I think the engine the game is built on doesn't support it yet, so that's why it hasn't happened yet.  But seriously, stop trolling people for this.  You people are despicable.  I expected better behavior from you modders.

[Fluffy (l2032)]

Please do read the numerous posts made about the fact that multi-core is NOT A MAGIC PILL. I've tried to explain before that you can't just have different threads to different things, everything needs to sync up. E.g. following your example, the animal thread would need to be aware of the hauling thread, because hauling determines where things (food!) are. Similar interconnections exist between all these threads, which means that every tick, they need to wait for each other, and be performed in the correct order. That means the speed gain per core is much less than linear, and a performance increase of 100% is just very unlikely.

Please don't take my reservations as trolling, I'm merely pointing out (again) that A: it's not easy, and B: the results aren't magic. Finally, again, keep in mind that the game is build upon Unity 4, which IS NOT THREAD-SAFE. That doesn't mean you can't do multi-core at all, it just makes it much, much harder, as you basically can only use unity methods in one (master) thread.

I too, would have preferred the game to have been multi-core from the start. It's just that at this point, it'd be a monumental spend (waste?) of time and money. As RawCode succinctly pointed out, RimWorld is not a plane. Stop asking for it to fly.

[Vas]

Fluffy, I wasn't saying you were trolling.  RawCode however was.
And I know Unity 4 isn't.  Unity 5 is I believe from what I hear.  I know that KSP was using an old version for a while and finally updated to Unity 5 to get 64 bit support working and it turned out well because now I don't have to worry about how many mods I use and the game has so much less physics issues now that it can use multiple threads.

This is proof right here.  Prior to multi-threaded support, I had extreme physics problems in KSP when trying to dock with a large ship in low orbit.  Often times the physics "kraken" would happen and the ship would rip it's self apart because the physics engine would break trying to keep everything calculated in a single thread.

Now, I have smooth docking with large ships in any orbit.  Multi-thread isn't as bad as everyone thinks.  It just has to be done right which will take some trial and error.

[Ectoplasm]

This is proof right here.  Prior to multi-threaded support, I had extreme physics problems in KSP when trying to dock with a large ship in low orbit.  Often times the physics "kraken" would happen and the ship would rip it's self apart because the physics engine would break trying to keep everything calculated in a single thread.

Not 5 posts before Fluffy said the following.

Generally speaking, games are relatively hard to parallelize, especially when a lot of the systems are interconnected. Because when system A is connected to system B, A has to wait for B to finish before it can proceed. Thats a potential slowdown, and it also makes the code immensely more complicated because you need to figure out exactly what needs to happen first, and what could potentially be done at the same time. So the challenge is to devise some way to 'break' the game into components that can run separately, and when and where these components need to wait for each other. Even if that is realistic, you still have to actually code it.

It's like trying comparing chalk and cheese, they are not the same. Also in KSP a huge issue was memory limitations, something removed with 64bit.

I have to add too, that Tynan wrote his own framework for unity for christ's sake.. I say this here to point out that many devs out there just take unity and run with it.. When you rewrite code because the standard isn't good enough for rimworld.. You're on another level.

ps. Rawwcode wasn't trolling imho, just trying to simplify it for some. Because clearly when fluffy tries to explain from more technical perspective, it seems the message flies over some peoples head.

[Vas]

What RawCode said, seemed very trollish.  It's like insulting to the intellect of the user.  That's how I felt when I read it, so others may feel the same way.

As for KSP, many issues were actually single core too.  It was physics issues that happened to be related to the single core system, while memory was an issue when you had a ton of mods.  I did hear that the KSP devs had to do a lot of rewriting to get the game up to date with the new Unity, but they managed to do it.  Shouldn't say no to a widely used technology while your game is in Alpha because you might have to rewrite some things and set back development a bit.  Imagine how much harder it will be to rewrite the game once it hits 1.0 state and is fully released and everyone complains that it takes a 10GHz CPU to run it because its single core only.

[Ectoplasm]

I'm not overly familiar with the mechanics of multi core computing Vas, but the explanation of fluffy's in that the game has to sync up is frankly logical - this needs to happen first then X can continue. That is exactly how things are in Rimworld. In KSP though you have one physics model to compute all at the same time. You build your rocket and then launch it and the game only (ha! "only") Needs to compute the forces on the rockets structure & components or the temperatures generated through velocity. This occurs all at once - the game already knows the design and the various tolerances involved - it just needs to run the simulation. THAT is exactly the scenario that would greatly benefit from multi core computing.

[lude]

It's near impossible to split a physics thread and have it synced up, in most cases the physics engine has to jump extremely randomly when skipping frames to keep up, rimworld also has aspects where it would be able to gain a lot from multicore support, but it's not easy to code, there is nearly no cultural knowledge to fallback to, it's completely new terrain

http://blogs.grammatech.com/multi-core-processors-headache-for-multithreaded-code
http://www.blachford.info/computer/articles/bigcrunch1.html
https://www.info.ucl.ac.be/~pvr/vanroy-mc-panel.pdf
http://spectrum.ieee.org/computing/software/the-trouble-with-multicore
http://www.sciencedirect.com/science/article/pii/S0965997811001244


and debugging multicore/multithreaded scenarios is a lot harder than without and tynan only recently started using a debugger, he made a really great game with the tools he has at his disposal and they're two coders now

I believe they're doing everything they see as necessary in a somewhat timecritical manner and have toiled with ideas like multicore support,
it's just not something
we as a continuum, mankind
have not yet properly invented and polished.

Single core physics with other stuff running on the same thread already causes more than enough hiccups and problems, situations where stuff moves through each other but it shouldn't, caused by bad speed or bad syncing, adding a second core would just increase these problems I'm thinking of KSP in particular.

I think the only problem offloadable to a second core in rimworld through hacks and strange magical code is the one to handle pathfinding, there are only few situations where two pawns need to care for each others movements and I dunno how it's realized, but like the travelling salesman problem, most things used for pathfinding are rather ressource intensive and only in really simple scenarios easy and quick to solve, even if you always start looking from a certain point in a radius or use other quick hacks

but alas I don't know how sensitive it is to syncing or how easy or super duper hard it would be to code

I spent years losing all my c/cpp/lpc knowledge with the help of herbal medicine :e


--- edit ---

also under windows 10 my rimworld uses ~30% which is the utilization of more than two cores at 4.5 ghz

[Vas]

In KSP though you have one physics model to compute all at the same time. You build your rocket and then launch it and the game only (ha! "only") Needs to compute the forces on the rockets structure & components or the temperatures generated through velocity. This occurs all at once - the game already knows the design and the various tolerances involved - it just needs to run the simulation.

Just a note, what happens when you enter 2.5KM of 7 other ships?  The game has to load all of them and calculate more than just their "on rails" status now in real time as you move towards/past them.  It also does physics on a per part basis, not "this rocket is one object".  If you don't have enough struts on one object to keep it attached and you make a wrong turn at a high speed, that single piece will rip off, and your balance will be offset and then physics starts hurting the rest of your unbalanced ship trying to tear more things off if you make another wrong turn or move.  Along with the heat calculations per part as time goes, and the wind force per part, current gravity's affect on your ship, etc etc.  It' a lot more than just "physics doing one thing".  KSP is a 3 dimensional game, with a lot going on all at once.

Rimworld has a lot more going on of course, and is much more CPU intense than most games would be especially if you're a heavy mod user adding many more events objects pawns and such.  I'm on an i7 that goes up to 3.6GHz and I still get lagged down when my base reaches about one year old because of how massive it gets.  I get lagged down a lot less than I did on my previous laptop which was an i7 that got up to 3.1GHz (rarely though cause damaged CPU fan and the motherboard had melted partially apparently..) but yea.  I still get lagged down, and Rimworld is hardly using any of my CPU at all when I'm lagged down.  If I build my range 56 SIF shield, the game loses the ability to go at 3x speed anymore, and I have to play at 2x or less.  So that one building is a massive hit on the CPU.  A single core can not possibly keep up with everything in this game, and this game is the type that will require multi-core support.

All game developers should be doing multi-core support by default in their game engines.  Honestly if I became a game developer right now, I'd turn down any game engine (Unity 4) that did not support Multi-core and show them that they need to upgrade their support to have multi-core or other game developers could turn them down too.  "Nah, I'd rather go with something that has 64 bit and multi-core, you guys don't have it so I'll find someone better."  If other game developers were to follow this logic, then these people would have to get off their asses and make their game engines support both 64 bit and Multi-core, or they'll just keep losing customers.

also under windows 10 my rimworld uses ~30% which is the utilization of more than two cores at 4.5 ghz

Refer to a statement above as well as this: Are you using 70+ mods in your game?  Is your map more than 2 years old thus far with lots of pawns and buildings everywhere?  If not, then you aren't playing the game as hard core as I am.  Good god you should see how bad it gets when Tribals spawn even on a small map with a small base.  Like 100 fracking pawns all spawn at once and lag your game so bad you die from lag more than you die from hoards of bodies being thrown at you.  And I'm on a 4th generation i7.  You're clearly on a desktop CPU of course so.  You have more power.

[Ectoplasm]

All game developers should be doing multi-core support by default in their game engines. 

To be fair, when Rimworld started this wasn't an option in Unity. Rimworld will be 3 in November. I think you need to consider this legacy, multi core just wasn't there in Unity.