Friday Facts #206 - Workflow optimisation

Regular reports on Factorio development.

Re: Friday Facts #206 - Workflow optimisation

Postby tom.i » Sat Sep 02, 2017 4:33 pm

Oh jesus, finally, replace function, I love you guys !!!
tom.i
Burner Inserter
Burner Inserter
 
Posts: 5
Joined: Sun Apr 23, 2017 7:20 am

Re: Friday Facts #206 - Workflow optimisation

Postby 5thHorseman » Sat Sep 02, 2017 9:23 pm

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.
Image Laziest Bastard Mod or Let's Play Image
"So you launched a rocket in a spaghetti factory? Well I hand crafted a rocket and threw it into space with my bare hands!"
User avatar
5thHorseman
Filter Inserter
Filter Inserter
 
Posts: 279
Joined: Fri Jun 10, 2016 11:21 pm

Re: Friday Facts #206 - Workflow optimisation

Postby genericname1 » Sun Sep 03, 2017 5:14 am

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
genericname1
Burner Inserter
Burner Inserter
 
Posts: 15
Joined: Fri May 22, 2015 12:55 pm

Re: Friday Facts #206 - Workflow optimisation

Postby posila » Sun Sep 03, 2017 7:39 am

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.
posila
Factorio Staff
Factorio Staff
 
Posts: 2043
Joined: Thu Jun 11, 2015 1:35 pm

Re: Friday Facts #206 - Workflow optimisation

Postby CardingiSFun » Sun Sep 03, 2017 9:03 am

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...
CardingiSFun
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Sat Aug 12, 2017 8:51 am

Re: Friday Facts #206 - Workflow optimisation

Postby Chaia » Sun Sep 03, 2017 12:03 pm

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.
Chaia
Inserter
Inserter
 
Posts: 27
Joined: Fri Jul 19, 2013 1:53 pm

Re: Friday Facts #206 - Workflow optimisation

Postby Darci of Mountain » Sun Sep 03, 2017 12:10 pm

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!
Darci of Mountain
Manual Inserter
Manual Inserter
 
Posts: 4
Joined: Wed Oct 19, 2016 12:37 am

Re: Friday Facts #206 - Workflow optimisation

Postby eXophobia » Sun Sep 03, 2017 1:14 pm

kovarex wrote:https://www.factorio.com/blog/post/fff-206

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/
User avatar
eXophobia
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Wed Mar 16, 2016 7:08 pm

Re: Friday Facts #206 - Workflow optimisation

Postby hoho » Sun Sep 03, 2017 1:28 pm

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.
hoho
Filter Inserter
Filter Inserter
 
Posts: 704
Joined: Sat Jan 18, 2014 11:23 am

Re: Friday Facts #206 - Workflow optimisation

Postby malventano » Sun Sep 03, 2017 6:25 pm

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
Editor, PC Perspective
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.
malventano
Fast Inserter
Fast Inserter
 
Posts: 159
Joined: Thu Apr 27, 2017 4:31 pm

Re: Friday Facts #206 - Workflow optimisation

Postby malventano » Sun Sep 03, 2017 6:37 pm

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
Editor, PC Perspective
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.
malventano
Fast Inserter
Fast Inserter
 
Posts: 159
Joined: Thu Apr 27, 2017 4:31 pm

Re: Friday Facts #206 - Workflow optimisation

Postby Mooncat » Mon Sep 04, 2017 2:21 am

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)
User avatar
Mooncat
Smart Inserter
Smart Inserter
 
Posts: 1163
Joined: Wed May 18, 2016 4:55 pm

Re: Friday Facts #206 - Workflow optimisation

Postby ToASter » Mon Sep 04, 2017 6:37 am

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...
ToASter
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Sun Sep 03, 2017 4:32 am

Re: Friday Facts #206 - Workflow optimisation

Postby Rseding91 » Mon Sep 04, 2017 7:46 am

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 IRC and Discord.
Rseding91
Factorio Staff
Factorio Staff
 
Posts: 6374
Joined: Wed Jun 11, 2014 5:23 am

Re: Friday Facts #206 - Workflow optimisation

Postby yohannc » Mon Sep 04, 2017 8:13 am

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)
yohannc
Burner Inserter
Burner Inserter
 
Posts: 7
Joined: Thu Jul 27, 2017 9:33 am

Re: Friday Facts #206 - Workflow optimisation

Postby ToASter » Mon Sep 04, 2017 5:36 pm

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.
ToASter
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Sun Sep 03, 2017 4:32 am

Re: Friday Facts #206 - Workflow optimisation

Postby ske » Mon Sep 04, 2017 6:47 pm

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
Fast Inserter
Fast Inserter
 
Posts: 232
Joined: Sat Oct 17, 2015 8:00 am

Re: Friday Facts #206 - Workflow optimisation

Postby ske » Mon Sep 04, 2017 6:49 pm

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"?
ske
Fast Inserter
Fast Inserter
 
Posts: 232
Joined: Sat Oct 17, 2015 8:00 am

Re: Friday Facts #206 - Workflow optimisation

Postby PunkSkeleton » Mon Sep 04, 2017 7:29 pm

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.
PunkSkeleton
Inserter
Inserter
 
Posts: 38
Joined: Sun Oct 09, 2016 2:10 pm

Re: Friday Facts #206 - Workflow optimisation

Postby mcwaffles2003 » Tue Sep 05, 2017 9:08 am

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
mcwaffles2003
Inserter
Inserter
 
Posts: 29
Joined: Wed Feb 01, 2017 7:56 pm

PreviousNext

Return to News

Who is online

Users browsing this forum: oi_wtf and 3 guests