[Posila] [0.16.41] Melting CPU while in Mainmenu (constant 55%)

This subforum contains all the issues which we already resolved.
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2339
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: [0.16.41] Melting CPU while in Mainmenu (constant 55%)

Post by Jap2.0 »

cyfrov wrote: response of human eyes is on the order of ~10ms
Response time is different from perception time. This is basically the 24/27/30/60/75/120/144 fps debate - 10ms is 100 fps, and people have refresh rates significantly higher than that.
There are 10 types of people: those who get this joke and those who don't.

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: [0.16.41] Melting CPU while in Mainmenu (constant 55%)

Post by posila »

cyfrov wrote:@posila ... sub-ms sleep accuracy is needed when paused?
I don't know, I haven't had chance to look into it further yet.

cyfrov
Inserter
Inserter
Posts: 25
Joined: Thu May 03, 2018 7:09 pm
Contact:

Re: [0.16.41] Melting CPU while in Mainmenu (constant 55%)

Post by cyfrov »

Jap2.0 wrote:
cyfrov wrote: response of human eyes is on the order of ~10ms
Response time is different from perception time. This is basically the 24/27/30/60/75/120/144 fps debate - 10ms is 100 fps, and people have refresh rates significantly higher than that.
You are absolutely right, the perception time is even slower, it takes a lot longer to identify and consciously process object information, so 60fps is more than enough for a reaction based game (Halo), and 30fps is enough for a thinking based game (Factorio)

The uber high refresh rates on TVs/Monitors is exclusively a marketing gimmick (I speak based on my background in designing high speed integrated circuits, including HDMI).

The technology has reached a level of saturation and commoditization, and makers are desperate to distinguish themselves from the Chinese no-name brands.
That being said, what the higher refresh rates do is they allow makers to cut corners on other parts of the display system. Simply put, they can provide a cheaper 30Hz effective display, while claiming to be the next best thing since sliced bread.
By employing temporal subsampling, they can reduce the framebuffer memory requirements in the display (save a few $). Alternatively, they can exploit oversampling techniques to maintain a color dynamic range without having to buy high resolution D/A converters (save a few more $). There are other tricks they can use, but these are the two most common.
To add to that, there is also supply chain pressure, especially when making physical things in the 10k+ unit range.
From the chip side, unless you're in the military area, there is a pressure to keep changing silicon process (e.g. 180nm -> 130nm -> 90nm -> 65nm ... 8nm) both internally, and from fabs.
Internally, to avoid price erosion, since a chip that has been in manufacture for over 5 years can see its profit margins shrink from 99% to <15%.
From fabs, since it's not always economical to be maintaining 20-30 year old technology, so they taper down their wafer capacity for a node, and require you to move to a different node if you want certain high volume production.
When faced with that push, unfortunately the change is not simple and straightforward as most code monkeys think, you can't just "recompile" your chip for a new process, you often have to start almost from scratch for the analog circuits. At which point, why not push that interface from 2Gbps to 3Gbps? at least you'll give marketing something to brag about...that's roughly how a lot of the internal conversations go...which then translates to a customer conversation that goes like this: we don't make the old chip in the quantities you want, but we can sell you the new one which let's you do more; Customer: but I don't need that; Sales: hmm, well...we can tell you how to "simplify" your system using our new chip, so that your BOM cost is roughly the same or lower

...so yeah...it's a different story when you look under the hood

Koub
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: [Posila] [0.16.41] Melting CPU while in Mainmenu (constant 55%)

Post by Koub »

[Koub] Now we're getting seriously off topic. Please let's keep it to the Original subject - and if it is indeed resolved, maybe switch to other topics.
Koub - Please consider English is not my native language.

cyfrov
Inserter
Inserter
Posts: 25
Joined: Thu May 03, 2018 7:09 pm
Contact:

Re: [Posila] [0.16.41] Melting CPU while in Mainmenu (constant 55%)

Post by cyfrov »

@Koub Apologies, it was just a practical explanation as to why spin counters are overkill.

To stay on topic, even 0.16.51 continues to melt the cpu while the game is paused or in main menu.
from @posila, i got the impression that this bug was going to be fixed at some point, just unsure if it's slated for the 0.17 release or sooner

cyfrov
Inserter
Inserter
Posts: 25
Joined: Thu May 03, 2018 7:09 pm
Contact:

Re: [Posila] [0.16.41] Melting CPU while in Mainmenu (constant 55%)

Post by cyfrov »

@Posila

No longer a problem as of 0.17.*
When paused or minimized, it now hums at barely 3% of a single core.
Actually the whole game is now much less CPU intensive than before, and not too many noticeable bugs.
Whatever you did, keep up the good work :D

Post Reply

Return to “Resolved Problems and Bugs”