Friday Facts #408 - Statistics improvements, Linux adventures

[FuryoftheStars]

Are you going to bring non blocking saving to single player? I really only see the multiplayer setting.

The non blocking saving setting they mentioned is for both.

[Hildar]

Awesome to hear how Linux support is going. Vulkan rendering backend instead of OpenGL when?

Having used async saving, it works great... except with Pyanadon's modpack. I assume this is the RAM issue you mentioned since PyAL uses ludicrous RAM amounts startup (I had to increase my swap space to get the game to load to the main menu, but no runtime performance issues). Also shout out to the cache-sprites and cache-prototypes advanced settings. Would love to see those promoted to the main settings screen.

[mamodom]

So what do you think? Are there any other statistics improvements you can think about for 2.0?

Great to see stats improvements!

There are some requests in this thread that are very specific solutions to very specific problems, and it's not realistic for all of them to exist. I do, however, like the idea of having access to the stats needed to solve a given problem.

One way to have that is to be able to plot circuit network values in the stats UI. It's then up to us to figure out how to get the values we need to solve our problems, which could enable more strange and creative uses of CN. This could be a "circuit probe" entity (or something) that is connected to the network you want to see in the stats UI.

I worry this might open a can of worms in terms of now needing a "probe list UI" and everything that implies (like shown in FFF#405).

A possible compromise could be not to have a probe entity, and limit the networks that can be plotted to the Radar transmission networks of FFF#402, which is one per surface. This compromise will certainly limit some workflows, but I'm sure someone will find a way around it in a mod with hidden surfaces or something

But speaking of mods, being able to add graphs to the stats UI and plot arbitrary values from the lua API could enable a lot more things. This would be a solution to Anti's power production/consumption ratio graph, or Ferlonas' Theoretical maximum consumption graph.

Great work!
Can't wait for 2.0

[Roani52]

Statistics enhancements proposals:
- consistent item colors across production and consumption bars (Currently most produced item is blue, second produced item is orange etc.) So when most produced are steel plates and most consumed is coal, then they have blue color on graph which is confusing.

Yes, please! This has confused, or even slightly annoyed, me more than once. This would be most useful when a (small) subset of items is displayed, though it would be nice to have it for the full overview as well.

It would also be nice if there's somehow an option to select a subset of items to be displayed simultaneously for production and consumption, though I have to admit I have no idea how to make that selection UI intuitive to use.

[AkBKukU]

If you are playing on Linux or macOS, please enable asynchronous saving [...] and report any issues you find.

I know you're looking for negative results to fix, but I wanted to mention that I used asynchronous saving on a 24/7 server for months on a bloated (~300MB saves) Space Exploration modded play though and it was flawless. That feature made that play through possible because it was taking so long to do single threaded saves that it was a serious interruption to playing.

So huge props for the async save, from my experience it's ready for prime time. And also thanks for continuing the linux support, it's the only platform I've played the game on and I hold it up as one of the gold standards for native linux games.

[Kadet123]

If it's possible, it might be worth exploring if the forked Factorio instance could unload essentially everything but raw entity data or similar. I don't know much about the internals of the game, even after reading all FFFs.

If the fork() finishes and the forked process checks if it is the child and not the parent, the forking already took place. The resources are already duplicated. There is no benefit in then releasing anything, just to release everything after the memory dump of the map finished anyway.

The fork() system call doesn't really copy everything a process owns. On modern unix systems, it duplicates the small process table entry and some management data within the kernel, but process memory isn't physically duplicated. With virtual memory management, only single memory pages are copied on the fly into process private memory space if one of the processes writes something into their memory - it's copy on write. If the parent Factorio process that continues to run changes 5% of its process memory while the child is saving at the same time, only this 5% is actually copied by the kernel and allocated separately.

The memory cost is in that the memory in the saving fork is constant, while the main game process continues to simulate and may be changing all kinds of game data. While the save is running, many memory writes in the main game process incur the time and RAM overhead of a page copy.

I wanted to say something along those lines, that even though its copy-on-write, the amount copied is entire pages (4096 byte blocks) even if only a single byte within in a page was updated.

When raigard's saying background saving "doubles memory usage", thats a bit of a worst case scenario, true. While its also true that much of the memory data is "read-only" once loaded (assets like graphics, sounds, etc), if the memory for those "read-only" assets is mixed in among memory allocations for entities, then yes that data will get copied when pages are written to.

At the point in time when fork() returns, memory has not yet been duplicated. Instead, both processes now have virtual memory mappings to the same memory regions. But when the very next game tick occurs, every game entity's state gets touched (each inserter moves a fraction of an angle, each assembler's recipe progresses a fraction, etc), and that triggers copying of all the memory pages holding those entity's data (this is when copy-on-write takes effect).

If the game engine uses 2 different memory pools for data that's "read-only" and data that changes every tick, then the amount of memory duplicated in copy-on-write can be minimized to less than "doubling the memory usage", but I don't know if Wube uses any memory management strategies like that.

[Jonathan88]

Just chipping in to say thank you for the consistent and dedicated linux support! Started back in 2014 with version 0.9 and first impression was surprise at how well it ran on my early 2000s laptop running Linux Mint! Well, until HD graphics were released. Suddenly want to reload to v0.9 with low res graphics just for the nostalgia...

[Atraps003]

Thank you for the native linux support.

[pleegwat]

If the game engine uses 2 different memory pools for data that's "read-only" and data that changes every tick, then the amount of memory duplicated in copy-on-write can be minimized to less than "doubling the memory usage", but I don't know if Wube uses any memory management strategies like that.

Splitting the parts of entities which change often from the ones which change rarely would also reduce the number of modified cache pages which need to be written back to RAM. That's a double-edged sword though, since it may in turn increase the number of cache pages which need to be fetched on every tick.

This would affect performance on all platforms, including windows.

[MEOWMI]

I feel like, if science is important enough to be its own (meta) item in the production graph, then there should just be a button to show it without having to type.

[kellerkindt]

Thanks for all the effort put into the Linux support! <3

[Kadet123]

If the game engine uses 2 different memory pools for data that's "read-only" and data that changes every tick, then the amount of memory duplicated in copy-on-write can be minimized to less than "doubling the memory usage", but I don't know if Wube uses any memory management strategies like that.

Splitting the parts of entities which change often from the ones which change rarely would also reduce the number of modified cache pages which need to be written back to RAM. That's a double-edged sword though, since it may in turn increase the number of cache pages which need to be fetched on every tick.

This would affect performance on all platforms, including windows.

I agree, that would probably not be worth it. But I wasn't advocating splitting the entity's data. I was talking about segregating memory that never changes once loaded (assets like sprites, sounds, etc) from entity memory (which frequently changes). The bitmaps for sprites (which are shared among many many entities) are already not stored in the same data structures as per-entity data (like individual inserter angles, hand contents, assembler recipe progress, etc).

[thedoh]

I would pay gobs and gobs of money if production stats were made available via an HTTP endpoint that could be scraped by Prometheus in the vanilla game. The in-game stuff is great, but not very flexible in the ways that something like Grafana can be. We can't "drill down" into stats from the 1000 hour graph, for example, to find out when something changed.

(I promise not to hook up Prometheus to AlertManager and start paging when power is low. )

[mamodom]

I would pay gobs and gobs of money if production stats were made available via an HTTP endpoint that could be scraped by Prometheus in the vanilla game. The in-game stuff is great, but not very flexible in the ways that something like Grafana can be. We can't "drill down" into stats from the 1000 hour graph, for example, to find out when something changed.

(I promise not to hook up Prometheus to AlertManager and start paging when power is low. )

Well, https://mods.factorio.com/mod/graftorio

[youROCK]

When did you implement fork() for save? I suggested it in 2016! viewtopic.php?f=66&t=24242

[thedoh]

I would pay gobs and gobs of money if production stats were made available via an HTTP endpoint that could be scraped by Prometheus in the vanilla game. The in-game stuff is great, but not very flexible in the ways that something like Grafana can be. We can't "drill down" into stats from the 1000 hour graph, for example, to find out when something changed.

(I promise not to hook up Prometheus to AlertManager and start paging when power is low. )

Well, https://mods.factorio.com/mod/graftorio

That's sweet! I wish they would include it in vanilla though.

[AileTheAlien]

Thank you so much for upstreaming some work!

[FuryoftheStars]

When did you implement fork() for save? I suggested it in 2016! viewtopic.php?f=66&t=24242

According to this other thread, sometime with version 0.16.x, though it appears to have been an undocumented change, so unknown if it was 0.16.0 or a later iteration.
viewtopic.php?f=6&t=56073

[EustaceCS]

Async saving is one of those oddball things that seems like it's a workaround to a bigger problem. If saves were barely noticeable then why even bother to put the effort in for a feature that 1% of 1% of the userbase uses? Why not work towards a solution that helps all users?

Different users might have completely different goals.
For starts, split-saving seems to be a nice thing to have in non-Dedicated-Server sessions. Especially for people which don't aim for converting every single chunk of game map into a factory. You know, PvP and PvE enjoyers with less emphasis on building things and more emphasis on shooting things, and casuals which can't into production minmaxing so they just overproduce everything, this kind of players.
ESPECIALLY if it comes from OS's native feature, not from some homebrew solution.

[Shuisman]

I second that the 5s option is not so useful, 10 or 15 would be more useful. Or have it at least remember the selected one.

Another thing related to statistics: it would be great if you press P while having an assembly machine dialog open, that it opens the production statistics page with the recipe-products of the assembly machine highlighted. See also viewtopic.php?f=6&t=109504&p=595685#p595685