Friday Facts #421 - Optimizations 2.0

Regular reports on Factorio development.
User avatar
FactorioBot
Factorio Staff
Factorio Staff
Posts: 423
Joined: Tue May 12, 2015 1:48 pm

Friday Facts #421 - Optimizations 2.0

Post by FactorioBot »

SnowZyDe
Inserter
Inserter
Posts: 44
Joined: Fri Sep 01, 2023 12:28 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by SnowZyDe »

Omg
pleegwat
Filter Inserter
Filter Inserter
Posts: 278
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by pleegwat »

But what if a chunk is revealed by more than 255 radars?
sorrydnoodle
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sat Jul 18, 2015 11:51 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by sorrydnoodle »

Good to see the quest for optimization continues, it has been one of the worries for me with the expansion, but as always my fears were unfounded.

Can't wait to do another 1000x research cost run.
:)
Arzorth
Inserter
Inserter
Posts: 24
Joined: Mon Oct 01, 2018 7:24 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Arzorth »

you guys rock!
User avatar
Hares
Filter Inserter
Filter Inserter
Posts: 339
Joined: Sat Oct 22, 2022 8:05 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Hares »

pleegwat wrote: Fri Jul 26, 2024 11:18 am But what if a chunk is revealed by more than 255 radars?
Yeah, I had similar questions. We 100% need nod which would bump radars until the counter resets to 0.
Siarhei
Manual Inserter
Manual Inserter
Posts: 3
Joined: Sun Jan 15, 2023 5:08 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Siarhei »

It would be interesting to know, why don't process each planet in a separate thread/CPU core?
Arzorth
Inserter
Inserter
Posts: 24
Joined: Mon Oct 01, 2018 7:24 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Arzorth »

If a chunk has a counter greater than 1, it is put in an update bucket, and we loop through 1 bucket each tick.
Shouldn’t this be “ If a chunk has a counter greater than 0”?
Terrahertz
Fast Inserter
Fast Inserter
Posts: 132
Joined: Mon May 15, 2017 7:49 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Terrahertz »

pleegwat wrote: Fri Jul 26, 2024 11:18 am But what if a chunk is revealed by more than 255 radars?
I guess you could use the 255 as a special value, telling the engine to look into a dedicated table, as this should not occur all that often and is only needed for updates to the counter.
aka13
Filter Inserter
Filter Inserter
Posts: 799
Joined: Sun Sep 29, 2013 1:18 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by aka13 »

This is simply amazing, I love you guys! Factorio has always been and will remain forever in my heart for the most performant and extensive game there is.
Pony/Furfag avatar? Opinion discarded.
User avatar
The Phoenixian
Fast Inserter
Fast Inserter
Posts: 234
Joined: Mon May 26, 2014 4:31 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by The Phoenixian »

With the lamps change I can see the Bad Apple and Doom people salivating already. I look forward to someone deciding to make an entire space platform just for image display.

EDIT: Let me correct myself. I look forward to someone outside the dev team, following Kovarex's example and deciding to make an entire space platform just for image display.
pleegwat wrote: Fri Jul 26, 2024 11:18 am But what if a chunk is revealed by more than 255 radars?
Hmmm... I wonder how plausible that limit is. Roboports are bigger and harder to hit the limit, so if they can hit the limit then so can radars.
32x32 tile chunks, radar range 2 should mean chunks can only be seen by roboports in a 3x3 area, divided by Roboports size of 4x4... 576. Possible, but you'd have to really go crazy. (or deliberately try to hit it with radars)

The most plausible situation for this to come up by accident is if some absolute madlad makes it such that roughly every second tile in a 3x3 chunk area has a roboport. For some reason.
Last edited by The Phoenixian on Fri Jul 26, 2024 11:46 am, edited 2 times in total.
The greatest gulf that we must leap is the gulf between each other's assumptions and conceptions. To argue fairly, we must reach consensus on the meanings and values of basic principles. -Thereisnosaurus
User avatar
Hares
Filter Inserter
Filter Inserter
Posts: 339
Joined: Sat Oct 22, 2022 8:05 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Hares »

Speaking of multi-threaded updates, could it be made so each layer of computation uses it's own thread? One thread for belts, one for machines, one for electric network, and so on. Yes, this may introduce 1-tick lag/delay on some events, but this will make the game overall update time be almost equal to the largest of its components, not the sum of them, which is perfect when some aspects take ~equal amount of time (which is a normal use case).
FasterJump
Fast Inserter
Fast Inserter
Posts: 237
Joined: Sat Jul 09, 2016 11:43 am
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by FasterJump »

What if the logistic robot has a curved path (chasing a mobile entity like the player or spidertron)?
NaurEnForven
Burner Inserter
Burner Inserter
Posts: 9
Joined: Fri May 03, 2019 5:29 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by NaurEnForven »

Regarding the electric network.
My approach would have been to optimize based on groups, i.e. idle or full load.
For these two cases there is no need to iterate through the entities, instead we just track the total power consumption. Then you track changes instead.
All entities report when they no longer should be part of the stable group and subtract their previously stable consumption from the total.
The changes to the total get processed first, moving the entity back into a dynamic group, which is how all entities currently work.
After that all the entities in the dynamic group get iterated over and the the calculation is done as in the current version.

Depending on how many entities are stable, this could be worth it.
Unless I am overlooking something and this does not work at all.
Terrahertz
Fast Inserter
Fast Inserter
Posts: 132
Joined: Mon May 15, 2017 7:49 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Terrahertz »

It's amazing that you managed to hit the point where multithreading would slow you down at least in some places, very well done folks :D
pleegwat
Filter Inserter
Filter Inserter
Posts: 278
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by pleegwat »

NaurEnForven wrote: Fri Jul 26, 2024 11:42 am Regarding the electric network.
My approach would have been to optimize based on groups, i.e. idle or full load.
For these two cases there is no need to iterate through the entities, instead we just track the total power consumption. Then you track changes instead.
All entities report when they no longer should be part of the stable group and subtract their previously stable consumption from the total.
The changes to the total get processed first, moving the entity back into a dynamic group, which is how all entities currently work.
After that all the entities in the dynamic group get iterated over and the the calculation is done as in the current version.

Depending on how many entities are stable, this could be worth it.
Unless I am overlooking something and this does not work at all.
That might save an update loop too. As encountered in the electric update, memory bandwidth is a limited resource, and you want to limit how many threads need to fetch the same page.
User avatar
MEOWMI
Filter Inserter
Filter Inserter
Posts: 335
Joined: Wed May 22, 2019 12:21 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by MEOWMI »

Those improvements are really quite big in aggregate. Like, imagine if you could get these kinds of improvements on your endgame gear in an MMO. That would be extreme!
Brambor
Fast Inserter
Fast Inserter
Posts: 189
Joined: Thu May 07, 2015 1:52 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Brambor »

Loved this FFF!
boskid wrote:Optimizing belt readers went through couple of iterations. One of them was trying to keep running total on transport lines however it failed.
I wonder why did it fail? Was it too complex to programm? Or was the additional complexity of checking all the inserters and other inputs and outputs making it slower than before?
samcday
Burner Inserter
Burner Inserter
Posts: 5
Joined: Thu Apr 13, 2023 6:39 am
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by samcday »

For a couple of years now, I've fantasized about asking Factorio devs for NDA access to the engine source. My dream? To decouple the Factorio renderer from UPS, such that it could do interpolation/prediction of "easy(ish) to predict" linear movement of bots (and maybe also items on the belt) in the extra frames.

That is, I think a Factorio base running at 60UPS but animating a horde of bots whizzing over sushibelts running at 120fps would look positively *sublime*.

Seems to me that this latest optimization goes a long way towards such a glorious future!
User avatar
Dev-iL
Filter Inserter
Filter Inserter
Posts: 304
Joined: Thu Jul 02, 2015 2:48 pm
Contact:

Re: Friday Facts #421 - Optimizations 2.0

Post by Dev-iL »

I always wondered, and may have raised it on IRC in the past:
1) whether utilizing GPUs for computations instead of (or in addition to) graphic rendering could speed things up. It's obviously no small effort to convert parts of the code to work on a GPU, but since the team now has experience with porting the game to different platforms, including a console, perhaps this is more doable.
2) Use linear algebra to update states - (sparse) matrix operations such as multiplications, additions, etc, utilizing BLAS and MAGMA. It would be conceptually simple to create state transition matrices to update the states on each tick. The real question is which parts of the game loop code can benefit from moving away from explicit sub-looping...
Leading Hebrew translator of Factorio.
Post Reply

Return to “News”