Factorio Forums

Ext3h wrote: ↑

Sun Dec 08, 2019 8:41 pm

That math is far off, unfortunately. Unpacking bit-packed structures like that is not free. Especially not if placed on arbitrary offsets, that's 6-10 extra instructions just for unpacking, including offset-calculation, bit-arithmetic etc., with the nasty side effect of massive register pressure negatively impacting assembly of the surrounding logic. Add to that overhead from loosing the ability to use any form of vector instruction, due to unsuitable alignment. Minimal sensible alignment for the structure is 16 byte, anything other than a multiple of that comes with several severe catches. Also 18 bits for X and Y combined? How far do you think you can get with a range of 0-512 in either direction? Update logic does not stop at the edge of a chunk.

Furthermore, there still isn't a sensible memory layout in most cases. Serializing by depth first traversal order of spanning tree is already as good as it gets, and even that only performs well in very few scenarios like main-bus etc. And whenever some entity updates, you have to rebuild the tree, reorder the components, inform the owning entities that their components memory locations just shifted, and generally accept the limitation that you can now never again hand out a pointer / index into the component storage without living in constant fear about index invalidation issues. Meaning, now you can't even establish a proper linked data structure within a component type, without bouncing back via the owning entity!

• Each tick; check if the inserter has a burner energy source. If it does:
  • Check if the energy source is completely empty and go to sleep if so (no fuel, can't move fuel into itself since it can never move).
  • Check if the item in the inserter hand can be used as fuel for this inserter. If it can:
  • Move the hand towards the inserter itself.

Every save file I've tested ended up running measurably faster in the end. The most extreme one (lots of steel furnace based smelting) showed a 2.3x speed-up.

bleistift2 wrote: ↑

Mon Dec 09, 2019 1:16 am

I never knew burner inserters could feed themselves That adds some real usefulness to them!

MrGrim wrote: ↑

Fri Dec 06, 2019 2:47 pm

Holy crap, what a FFF! It's like you guys read my mind and got to all of the things I could have hoped for all in one week!

If I could just ask one more tiny thing. With the sound redesign, could the "listener" be changed to the engineer instead of the camera? I spend so much of my time fully zoomed out, and I fear I'll miss out on all of this great sound work. It feels very odd while playing that sounds don't play in relation to my avatar.

Thank you!

factoriouzr wrote: ↑

Fri Dec 06, 2019 5:55 pm

This is all great. Good work everyone.

With this new even framework, can you please implement the ability to set not yet researched recipes on factories especially from blueprints. It often happens that we have many blueprints built up in our library for many different things over the many many games we have played. When playing again, your research order will not be the same as last time and when you put down a blueprint, anything that is not yet researched will not be set on the factories in the blueprint. This is not intuitive and behaves differently then everything else set from blueprints (viewtopic.php?f=6&t=28954).

Also it's good to have tree animations and it looks better then not having them, but somehow they still look a bit like just using a noise function and not the actual leaves moving. It looks like a distortion filter was just applied to slightly pull and push parts of the tree sprite.

Thanks

Ormy wrote: ↑

Tue Dec 10, 2019 10:59 am

MrGrim wrote: ↑

Fri Dec 06, 2019 2:47 pm

[…] If I could just ask one more tiny thing. With the sound redesign, could the "listener" be changed to the engineer instead of the camera? […]

Please Devs if you are going to implement this suggestion make it a toggle-able option, I do not want to always hear the sounds from the engineers perspective. […]

Trebor wrote: ↑

Mon Dec 09, 2019 7:22 pm

bleistift2 wrote: ↑

Mon Dec 09, 2019 1:16 am

I never knew burner inserters could feed themselves That adds some real usefulness to them!

This why many backup steam power units incorporate them, they will startup on their one once fuel is restored.

coppercoil wrote: ↑

Sun Dec 08, 2019 9:41 pm

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

bobucles wrote: ↑

Thu Dec 12, 2019 7:33 pm

While unpacking a multi purpose variable may be fast, it still takes time.

bobucles wrote: ↑

Thu Dec 12, 2019 7:33 pm

coppercoil wrote: ↑

Sun Dec 08, 2019 9:41 pm

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

There's always a way to trade off between CPU cycles and memory storage. There's even some proof of concept FPS games that fit all their content into a 200kB executable. I'd try uploading it but the entire game is buried somewhere in my archives.

Pinching pennies does not always mean improved performance. While unpacking a multi purpose variable may be fast, it still takes time. During that time the other pieces of that variable require special treatment, and then it has to be repacked when it's done. That's a lot of extra baggage to save what? A byte here, a byte there? Save that kind of effort for micro architectures like AVR, where every single byte is a precious resource.

It won't even be equally effective across all PCs, since you're starting with an assumption that every computer has a fixed amount of CPU power per RAM power. A 16 core monster can happily trade a mountain of CPU cycles for a pinch of RAM all day, but a dual core system will get annihilated by the same exchange rate. It's a nasty game to play and ultimately there are superior places to save performance.

Shingen wrote: ↑

Fri Dec 06, 2019 12:32 pm

This is another nice example of "Factorio is not CPU bound, it's memory latency bound". More cores wasn't going to make this faster - because it was never limited by how fast the CPU ran.

uhh what? no.
more cores weren't going to make this faster, because no N-threaded program will run faster if you just "throw more cores at it" (i.e. if you already have N cores and add more).
number of cores != speed of the CPU.

and another thing:

1 of the 3 always takes significantly longer to finish than the others. That means that the others end up being essentially "free"; the game has to wait for the slowest to be finished anyway so the faster 2 of the 3 get a "free ride" to finish long before game finishes waiting for the slowest to be done.

i don't know what you mean by "free ride", they're still being computed, it's all weirdly worded.

if one of them takes significantly longer than the other 2, how about make it run parallel to the other 2 being run sequentially?
as in:

Code: Select all

------1------->
--2--> --3-->

this way they won't compete as hard for resources - however, of course, overall they will compete for a bit longer

------1a------->------1i------->
------1b------->------1j------->
------1c------->------1k------->
------1d------->------1l------->
------1e------->------1m------->
------1f------->------1n------->
------1g------->--2a-->--2b-->
------1h------->--3a-->--3b-->

bobucles wrote: ↑

Thu Dec 12, 2019 7:33 pm

coppercoil wrote: ↑

Sun Dec 08, 2019 9:41 pm

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

There's always a way to trade off between CPU cycles and memory storage. There's even some proof of concept FPS games that fit all their content into a 200kB executable. I'd try uploading it but the entire game is buried somewhere in my archives.

coppercoil wrote: ↑

Thu Dec 12, 2019 8:41 pm

bobucles wrote: ↑

Thu Dec 12, 2019 7:33 pm

While unpacking a multi purpose variable may be fast, it still takes time.

Cache misses takes much more time. Even hyperthreading was born

Dualcore system shouldn't be considered as primary dev's target. Does anybody care about Android 4.4? They still exists...

mrvn wrote: ↑

Fri Dec 13, 2019 11:52 am

Shingen wrote: ↑

Fri Dec 06, 2019 12:32 pm

1 of the 3 always takes significantly longer to finish than the others. That means that the others end up being essentially "free"; the game has to wait for the slowest to be finished anyway so the faster 2 of the 3 get a "free ride" to finish long before game finishes waiting for the slowest to be done.

i don't know what you mean by "free ride", they're still being computed, it's all weirdly worded.

if one of them takes significantly longer than the other 2, how about make it run parallel to the other 2 being run sequentially?
as in:

Code: Select all

------1------->
--2--> --3-->

this way they won't compete as hard for resources - however, of course, overall they will compete for a bit longer

No, go the other way. Figure out which subsets of 1, 2 and 3 don't interact with each other and then do

Code: Select all

------1a------->------1i------->
------1b------->------1j------->
------1c------->------1k------->
------1d------->------1l------->
------1e------->------1m------->
------1f------->------1n------->
------1g------->--2a-->--2b-->
------1h------->--3a-->--3b-->

prodacc wrote: ↑

Wed Dec 18, 2019 6:04 am

Any sign of the patches coming back into stock?