Friday Facts #206 - Workflow optimisation

Regular reports on Factorio development.
tom.i
Burner Inserter
Burner Inserter
Posts: 10
Joined: Sun Apr 23, 2017 7:20 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by tom.i »

Oh jesus, finally, replace function, I love you guys !!!

User avatar
5thHorseman
Smart Inserter
Smart Inserter
Posts: 1193
Joined: Fri Jun 10, 2016 11:21 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by 5thHorseman »

I see a lot of people worried that "you can replace yellow splitters with yellow belts" means "you can't blanket replace yellow belts with red belts, because they'll also replace the yellow splitters."

I don't see why this has to be the case at all. Why can't they allow you to replace all 3 yellow belt types with the other belt types of the same color, but only allow you to cross colors, not types?

So, a yellow belt will be replacable by a yellow splitter, a yellow underground, a red belt, or a blue belt. Only.

This would give us the new functionality but not remove the functionality we have now.

genericname1
Burner Inserter
Burner Inserter
Posts: 16
Joined: Fri May 22, 2015 12:55 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by genericname1 »

Since I work with servers all day here are a few suggestions.

1) stop buying consumer grade hardware!
2) go and buy a datacentre grade SSD. They tend to come rated for a number of drive writes per day - 3 dwpd is the full capacity of the drive written 3 times a day every day for several years. Generally several petabytes of data
3) look at nvme (Intel make some lovely pci ssds, 1gigabyte/s read speeds etc)
4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by posila »

genericname1 wrote:4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash
Half of the build time (or maybe even more now) is due to linking which is just single thread.

CardingiSFun
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sat Aug 12, 2017 8:51 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by CardingiSFun »

I say instead of placing the belts on the underground belt just be able to place a belt on one side of the underground and it automatically replaces the full length with the belt. Some QOL researches like Inventory Size, Crafting Speed In Inventory, Etc...

Chaia
Inserter
Inserter
Posts: 27
Joined: Fri Jul 19, 2013 1:53 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by Chaia »

5thHorseman wrote:I see a lot of people worried that "you can replace yellow splitters with yellow belts" means "you can't blanket replace yellow belts with red belts, because they'll also replace the yellow splitters."

I don't see why this has to be the case at all. Why can't they allow you to replace all 3 yellow belt types with the other belt types of the same color, but only allow you to cross colors, not types?

So, a yellow belt will be replacable by a yellow splitter, a yellow underground, a red belt, or a blue belt. Only.

This would give us the new functionality but not remove the functionality we have now.
This sound like a solid idea. It will help avoiding switching splitters while upgrading by accident without making the planned replace-feature less intuitive.

Darci of Mountain
Burner Inserter
Burner Inserter
Posts: 7
Joined: Wed Oct 19, 2016 12:37 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by Darci of Mountain »

kovarex wrote:
Ratzap wrote:Now all stock needs is the functionality from 'Upgrade planner'. Manually replacing yellow transport then red later in my sotck save is soooo tedious and error prone.
It is not on our to do list, but I like the idea of Upgrade planner, so it might become vanilla future some day.
Sadly the only thing that came up into my mind was "Wow, It will be a real nuisance without Klonan's upgrade planner...", thing is, First I do upgrade all the splitters, then the undergrounds, then I just run around up and down placing belts going through whatever is there, now, with the new feature it means I have to be careful to not destroy all the balancers and stuff replacing splitters and whatnots with regular belts...
Please, we beg you, the Upgrade Planner should go vanilla.

Not so related question, what happens to the stuff on belts/splitters/undergrounds when quick replaced? Just go to the inventory?

Thanks for the great game, community and for all of you devs being what you are. Great game, great team!

User avatar
eXophobia
Manual Inserter
Manual Inserter
Posts: 2
Joined: Wed Mar 16, 2016 7:08 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by eXophobia »

Hey there
I've written a slightly longer response regarding compilation time over at the Steams. Copying the post might just clutter this thread so I'll just link it here:
http://steamcommunity.com/app/427520/di ... 195431745/

hoho
Filter Inserter
Filter Inserter
Posts: 677
Joined: Sat Jan 18, 2014 11:23 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by hoho »

posila wrote:
genericname1 wrote:4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash
Half of the build time (or maybe even more now) is due to linking which is just single thread.
Would splitting the executable to several dlls/so's help?

Of course, it wouldn't help with full rebuild and if you alter some piece of code that affects everything but I would imagine if one works on something that effects a small piece of code, linking should be faster than linking one big executable.

malventano
Filter Inserter
Filter Inserter
Posts: 340
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by malventano »

Lappro wrote:I'm curious about the reasoning why you've chosen to upgrade your dev machines to i9s. Is there a reason threadripper didn't make it or was it never considered? At a quick glance it looks like you could've gotten 6 cores/12 threads more for the same price.

Either way great FFF again, nice combination of news for the average player as well as some nice in-depth behind the scenes stuff.
Lower IPC on Ryzen, and Factorio performance is more reliant on single threaded performance.
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

malventano
Filter Inserter
Filter Inserter
Posts: 340
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by malventano »

genericname1 wrote:Since I work with servers all day here are a few suggestions.

1) stop buying consumer grade hardware!
2) go and buy a datacentre grade SSD. They tend to come rated for a number of drive writes per day - 3 dwpd is the full capacity of the drive written 3 times a day every day for several years. Generally several petabytes of data
3) look at nvme (Intel make some lovely pci ssds, 1gigabyte/s read speeds etc)
4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash
1. The consumer grade hardware has higher clocks / fewer cores, which benefits Factorio run speed. Compiles may take a few more seconds with fewer cores, but the game needs to run quickly.
2. Datacenter SSDs are not tuned for client workloads. Compiles are not really a datacenter class workload and even though they are heavy on writes, a modern client SSD will likely perform better overall.
3. Intel PCIe SSDs, while great for random writes, actually have relatively poor random read performance, which is critical for compile times.
4. Agreed on that point. I would have recommended 7700k's as they can easily achieve 5GHz overclocks and would likely build Factorio faster than a stock i9, not to mention the 7700k is likely the best performing CPU for Factorio overall as it has the much lower latency to the DRAM compared to i9's, so cache misses have less of a penalty. 14 core Xeon's might be better for build times but would not perform as well in the game.
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

User avatar
Mooncat
Smart Inserter
Smart Inserter
Posts: 1190
Joined: Wed May 18, 2016 4:55 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by Mooncat »

I'm sure I will love the new features!
Regarding to transport belts, is this suggestion on the todo list?
Conveyor Belt Auto-Direction
(Auto rotate transport belts as long as mouse button is pressed)

ToASter
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Sep 03, 2017 4:32 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by ToASter »

The result is, that changing boost::mpl::vector66 to std::variant can improve the compile time from 1:44 to 1:20 and getting rid of templates completely by using unions can decrease the compile time to 0:53.
Ho did you realize that it was boost which adds that much time to the compilation?
in a project with 3390 files, 410k lines of code and 15Mb of source code
I guess in such a big project its hard to put fingers on 2 files easily.....also because of from what you said i think you are using boost in much more places...

Rseding91
Factorio Staff
Factorio Staff
Posts: 13171
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by Rseding91 »

ToASter wrote:Ho did you realize that it was boost which adds that much time to the compilation?
I tested replacing boost::variant with std::variant when trying new C++17 features because every time I look into the internals of a boost class implementation it makes me sad at how poorly written it is.
If you want to get ahold of me I'm almost always on Discord.

yohannc
Inserter
Inserter
Posts: 30
Joined: Thu Jul 27, 2017 9:33 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by yohannc »

Great fff, as always, so interesting and appealing ! Realy, it's like reading a book, and you wait for next chapter every friday !

But can i give a suggestion about replacement belts ?

An upgrade key could be helpfull, when you press this key, under cursor (work by dragging too) :
- yellow belt is replaced by red belt
- red belt by blue belt
- yellow inserter by blue inserter
- grey factory by blue factory
- etc

(and until the key is not released, all upgraded items should be kept in memory to avoid upgrading them twice, like underground belt)

ToASter
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Sep 03, 2017 4:32 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by ToASter »

Rseding91 wrote: I tested replacing boost::variant with std::variant when trying new C++17 features because every time I look into the internals of a boost class implementation it makes me sad at how poorly written it is.
Wow. So it was just by chance.

ske
Filter Inserter
Filter Inserter
Posts: 411
Joined: Sat Oct 17, 2015 8:00 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by ske »

Rseding91 wrote:I can answer that one: Rust sounds interesting at first but places *way* too many restrictions on what you can do such that I would venture to say it's impossible to write any reasonably sane program with it without having to use the "just let me do it" "unsafe" option all over the place defeating the so-called advantages it's meant to give.

Regarding segfaults/off-by-one errors: no. Those are C problems and we write modern C++ - memory leaks/off-by-one errors are a symptom of someone using C++ as C - and a sign that they aren't a good developer. Those problems were solved long ago around when the C++ 11 standard was finished in 2011.
Thanks for that answer. I've not used Rust first-hand but have some experience in C++11 and rarely encountered the problems people usually complain about. Sure, it's ugly in so many ways but on the other hand it seems to be the only game in town when digging down to the bare metal. Rust might change that but we'll see. It might be time to get some real Rust experience on microcontrollers.

ske
Filter Inserter
Filter Inserter
Posts: 411
Joined: Sat Oct 17, 2015 8:00 am
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by ske »

Rseding91 wrote:
ToASter wrote:Ho did you realize that it was boost which adds that much time to the compilation?
I tested replacing boost::variant with std::variant when trying new C++17 features because every time I look into the internals of a boost class implementation it makes me sad at how poorly written it is.
Is it "poor" or "sophisticated beyond human comprehension"?

PunkSkeleton
Long Handed Inserter
Long Handed Inserter
Posts: 82
Joined: Sun Oct 09, 2016 2:10 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by PunkSkeleton »

hoho wrote:
posila wrote:
genericname1 wrote:4) if your build process could use more than one core rather than the insanely expensive i9 you could have had a 14 core xeon for a similar amount of cash
Half of the build time (or maybe even more now) is due to linking which is just single thread.
Would splitting the executable to several dlls/so's help?

Of course, it wouldn't help with full rebuild and if you alter some piece of code that affects everything but I would imagine if one works on something that effects a small piece of code, linking should be faster than linking one big executable.
I don't know if it's feasible for production (I don't do big projects in C++) build, I guess they would have did it long ago if it would help. Compilation times are huge for many C++ projects, not only in video game industry.
Anyway for development you may try to use preloading:
https://stackoverflow.com/questions/341 ... ss-methods
So for example when working on stack optimisation you:
1. Compile the basic game once.
2. Create a separate file with new versions of replaced methods.
3. Compile this file.
4. Run the game with this file preloaded.

Then every next compilation is just steps 3 and 4. Then you don't have to make commits like "now I can split stacks" because all you do during development is "hacking" into the code by preloading some methods.

mcwaffles2003
Inserter
Inserter
Posts: 30
Joined: Wed Feb 01, 2017 7:56 pm
Contact:

Re: Friday Facts #206 - Workflow optimisation

Post by mcwaffles2003 »

will oil derricks actually have chirality?

2 derricks in that pick are different from the other 2 derricks, or did you guys just edit that?

also, please do the non joining pipes.... it would make the world easier

Post Reply

Return to “News”