hello, i have a suggestion everybody is gonna like, Multi-Core support.
now, when you get a big colony, the game starts running like dogshit. the cause is the non-multi-core support engine.
everybody is gonna get a HUGE fps boost if this gets added
Do you want Z-level support with that
Don't forget multiplayer.
and 3D mapping in the Unreal(6?) engine.
in all seriousness Tynan can only do so much with unity, Im sure that if its ever an option worth investing the time into then he will do it.
Not sure if Multicores are needed as of yet, I can play ludricrous large maps with a good PC that is 5 years old.
Quote from: Headshotkill on January 20, 2016, 03:08:42 AM
Not sure if Multicores are needed as of yet, I can play ludricrous large maps with a good PC that is 5 years old.
That's because performance per processor has pretty much been the same over the last 10 years or so...
Also, stop suggesting things that require an engine change - they're just not going to happen.
the Multi core support is badly needed, you will basicly get a 4x performance boost, its just Unity 5 or whatever engine has multi core support....
RW runs on unity 4, which is not thread-safe. Also, 4 cores does not equal 4x the speed, it highly depends on how much can be parallelised. Finally, even if the engine supports multi-core, that doesn't mean the game can just be 'switched' to have multi-core support, it would require extensive reworking of the base code.
Now I'm not saying it wouldn't be a good idea, but it's been suggested many, many times, usually as if it's a trivial thing Tynan should do in a slow weekend. It very definitely is NOT trivial to change the game to have multi-core support.
Now added to the Frequent suggestions topic list. Im surprised its taken this long to add it.
Its needed. The fps neeeeeeeeeds to be increased
I'd throw another 30-60 (depending on improvements) to a kickstarter campaign for something like full 3d (with z-level construction), direct x12, and multi-core/threading. Running in like UE4 or Unity 5. . . Just saying
Would you do it if it's not Rimworld? Tynan would still be the one who codes it (and maybe ison), but it probably wouldn't be Rimworld. Because, as someone had said, putting 3D into Rimworld is such a massive effort, might as well make a new game.
Just saying.
And now you people see why it's hard to keep new community members here. the first 3 replies are trollish posts trolling him about how he wants something as realistic as multi-core support. It's unrealistic to not have it anymore because ALL COMPUTERS WORLD WIDE have more than one core in them now. You can't buy one with less unless you go trying to build one with a single core, which would be stupid to be honest. And honestly something like Z levels should be added, because the game now has too much in it to be contained on a single level. It already uses a "z-levels" system in a way, it just needs to be made true z levels where colonists can not leave the level they are on, but anyway.
Quote from: Vas on January 26, 2016, 12:10:47 AM
And now you people see why it's hard to keep new community members here. the first 3 replies are trollish posts trolling him about how he wants something as realistic as multi-core support. It's unrealistic to not have it anymore because ALL COMPUTERS WORLD WIDE have more than one core in them now. You can't buy one with less unless you go trying to build one with a single core, which would be stupid to be honest. And honestly something like Z levels should be added, because the game now has too much in it to be contained on a single level. It already uses a "z-levels" system in a way, it just needs to be made true z levels where colonists can not leave the level they are on, but anyway.
While many of us (modders) would agree that z-levels, multiplayer and multi-core support would have been great if supported from the start, we also have a higher than average knowledge of how the game actually works. The reason we're being derisive is that a) all three of these suggestions would basically require a full rewrite of the game, and b) Tynan, and various modders have explained on many occasions that it's not a design goal/not feasible/not going to happen.
Quote from: Nickname34 on January 19, 2016, 12:43:34 PMthe 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.
Quote from: hoho on January 27, 2016, 05:08:57 AM
Quote from: Nickname34 on January 19, 2016, 12:43:34 PMthe 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.
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?
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.
captain obvious thread...
Quote
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
loll : ]]
Quote from: hoho on January 27, 2016, 05:08:57 AMI'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.
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.
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.
Quote from: Vas on February 04, 2016, 08:34:09 AM
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.
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.
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.
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
Quote from: Ectoplasm on February 05, 2016, 06:56:32 AMIn 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.
Quote from: lude on February 05, 2016, 07:46:59 AMalso 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.
Quote from: Vas on February 05, 2016, 10:15:51 AM
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.
QuoteIf 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
I have to say I take offense at this. Clearly, that mod is horribly coded. I know in this day and age of cloud computing throwing more and more hardware (or cores) at everything is pretty much the default solution, but whatever happened to optimization?
Honestly, if a single mod is putting that much stress on your game, don't you think that mod is the problem, and not the game it self?
Ill post a pic of a rather large base i have running currently with a decent helping of mods on the biggest map and it still runs fine. Im running fx8350 so a single core of that is nothing like an i7 so yeah id agree with fluffy it must be the mods.
The 56 circular shield has to do a crazy amount of checking on the hundreds of cells in it area. I used the same code to make my shields and i can have 10+ of them simply cuz they are smaller.
"If I could, I'd make everyone do it the way I wanted them to or their game will never survive." Literally what you said, vas...
Quote from: Vas on February 05, 2016, 10:15:51 AM
Quote from: Ectoplasm on February 05, 2016, 06:56:32 AMIn 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.
Oh I know, I also use Ferraroram and the integrity mod, I also know what happens with a lot of ships near each other and being kept in physics mode or how multiplayer mod deals with that limitation or how hard it is to try to crash two things at high speeds in orbit, tho i personally didn't manage that, just watched one of scott's videos.
Quote
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.
Yeah, like the things propagating per cell is very elaborate, compared to simulators like DF2, I just upped my CPU to 4.2ghz with an FSB of 240, the "mysterious IPC" is more affected by FSB increase than by multiplier, keeping the other busses at their vanilla speeds with an increased FSB netted me very nice results with most single core limited games, especially in games like these I'm currently using 153 mods and I tend to play for longer, but can't say that having over medium sized maps is fun after a few years, I also tend to have around a 100 animals, a dozen or two bots and 40-50 colonists and a quarter of that in prisoners, but my game usually only hangs majorly when there's job ticker or pathfinder issues or other issues caused by mods, I try to resolve them as I go by playing.
So at least having some of the minor tasks that are not time critical or dynamic on another core would be nice, but that already would let debugging and bug finding problem arise that are a lot harder to fix, so I'm indifferent to should rimworld go multicore, I personally like the game and will just be waiting for it's ideological sequel that will come out in a few years or a decade when all these problems have already been tackled by students, professors and experienced game developers and the solutions then will be part of public knowledge, easily available to anyone.
Quote
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.
If i became a game developer right now I'd also look into simple or elaborate multicore usage depending on what I want to achieve, but 64bit would be an absolute must unless what I want would be smaller and faster in a 32bit scenario.
But most people learn as they go by developing and there are few sets of standards, CCC tries to propagate some, for more elegant code, better propagation of solutions and simpler designs.
Quote
Quote from: lude on February 05, 2016, 07:46:59 AMalso 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.
Yeah I use a desktop and will always be using them for gaming, even brought my old one to my parent's place so if I do vacation there I don't have to deal with my laptop.
I also know how horrible it gets once there's a few hundred pawns spawning or a tiny problem with that together bringing the game to a halt.
Also my CPU is the smaller brother of skullywag's but it does very fine in certain scenarios.
running 4 cores instead of 8 (the option where no core shares ressources with another)already increases it's single core performance by about 12-15% and increasing the FSB instead of the multiplier also increases single core performance a lot, just multiplier does a rather bad job and with games like these in most scenarios increasing FSB by 20% nets me a near 20% performance increase as well as often just being fast enough to have some overhead again or not having so much stuff lagging behind that needs to be calculated.
tl;dr that 20% made speed option 2 unlaggy again with over a 100 of my pawns and a lot of stuff.
Quote from: Ectoplasm on February 05, 2016, 11:20:09 AM
Quote from: Vas on February 05, 2016, 10:15:51 AM
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.
Yes, but other engines had it and 64 bit too.
QuoteQuote from: Fluffy (l2032) on February 05, 2016, 11:37:26 AM
Quote from: VasIf 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
Clearly, that mod is horribly coded. (stuff)
Honestly, if a single mod is putting that much stress on your game, don't you think that mod is the problem, and not the game it self?
Quote from: skullywag on February 05, 2016, 12:41:59 PMThe 56 circular shield has to do a crazy amount of checking on the hundreds of cells in it area. I used the same code to make my shields and i can have 10+ of them simply cuz they are smaller.
56 is a massive range, that's why it slows down the game. I got tired of trying to build a SIF shield every 6-8 blocks so I wanted one massive one to protect a large area so I made the mod that adds one, on top of the ED Shields mod.
Skully, are you saying that I could have 50+ small SIF shields as apposed to one large one?
Fluffy, The game lags down after I get a large base 2 or 3 years in. Doesn't your game have an extreme lag hit in late game tribal raids? Like 40+ pawns suddenly spawning to come destroy your base.
Quote from: Z0MBIE2 on February 05, 2016, 01:21:33 PM"If I could, I'd make everyone do it the way I wanted them to or their game will never survive." Literally what you said, vas...
No, I said I'd make game engine makers keep up with times or not use their product to make my game. Get it right.
No one in the world has a single core CPU anymore. All machines are multi-core unless you specifically go out designing one that is single core. There's only so much you can do with a single core at this point. You can't give more and more power to a single core without higher and higher temps. I think the world record so far is almost 9GHz on a massively overclocked system cooled with Liquid Helium I think. I'm guessing right now because I don't remember too well. Also, see? Even this extreme overclock is two core, multi-core. http://valid.x86.fr/lpza4n
So why aren't game engine developers keeping up? This technology has been out for ages, and some are just lazily lagging behind where it's safer and easier to work at rather than trying to keep up and take a little risk. I mean, Unity is finally getting up there now or trying, but still. If I were a game dev, I would look for a way to support all my potential users, and if the game engine I was looking at didn't support multicore, I would look into other game engines because I know for a fact that there is no single core gaming machines out there.
By the way, as stated before some things in this game CAN be offloaded to other cores. Path finding, for example. 40+ tribals spawn and suddenly your game goes from a smooth 60FPS down to 5FPS (technically speaking, not graphics lag) trying to process their path finding and whatever else it's processing during their attack.
Also, temperature calculations can be offloaded to another core in order to speed up temp checks. You don't need to specifically wait for a temp check to go through to test something. Simply set the cell/room temp and have the other object that deals with temps do a "check current temp" every so often.
TempCore: Run Calculations every 50ms
Heater: Checks Temp every 200ms
Cooler: Checks Temp every 200ms
ObjectThatGoesBoomIfXTemp: Checks Temp every 100ms
Just an example really. You can set how often it will check the current temp while the temp of everything is calculated separately.
Lude,
I use a gaming laptop because I don't have internet at home and have to go to town a lot. :P My current laptop can most likely do anything your desktop can do. :P Maybe not 4k resolutions and stuff but I don't care about that. 1080p is fine with me, not like I have 4k screens or need one anyway. xP Not much else I can reply to as it would either be off topic or I agree. :P
QuoteSo why aren't game engine developers keeping up? This technology has been out for ages, and some are just lazily lagging behind where it's safer and easier to work at rather than trying to keep up and take a little risk.
For the last time;
because it is hard, and
games do not lend themselves particularly well to parallelism.
At this point we're both sounding like broken records. I keep giving you perfectly valid reasons for why Ludeon/Tynan may not have implemented, and may never implement parallelism to take advantage of multi-core architecture ( we never know, maybe he'll get inspired. ), and you keep giving irrelevant counter examples.
In the end, I love Ludeon and Rimworld for what it is, one guy doing what he wants, how he wants to do it, and creating a creative and weird game that can truly surprise you.
oh on a final note, sure, my game slows down too when a colony gets large. But 1; the game was never meant to be a Sim City clone, it's a small-scale story telling game, and 2; I would not use a mod that scans ~350 cells every single tick.
<img removed>
Ludeon made Unity? I didn't know that. </sarcasm>
I was blaming Unity for not being multi-core. Not Ludeon. I was saying that had I been the one choosing a game engine, I would have chosen one that had multi-core support to begin with, as well as 64 bit support. Two technologies that are in every computer around the world now. Yes, it's hard, but you have to adapt and get used to it. You can't just stay in the past.
I love the game still, even though I'm irritated that some of it literally throws logic out the window as if the laws of physics don't apply (The year's length, Steel being thousands of years old), I just want m new age computer to be able to play this game smoothly. But it can't. No computer can, because it does not utilize multi-core support and there is way too many things in this game that require CPU time. Some things are constant and require per tick calculations thus putting a larger load on the CPU. Some of these calculations literally can be offloaded to another core without hurting gameplay in the slightest and without anything waiting on that core to finish what its doing in order to continue.
Like I said in an earlier example.
Put temperature calculations into its own core. Have it calculate all temperature things per tick as normal, maybe even give it double speed on that so it can check more often because it now has its own dedicated core.
Now, things that require the temp no longer need to ping the CPU or anything to find out, they just read the "CurrentTemp" value in memory provided by the other core that does the temperature work. So one core is no longer managing path finding, temperatures, random event counters, animals, grass growing, power network, etc.
But yes, it is hard work. and UNITY, should have been putting support for this in to begin with and no game engine should not support multicore at this point in time because we simply aren't ever going back to a world of single core processing. After seeing the game progress for a long time now, I can see that raids are increasing in size in order to make them more difficult which is putting even more hurt on the CPU. What happens when this game is released and it is set up in such a way that you can only play for 6 game months before the world's greatest super computers start to lag? Who's going to want a game that can't be processed unless you have a liquid hydrogen cooled CPU running at extreme levels of overclock that'll melt your CPU in less than half a second should your cooling solution fail?
Your argument: Because it's hard.
My argument: It needs to be done.
You proved its hard.
I proved it needs to be done.
So yes, we've gone around in a circle of you saying "its too hard, so we shouldn't do it." while I keep pointing out how the game lags too much even on high end CPUs mid-late game and it isn't even released yet which could be bad for the future of the game if we add any more advanced things to the game.
EDIT: Nice image, I don't even remember who that is, but it did manage to take me about 20 minutes to load it. :P
And when you get into this never ending loop ease will more than likely win out.
Well, I guess that means when the game is released and you can't play for more than 1 hour because an hour later even on the most high end machines, people will complain, rate the game down for being unplayable, and it will lose many sales. And you will have no one to blame but yourselves for not pushing multi-core harder before release. I know for a fact, if people play the game and it starts to lag on their high end machines, they aren't going to be "understanding" of the programming difficulties of multi-core support. They will complain, and they will bitch. Some people even bitch about Metal Drift not being multi-core, and it doesn't even need multi-core support because it's too basic of a game that can't even lag on any processor that's still working today (assuming people stop using 10 year old CPUs that is) (graphics is another story).
I know that the community will complain about lack of multi-core support, and while we here understand the difficulties of making the game multi-core, the masses will not understand and will rant, bitch, complain, rate the game down, make it out to be a bad game to buy. I foresee this happening. So if Tynan is ok with the risk of this happening, sure, he can continue on the easy path and let the game continue being laggy on high end multi-core CPUs. It's his choice after all.
I originally replied because people here were trolling the author of this post for wanting multi-core. I mean sure, he did kinda say it in a basic way and a bit of that standard ignoring everything others say "please we need it, do it, make it happen" way... But no one should troll another for such a legitimate suggestion. That's wrong, no, just don't do it. He hasn't even been back since then.
Multi-core is a legitimate suggestion that no one should troll someone over because as you know, nearly all CPUs in the world are multi-core multi-threaded. Even the world record CPU is multi-core with a speed of nearly 9GHz. You'd think a world record CPU would be single core to promote more speed and better temp stability but nope, it was multi-core.
Quote from: Vas on February 06, 2016, 09:16:28 PM
Ludeon made Unity? I didn't know that. </sarcasm>
I was blaming Unity for not being multi-core. Not Ludeon. I was saying that had I been the one choosing a game engine, I would have chosen one that had multi-core support to begin with, as well as 64 bit support. Two technologies that are in every computer around the world now. Yes, it's hard, but you have to adapt and get used to it. You can't just stay in the past.
I love the game still, even though I'm irritated that some of it literally throws logic out the window as if the laws of physics don't apply (The year's length, Steel being thousands of years old), I just want m new age computer to be able to play this game smoothly. But it can't. No computer can, because it does not utilize multi-core support and there is way too many things in this game that require CPU time. Some things are constant and require per tick calculations thus putting a larger load on the CPU. Some of these calculations literally can be offloaded to another core without hurting gameplay in the slightest and without anything waiting on that core to finish what its doing in order to continue.
Like I said in an earlier example.
Put temperature calculations into its own core. Have it calculate all temperature things per tick as normal, maybe even give it double speed on that so it can check more often because it now has its own dedicated core.
Now, things that require the temp no longer need to ping the CPU or anything to find out, they just read the "CurrentTemp" value in memory provided by the other core that does the temperature work. So one core is no longer managing path finding, temperatures, random event counters, animals, grass growing, power network, etc.
But yes, it is hard work. and UNITY, should have been putting support for this in to begin with and no game engine should not support multicore at this point in time because we simply aren't ever going back to a world of single core processing. After seeing the game progress for a long time now, I can see that raids are increasing in size in order to make them more difficult which is putting even more hurt on the CPU. What happens when this game is released and it is set up in such a way that you can only play for 6 game months before the world's greatest super computers start to lag? Who's going to want a game that can't be processed unless you have a liquid hydrogen cooled CPU running at extreme levels of overclock that'll melt your CPU in less than half a second should your cooling solution fail?
Your argument: Because it's hard.
My argument: It needs to be done.
You proved its hard.
I proved it needs to be done.
So yes, we've gone around in a circle of you saying "its too hard, so we shouldn't do it." while I keep pointing out how the game lags too much even on high end CPUs mid-late game and it isn't even released yet which could be bad for the future of the game if we add any more advanced things to the game.
EDIT: Nice image, I don't even remember who that is, but it did manage to take me about 20 minutes to load it. :P
actually unity is multi threaded:
"We internally multithread code with our job system. We do it in a way that is completely hidden from the user for as much code as possible. The guiding principle is always that from a script the outputs and order of outputs are always the same, whether multithreading is enabled or not. Essentially we provide deterministic behaviour when multithreaded code is enabled. Eg. Mecanim / Shuriken / Multithreaded renderer / Mesh skinning / Cloth / Various smaller tasks etc all use the job system. "
Recent versions of Unity introduced more multithreaded editor improvements like substance reimports (from http://unity3d.com/unity/whats-new/unity-4.2 ), and skinning can be done on the GPU (DX11, Pro only), which technically isn't multithreaded but does run massively parallel outside the CPU, so you know, basically the same thing :)
Additionally, going forward Unity is looking at the following:
"We have recently invested a some good chunk of time in improving the scheduling. Specifically we are coming up with safe ways of running as much code as possible in parallel to scripting code. Running not only the render thread but also arbitrary jobs in parallel to scripting is quite important for getting full multithreading utilization.
Scripting code can do pretty much anything at any point and our goal is to make it invisible to game code when we do multithreading except for the performance increase. So it's a bit of a tricky problem.
For example a script might get/set the position of a transform component at any point. So if you run the animation system in parallel and it writes to the transform position, accessing the transform must wait for the job to complete. We found some very interesting ways to handle this in a safe and very efficient way. A lot of work went into lock free data structures to make it efficient. But it's showing some very big improvements. This is definitely not shipping yet and still in deep R&D.
We also are converting more and more code, recently Navmesh, culling a couple of smaller chunks of code like caching transforms prior to culling etc to be multithreaded."
as a tip win10 scheduling is superior to win7 or 8 and will net you an improvement in single core heavy games, up to 12% but mostly somewhere around 6-8% and there are probably scenarios where it's worse or better
and under win10 the game utilizes three cores, no clue what exactly it does but two are usually heavily utilized while the third not so much
I would need a monumental colony in vanilla to test my processor (which doesnt have a particularly high clock) even modded im not seeing slowdowns with 15+ colonist plus a dozen bots and 100s of animals on full size maps 5 years into the game. It sounds to me like the people mentioning slowdows are using the same set of mods of the hardcore modpack. My guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
Quote from: Vas on February 06, 2016, 09:16:28 PM
Well, I guess that means when the game is released and you can't play for more than 1 hour because an hour later even on the most high end machines, people will complain
Anyone else here thinking that this is complete and utter rubbish? ONE hour and your game is unplayable? Rubbish. Total rubbish. Stop exaggerating. That doesn't happen for me on an i3-2100. And if it is happening for you, clearly it's something other than rimworld that's the root cause. MODs maybe? If a mod is causing problems no number of additional threads will fix things.
Quote from: skullywag on February 08, 2016, 12:06:38 PM
I would need a monumental colony in vanilla to test my processor (which doesnt have a particularly high clock) even modded im not seeing slowdowns with 15+ colonist plus a dozen bots and 100s of animals on full size maps 5 years into the game. It sounds to me like the people mentioning slowdows are using the same set of mods of the hardcore modpack. My guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
Ultimately though I'd concede the point that multi threading would be better, but even in Factorio which uses multi threading (though currently in a limited way) You can still end up with a factory so big that the game slows down.
Quote from: kovarexYes, but in a limited way.
- It uses separate threads when preparing the render data.
- It uses separate thread for render and game update.
- It uses separate thread for map generation.
But the game logic (which is the most limited factor) runs in single thread, so when your factory gets really big it will start to lag while your other cores will not be utilitised fully.
We will probably split the game logic into multi threaded algorithm someday, but it is not as easy :)
And it is that last sentence from kovarex (head developer for Factorio) Which I feel just flies over your head. Multi thread support was not available when rimworld started development, would you tell us now how long it would take to rewrite rimworld to facilitate multi threads? I do not know the complexity or intricacies involved, but I do know that if it were easy - it would of been done already. But who knows what plans there are for rimworld down the line.
Quote from: lude on February 08, 2016, 11:17:20 AM
as a tip win10 scheduling is superior to win7 or 8 and will net you an improvement in single core heavy games, up to 12% but mostly somewhere around 6-8% and there are probably scenarios where it's worse or better
I'm on Windows 10 and after many straight hours of gameplay, the game gets laggy, and then when I start making intense structures like massive shield generators, the game bogs down to a crawl. So the game does get laggier the larger my base is, even on Windows 10 and it's crappy horrible minimalist system where people seem to THINK it runs faster because they deleted all graphics in Windows 10 and deleted old code making older games incompatible, like Blit technology.
Quote from: Ectoplasm on February 08, 2016, 01:46:12 PM
Quote from: Vas on February 06, 2016, 09:16:28 PM
Well, I guess that means when the game is released and you can't play for more than 1 hour because an hour later even on the most high end machines, people will complain
Anyone else here thinking that this is complete and utter rubbish? ONE hour and your game is unplayable? Rubbish. Total rubbish. Stop exaggerating.
Quote from: skullywag on February 08, 2016, 12:06:38 PMMy guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
Ultimately though I'd concede the point that multi threading would be better, but even in Factorio which uses multi threading (though currently in a limited way) You can still end up with a factory so big that the game slows down.
Quote from: kovarexWe will probably split the game logic into multi threaded algorithm someday, but it is not as easy :)
Multi thread support was not available when rimworld started development, would you tell us now how long it would take to rewrite rimworld to facilitate multi threads? I do not know the complexity or intricacies involved, but I do know that if it were easy - it would of been done already. But who knows what plans there are for rimworld down the line.
1. I was saying when the game is released, this could be an effect of the game when trying to play long term if it does not use multi-threading by then. You're meant to quickly get off the planet, which is what Tynan is trying to do for the game. He wants to make late game players like me have a harder and harder time treating the game as a colony simulator rather than a "get the hell off this planet" simulator. His making larger and more complex raids is proof that the game is going down a semi-bad path where in order to make it more difficult, he just lobs more and more mindless AI at you. The more complex you make the AI, the more CPU they will need to operate. So whether he increases the AI abilities or increases the number of AI thrown at you, both are going to need more than one core to operate if it is to maintain smoothness.
2. I didn't look much into Factorio. It never interested me when I saw it.
3. I'm pretty sure at this point multi-core support will be very complex to add in. The only things I can see that can somewhat easily be split off into their own threads without needing to wait for other things in the game to process first, is Temperature, and Path finding. Path finding may need to wait on a few things in the game, but the way it works now I don't think so. There might also be the power grid that could be split off, but that one does affect one of the main threads in the game so that could be hard to do, who knows. I just know that, after 6+ hours of gameplay, my game becomes very laggy. I can't build my favorite shield generator because the ProtectCell method is very CPU intense.
Quote from: skullywag on February 08, 2016, 12:06:38 PMMy guess is we have a few mods that need some optimisation, cuz im just not seeing these performance issues...
I have 70 mods. 6 hours into the game, without even making shields yet, my game gets laggy. Particularly laggy when a Tribal Raid comes in, which is just a cluster fuck of 100+ pawns bum rushing you.
Vas, you actually have a point in that there will probably be negative comments about it being single threaded on steam. This is something for Tynan to think about, and balance with the cost and opportunity cost of adding more content. As noted before, it's a huge amount of work, during which time no or hardly any new content would be added. We could debate if such a 'content drought' would be worse for PR/sales than being single threaded, but that would all boil down to assumptions, so let's not go there.
As for your comments about speed. Again, you mention that adding 'intense structures' makes the game laggy. This is absolutely completely your choice. The game is very moddable, which means that there are (possible) mods out htere that will just be too intensive. It's hardly like you can design for that kind of thing (Oh and btw, even in multi-core that one mod would still run in one core (unless the modder goes multi-core too, which is unlikely at best), and would still slow down the game to a crawl.)
As for the comment about Win10. If you remove UI elements and obsolete code, how is that a 'perceived' speed increase? Sounds to me like the speed increase is very real, you just don't like the way it's done.
We modders add most of the content to the game though. Right now there isn't much PR/Sales going on I don't think because the game isn't on steam yet and most people wan the game on steam before they buy it.
I've had laggy gameplay without mods. It happens often late game with huge raids and such. Its easier to see when you have a heavily modded game though because we are using things that are available in the game's code already just in a more advanced or larger way.
Sure, we could downgrade to MS DOS and have a speed increase too. Lets do that!
I wouldnt say mods provide most of the content, but yes, a large amount of content is provided through mods. Problem with that is that modders don't necessarily have the same coding standards as Tynan does, and some mods are known to be quite horrible performance wise. I would hope any reasonable person understands that mods slow down a game, even the Steam crowd. In the same line of thinking, because of the game being so moddable, I don't think we can reasonably expect it to "always run smoothly". You just don't know what a modder/player decides to add (e.g. adding a building that scans ~500 cells for their contents 60 times per second..).
I did say 'remove [...] obsolete code'. MS-DOS is very much obsolete. Modern OS's have a vastly improved kernel, and every once in a while, doing a spring cleaning is not a bad idea. (Just like you should probably tone down or delete that shield mod).
The game uses quite a horrible system for mods. We have to over writ every single thing in a Def when we change it. No two people can modify the same def.
Example: I can't alter Hydroponics to be 1x1 in size, while someone else changes the hydroponic's HP to 7000, while someone else changes the materials used to make it.
Starbound lets multiple mods edit the same item and it work so long as the modders did it right using an _merge _overwrite method.
Ok, lets go to a modern day DOS, according to you, that would be an improvement. Delete all UI, everything in the system, go to a modern day DOS using a new age kernel. Like Power Shell. No more UI of any kind. Imagine what kind of speed boost you get then!
Honestly, my 4 year old Windows 7 laptop with a 2-3 year old operating system well used and all, cloned several times, boots up faster than my new 2 month old Windows 10 laptop with hardly anything on it yet. And no, don't claim it's the hardware specs because this machine can run circles around my old laptop. Just look at the specs in my sig.
my surface pro 3 i7 windows 10 boots from cold in < 2 seconds, i press power i see a flash then the logo and spinny thing goes for a second and then im on my lockscreen. Just saying.
Sure you can modify the same def. Create a dll and go to town. I do it all the time to make sure I don't just catch/alter vanilla defs, but all modded defs of a kind.
And yes. Generally speaking, when you remove features you don't need, your system will speed up. There's a reason some people prefer working with command line interfaces, and that there's server versions of many OS's. Wether or not your particular system is faster or not is anecdotal, and fairly irrelevant.
@zombie; nope. Whole defs are overwritten.
The last def loaded lives whole.
Quote from: skullywag on February 11, 2016, 02:44:44 AM
The last def loaded lives whole.
That sounds like a weird pass phrase in a weird spy movie. An indie one, at that.
Quote from: skullywag on February 10, 2016, 10:52:06 AM
my surface pro 3 i7 windows 10 boots from cold in < 2 seconds, i press power i see a flash then the logo and spinny thing goes for a second and then im on my lockscreen. Just saying.
A minimalistic machine with nothing installed, right? Isn't a surface pro a performance tablet or laptop? That doesn't have a GPU or uses an integrated one that is. Something that is incapable of doing much. Mine is a hard core gaming machine with lots of things installed. Not all simultaneously running of course. Steam, Skype, and my security/maintenance tools all boot up with the machine. Even more things boot up on my Windows 7 hard drive because it's a 4 year old system with tons more stuff installed and 4 years of preferences and settings on it. It boots up faster than Windows 10 does.
Quote from: Fluffy (l2032) on February 10, 2016, 03:41:18 PM
Sure you can modify the same def. Create a dll and go to town. I do it all the time to make sure I don't just catch/alter vanilla defs, but all modded defs of a kind.
And yes. Generally speaking, when you remove features you don't need, your system will speed up. There's a reason some people prefer working with command line interfaces, and that there's server versions of many OS's. Wether or not your particular system is faster or not is anecdotal, and fairly irrelevant.
Not all of us can create DLLs and advanced mods like that. Some of us can only do XML edits. Starbound realized that and made it easy to mod the files and allowed multiple people to edit the same file via _merge and such.
Not all of us can use command line interfaces because we aren't knowledgeable enough or don't have the memory capacity to remember every command or argument to put in.
To be fair though, you honestly can't argue and complain about the xml overwriting others if you're incapable of making dll's. That's the solution, and I doubt Tynan is focusing to make modding ultra easy for everyone.
Alphas aren't about optimizations though, which I suppose is what multi-core support could be categorized as.
Game runs fine on a Dual-core 2.1Ghz AMD processor (A very old one, laptop processor even), also had it run fine on a 2.6 Ghz Core2Duo..
Optimizations come later, any way.
I feel like this topic is starting to devolve into random arguments. I like that.
First, the generic point. Adding features to any piece of code will generally make it slower. Those features may be useful or necessary to you, but they will make the code slower. A GUI is pretty much mandatory for most PC-users, but the computer would run faster without it. (Whether it would be more efficient in daily use is an entirely different matter.)
Second, the specific point about win 10 vs win 7. Let's look at the first handful of google hits for the phrase "win 10 vs win 7 boot times".
1) https://www.youtube.com/watch?v=wb4Jd6-k2pw - benchmark on a real crappy machine, win 10 performs about 10% slower, but boots several seconds faster.
2) https://www.youtube.com/watch?v=taakavJ0mDI - Win 10 boots several seconds faster.
3) No benchmarks (google, please).
4) http://www.techspot.com/review/1042-windows-10-vs-windows-8-vs-windows-7/ - win 10 is marginally slower to load from logo (whatever that means), but much faster to load from sleep/hibernate. Win 10 performs marginally better than win 7 in single thread, 7% faster in multithread. Win 10 performs much better on Futuremark PCMark 7 benchmark. Win 10 is slower with most browsers (Edge appears to be quite fast), and marginally slower in other common office applications. I/O disk operations are similar across win 7/8/10, with 7 lagging behind in one test. Gaming performance is equal for all three, with 7/10 trading blows in particular games.
5 & 6) not relevant (win 7 vs 8)
7) http://www.tenforums.com/performance-maintenance/20765-lets-hear-how-your-pcs-performing-win-10-vs-win-7-a.html - mixed, but feedback seems to be in favour of win 10. Note that this was close after release, and many gripes were (hopefully) fixed by now.
I could keep going on and on, but your one subjective measurement that win 10 is loading slower isn't really holding up against the majority of evidence out there. Now, ofcourse it's entirely possible that win 10 does boot slower on your particular machine, but saying that it loads slower in general seems like an unsubstantiated claim. Finally, we do have to take account of the fact that google is spying on me, and I wouldn't put it past them to filter search results just so that they make me happy, and more likely to click an add somewhere. We could try and test that theory - why don't you also do a google search and report back?
Finally, I actually agree with you that it would be nice to edit individual xml tags without overriding the whole tag, I actually proposed building that into CCL - but (for reasons I can't remember, but I'm sure they were good...) most modders thought that was a bad idea.
Quote from: Vas on February 04, 2016, 08:09:01 AM
Quote from: hoho on January 27, 2016, 05:08:57 AMI'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?
Experience from writing software running in parallel. I'm almost certain there is some "main" thread that runs stuff that can't be parallelized effectively and will limit the overall speed the game can run:
https://en.wikipedia.org/wiki/Amdahl%27s_law
Quote from: Vas on February 04, 2016, 08:09:01 AM
MultiCore/Thread: Game is able to offload some work to different threads.
Emphasis on "some".
Quote from: Vas on February 04, 2016, 08:09:01 AM
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.
Nice hypothesis. Too bad all these things are depending on each other meaning there is tons of synchronization and waiting for intermediate results between threads meaning it that parallelization won't give anywhere near linear increase in speed.
Quote from: Vas on February 04, 2016, 08:09:01 AM
It really sucks everyone here has taken up to trolling the community for requesting multi-core support all the time.
Most people I've seen "trollin" here are people that actually know a bit or two about programming.
Quote from: Vas on February 04, 2016, 08:09:01 AM
Even he must know by now his game has too much data to process on a single thread
I *highly* doubt that. Take Factorio - it has little to no problems handling hundreds of thousands of objects in-game at 60 updates per second without multithreading. All it takes is to use efficient algorithms, possibly with redesigning one's data structures to match those algorithms. As simple things as how variables in a structure are laid out can mean massive speed difference due to trashing of L1 cache, having not-so-good data structures (e.g linked lists instead of arrays/vectors) can mean you'll break the processor precaching leading to it waiting for hundreds of cycles for data to arrive just to spend a dozen cycles to do the math on it.
Quote from: lude on February 05, 2016, 01:39:37 PMYeah, like the things propagating per cell is very elaborate, compared to simulators like DF2, I just upped my CPU to 4.2ghz with an FSB of 240, the "mysterious IPC" is more affected by FSB increase than by multiplier, keeping the other busses at their vanilla speeds with an increased FSB netted me very nice results with most single core limited games
That seems to point to the game/mods being inefficient in their data layout in memory. Increasing FSB lowers memory latency and thus helps in scenarios where either precaching doesn't work as well or where caches get trashed.
Quote from: Vas on February 06, 2016, 10:17:00 AM
Quote from: Ectoplasm on February 05, 2016, 11:20:09 AM
Quote from: Vas on February 05, 2016, 10:15:51 AM
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.
Yes, but other engines had it and 64 bit too.
At the time, there pretty much were no other engines availiable for the price of Unity.
Also, 64bit support is trivial compared to multithreaded stuff. Pretty much the only thing you need to look out for is doing pointer arithmetic.
Also, there are scenarios where 64bit instead of 32bit computing causes performance losses.
QuoteBy the way, as stated before some things in this game CAN be offloaded to other cores. Path finding, for example.
I'm almost certain that pathfinding in this game is one of the least expensive algorithms, unless awfully inefficient algorithms are being used right now. Maps are relatively small and there aren't many pawns running around. No, 100 isn't many for half-decent pathfinders on a 500k square area.
Again, bringing Factorio as an example, they have infinite map sizes, kind of like Minecraft - their size is limited to how far you've explored. They improved their pathfinding speed by several orders of magnitude by tuning the algorithms.
QuoteAlso, temperature calculations can be offloaded to another core in order to speed up temp checks.
As I said earlier, those checks aren't independent and depend on other things leading to having to synchronize things leading to nowhere near as fast speedups.
For example, if temperature check has to alter parameters of something it means nothing else can access that something during the operation. The data of the "something" has to be locked, modified and unlocked. Every single time anything else access that object, that lock has to be checked no matter if it is locked or not in reality. It means often times the locked status has to be transferred from one core to another, through RAM in worst-case scenarios. If something does have it locked then everyone else are just dead in the water busylooping and checking for when the lock is released. In other words, everything else waiting behind the lock are wasting CPU time while doing nothing useful.
QuoteI was saying that had I been the one choosing a game engine, I would have chosen one that had multi-core support to begin with, as well as 64 bit support.
Can you point to an engine from 3y ago that supported those things and didn't cost half a million?
Quoteand UNITY, should have been putting support for this in to begin with
Considering it took two YEARS for KSP to adapt to unity5, how long did you think unity devs had to spend to make their engine to support multithreading? IIRC, they were essentially forced to rewrite almost everything.
For the record, I'm playing the game on a CPU from 2007, Core 2 Quad 6600. A 2.4GHz CPU. The game runs roughly as fast as on my laptop with the latest I7 running at 2.8GHz. In pretty much every synthetic test, the laptop CPU is almost twice the speed of the older CPU in single-threaded loads. This, again, hints to me that isses are in algorithms and/or data layout. Most likely it's not the game but the mods used. They are probably trashing caches and thus depending heavily on memory latency. Those two are almost equal between the two PCs I have.
Last time I had any serious issues was when I was using zombie apocalypse, aparello and something that modified weather calculations. Problem was that first mod added huge waves (seeing >100 zombies was common), second added a TON of clothes that are *actively* worn (leading to several times more calculations to be made for temperature/combat and most likely a lot of other things) and last one simply made weather calculations take longer. Each mod individually probably wouldn't have made much of a problem but combined they increased some calculation requirements by at least an order of magnitude. In addition, they didn't add a constant scaling but exponential.
Hello guys, pitching in
actually RimWorld does a good job with defining individual mods and such, that's how you do "modifications" e.g tweak a particular object, and RimWorld as it is Runs fine on my 1.2 ghz dual core atom 2gb ram notebook. Its the number of entities and their pathing that makes my game gobble so much processing due to select cells being selected on a large number of objects simultaneously, which just works! *not being todd.
My elderly mods, I've made all my buildings especially my traps use Ticks which hogs processing but all I've set up is limit ticking by a quarter to optimize its usage this is defined on my old iteration of Traps where Trap Holes wait for an entity to go into a single cell every game tick, butRimWorld responds very well to this due to testing 100pcs of trap holes and nay a single process hog was encountered running fine as a dandy on my little notebook. *note that this was alpha7 I haven't played and modded since sadly :(
all in all I think Tynan is doing superb on RimWorld and I hope this piece of software he made will be a legend once its brought high above the atmosphere for everyone to enjoy. Once RimWorld goes live we'll all just look back at how we all argued what RimWorld should be, rather than what RimWorld has become.
Quote from: minami26 on February 12, 2016, 03:13:43 AM
all in all I think Tynan is doing superb on RimWorld and I hope this piece of software he made will be a legend once its brought high above the atmosphere for everyone to enjoy. Once RimWorld goes live we'll all just look back at how we all argued what RimWorld should be, rather than what RimWorld has become.
Well said.
Quote from: hoho on February 12, 2016, 02:08:29 AMQuote from: Vas on February 04, 2016, 08:09:01 AM
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.
Nice hypothesis. Too bad all these things are depending on each other meaning there is tons of synchronization and waiting for intermediate results between threads meaning it that parallelization won't give anywhere near linear increase in speed.
You do realize the game doesn't need to wait for any reason to get a temp right? Temp can entirely be separated into a different thread, nothing needs to wait on it. Heat/Cold pushers while powered, will be processed by the temperature thread.
Path finding can also be separated I believe, and path finding is quite the intensive event. Ever had 100 tribals spawn on your map?
Sure, some things will need to wait on a thread, but it may not be as much work. I'm not entirely sure but I'm guessing here:
Thread 1 (main thread) : Pawn starts cleaning? == True
Thread 1: Push to Thread 4
Thread 4: Path find to nearest dirt spot.
Thread 4: Clean spot.
Thread 4: Loop 10x times.
Thread 4: Check if pawn needs to change jobs. If False, loop 10x times. If True, push to Thread 1.
Quote from: hoho on February 12, 2016, 02:08:29 AMQuote from: Vas on February 04, 2016, 08:09:01 AM
It really sucks everyone here has taken up to trolling the community for requesting multi-core support all the time.
Most people I've seen "trollin" here are people that actually know a bit or two about programming.
I was talking about the first few posts, not the discussions after I came in. It doesn't matter if you know a thing or two about programming, it doesn't give you the right to troll someone who doesn't. You explain why x feature can or can't be done, and you leave it at that. You don't go "Hah, sure, when pigs fly." like some ass hat.
Quote from: hoho on February 12, 2016, 02:34:40 AM
QuoteBy the way, as stated before some things in this game CAN be offloaded to other cores. Path finding, for example.
I'm almost certain that pathfinding in this game is one of the least expensive algorithms, unless awfully inefficient algorithms are being used right now. Maps are relatively small and there aren't many pawns running around. No, 100 isn't many for half-decent pathfinders on a 500k square area.
I've had large raider spawns land on my map, mostly Tribals, that do it, causing massive lag as they all path find to their idle spot, then the lag settles slightly, then starts up again when they start path finding to my elaborate base setup. This even happens on the default sized map with little to no mods.
Quote from: hoho on February 12, 2016, 02:34:40 AM
QuoteAlso, temperature calculations can be offloaded to another core in order to speed up temp checks.
As I said earlier, those checks aren't independent and depend on other things leading to having to synchronize things leading to nowhere near as fast speedups.
For example, if temperature check has to alter parameters of something it means nothing else can access that something during the operation. The data of the "something" has to be locked, modified and unlocked. Every single time anything else access that object, that lock has to be checked no matter if it is locked or not in reality. It means often times the locked status has to be transferred from one core to another, through RAM in worst-case scenarios. If something does have it locked then everyone else are just dead in the water busylooping and checking for when the lock is released. In other words, everything else waiting behind the lock are wasting CPU time while doing nothing useful.
If an object in the game needs to check the temp that is using Thread 1, and Thread 6 is handling temperatures. Thread 6 does the temp calculations and sets the temp of a room into memory so that any Thread 1,2,3,4,5,7,8 object can check it any time. It keeps outputting the temp to those memory values as often as it is told to. Anything that pushes heat or pushes cooling, is processed by thread 6. If such object relies on power, the power thread, thread 4 (for example) can keep a list of powered objects in memory, and alter their state like that so thread 6 simply needs to check that Item624722 Power == 1 before processing it's heat/cold pusher stats. Thread 6 does not need to alter the power net to check the state of an object. Thread 4 does not need to alter the temperature of anything to check the amount of heat in an area. They check a memory value before running their command.
Instead of Thread 1:
Check Power Net;
Power Net Positive == False;
Check power net storage;
Power net storage == Positive;
Set Item624722 power state to True;
Set Item11935 power state to True;
Set other items power state to True; (probably 40 more lines)
Check Item624722 power state;
Item624722 power state == True
Item624722 pushes 16 units of heat to Room662;
Check Room662 Size;
Room 662 size == 30; (cells)
Alter Room662 temperature + 0.53;
Is Room662 temperature dangerous;
Room662 temperature < 400;
Check Item11935 power state; (+7 more lines)
Check other heat/cold pusher power states; (In my case, normally 20 items here, +7 each one)
Check OutdoorsTemp;
Alter all temps inside walls touching Outdoors -0.7; (Probably 20 lines of stuff here)
pawn job7225 (and following 6 lines);
(+60 more lines of miscellaneous stuff);
Check Power Net; (looping back to beginning for the next tick)You'll get Threads 1, 4, 6:
Simultaneously:
Thread 1: Pawn Jobs (+30 more lines)
Thread 1: Countdowns for story teller events (+5 lines)
Thread 1: Set memory values for various things so other threads can access quickly (+12 lines)
Simultaneously:
Thread 4: Check Power Net;
Thread 4: Power Net Positive == False;
Thread 4: Check power net storage12; (memory value for that particular networked storage)
Thread 4: Power net storage12 == Positive;
Thread 4: Set Item624722 power state to True;
Thread 4: Check Power Net; (loop back to beginning of this stage, for all other items)
Simultaneously:
Thread 6: Check Item624722 power state;
Thread 6: Item624722 power state == True;
Thread 6: Item624722 pushes 16 units of heat to Room662;
Thread 6: Check Room662 Size;
Thread 6: Room 662 size == 30; (cells)
Thread 6: Alter Room662 temperature + 0.53;
Thread 6: Is Room662 temperature dangerous;
Thread 6: Room662 temperature < 400;
Thread 6: Check Item11935 power state; (loop back to beginning for all other heat/cold pushers)
Thread 6: Check OutdoorsTemp;
Thread 6: Alter all temps inside walls touching Outdoors -0.7; (Probably 20 lines of stuff here)I'm just, making a rough guess here for this stuff. But Power Net (thread 4) uploads the state of the power grid for each item to a memory value, while temperature (thread 6) checks those states before executing the heat/cold pushing power of that thing and altering the temperature before uploading the temperature of that room to memory both doing this simultaneously and synchronization doesn't matter here because the temperature from the previous check 1 tick ago is still there and it is doubtful to have changed dramatically enough in a single tick to matter if it checked 1 nanosecond too soon. While Thread 1 is free to carry out the other commands minus all temperature and power net calculations, where it only needs to run a single "Check state" command to check a value from memory that the other thread had uploaded there.
Granted, I don't know how this stuff works. This is just how I imagine it would work if it were optimized with multi thread.
Argument ad nausum.
Quote from: Vas on February 14, 2016, 02:41:40 PM
Quote from: hoho on February 12, 2016, 02:08:29 AMQuote from: Vas on February 04, 2016, 08:09:01 AM
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.
Nice hypothesis. Too bad all these things are depending on each other meaning there is tons of synchronization and waiting for intermediate results between threads meaning it that parallelization won't give anywhere near linear increase in speed.
You do realize the game doesn't need to wait for any reason to get a temp right? Temp can entirely be separated into a different thread, nothing needs to wait on it. Heat/Cold pushers while powered, will be processed by the temperature thread.
Path finding can also be separated I believe, and path finding is quite the intensive event. Ever had 100 tribals spawn on your map?
Sure, some things will need to wait on a thread, but it may not be as much work. I'm not entirely sure but I'm guessing here:
Thread 1 (main thread) : Pawn starts cleaning? == True
Thread 1: Push to Thread 4
Thread 4: Path find to nearest dirt spot.
Thread 4: Clean spot.
Thread 4: Loop 10x times.
Thread 4: Check if pawn needs to change jobs. If False, loop 10x times. If True, push to Thread 1.
Gawd no. Tynan will not rewrite the jobs system just for you.
Also, having 1 thread per pawn won't end well. The game *will not* be faster, if anything slower due to the extra overhead starting and calling another thread.
Quote from: Vas on February 14, 2016, 02:41:40 PM
Quote from: hoho on February 12, 2016, 02:34:40 AM
QuoteBy the way, as stated before some things in this game CAN be offloaded to other cores. Path finding, for example.
I'm almost certain that pathfinding in this game is one of the least expensive algorithms, unless awfully inefficient algorithms are being used right now. Maps are relatively small and there aren't many pawns running around. No, 100 isn't many for half-decent pathfinders on a 500k square area.
I've had large raider spawns land on my map, mostly Tribals, that do it, causing massive lag as they all path find to their idle spot, then the lag settles slightly, then starts up again when they start path finding to my elaborate base setup. This even happens on the default sized map with little to no mods.
Tribals don't only do pathfinding... you know that right?
They need to decide what to do, ect.
Quote from: Vas on February 14, 2016, 02:41:40 PM
Quote from: hoho on February 12, 2016, 02:34:40 AM
QuoteAlso, temperature calculations can be offloaded to another core in order to speed up temp checks.
As I said earlier, those checks aren't independent and depend on other things leading to having to synchronize things leading to nowhere near as fast speedups.
For example, if temperature check has to alter parameters of something it means nothing else can access that something during the operation. The data of the "something" has to be locked, modified and unlocked. Every single time anything else access that object, that lock has to be checked no matter if it is locked or not in reality. It means often times the locked status has to be transferred from one core to another, through RAM in worst-case scenarios. If something does have it locked then everyone else are just dead in the water busylooping and checking for when the lock is released. In other words, everything else waiting behind the lock are wasting CPU time while doing nothing useful.
If an object in the game needs to check the temp that is using Thread 1, and Thread 6 is handling temperatures. Thread 6 does the temp calculations and sets the temp of a room into memory so that any Thread 1,2,3,4,5,7,8 object can check it any time. It keeps outputting the temp to those memory values as often as it is told to. Anything that pushes heat or pushes cooling, is processed by thread 6. If such object relies on power, the power thread, thread 4 (for example) can keep a list of powered objects in memory, and alter their state like that so thread 6 simply needs to check that Item624722 Power == 1 before processing it's heat/cold pusher stats. Thread 6 does not need to alter the power net to check the state of an object. Thread 4 does not need to alter the temperature of anything to check the amount of heat in an area. They check a memory value before running their command.
Instead of Thread 1:
Check Power Net;
Power Net Positive == False;
Check power net storage;
Power net storage == Positive;
Set Item624722 power state to True;
Set Item11935 power state to True;
Set other items power state to True; (probably 40 more lines)
Check Item624722 power state;
Item624722 power state == True
Item624722 pushes 16 units of heat to Room662;
Check Room662 Size;
Room 662 size == 30; (cells)
Alter Room662 temperature + 0.53;
Is Room662 temperature dangerous;
Room662 temperature < 400;
Check Item11935 power state; (+7 more lines)
Check other heat/cold pusher power states; (In my case, normally 20 items here, +7 each one)
Check OutdoorsTemp;
Alter all temps inside walls touching Outdoors -0.7; (Probably 20 lines of stuff here)
pawn job7225 (and following 6 lines);
(+60 more lines of miscellaneous stuff);
Check Power Net; (looping back to beginning for the next tick)
You'll get Threads 1, 4, 6:
Simultaneously:
Thread 1: Pawn Jobs (+30 more lines)
Thread 1: Countdowns for story teller events (+5 lines)
Thread 1: Set memory values for various things so other threads can access quickly (+12 lines)
Pawns need the power state to know which buildings to use. Thread 4 locks the power state varibal so thread 1 does nothing untell thread 4 finishes.
Simultaneously:
Thread 4: Check Power Net;
Thread 4: Power Net Positive == False;
Thread 4: Check power net storage12; (memory value for that particular networked storage)
Thread 4: Power net storage12 == Positive;
Thread 4:[b] Set Item624722 power state to True;[/b]
Thread 4: Check Power Net; (loop back to beginning of this stage, for all other items)
Simultaneously:
Thread 6: [b]Check Item624722 power state;[/b]
Thread 6: Item624722 power state == True;
Thread 6: Item624722 pushes 16 units of heat to Room662;
Thread 6: Check Room662 Size;
Thread 6: Room 662 size == 30; (cells)
Thread 6: Alter Room662 temperature + 0.53;
Thread 6: Is Room662 temperature dangerous;
Thread 6: Room662 temperature < 400;
Thread 6: Check Item11935 power state; (loop back to beginning for all other heat/cold pushers)
Thread 6: Check OutdoorsTemp;
Thread 6: Alter all temps inside walls touching Outdoors -0.7; (Probably 20 lines of stuff here)
Weather needed to acsess the power state of an object. the power state is locked instantly when thread 4 starts and is only released when thread 4 ends. So thread 6 does nothing aswell.
YOU have just described the EXACT senerio which hoho was talking about. Thread 6 and 1 do nothing untell 4 finsishes. Thread one does nothing until 6 finishes as it needs to know the temperature... (to calculate if your pawn freeze, for example)
You have only added the overhead of creating these threads and having the scheduler handle them.
I'm just, making a rough guess here for this stuff. But Power Net (thread 4) uploads the state of the power grid for each item to a memory value (not how computers work.), while (No. thread 6 needs to know the new power state before it starts. so he just waits thier doing nothing. he does it AFTER, not while.) temperature (thread 6) checks those states before executing the heat/cold pushing power of that thing and altering the temperature before uploading the temperature of that room to memory both doing this simultaneously and synchronization doesn't matter here because the temperature from the previous check 1 tick ago is still there and it is doubtful to have changed dramatically enough in a single tick to matter if it checked 1 nanosecond too soon. (Gawd no. WHILE thread 4 works on calculating the power state THE VARIABLES ARE LOCKED. LOCKED. THEY ARE LOCKED. How is that hard to understand. NOTHING other than thread 4 can use them WHILE THEIR LOCKED. HE will not accsess them 1 ns to early, because they are LOCKED. thread 6 will sit their doing nothing unwell their are UNLOCKED. If thread 6 tries to access the LOCKED variable you will recive a memory exception followed by RW promptly crashing.) While Thread 1 is free to carry out the other commands minus all temperature and power net calculations, (But the pawn calculations NEED to know the powerstate AND tempetruer. Those varibles are LOCKED. This thread will just sit their and do nothing. ) where it only needs to run a single "Check state" command (This is the third time I say this. THEY ARE LOCKED. YOU CANNOT USE THEM.) to check a value from memory that the other thread had uploaded there.
Quote from: Vas on February 14, 2016, 02:41:40 PM
Granted, I don't know how this stuff works. This is just how I imagine it would work if it were optimized with multi thread.
Welcome to Computing 101. The compiler nor the computer give a flying fuck about what you think.
EDIT: Please note: The red ain't for anger, its just that I'm to lazy to split it into 1 thousand seperate quotes and teh color red makes my comment stand out. If you have another color you'ld prefer please tell me.
What Gent said.
Quote from: Vas on February 14, 2016, 02:41:40 PMYou do realize the game doesn't need to wait for any reason to get a temp right? Temp can entirely be separated into a different thread, nothing needs to wait on it. Heat/Cold pushers while powered, will be processed by the temperature thread.
So, when will food on ground be updated depending on ... temperature? What about feelings of pawns and animals? What about plant growth? When will the rooms decide how to change their temperature depending on heat sources and heat "bleeding" through walls? All these things depend on each other at *some* point and *all* these points have to be synchronized between threads.
Quote from: Vas on February 14, 2016, 02:41:40 PMPath finding can also be separated I believe, and path finding is quite the intensive event
I have no idea how the pathfinding has been implemented in this game but I do know that on 2d grid, there are some extremely efficient algorithms for doing it. Again, look up Factorio and how they optimized their pathfinder by several orders of magnitude. Having thousands of *actively moving* mobs on a map size of several million squares doesn't really make a dent in game performance there and *everything* but rendering is running in a single thread in that game.
[/quote]It is. One can do thousands of calculations when thread hits a mutex lock, millions if that thread gets thrown off the core to pull in another and that doesn't even take into account the time it takes to propagate mutex changes between cores.
Quote from: Vas on February 14, 2016, 02:41:40 PM
Thread 1 (main thread) : Pawn starts cleaning? == True
Thread 1: Push to Thread 4
Thread 4: Path find to nearest dirt spot.
Thread 4: Clean spot.
Thread 4: Loop 10x times.
Thread 4: Check if pawn needs to change jobs. If False, loop 10x times. If True, push to Thread 1.
"Push to thread 4" - what exactly does that mean? You mean main thread builds a "command" for the "clean dirt" handling thread, adds it to some global queue (that can be modified by a single thread at any time, anyone wanting to add/remove stuff from it *must* wait until previous actions are complete) and sends a message to the thread 4 that it has some work to do?
Sure, it can be done like that. Only problem is that the cleaning thread, as you described, does a ton of stuff that depends on all sorts of external variables that can be changed at any point and the job it does is spread over several seconds and several dozen "ticks" during each everything can change (e.g the pawn gets hit by a bullet). Also, that would mean you *can't* separate pathfinding to a new, separate thread.
Also, that "push to thread 1" at the end seems rather weird. Do you mean that it gives over the CPU for the main thread to run? I sure hope not as that's nothing like multithreading works in reality.
Quote from: Vas on February 14, 2016, 02:41:40 PMYou explain why x feature can or can't be done, and you leave it at that.
Sadly, you are trying to offer ideas that are, well, useless. Parallel programming doesn't seem to be a topic you know much about.
Quote from: Vas on February 14, 2016, 02:41:40 PMI've had large raider spawns land on my map, mostly Tribals, that do it, causing massive lag as they all path find to their idle spot, then the lag settles slightly, then starts up again when they start path finding to my elaborate base setup
So, what makes you think it's pathfinding instead of the pawns updating their mental states to changing surroundings?
Quote from: Vas on February 14, 2016, 02:41:40 PMIf an object in the game needs to check the temp that is using Thread 1, and Thread 6 is handling temperatures. Thread 6 does the temp calculations and sets the temp of a room into memory so that any Thread 1,2,3,4,5,7,8 object can check it any time
... and every time something tries to read that temp value, they need to check if mutex protecting it is locked or not.
Quote from: Vas on February 14, 2016, 02:41:40 PMIf such object relies on power, the power thread, thread 4 (for example) can keep a list of powered objects in memory, and alter their state like that so thread 6 simply needs to check that Item624722 Power == 1 before processing it's heat/cold pusher stats.
So, powered items have to additionally check if they are allowed to access the powered state before even beginning their heat calculations. That happens for *every single powered item* that produces heat.
I assume the "simultaneously" there meant that threads 1, 4 and 6 are ran in parallel and not that each thread is somehow duplicated.
- Thread 1: Pawn Jobs (+30 more lines)
What does that "+30 more lines" mean? That thread 1 handles pawn jobs? What does "handles a job" mean, exactly? That it takes into account the pawn mental state, resources availiable and jobs availiable, pathfinds to gather stuff up and do whatever else is required?
- Thread 1: Countdowns for story teller events (+5 lines)
I'm almost certain that story teller stuff is triggered at best once a second and takes less than 1000 CPU cycles to run. I wouldn't be surprised if it's usually even much less than that. In other words, I believe storyteller takes almost no CPU power at all.
- Thread 1: Set memory values for various things so other threads can access quickly (+12 lines)
Will you lock each element individually or everything together during the time they get updated?
If you do it individually it would mean a ton of mutexes are required (yay increased cache load) and everything has to checked every time things are accessed. Though at least you can have one thread handling object N in the array while another thread handles object N+1.
When locking everyhting you'll make everything stop while those updates are made but at least you won't have to worry about checking for each object mutex and can just assume that if the object array is usable, all are. Less mutexes at cost of less granularity. Though I'm extremely doubtful that object-level mutexes would make much sense in this game.
Thread 4, as you described, seems to handle a single powered element. I would guess that would take just a few hundred CPU cycles without accounting for mutexes or locking. Throwing that sort of thing to a separate thread makes little to no sense.
I highly doubt separating electricity handling to a separate thread would make sense. Rimworld has *significantly* simpler power networks than Factorio and it's clearly possible to optimize them to take neglible CPU time in single thread. I wouldn't be surprised if hitting just a single mutex in there would slow it down by 2x vs having it run in main thread.
- Thread 6: Check Item624722 power state - assuming per-object locking it would mean checking for that lock before checking for it.
- Thread 6: Item624722 pushes 16 units of heat to Room662; - meaning it has to lock the data structure where it writes to
Quote from: Vas on February 14, 2016, 02:41:40 PMI'm just, making a rough guess here for this stuff
That you do :)
Most games don't even attempt to separate threads by task-types all that much. Sure, input, rendering, sound and physics are generally
each in a different thread but each one of them has drastically different CPU requirements and that alone rarely has much impact on performance. I've yet to hear any game getting anywhere near 2x speedup from just that going from single core to any number of cores you throw at it - Amdahl's law.
What most games do is to figure out what *actually* takes CPU time and parallelize that. Usually it's physics and often preparing data to be sent for rendering on GPU. In rimworld, neither is anyhwere near taxing on CPU (or GPU). Not knowing the details of inner workings of Rimworld it's really hard to make suggestions on how to parallelize it successfully but I can say for a fact that the scenarios you proposed would be rather inefficient for any type of game if the aim is to gain actual performance increase.
Quote from: Vas on February 14, 2016, 02:41:40 PMBut Power Net (thread 4) uploads the state of the power grid for each item to a memory value, while temperature (thread 6) checks those states before executing the heat/cold pushing power of that thing and altering the temperature before uploading the temperature of that room to memory both doing this simultaneously and synchronization doesn't matter here because the temperature from the previous check 1 tick ago is still there and it is doubtful to have changed dramatically enough in a single tick to matter if it checked 1 nanosecond too soon
Sure, double-buffering can work in some scenarios. Problems emerge if you have feedback loops and if several things can effect same things - depending on what sequence threads get executed you can get wildly varying results. Not to mention that you'll have to synchronize everything at every tick/frame anyway. Again, Amdahl's law hits hard here as everything will be running at the speed of the slowest part.
Adding in multithreading to anything that was written without having that in mind from the early designs is pretty close to insanity. The ones that have done that have generally ended up rewriting almost entirety of their codebase. Again, there is a reason why Kerbal Space Program took *years* to update to Unity 5.
In addition, it's always preferred to first optimize the algorithms as much as possible. It helps both single-threaded and multi-threaded cases and while parallelizing over infinite threads usually doesn't give more than 2x speedup in games, optimizing algorithms tends to often give exponential speedups.
For example, if one were to optimize whatever it is that makes huge swarms slow to run at (being optimistic here) 3x the speed over 8 cores, fine, you'll get 30FPS instead of 10 you had before. Now, if one manages to replace a quadratic algorithm with linear or even constant speed one, you can essentially increase the swarm size by several orders of magnitude long before you'll even feel any slowdowns.
Sadly, without knowing where are the bottlenecks in Rimworld it's impossible to even guess what might benefit from optimization or if parallelizing it would help at all.
Rant on Factorio:
QuoteAgain, looking at Factorio, my current factory is just a beginning one with lousy 5000 solar panels, 2000 accumulators (think batteries) and ~100 coal fired power plants. They power ~500 machines + ~10000 inserters (things that move items from one place to another, I use bullet-based turrets and each requires one inserter, I essentially have a wall of them around my base and have killed over 300,000 enemy units).
The game has no problems running at 60 updates per second. According to the debug screen, electric network takes about 1/10'th of entire update per-tick and at less than 1ms. I'm producing on averaeg about 20,000 items per minute or ~180 per second. For almost every item, inserter has to move it from one place to another and majority of items move on conveyor belts hundreds of tiles long. My pollution cloud covers around 5 million squares (and gets absorbed/moves/spreads according to forests/winds) and influences the actions of all the mobs in it's area (though pollution gets calculated by chunks, each 256 squares). Overall I've explored an area of around a billion squares (equivalent of Rimworld map size of ~32,000 times 32,000) = thousands of enemy spawners generating mobs to throw at me as pollution hits them or just wander around idling (but still requiring path finding).
In addition to all that, the game is *massively* modded with mods written in Lua - zero compiled code in mods as there is in Rimworld. The game does have 2 threads but one of them is purely for rendering while the other deals with all the heavy-lifting.
In other words, it's perfectly possible to optimize a game to be able to handle huge scale and loads of entities/pawns without too much problem. Obviously, it's not easy. Those guys have had several optimization passes, each bringing significant increase to the size of factory one can make before it slows down too much.
Also note that my factory is tiny compared to what some people have created after spending over thousand hour building on one. I know some require nearly an hour of real-time to travel between the mining outposts at opposite sides of the map using an in-game train
TL;DR
It is possible to multithread Rimworld. I don't think it's required nor do I think it'd give a measurable performance increase. I'm absolutely positive that there are MASSIVE gains to be had from improving the algorithms that are currently used.
Also, sorry if I sound harsh. It's just that your suggestions aren't really helping (you can be quite certain that Tynan knows *much* better than any of us what and how would make sense to parallelize, if anything) and make claims about parallelization that simply don't work in real world.
You hit the nail on the head, hoho. Way better then I could either.
Thanks hoho, I've been trying to say this stuff for weeks, but you've said it better and with much more detail than I even could.
Also, I feel like I may be partially responsible for the belief that pathfinding is such a bottleneck, I've repeated that several times but I'm actually not sure where I got the information from. Oh well, if only we could attach a debugger/profiler.
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 14, 2016, 07:32:33 PM
Gawd no. Tynan will not rewrite the jobs system just for you.
Also, having 1 thread per pawn won't end well. The game *will not* be faster, if anything slower due to the extra overhead starting and calling another thread.
Wow, when did I say 1 thread per pawn? I was making an example.
Also, when did I say "just for me"? Quit exaggerating. Everyone but you wants multicore to happen. See, I can do it too.
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 14, 2016, 07:32:33 PMBitchy red rant of bitchyness and being dickish
Perhaps no one told me in a nice way that threads lock a variable, when you are able to do this, I will respond to you. As I had said at the end, which you also quoted below. I don't know exactly how it works. I assumed that if it can upload a thing to memory, the thread may lock something but the memory value can be read at any time. If something needs to check the state, it looks for the memory value and reads it. I assumed, you could READ locked things.
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 14, 2016, 07:32:33 PM
Quote from: Vas on February 14, 2016, 02:41:40 PM
Granted, I don't know how this stuff works. This is just how I imagine it would work if it were optimized with multi thread.
Welcome to Computing 101. The compiler nor the computer give a flying fuck about what you think.
Well if you're going to be a rude little dick, I don't give a flying fuck what you think either.
Quote from: hoho on February 15, 2016, 04:50:19 PMSo, when will food on ground be updated depending on ... temperature? What about feelings of pawns and animals? What about plant growth? When will the rooms decide how to change their temperature depending on heat sources and heat "bleeding" through walls? All these things depend on each other at *some* point and *all* these points have to be synchronized between threads.
---------------------------------------------------------------
TL;DR
It is possible to multithread Rimworld. I don't think it's required nor do I think it'd give a measurable performance increase. I'm absolutely positive that there are MASSIVE gains to be had from improving the algorithms that are currently used.
Also, sorry if I sound harsh. It's just that your suggestions aren't really helping (you can be quite certain that Tynan knows *much* better than any of us what and how would make sense to parallelize, if anything) and make claims about parallelization that simply don't work in real world.
Previously, I had assumed that a thread can look up read only memory values to perform its next calculation. AKA, A plant that depends on the temp can look up the memory value for the room temp it is in, to decide if it should continue growing or not. It doesn't need to write to the temp to be able to grow after all. It only needs to know what it is. The ticker event handles how often the plant will check the temperature. It doesn't need to be perfectly synchronized after all. That is what I assumed. And after reading half of what Gent said and him saying "don't give a fuck what you think", I'm rather pissed and don't feel like reading much now. I'll come back and read the rest of what you said a bit later but I give up. No one here gives a shit about my original intentions of posting here.
I was merely posting before to get people to stop being dicks towards people who suggest multi-threading. I should have left it at that and not said anymore, but everyone here who programs likes to intervene and say "NO DON'T POST IT" and/or troll the person who posted it. My original point, my original goal, was to get everyone to stop trolling someone over an idea. Unless that idea is obviously outlandish and stupid, there should be no cause for trolling and multicore is not an outlandish or stupid idea. Its difficult, but possible, and most games these days support it. So there's no need to troll someone over it.
I'm sure Tynan does know more though. I was just trying to provide my own perspective. Also sometimes it takes a different perspective for someone to catch an idea of how to do something. My perspective may not be possible but someone could see it and think "Holy crap, I got an idea" from it. Until I read your post, I may not understand why a thread can't read a read only memory value to do its next thing, so I'll wait on anything further. For now, I just give up.
Quote from: Vas on February 18, 2016, 03:37:27 PM
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 14, 2016, 07:32:33 PM
Gawd no. Tynan will not rewrite the jobs system just for you.
Also, having 1 thread per pawn won't end well. The game *will not* be faster, if anything slower due to the extra overhead starting and calling another thread.
Wow, when did I say 1 thread per pawn? I was making an example.
Also, when did I say "just for me"? Quit exaggerating. Everyone but you wants multicore to happen. See, I can do it too.
I know for a fact not everyone wants a multi core system.
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 14, 2016, 07:32:33 PMBitchy red rant of bitchyness and being dickish
Perhaps no one told me in a nice way that threads lock a variable, when you are able to do this, I will respond to you. As I had said at the end, which you also quoted below. I don't know exactly how it works. I assumed that if it can upload a thing to memory, the thread may lock something but the memory value can be read at any time. If something needs to check the state, it looks for the memory value and reads it. I assumed, you could READ locked things.
Hmm, is green a good color?
Have you read Moho's response? I think he said it nicely and clearly.
PS: Next time before spewing crap out of your ass, maybe you should consider reading about multi threading. You'll sound less like an ignorant little fuck.
Here is a great quote from StackOverflow (which literally took 13 seconds to find)
Quote from: StackOverflow
When I am having a big heated discussion at work, I use a rubber chicken which I keep in my desk for just such occasions. The person holding the chicken is the only person who is allowed to talk. If you don't hold the chicken you cannot speak. You can only indicate that you want the chicken and wait until you get it before you speak. Once you have finished speaking, you can hand the chicken back to the moderator who will hand it to the next person to speak. This ensures that people do not speak over each other, and also have their own space to talk.
Replace Chicken with Mutex and person with thread and you basically have the concept of a mutex.
Of course, there is no such thing as a rubber mutex. Only rubber chicken. My cats once had a rubber mouse, but they ate it.
Of course, before you use the rubber chicken, you need to ask yourself whether you actually need 5 people in one room and it would not just be easier with one person in the room on their own doing all the work. Actually, this is just extending the analogy, but you get the idea.
From: http://stackoverflow.com/questions/34524/what-is-a-mutex
Also:
http://www.albahari.com/threading/
http://www.albahari.com/threading/part2.aspx
http://www.albahari.com/threading/part3.aspx
http://www.albahari.com/threading/part4.aspx
http://www.albahari.com/threading/part5.aspx
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 14, 2016, 07:32:33 PM
Quote from: Vas on February 14, 2016, 02:41:40 PM
Granted, I don't know how this stuff works. This is just how I imagine it would work if it were optimized with multi thread.
Welcome to Computing 101. The compiler nor the computer give a flying fuck about what you think.
Well if you're going to be a rude little dick, I don't give a flying fuck what you think either.
I never said that _I_ don't give a fly fuck for what you think, but I instead said the _compiler_ doesn't give a flying fuck. Then again, it goes without saying that I don't give a flying fuck either. :P
Quote from: hoho on February 15, 2016, 04:50:19 PMSo, when will food on ground be updated depending on ... temperature? What about feelings of pawns and animals? What about plant growth? When will the rooms decide how to change their temperature depending on heat sources and heat "bleeding" through walls? All these things depend on each other at *some* point and *all* these points have to be synchronized between threads.
---------------------------------------------------------------
TL;DR
It is possible to multithread Rimworld. I don't think it's required nor do I think it'd give a measurable performance increase. I'm absolutely positive that there are MASSIVE gains to be had from improving the algorithms that are currently used.
Also, sorry if I sound harsh. It's just that your suggestions aren't really helping (you can be quite certain that Tynan knows *much* better than any of us what and how would make sense to parallelize, if anything) and make claims about parallelization that simply don't work in real world.
Previously, I had assumed that a thread can look up read only memory values to perform its next calculation. AKA, A plant that depends on the temp can look up the memory value for the room temp it is in, to decide if it should continue growing or not. It doesn't need to write to the temp to be able to grow after all. It only needs to know what it is. The ticker event handles how often the plant will check the temperature. It doesn't need to be perfectly synchronized after all. That is what I assumed. And after reading half of what Gent said and him saying "don't give a fuck what you think", I'm rather pissed and don't feel like reading much now. I'll come back and read the rest of what you said a bit later but I give up. No one here gives a shit about my original intentions of posting here.
Such shame, you will not read a perfectly good answer just cause asshole called 'Gentz' broke your feelings. I'm sorry for your loss, but if you refuse to listen to the other side of the argument then why should I either bother responding?
I was merely posting before to get people to stop being dicks towards people who suggest multi-threading.
No one was being dickish, they were being sarcastic, theirs a difference.
I should have left it at that and not said anymore, but everyone here who programs likes to intervene and say "NO DON'T POST IT"
Well, maybe people should start using the search function. TBH this 'debate' has been settled a long time ago with the results being "Not happening".
and/or troll the person who posted it.
If they won't bother searching it up then we (or at least I) will take the equivalent amount of effort and just troll them.
My original point, my original goal, was to get everyone to stop trolling someone over an idea.
Yup, but your far from that original goal, now your pretending to have some knowledge about multithreading and spewing out pseudocode which has no basis in reality.
Unless that idea is obviously outlandish and stupid,
If you've reading anything we've said you'd realize the idea IS outlandish and stupid FOR this type of application. You don't even need to read what WE said, you can use the mystical search function and see what others have said, even Tynan himself.
there should be no cause for trolling and multicore is not an outlandish or stupid idea.
Learn how multithreading works, then you will realize how stupid and outlandish it is for this type of application.
Its difficult, but possible, and most games these days support it.
Argument ad populum. Logic is:
IF many things have done it THEN it is plausible AND beneficial.
Okay, many people spoke roman in the past SO everyone speaking roman NOW must be a GREAT idea, and surly everyone will benefit, right?
God no.
OTHER games have done it, it doesn't mean it will actually work with THIS game.
OTHER people have benefited a lot in the past from learning latin, it doesn't mean that I will benefit from learning latin to the same degree, if at all.
So there's no need to troll someone over it.
Thier is no reason for you to spew random crap out about how multithreading should be done when you know nothing about multithreading or computers.
I'm sure Tynan does know more though.
Great. You can agree on ONE thing.
I was just trying to provide my own perspective.
Great. I don't care about how you THINK computers should work, I only care about HOW THEY ACTUALLY WORK
Also sometimes it takes a different perspective for someone to catch an idea of how to do something.
Thier is nothing we can learn from YOUR perspective other than that you lack basic knowledge in this Field. Anything other than that that we can "learn" is false.
My perspective may not be possible but someone could see it and think "Holy crap, I got an idea" from it.
Professionals in this field have worked for more than a decade to improve multithreading, and you just think you can come in with no experience whatsoever and revolutionize multi-core computing? Ego much?
MAYBE if you has SOME knowledge in multi threading and then CLEARLY defined an method that can THEORETICALLY increase speeds by lets say 0.01% then we could get an idea from it. But you just spewing crap gives no ideas.
Until I read your post, I may not understand why a thread can't read a read only memory value to do its next thing, so I'll wait on anything further. For now, I just give up.
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 18, 2016, 08:07:08 PMUgly wall of text that I'm still not reading.
How about you just drop it, and leave the god damn thread alone. Stop being such a rude little asshole. I swear, is it really so hard for you to fucking drop it? Maybe if you fucking open your god damn eyes, you'll see I said "I give up" and explained some other things that you're still fighting against because you wanna sound like a super genius and win the thread war. I'd be more inclined to read what you say if you didn't come at me all angry and pissy and with the "i'm right your wrong go back to school" attitude. But nope. You're still coming here coloring shit and not bothering to try and make your post look nice, instead you think color fixes it when you should be cutting out bits to make it less of a wall of text. EG, the links on "threading" where you linked all part pages which clearly was useless.
It seems your only purpose here is to pick a fight you can win and drive in the nail as deep as you can get it simply so everyone can go "Oh wow, Gent knows everything, that guy's awesome. He sure showed Vas!"
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 18, 2016, 08:07:08 PMIf they won't bother searching it up then we (or at least I) will take the equivalent amount of effort and just troll them.
Interesting. Instead of being a "gentleman" and say "This has been debated before, here's the thread link." then report the post to have it locked by a moderator. You go into the post and troll them like a dick. Got it.
P.S. I know I was wrong on my multi-core assumptions and theories (when I didn't know anything about how it worked) (still don't particularly know) but I'm not gonna sit here and let some guy treat me like I'm a dumbass and sit here publicly doing his best to make me out to be the bad guy and everything. A moderator or admin needs to delete or lock this thread. Whichever. At this point it is a useless thread where people come here for a laugh or to troll someone.
Quote from: Vas on February 18, 2016, 10:39:34 PM
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 18, 2016, 08:07:08 PMUgly wall of text that I'm still not reading.
The ignorance is strong with this one, if you won't bother reading it why bother replying?
How about you just drop it, and leave the god damn thread alone.
How about you just drop it, and leave the god damn thread alone.
Stop being such a rude little asshole.
And your not being rude either? ???
I swear, is it really so hard for you to fucking drop it?
Yes, it actually is hard for me to drop it.
Maybe if you fucking open your god damn eyes, you'll see I said "I give up"
If you gave up then why reply?
and explained some other things that you're still fighting against
Well your explanations are invalid, or I wouldn't have to reply to it.
because you wanna sound like a super genius and win the thread war.
I don't need your confirmation to 'sound like a super genuis'. TBH anyone who knows a thing about computers should know this stuff.
I'd be more inclined to read what you say if you didn't come at me all angry and pissy and with the "i'm right your wrong go back to school" attitude.
You seem to have that same attitude, yet I still read what you write.
But nope. You're still coming here coloring shit and not bothering to try and make your post look nice,
I can't be bothered to separate it into 50 different quotes. Just like you can't be bothered to learn how multithreading actually works.
instead you think color fixes it when you should be cutting out bits to make it less of a wall of text.
But I responded to every line. TBH the only thing I should have cutout was the last line. Does that ONE line bother you?
EG, the links on "threading" where you linked all part pages which clearly was useless.
Or you didn't read them. I've been using those as a reference sheet (see I don't talk out of my ass, unlike you) the whole time so I find it hard to believe they are useless. They describe EXACTLY how to multithread in C# (what RW is made in). What more can you ask for?
It seems your only purpose here is to pick a fight you can win and drive in the nail as deep as you can get it simply so everyone can go "Oh wow, Gent knows everything, that guy's awesome. He sure showed Vas!"
Nope. My goal is for you to learn ANYTHING about how threading works.
Quote from: TheGentlmen (GENTZ /'jen(t)z/) on February 18, 2016, 08:07:08 PMIf they won't bother searching it up then we (or at least I) will take the equivalent amount of effort and just troll them.
Interesting. Instead of being a "gentleman"
Dispite what my name may lead you to believe, I'm for from a "gentleman"
and say "This has been debated before, here's the thread link." then report the post to have it locked by a moderator.
OR they can use the fucking search function.
You go into the post and troll them like a dick. Got it.
TBH in this post I'm yet to troll anyone cause I got here late. The only thng I've done in this post is to reply to your extreme concentration of bullshit you call a reply.
P.S. I know I was wrong on my multi-core assumptions and theories (when I didn't know anything about how it worked)
Well, why make assumptions when you can read up about how it ACTUALLY works.
(still don't particularly know) but I'm not gonna sit here and let some guy treat me like I'm a dumbass
So sorry I broke your heart.
and sit here publicly doing his best to make me out to be the bad guy and everything.
Err, no. This ain't my 'best'... my 'best' would get me temp banned.
A moderator or admin needs to delete or lock this thread.
Okay then.
Whichever. At this point it is a useless thread where people come here for a laugh or to troll someone.
Laughing is good for your health you know.
I just realized your not gonna read it at all. Just shows how ignorant you are.
Wow. Can both of you cool it down a bit?
@Vas; I'm curious, do you actually want Tynan to implement multicore, or are you merely suggesting it would be a good thing?
Thing is, several people who know more about the subject have told you that it's basically not worth the effort, but you keep arguing that it is. Anyhow, this thread is turning nasty - I'm out.
Quote from: Vas on February 18, 2016, 03:37:27 PMI assumed that if it can upload a thing to memory, the thread may lock something but the memory value can be read at any time.
Technically, you are correct - everything can be read at any time.
Problems emerge when some parameters are more complex than the simpliest variables (single integer or floating point value, boolean). In those cases, it's likely that when someone is changing that multi-number parameter then the one reading it gets first half from old state and second half from new state. In those cases, all write *and* read accesses must check for the locks.
Also, the locking doesn't work automatically. Programmer has to specifically write stuff like:
check if lock is already locked by someone else
If yes, put the thread to sleep with wake condition of "this lock is released"*
If not, lock it yourself
change or read the variable
remove the lock
If theread does happen to get thrown off the core while it's in sleeping state then that alone will take hundreds of CPU cycles, getting it back there again costs hundreds to move data, thousands if some data was thrown out of caches completely.
Quote from: Vas on February 18, 2016, 03:37:27 PMNo one here gives a shit about my original intentions of posting here.
"Problem" is, everyone with half a brain knows that hypothetically, multithreading can make things faster. There aren't much reason to point that out as I'm quite certain Tynan is fully aware of it already.
As has been said here, multithreading can at best increase speed lineary by at best 2-3x. Optimizing algorithms will often give much more performance than that and will make the game scale vastly better. It makes MUCH more sense to optimize algorithms than spending huge amounts of time to make the game run in threads.
Quote from: Vas on February 18, 2016, 03:37:27 PMIts difficult, but possible, and most games these days support it.
I can assure you, almost every AAA game out there is *not* parallelizing their core logic to run in more than one thread.
What they probably are doing is separating things out by tasks. E.g rendering in one thread, physics in other, preparing data for rendering in third, AI in fourth etc. They also usually use third-party libraries for some tasks, especially physics, and those libraries are often internally multithreaded. As most of those games are rather graphics-intensive, the threads dealing with rendering and preparing data for rendering take a LOT of computing time so spreading them out to different threads makes sense.
Rimworld is essentially nothing like those games. Its rendering is trivial (I'd think it could run at several thousand FPS if we'd turn off all other processing) and it has no real physics. Almost all the computing time is taken by the "AI" and general game logic and it's extremely hard to split that to run in several threads. In those AAA games, that part of the game barely takes a couple dozen percentages from a single core to run.
"Multi number parameters" could be having to check for all body parts for injuries-upgrades to figure out how fast someone runs, having to check for positions of animals to figure out who to hunt, having to check objects in path of a bullet to figure out where it hits etc.
Another HUGE issue with multithreading is when objects can be removed or created at pretty much random. For example, if one is applying medicine to another character and the char dies in the middle of it (and the data structures describing their health go with it), the one doing the healing *must* know that the person died before it attempts to do anything with the data of the character they were healing.
Essentially, even if one thread wants to only read data that is managed by another thread it's not enough to just check if the data exists to start reading it. It must be enforced that the data doesn't get deleted before all the reading is complete. Trying to read data that has been deleted generally results in application crashing. Same with trying to write to structures that have been deleted. Only protection against such crashes is, again, locking them leading to bottlenecks.
Yet another issue with threads are deadlocks. Deadlock is what happens when you have a circular dependency between locks and threads. Here is a simple example code demonstrating deadlocks: http://stackoverflow.com/a/1385876 That sync() call there is locking the variable. If a deadlock occurs, the application has hanged - it can't proceed further as two (or more) threads are stuck waiting after each other and none can proceed.
Avoiding deadlocks is by far the hardest thing in threading.
Just wanted to say that all the fighting stops now or I'm looking at about six or so people looking at a full week ban. The good news? One of you buggers is about to win the perma-ban lottery if you have to be warned/banned again!
I grow sick and tired of the childish bickering. There are better ways to have a jovial slap-fight and you all seem to be really bad at it.
(http://i.imgur.com/aiwA1Gp.gif)
Quote from: hoho on February 19, 2016, 06:04:38 AM
...re few previous posts..
Insightful stuff, thanks. Always nice to have the voodoo of coding explained :)
Im not sure why you guys got the problem with multi core, works perfect for me :D
(http://s7.postimg.org/tell7r8a3/Multi_Core.gif)
Quote from: Ectoplasm on February 19, 2016, 02:12:16 PM
Quote from: hoho on February 19, 2016, 06:04:38 AM
...re few previous posts..
Insightful stuff, thanks. Always nice to have the voodoo of coding explained :)
I agree, Hoho explained things without insulting me or being hostile. I'll have to go through and read it all when I get back. :P
Ramsis, will you lock the topic? There's no real point for it to continue being up. I failed at trying to stop people from trolling anyone who suggests a feature and made things worse by guessing and making theories without prior knowledge of how threading works. I'm not sure who you mean about the perma ban thing though.
Quote from: mrofa on February 19, 2016, 03:21:43 PM
Im not sure why you guys got the problem with multi core, works perfect for me :D
(http://s7.postimg.org/tell7r8a3/Multi_Core.gif)
I have 64 AI cores attached to my machine. :| It only takes 1.21GW!
Quote from: Vas on February 20, 2016, 07:56:15 PM
Ramsis, will you lock the topic? There's no real point for it to continue being up. I failed at trying to stop people from trolling anyone who suggests a feature and made things worse by guessing and making theories without prior knowledge of how threading works. I'm not sure who you mean about the perma ban thing though.
+1 to this. I feel that this thread has gone the way of
https://ludeon.com/forums/index.php?topic=17451.0
that one. So, yes Ramsis. Please do
Quote from: jzero on February 21, 2016, 09:45:42 AM+1 to this. I feel that this thread has gone the way of
https://ludeon.com/forums/index.php?topic=17451.0
that one. So, yes Ramsis. Please do
You missed a period at the end of "please do" and forgot to put a semi colon after "way of", or some other mark of some kind before the next line! :o
*is just teasing, your sig has grammar nazi in it! :P*
Forum threads often get heated when there are two clashing sides, it's an inevitable part of the human condition.
You could agree to disagree. It's better than continually locking horns.
I just want to throw my support behind the need for multi-core or any other solution to increase FPS in mid to late game scenarios.
I have currently 22 pawns, running on a small map (on purpose) with an 5930x Intel, one of the best processors out. At best I am getting 30 FPS at 3x. It's quite frustrating, more so because this game is one of the best I've ever played and its being held back by performance issues and lack of better (tm) modding support.
If an entire version cycle (or more) was spent only on performance and modding support it would ensure this game is played for a decade, much like you see with the Civilization Series.
The subject seem to be still up do date. A17b has just been released.
I understand that implementing multi-core support on RimWorld is not as easy.
However I am pretty sure it can do few things.
Did anyone mention that perhaps, maps could be ticked individually using their own thread ?
I don't think maps have to "wait for each other" to be done processing.
Of course this is only pertinent if have multiple maps within a single world. Yet why it could not be a nice improvement for this particular situation ?
Beside, what about running "world elements" in its own thread as-well ?
Quote from: Vas on January 26, 2016, 12:10:47 AM
And now you people see why it's hard to keep new community members here.
They could read the stickied posts and run a search...just saying
Oh my, this thread sure turned out to be can of worms. :@ Not that it is first time I see heated discussions about multi-threading in games. Seems that many people get annoyed over weak-core multi-core processors. :c
Quote from: Vas on February 22, 2016, 03:36:15 AM
Forum threads often get heated when there are two clashing sides, it's an inevitable part of the human condition.
While I agree that heated discussion can be productive (far more productive than silencing anything that is remotely controversial
coughdiscord
cough), I see no point in personal attacks or talking about people. :V Heck, you can even get angry and frustrated, but why target people with your anger? There are plenty of better ways of letting it out (if you know what I mean
( ͡° ͜ʖ ͡°)). :P
Discuss, but don't hate each other! Yay!
My (useless) 5 cents: Single core speed isn't improving any time soon (due to technical limitations, as I understand it), so if the game starts running slow on
almost-best-single-core-possible, multi-threading will be a must. I think we are far from there, and there is plenty of optimization work to do still, so maybe it isn't necessary. That said, the earlier it is implemented, the less work it would need (I got this one right,
right?). So the grand question is: will final RimWorld be big enough to overwhelm a powerful single-core?
i have over 300 hours in game, literally have like 17 game files, and i have tested on stream "twitch", adding MODS, i have 70+ mods and found they didn't had a major impact. Naked Game, and Modded Game, had the same issues, late game I've tried getting rid of Zoning all together. BUT REALLY it is just postponing the inevitable. I LOVE THE GAME, I WAS BLOWN OUT OF MY MIND WHEN I SAW IT, PLAYED IT, ADDED MODS, TEST IT, but at this point i can't recommend RimWorld because it has a hardware cap. and no matter how much you want to NOT LEAVE THE PLANET, and JUST STAY WITH YOUR COLONY, you CAN'T because eventually it will become unplayable. Due to Hardware CAP, i know it's ALPHA and i know it's up to the devs but it's just sad to find something you like and can't fully play the extend of it.
Late game is just awful.
The game will eventually die if this isn't added. As the game goes further into development more mechanics will exist that will have to be accounted for and along with the increase in the size of the modding community the lack of multi-core support will only make Rimworld harder and harder to play. Is this a hefty task to undertake? Yes. But it's worth it and the longer it's ignored the worse it'll be.
Tynan plz fix, We need multi core support so my 4 core Intel i7 doesn't literally melt the motherboard and I can have 4 cores operating half capacity instead of one doing max load
easy fix for everyone: buy an old computer with a single core three and a half ghz processor. put your gaming graphics card inside of it and pimp it with some ram. done. in the very worst case you might need to get a new motherboard and electric parts for it to take more watts
download an old windows version, maybe windows xp, maybe win 7 (there is no reason to ever use vista)
ideally, look for 64bit but that is rarely possible with such old machines. since you cant get 64bit, you might aswell go xp in some regards. but i guess you should experiment or look up the games you wanna play on it.
and all your (oldschool-) gaming problems solved for decades to come. look at it as your nintendo switch for pc games
I have the normal version of Windows and on that this game runs perfectly, I think due to unwanted files this issue may occur, by deleting this files the game can support the graphics of the picture.