Factorio Forums

A: The detailed look into optimizations are quite possibly my favorite things to read about in FFF. Please never stop.
B: Those labs look amazing.

Yet another step for everything in factorio to be in HD!

A linked list of multiply-inheriting classes? I'd have expected an array of structs.

By changing the zoom rate from 1.1, to the 7th root of 2 (1.104089...), the zoom now increments perfectly from 1.0 to 2.0 in 7 steps.

You guys are... I just love you guys.
I play games for over 20 years now, but I have NEVER seen someone give this much attention to their game.

I would approach this from a different perspective (I don't know if it is viable, but it doesn't hurt to explore it):

Looking at the factory as a graph of interacting entities, you will have tightly coupled areas (like an actual production plant with belts, splitters, inserters, production ...) that are loosely coupled (by trains, very long belts, large distance logistic networks ...).

If you now identify the tightly coupled areas, especially the ones outside the players attention (the window he is looking at), you can run each area through multiple ticks (like fast forwarding each area 500ms at a time) and get a nice hot cache for that. Then you switch to the next area. As they are coupled by things like trains, that are "slow" to fill, that will be hardly noticable.

The better your partitioning algorithm is, the smaller the areas are that you can identify for this process, which leads to nice cacheable sizes.

you lost me this time. how did you determine what byte range to prefetch? and also, i assume, you have to cast those raw bytes into a valid object. how do you know which bytes go into what variable? is the variables sequence the same on all hardware architectures? how did you address that uncertainty? how do you make sure, the cast is correct? checksum? hardware specific casts? hm,yes,yes, i get the picture. pretty nice coding stunt. seems risky at first glance.

iamwyza wrote:A: The detailed look into optimizations are quite possibly my favorite things to read about in FFF. Please never stop.

Indeed. FFF are my favorite way to start into weekends! Even if those are very technical sometimes, it is interesting to stay in touch with the developers and learn about their daily work and struggles.

Nice and steady flow of optimisations coming in *thumbs up*

pleegwat wrote:A linked list of multiply-inheriting classes? I'd have expected an array of structs.

I'm surprised to. I'd have expected C++ to handle virtual function calls and inheritance at compile-time, but apparently things are setup so that some of the required class structure isn't known until run-time?

You guys are using... linked lists?...

Why, oh why do you use linked lists? It is supposed to be common knowledge that in almost all situations even a straight vector is better.

At the very least something like C++'s deque would be better.

More optimizations, woohoo! While I usually don't understand much of the technical parts, it is always a joy to read through anyway to get a deeper look into stuff, and realize more of whats happening behind the scenes. A 9-13% improvement with the memory fetching on some saves is quite significant for sure! The hype for 0.16 keeps growing, especially with the new HR lab graphics as well which look glorious.

Hope all goes well with the management programs you're playing around with too!

By changing the zoom rate from 1.1, to the 7th root of 2 (1.104089...), the zoom now increments perfectly from 1.0 to 2.0 in 7 steps.

It's music!
http://pages.mtu.edu/~suits/notefreqs.html

AssaultRaven wrote:

pleegwat wrote:A linked list of multiply-inheriting classes? I'd have expected an array of structs.

I'm surprised to. I'd have expected C++ to handle virtual function calls and inheritance at compile-time, but apparently things are setup so that some of the required class structure isn't known until run-time?

Nope, C++ virtual function calls need to translate the virtual member function pointer with the class-specific pointer the object holds, and that gives you the pointer to the function it should call.

You can only statically compile it if the function is non-virtual, or if through optimization you know that the object must be a specific type.

BTW, multiple-inheritance knows the class structure at compile time. It would be more of an issue with run-time not knowing what particular class or inherited classes the object was.

Thank you very much for this FFF! I found the technical details really interesting, especially those about prefetching.

AssaultRaven wrote:

pleegwat wrote:A linked list of multiply-inheriting classes? I'd have expected an array of structs.

I'm surprised to. I'd have expected C++ to handle virtual function calls and inheritance at compile-time, but apparently things are setup so that some of the required class structure isn't known until run-time?

Thinking further on it it's worse: This suggests they're evaluating every object in every tick.

Even if I've got a fully beaconed up yellow assembler making copper wire, that's going to do a craft like what, every 6 ticks?
So that's 1 tick out of 6 that it needs to do work. The other 5, at most you're updating the craft progress (don't do that. Save the time it'll be done instead).

Very many entities will be aware ahead of time when they will next need to do work. An assembler doesn't need to do a thing for X ticks until its craft is done. An inserter is doing nothing for Y ticks until its swing is complete. Etc. Even an inserter hovering over a belt can predict to some degree when a relevant item (or empty spot) will next come up.

Make an array of entities per chunk and the only thing you have to do every tick is scan the list for which entities need an update. Then pointer out the actual entities, since they're dynamic and relatively large.

And try to figure out if your class structure is getting inlined out properly in that codepath.


Oh, and rendering only applies to on-screen entities. You can determine animation frame from speed and next done tick in the render pass.

To get a bit more diversity, the measurements for this chart were done on a different CPU (i7-6700K vs i7-4790K previously)

If I may, I think the tests for optimization should be run not only on Intel, but also on AMD CPUs : we've seen recently how the architecture of the last AMD architecture has unforeseen effect on performance.

Math Math Math - Oooo! Picture!

cpy wrote:First! Hurray!

Some forums have rules aginst that kind of "spam" you know... (Sadly, not this one.)

Wait, Labs are just Plasma balls.

imean they could look like one of these Centrifuges or atleats something that makes you able to tell which Science packs are in it without the Advaned View