Hi folks,
I’m not sure if this is a request for help, or a request for a quick explanation (or a link perhaps to where this might be discussed). I did search a few terms and didn’t see exactly what I wanted to ask, so here I am.
I do apologize, I’m just new to the community, gaming with Lutris or even wine in general, so I don’t exactly know what I’m talking about yet. =)
I have been running Final Fantasy XIV for a few weeks, and just this morning I started running a WoW client (Project Ascension). Both are running very well, and so I expect this is normal behaviour. Does Lutris (or Wine) always run on a single Thread/Core?
I originally observed this behaviour when installing Final Fantasy, and thought it perhaps because it was just an installer application. But then I noticed both games also saturate one core, and one core only while running. I’m using the DirectX to Vulcan component, and I’m getting about 200FPS(on wow), so no complains there.
Is this just normal behaviour?
Thank you!
-Sam
Is option restrict to single core(Lutris Configure/System options + Show advanced options) set to off?
Hi, thank you for the response! Looks like it’s set to off.
I’m not sure it’s really a problem or not, it just feels funny. =)
I’m going to post another post, because I can only share one image in a single post. The next post will just be the system monitor showing the single core saturation when my game window is focused.
Thanks again!
And here is the system monitor view.
…Can’t say much about Final Fantasy, but WoW client is single-threaded (or at least it was the last time I checked), which is the case more often than not in pretty much any software. The reason being that implementing a multi-threaded application is much more complicated than a single-threaded one. Implementing multiple threads has become more widespread now that Moore’s law doesn’t apply to CPU core power anymore (3GHz is an approximate ceiling and had been for a while) and they’ve switched to cramming more cores into processors, but (non-broken) thread interaction in imperative code had always been a nightmare, so multithreading is normally seen as a last resort card by just about any developer.
1 Like
Awesome, thank you for this. I’ll consider this answered. =)
You are right on the statement of thread interaction with imperative code is a nightmare =) Maybe not a nightmare, it’s just a different way of looking at a problem.
say you had an array of 20 elements, and a statement like
for (int i = 0; i < 20; i++) that’s easy on a single core.
But if you had 4 cores available, you’d only want each core to hit 5 elements (each core isn’t really aware of what the other is doing, but the resources they are dealing with are shared)
Anyways, I guess I was just over thinking it. I hadn’t observed this behaviour in windows, though the monitor in windows by default shows an overall CPU saturation graph.
Thanks again!
If the matter was just “splitting a list between cores”, that would’ve been fairly simple… The problem is actual interaction, i.e. coordination of changes. For instance, if you have a thread rendering stuff, a thread calculating stuff, and another one for network data exchange, the rendering thread needs to regularly receive updates on the state of the screen (very regularly, and in imperative code that means very regularly pausing the whole thread until information is received… and then pausing the whole calculation thread until rendering thread finishes reading new information), and that might be a problem, because the state is controlled by another thread which may be stuck processing large amounts of data coming from the network thread… Merely setting this up in a way that won’t break and won’t have serious runtime problems (like getting stuck in a livelock) is the nightmare I’m referring to.
As for Windows, I never found their CPU status thingie very accurate TBH
