[Suggestion] Use more resources
Moderator: NBJeff
[Suggestion] Use more resources
I'm seeing game lags on a large map with very little things actually on it, but the program is only using 14% CPU and ~600mb of RAM. There's tonnes of resources that you're not making use of at the moment. Please make it use up more resources instead of lagging on systems that have resources available.
Oh look! Someone does not know what Alpha stands for in "Prison Architect ALPHA"
Life is NOT like a box of chocolates, it's more like a jar of jalapeños: What you do today might burn your a** tomorrow.
~Garfield
~Garfield
I'm pretty certain that your Operating System is in charge of assigning resources to programs. In fact... if anything other than your Operating System had this power, then games (and other programs) (particularly in alpha) would be crashing computers. Instead, simply the individual program is prone to fail when the operating system doesn't give the program the power it requests.
Now with that said, the slow down in the game can almost certainly be resolved with better, more efficient programming (it's possible that not too much is multi-threaded yet, and multi-threading will almost certainly allow the game to use more of your resources)... but the game is still in Alpha. I mean, the whole game freezes up for several very long seconds every time the game auto-saves.
Now with that said, the slow down in the game can almost certainly be resolved with better, more efficient programming (it's possible that not too much is multi-threaded yet, and multi-threading will almost certainly allow the game to use more of your resources)... but the game is still in Alpha. I mean, the whole game freezes up for several very long seconds every time the game auto-saves.
VoiD88 wrote:Oh look! Someone does not know what Alpha stands for in "Prison Architect ALPHA"
You mean like the stage at which you give early feedback, of, oh, say, something that could potentially cause some pretty involved work such as changing the way the program utilizes resources?
xander wrote:Yeah... that's not how it works.
xander
Pogo wrote:I'm pretty certain that your Operating System is in charge of assigning resources to programs. In fact... if anything other than your Operating System had this power, then games (and other programs) (particularly in alpha) would be crashing computers. Instead, simply the individual program is prone to fail when the operating system doesn't give the program the power it requests.
Now with that said, the slow down in the game can almost certainly be resolved with better, more efficient programming (it's possible that not too much is multi-threaded yet, and multi-threading will almost certainly allow the game to use more of your resources)... but the game is still in Alpha. I mean, the whole game freezes up for several very long seconds every time the game auto-saves.
The OS is obviously the final arbiter of how much resource a program gets, but you won't get it if you don't ask for it. There's a reason games don't usually go over 4GB of RAM while Premiere can eat up almost everything you have available, the way the program is designed (and the kind of thing it does) definitely has an impact on how much resources it will make use of. Parallelization too would be great as far as CPU usage goes.
primexx wrote:The OS is obviously the final arbiter of how much resource a program gets, but you won't get it if you don't ask for it. There's a reason games don't usually go over 4GB of RAM while Premiere can eat up almost everything you have available, the way the program is designed (and the kind of thing it does) definitely has an impact on how much resources it will make use of. Parallelization too would be great as far as CPU usage goes.
That still is not how it works. There are definitely places where the game could be optimized, but the game not using 100% of your system resources does not indicate that it is failing to behave correctly, nor does it indicate that it could be using more resources to do more work. Not everything is parallelizable, and there are tons of potential bottlenecks (GPU, CPU, RAM, bus speed, &c.). A perfectly optimized game might not use 100% of the available resources and still lag.
xander
primexx wrote:You mean like the stage at which you give early feedback, of, oh, say, something that could potentially cause some pretty involved work such as changing the way the program utilizes resources?
"early feedback" - OK
"something that could potentially cause some pretty involved work" - OK
"changing the way the program utilizes resources" - Wrong. As said above, I agree that optimizing the code for performance is a really big step in software development, but that is the sole purpose of the entire Beta phase for this very reason. Also, it wouldn't make sense to start with heavy optimization now (not talking about minor tweaks because there have been some already) when a lot of features haven't even been added to the game, because those would most likely require a complete rehaul of the optimization process. That's why almost all software developers wait with optimization until their program is feature-complete.
So to sum it up: Alpha is for adding features, Beta is for code optimization for performance (which includes making the program able to multi-thread, thus using more resources of your hardware).
Life is NOT like a box of chocolates, it's more like a jar of jalapeños: What you do today might burn your a** tomorrow.
~Garfield
~Garfield
- paktsardines
- level5
- Posts: 1752
- Joined: Mon Oct 01, 2012 11:10 am
- Location: Australia
- paktsardines
- level5
- Posts: 1752
- Joined: Mon Oct 01, 2012 11:10 am
- Location: Australia
-
- level0
- Posts: 6
- Joined: Sat Aug 10, 2013 4:39 pm
- Location: Salt Lake City, Utah
Needs more cowbell for multicore CPU's
Yeah, code optimization comes later. However the idea should still be explored to support a multicore environment. As it is now, PA is only using 1 core of the 6 I have available. And that 1 core is slammed at 100% soon after reloading. Many mobile devices along with PC's are largely multicore these days as well, so this would be a huge boost to playability.
For those of us who have the extra resources to throw around, you might try setting the game's affinity for a specific CPU coreon your puter by doing the following:
1. Get PA running at a point you start to chug chug along (lag).
2. Open the Winblows task manager, click on the performance tab.
3. Take note of which cores are not being utilized, then select the Processes Tab. (Note that as most things puter related, the cores start at 0 instead of 1)
4. Right-Click on the Prison Architect.exe Process, and select "Affinity."
5. Change the values to reflect the underutilized core found in step 3, and click 'OK.'
This process has put the game into a better state (runs faster than before) than letting Windows choose my core for me. I thought it might help you guys as well.
Thanks again guys, I'm having a blast with PA.
-Overt.
For those of us who have the extra resources to throw around, you might try setting the game's affinity for a specific CPU coreon your puter by doing the following:
1. Get PA running at a point you start to chug chug along (lag).
2. Open the Winblows task manager, click on the performance tab.
3. Take note of which cores are not being utilized, then select the Processes Tab. (Note that as most things puter related, the cores start at 0 instead of 1)
4. Right-Click on the Prison Architect.exe Process, and select "Affinity."
5. Change the values to reflect the underutilized core found in step 3, and click 'OK.'
This process has put the game into a better state (runs faster than before) than letting Windows choose my core for me. I thought it might help you guys as well.
Thanks again guys, I'm having a blast with PA.
-Overt.
Optimizing can be done while there are missing features. Obviously you can't optimize code that doesn't exist, but you can optimize that which does. It is not automatically wasted effort either. Most code does tend to remain as it was first written. And minor changes in the future are usually not a problem as long as you didn't optimize the code into an unmaintainable mess. People don't do that unless they are desperate.
As Overtkill mentioned, PA is only using one of his 6 cores currently.
The problem is that Prison Architect isn't multi-threaded yet. (Did I or did I not address this in my first post in this thread?)
A program can only use multiple cores if that program is multi-threaded. If a program is single-threaded, then each line of code can only be executed as soon as the line before it is finished executing. And when the game has to operate in real time and draw a new frame between each set of calculations, it doesn't matter how good your computer is, the game is going to run slow. In fact, drawing graphics is one of the most CPU intensive processes a program can tell a computer to do.
So, while there are almost definitely other parts of the code that could be optimized, the biggest performance improvement will come from multithreading the program. But multithreading is a big, big headache. It has to be eventually done, but better the minimize the time you spend with it.
When the game is multithreaded, that's a big time consuming headache. And everything programmed after this fact has to be sure to run with the multithreading... and if a feature added later means that the threads need to be divided differently in order to run more efficiently, well, that's just too bad, because then you're basically scrapping all the time you spent multi-threading and redoing it all.
Better to put this off until you're done adding features.
The problem is that Prison Architect isn't multi-threaded yet. (Did I or did I not address this in my first post in this thread?)
A program can only use multiple cores if that program is multi-threaded. If a program is single-threaded, then each line of code can only be executed as soon as the line before it is finished executing. And when the game has to operate in real time and draw a new frame between each set of calculations, it doesn't matter how good your computer is, the game is going to run slow. In fact, drawing graphics is one of the most CPU intensive processes a program can tell a computer to do.
So, while there are almost definitely other parts of the code that could be optimized, the biggest performance improvement will come from multithreading the program. But multithreading is a big, big headache. It has to be eventually done, but better the minimize the time you spend with it.
When the game is multithreaded, that's a big time consuming headache. And everything programmed after this fact has to be sure to run with the multithreading... and if a feature added later means that the threads need to be divided differently in order to run more efficiently, well, that's just too bad, because then you're basically scrapping all the time you spent multi-threading and redoing it all.
Better to put this off until you're done adding features.
Who is online
Users browsing this forum: No registered users and 12 guests