CPU usage x64 2193

Hi i have check with an tool and some test and it seems that stonehearth mostly only attack one cpu? after removing the usage of this cpu for stonehearth its now use 2 cpus and is faster / less stutters

also interessting - i have start the stonehaerth.exe from the x64 manually and its also faster? … hmmmm ^^ i think i must check something :stuck_out_tongue:

soooo i have found one main issue for me ^^ on the normal stonehearth.exe was still kompatibliti for windoof 7 active so the games stutters ^^ reinstall etc havent affect this setting :wink: after remove now its plays correctly lol but the cpu usage is the same - it mostly use only one cpu (i have 6 and its only use the last one but without stutters its not the problem anymore xD) but now i reach the 4 night and iam attacked by 5 / FIVE Goblinsquads -.- no chance xD

Hi there,

I’ve noticed some bigger issues with stonehearth regarding the multicore cpu support.

Stonehearth currently just use one cpu, is that right?

I have a system with a six-core cpu, and stonehearth constantly just use 1/6 of my whole cpu power. This leads to heavy lags in bigger cities. Sometimes it’s going to stuck even at 14-15 citizens and many items floating around.

I would normaly suggest, that my cpu is good enough to handle this game easily, but currently the idle bar is just visible until <=10 citizen. After that point the lua scripts consume the “whole” cpu.

Maybe this is just a bug. Would be great to hear from you.

Best regards,

Oh sorry, forgot some system informations:

I’m currently using steam_latest
on a System with Intel® Cor™ i7-5930K CPU @ 3.50GHz (each, 6-core with Hyperthreading, 12 logical cores).
48GB DDR4 Ram
Windows 8.1 (x64)

which version? 205 or 2193 and if 2193 have you enabled x64 in the settings?

Ah, there are x64 settings? Just see that those settings where turned of. Just thought they were x64 as the version is x64.

My version is: develop 2193.

I give it a restart and try again.

1 Like

Nope, sorry. The same as before. It just consumes a small potion of cpu and the system itself is still stucking.

have you any compatiblitymodes on? i have the issue because i have used it :wink:

and do you see which cpu will be used? i have checked it myself and see that its use the 6th cpu at full and only sometimes use others


no I don’t have any compatibility modes set.
The System is just a few weeks old, and stonehearth is on a fresh install.

I’ve used perfmon and see that it’s cpu no. 3 which is used by stonehearth.

1 Like

@SteveAdamo can you merce this with an old topic from me? CPU usage x64 2193

will do… as soon as I’m in the office … :wink:


Thank you my HERO :smiley:

lua does not support multiple threads, ergo is Stonehearth’s possible multicore support is limited. In the best case, it will use three threads (one for the server, which could be a different program at some point in the future), one for the client lua and one for the GUI.

That means that a six-core CPU is as good, or rather worse, than a dual core.


nice … ähhh bad to know ^^ BUT Thank you very much for this info :smiley: i havent known that lua has this limits ^^

They should launch multiple lua instances then… I just have no idea what would in each one… I guess a scheduler for each collection of units and IPC?

I actually forgot one possibility; the path finding, depending on implementation, could be put in as many threads as you please. However, this requires special implementations and tight rules on the graph (i.e. what the landscape looks like or rather, how it behaves).

A lua state is an isolated unit that is managing everything lua requires: It allocates and frees all the memory, keeps tracks of variables and all data, calls the functions and so forth. Every state is its own virtual machine. Even if you had two lua states in the same program, they would be completely independent, i.e. lua state L1 cannot communicate with lua state L2. They do not share any variable, library or whatsoever. You could run Stonehearth’s lua in one state, GMod’s lua in another and in the third you could have Factorio - and they wouldn’t interact or interfere with each other.

In order to communicate, you would need to supply such a functionality. Stonehearth has this already in form of radiant.call which is used to communicate between server and client state. This adds a delay however, because it needs to specifically poll for such requests. I think Stonehearth’s polling interval is somewhere around 200ms, but I could be mistaken. So for example, a simple request to another lua state would take at least 400ms to complete - at which point, you’re very likely better off to just have it run in the same core (unless you’re using asynchronous methods, which Radiant has been doing more and more over the last few Alphas).

So if we had a state for the AI, it couldn’t interact with anything outside of the state. If it needed to query the time, for example, it would need to send a request to the other thread (or alternatively, such functionality needs to be implemented in C or maybe some ominous lua state that only serves as library - but that would be blocking).

Parallel programming is a very complicated, very difficult and on top of all very delicate topic. Even lua’s coroutines might produce more overhead than they are worth (especially when we’re using JIT), so the maybe obvious solution to “just coroutine everything” is poor rather than good.

As a rule of thumb, more more threads does not equal a better or faster game. Not every game can be threaded the same way. As another example, we could say “Alright, we put the whole state of the AI of every AI player in its completely own client state and just let it connect to the main game like a normal player” - sounds like a sane idea, with the disadvantage that you have n equal game states running now, which means you have n times the terrain, n times every script loaded and so forth… Suddenly your memory footprint just explodes.