I'm actually a bit surprised to read this thread. I've only run the game a few years in 2.7, but I'm getting better performance than I ever have.
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Did 2.7.2 address the performance issues? I've been working through a backlog of a bunch of games, and haven't wanted to jump back into Stellaris until the performance issue got sorted. It sounds like it may have?
All it would have taken to answer your question, would have been to read the last two pages ._.
- 4
And just to throw in my cheap a** rig for comparison:
Two things that come to mind:
1) Your Core i9 and Ryzen 7 monsters produce the same Stellaris performance as a CPU that sold for 60 bucks. It would be funny if it wasn't so cynical.
2) This engine can NOT do multi-threading. This has been an issue since the days of HoI2. Clausewitz tried, and ... somehow failed.
I can faintly remember a Paradox dev explaining that no matter how many threads you use to disperse your tasks, at the end of the day, all threads have to wait for slowest one to finish. Which means, I guess, that there is something fundamentally ancient about how this engine distributes workload. But I'm no coder. I merely observe.
- 2
- 1
- 1
It's correct that if you're splitting work across multiple cores for a particular operation you still need to wait for the last thread to complete before you can go onto the next operation. However, if this is a "big" issue that is severely limiting the benefits of multiple cores then from my own programming experience I would say "You're doing it wrong!", though of course architectural limitations might be preventing optimal solutions.
To give an example from my own experience, I was implementing a complex image processing algorithm and wanted to speed it up. My computer at the time had 8 cores and 16 threads, so I hoped to at least get an 8x improvement. My first implementation did some coarse grained static allocation of the work - divide the image into bands (one per parallel thread) and execute those in parallel (eg if you had just 2 threads you'd divine the image into two and each core would process exactly half the image). That's very simple and requires very little synchronization overhead. But I only got a 3x speed increase. For my second implementation I did dynamic fine grained allocation of work - divide the image into groups of rows, each 16 pixels high, turning that into a work queue. Each parallel thread then goes in a loop, getting the next group of rows from the queue and processing it until all groups of rows are completed. This means different threads will complete different amounts of work. You still need to wait for the last thread to complete, but since each piece of work is very small, the wait is short. With that version of the algorithm I got a 10x improvement over single threaded performance.
That was about 10 years ago and my first real experience of doing such a thing. So I feel quite disappointed with where Stellaris is at. That being said, I did have the advantage of being able to completely re-write my own code to get the most out of it. With a large and complex code base that wasn't originally multi-threaded, changing it to support fined grained multithreading with dynamic work allocation can be difficult depending upon the circumstances. I also get the feeling that during the part of the processing that renders a frame of graphics in Stellaris, rather too many calculations are being done on the fly (eg for the various numbers and status flags) rather than being pre-calculated and it feels to be that that part isn't multi-threaded at all.
But it's not like Stellaris is an old game, built before multi-cores were common. It's something they should have reasonably considered since the start. Perhaps the rate of change in terms of adding new features got in the way? My general impression is not that Stellaris's performance couldn't be significantly improved but more that the management team don't want to allocate the developer resources because they don't consider it to be a serious problem. From a business perspective I would say this is very stupid if this is causing most players big problems (which seems to be the case) as it's a LOT more expensive and difficult to get new customers/players than it is to retain your existing playerbase.
- 3
- 3
Thank you for your example and insight. I think you cut right to the core of the issue, pun intended.
As to the motivation of the dev team, I would rather think that there is no one aboard who knows how to revamp the Clausewitz engine (anno 2007) for Stellaris' needs. Maybe they are not even allowed to tamper with the common trunk of Paradox proprietary assets. Whatever the root cause, I simply assume it's above their pay grade. The alternative would sound much darker, i.e. no resources allocated on purpose, not allowed to outperform other internal workgroups...
Bottom line, as long as Clausewitz is in the room, we won't go anywhere fast. And I'm truly sorry for all the modern CPU users out there.
- 2
- 1
I suspect it's less "don't know how" but more along the lines of "not allowed to". Basically unless you can show management that fixing the engine will net them MORE money than releasing another paid DLC then the odds are good the next big thing the team will work on is ... paid DLC.
FYI: In terms of tasks one of the easiest / best-suited tasks to parallelized would be video processing. As mentioned by the other poster if you have 8 cores / 16 threads you might be able to write a tool that increases speed by 10X compared to "single core processing" -- you just need to be clever. For something like Stellaris though I'd be surprised to hear that you could realistically get much better than 4X.
I don't know much about Vicky 2 but I've been told that they deal with MORE pops, jobs, factions, etc. in that game and the performance is just fine. If that's the case maybe existing code could act as a template to improve what we see in Stellaris???
My major performance complaint isn't the overall performance, but the specific performance when I open a colony view window.
Somewhere between 2375 and 2425, when I open one of my colony views (AI colony views do not have this problem) the game starts taking a second or more to respond to mouse clicks. Is this normal, or are there settings I should change to get it back to behaving like a sensible UI?
Somewhere between 2375 and 2425, when I open one of my colony views (AI colony views do not have this problem) the game starts taking a second or more to respond to mouse clicks. Is this normal, or are there settings I should change to get it back to behaving like a sensible UI?
At the state of things, a 4x improvement would still be massive. But, your argument from the financial point of view is a stinging one.
Given this thread is two years old and 66 pages long, I'd hazard a guess we're at a point where more existing players would pay 10 bucks for a "performance DLC" rather than the next species DLC. Although I hear the Aquatics are in high demand. From a business ethics standpoint though, this is a non-starter.
Where do we go from here? Whithout an official statement, we're all fishing in the dark. The slow, creeping dark of the Stellaris universe.
- 1
My advice would be to keep up the pressure. Keep posting here ... Keep asking questions during Paradox Streams ... If there are any Paradox "live" events ask questions there.
IF you think new PAID DLCs aren't worth buying given the state of the core game then DON'T BUY THEM. Granted that's just a drop in the bucket but IF the company thinks that the state of the core game will impact their bottom line then they may re-analyze the performance impact.
FYI: One of the things I mentioned earlier is that new features have to be very carefully examined for performance implications. A seemingly minor change could cause a significant drop in performance. I didn't expect the to see the drops we have AS QUICKLY as we have but that just goes back to the point that AI quality, performance, etc. are all things that probably shouldn't be fixed-once-then-ignored as new problems will appear & gum up the works.
IF you think new PAID DLCs aren't worth buying given the state of the core game then DON'T BUY THEM. Granted that's just a drop in the bucket but IF the company thinks that the state of the core game will impact their bottom line then they may re-analyze the performance impact.
FYI: One of the things I mentioned earlier is that new features have to be very carefully examined for performance implications. A seemingly minor change could cause a significant drop in performance. I didn't expect the to see the drops we have AS QUICKLY as we have but that just goes back to the point that AI quality, performance, etc. are all things that probably shouldn't be fixed-once-then-ignored as new problems will appear & gum up the works.
- 1
- 1
Yep. Maybe we should organise some community polls? That being said, I suspect there'd be quite a bit of tension in this. Eg, those who feel that paying extra for a properly working game is unfair. But then again, if the DLC itself is relatively simple and the base game sees a big improvement then those who feel that paying extra for a properly working game can simply skip the DLC.
You don't even need to be clever. There's a group of algorithms that are considered to be "embarrassingly parallel" - and yeah, many forms of video processing would fall in that category.
Anyway, with regards to Stellaris, I think the limits of parallelism would be different for different parts of the game. Eg, I can't imagine it being too hard to process colonies in parallel, though you might have problems with especially large colonies (in which case you probably want to start processing bigger colonies first). However, something like space battles might be harder to parallelise, depending upon the underlying details of the algorithm. Sector and Empire level stuff (including the "AI") might be hard to parallelise well.
It certainly feels to me that while the current Stellaris is a lot more complex than it used to be, it's not that complex relatively speaking. An individual pop is not that complex an object and processing 10,000 of them shouldn't be that big an overhead, especially when not much changes per day from a pop's point of view. It does feel like the underlying processing is very inefficient, to the extent that there's perhaps more to be gained in performance there than from multithreading.
@CPR :
I think a community poll would be OK if we approached it in the most constructive way possible. At least it would be a "data point" that a community / forum manager could take to the big-wigs so they can figure out if fixing "core elements" is worthwhile to them.
As someone that spent time working on a multi-tasking OS core I will definitively say that average run-of-the-mill programmers will tend to write BAD multi-threaded / parallel code esp. when under a time crunch. You need someone that is REALLY GOOD at specifically those sorts of things to write both functionally correct AND quickly executing [fast] code. The familiar example is you can have HIGH-Quality parallel code, you can have that code done quickly, you can have the code done cheaply .... pick 2 of 3
My speculation is that the code for the engine PLUS the Stellaris specific code written on top of the engine is likely VERY spaghetti-fied and/or convoluted. I come to this based on either a live stream OR DEV post [I forget] where they described how bonuses were applied and there was a very specific AND very serialized nature to how they were calculating a lot of the interacting bonuses. After hearing the description it made me think that it would likely be best for someone to REDESIGN things [at least bonuses] from the ground up to remove the tedious serialized nature of how the bonuses interacted with each other.
Basically it's not worth trying to untie/untangle the gordian knot ... your best off starting from scratch -- preferably by someone that's very good at parallelization but has NOT been exposed to the way Stellaris currently does things per-se --- that gives them a better chance to come at things with a fresh approach instead of "this is the way we always have done it before".
I think a community poll would be OK if we approached it in the most constructive way possible. At least it would be a "data point" that a community / forum manager could take to the big-wigs so they can figure out if fixing "core elements" is worthwhile to them.
As someone that spent time working on a multi-tasking OS core I will definitively say that average run-of-the-mill programmers will tend to write BAD multi-threaded / parallel code esp. when under a time crunch. You need someone that is REALLY GOOD at specifically those sorts of things to write both functionally correct AND quickly executing [fast] code. The familiar example is you can have HIGH-Quality parallel code, you can have that code done quickly, you can have the code done cheaply .... pick 2 of 3
My speculation is that the code for the engine PLUS the Stellaris specific code written on top of the engine is likely VERY spaghetti-fied and/or convoluted. I come to this based on either a live stream OR DEV post [I forget] where they described how bonuses were applied and there was a very specific AND very serialized nature to how they were calculating a lot of the interacting bonuses. After hearing the description it made me think that it would likely be best for someone to REDESIGN things [at least bonuses] from the ground up to remove the tedious serialized nature of how the bonuses interacted with each other.
Basically it's not worth trying to untie/untangle the gordian knot ... your best off starting from scratch -- preferably by someone that's very good at parallelization but has NOT been exposed to the way Stellaris currently does things per-se --- that gives them a better chance to come at things with a fresh approach instead of "this is the way we always have done it before".
If we want to organise a poll, I guess the first thing to discuss is the general framing of the question. I've thought of a few but the one I like the most so far is this:
"Engineering time is limited. Giving a higher priority to one aspect of the game software means a lower rate of improvement in one or more other aspects of the game. Is there a particular part of the game software that you want to see given a much higher priority despite this inevitable trade-off?"
The first option would be "I'm happy with the current priorities / It's not my business to tell how Paradox to operate" and the rest would be different areas for software developer time (so would not include things like price, localisations, graphical assets, sound or music)
A follow-up question could be on what you think could be deprioritised.
"Engineering time is limited. Giving a higher priority to one aspect of the game software means a lower rate of improvement in one or more other aspects of the game. Is there a particular part of the game software that you want to see given a much higher priority despite this inevitable trade-off?"
The first option would be "I'm happy with the current priorities / It's not my business to tell how Paradox to operate" and the rest would be different areas for software developer time (so would not include things like price, localisations, graphical assets, sound or music)
A follow-up question could be on what you think could be deprioritised.
- 1
- 1
I think the problem is not that the devs arent aware of the performance issues, but the fact that fixing/improving that costs money. I have no idea how much work it really is, but i strongly doubt it can be done by one programmer- instead i assume you need several highly skilled programmers who are able to fix it well enough for a big performance boost and fast enough that the release of new DLCs/content is not delayed. But Paradox cannot be sure if they get the invested money back as the Stellaris amin game and most of the old DLCs have already made their revenue- a performance patch will not likely increase the sales. Fixing the performance for free (unless its totally broken) is quite likely something the devs cant do as they have to gain earnings.
Thus i think you should change the questions- instead of "How many people want performance improvement instead of new content?" (i assume more than 90% want that) you should ask: "How much are you willing to pay for a performance DLC?" This way, Paradox can see if it is worth to spend more money on that.
I would ask the following:
"How much money would you spend for a DLC which improves the performance significantly (e.g. 3 times the 2.6.3 or 2.7.2 performance)":
(Including the money you would spend on additional DLCs /Basis games you would only buy if the performance gets addressed)
(Including a price rise for future DLCs if they contain performance improvements e.g. if Paradox wants to combine performance boost with new features)
- 0 bucks
- 5 bucks
- 10 bucks
- more than 10 bucks
This way, Paradox can do quick math and decide if they can afford to spend more money on it.
Thus i think you should change the questions- instead of "How many people want performance improvement instead of new content?" (i assume more than 90% want that) you should ask: "How much are you willing to pay for a performance DLC?" This way, Paradox can see if it is worth to spend more money on that.
I would ask the following:
"How much money would you spend for a DLC which improves the performance significantly (e.g. 3 times the 2.6.3 or 2.7.2 performance)":
(Including the money you would spend on additional DLCs /Basis games you would only buy if the performance gets addressed)
(Including a price rise for future DLCs if they contain performance improvements e.g. if Paradox wants to combine performance boost with new features)
- 0 bucks
- 5 bucks
- 10 bucks
- more than 10 bucks
This way, Paradox can do quick math and decide if they can afford to spend more money on it.
- 5
0 bucks, because you already paid for the "privilege" to be able to have decent performance when you bought the game. Decent performance being running the game on recommended settings using recommended hardware and having performance that is comparable to other competitors' products on the market, something that you can't achieve right now. I don't know how this is even a debate, because asking money for something that should've been there in the first place cannot be justified with any amount of mental gymnastics.
- 9
- 2
I wonder: Is there anyone out there who hasn't got performance issues in the end-game on larger maps? Come on paradox. You need to fix this no matter how. Such a great game but this tends to destroy all ot it.
- 3
- 2
So I build a new Pc with a Ryzen 5 and 16GB of ram. But the game runs fine, until I come to mid game. I start off with a stable 120 fps and mid game it becomes 70 fps, MY cpu is working his ass of. I love the game, relaxing and building an empire in my spare time, but the slow down is a drag. I support the idea of a poll, and a Q&A. I don't want to talk trash about paradox maby they listen they did that with Imperator. Please Paradox fix this. Make it multi-proccesing (I know it isn't an option, but a man can dream alright XD)
- 1
I feel for you. My guess is you spend 700$+, get a decent modern-day gaming rig, and I doubt your performance in Stellaris is world's better than my computer from 8 years ago
While I'm sure we could get back to the performance boost we had with 2.6.x without toooo much hassle I'm more worried about the future of the game && whether new updates will just break the performance [or AI] again.
*************************************
While you're talking abut dreaming I'd like to see the end of "Stellaris I" could somewhere around 2.9.5 where the last 5 "patch" releases are just various bug fixes, QOL fixes, etc. that will leave Stellaris I in good shape. Basically be to Stellaris (I) 2.x what the 1.9.1 release was to early Stellaris -- the peak refinement of the early days of Stellaris. Then, hopefully, Paradox can invest serious $ into the next generation engine so they can scale MUCH better than they do now with both Memory && CPU and come up with a Stellaris II that is better able to realize the vision of the DEVs without it being so easy to break performance [or AI if possible].
- 1