Friday Facts #204 - Another day, another optimisation
Re: Friday Facts #204 - Another day, another optimisation
[Edited by Koub]
Last edited by Koub on Wed Aug 23, 2017 5:41 pm, edited 1 time in total.
Reason: Removed the "First", I don't want firsting to become a thing in this forum.
Reason: Removed the "First", I don't want firsting to become a thing in this forum.
Re: Friday Facts #204 - Another day, another optimisation
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.
B: Those labs look amazing.
-
- Fast Inserter
- Posts: 232
- Joined: Thu Dec 31, 2015 7:36 am
- Contact:
Re: Friday Facts #204 - Another day, another optimisation
Yet another step for everything in factorio to be in HD!
Re: Friday Facts #204 - Another day, another optimisation
A linked list of multiply-inheriting classes? I'd have expected an array of structs.
Re: Friday Facts #204 - Another day, another optimisation
You guys are... I just love you guys.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.
I play games for over 20 years now, but I have NEVER seen someone give this much attention to their game.
-
- Burner Inserter
- Posts: 13
- Joined: Sun Jun 12, 2016 3:12 pm
- Contact:
Re: Friday Facts #204 - Another day, another optimisation
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.
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.
Re: Friday Facts #204 - Another day, another optimisation
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.
Re: Friday Facts #204 - Another day, another optimisation
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.iamwyza wrote:A: The detailed look into optimizations are quite possibly my favorite things to read about in FFF. Please never stop.
Nice and steady flow of optimisations coming in *thumbs up*
-
- Long Handed Inserter
- Posts: 58
- Joined: Sun Jun 08, 2014 4:00 am
- Contact:
Re: Friday Facts #204 - Another day, another optimisation
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?pleegwat wrote:A linked list of multiply-inheriting classes? I'd have expected an array of structs.
Re: Friday Facts #204 - Another day, another optimisation
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.
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.
- Xterminator
- Filter Inserter
- Posts: 981
- Joined: Sun Jun 15, 2014 4:49 pm
- Contact:
Re: Friday Facts #204 - Another day, another optimisation
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!
Hope all goes well with the management programs you're playing around with too!
Re: Friday Facts #204 - Another day, another optimisation
It's music!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.
http://pages.mtu.edu/~suits/notefreqs.html
Last edited by darkfrei on Fri Aug 18, 2017 6:48 pm, edited 1 time in total.
Re: Friday Facts #204 - Another day, another optimisation
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.AssaultRaven wrote: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?pleegwat wrote:A linked list of multiply-inheriting classes? I'd have expected an array of structs.
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.
Re: Friday Facts #204 - Another day, another optimisation
Thank you very much for this FFF! I found the technical details really interesting, especially those about prefetching.
Re: Friday Facts #204 - Another day, another optimisation
Thinking further on it it's worse: This suggests they're evaluating every object in every tick.AssaultRaven wrote: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?pleegwat wrote:A linked list of multiply-inheriting classes? I'd have expected an array of structs.
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.
Re: Friday Facts #204 - Another day, another optimisation
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.To get a bit more diversity, the measurements for this chart were done on a different CPU (i7-6700K vs i7-4790K previously)
Koub - Please consider English is not my native language.
-
- Fast Inserter
- Posts: 104
- Joined: Tue Nov 15, 2016 10:56 pm
- Contact:
Re: Friday Facts #204 - Another day, another optimisation
Math Math Math - Oooo! Picture!
"And then Bender ran."
Re: Friday Facts #204 - Another day, another optimisation
Some forums have rules aginst that kind of "spam" you know... (Sadly, not this one.)cpy wrote:First! Hurray!
Re: Friday Facts #204 - Another day, another optimisation
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
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