I would argue that even if it is on the screen, the user would not notice it. AT least I run Fractorio on quite a large screen (1920x1920 resolution) and I am NOT having my attention on most of the things I see there, particularly when zoomed out a little. I am mostly focused on the small area around my avatar when building.Mekronid wrote:I'm aware, but to be frank, subtlety costs CPU time. Look at it from a mathematical standpoint: belts' throughput is a fixed value, production is a fixed value, and inserters' throughput is a fixed value. Rotation and elongation speeds should be fixed values as well. Any variation in the above should be due to three things: power (predictable), boosts (predictable), and random chance (random). Because there is only one source of randomness, the difference over time caused by any subtleties should result in a reversion to the mean. Reversion to the mean is the rule that says any series of random events with a fixed probability will eventually converge on an average distribution.Lubricus wrote:Factorio is more subtle than that, inserters don't just have a pick up speed, they have a rotation and elongation speeds so the order, placements and how clumped the items is on the belt will have an effect on the speed of the inserters. Then everything also have to be perfectly deterministic so simplifications "on the fly" would be problematic.
I've found there's often a complicated way that looks nice on screen and there's an elegant way that looks nice to the computer's hardware. If the player isn't gonna see it, and we know the math averages out, then the little subtleties only serve to bog down the CPU. By doing this you separate the probabilistic math from the synchronous calculations, thereby allowing for more effective multithreading.
Some related trivia: removing a progress bar from some resource-intensive applications can drastically speed up execution speed. Positioning and rendering takes up an asston of processing time when being used synchronously on backend code. Hence why some programs nowadays (notably, several operating systems, especially if no video drivers are loaded) don't have functional progress bars.
Friday Facts #215 - Multithreading issues
Re: Friday Facts #215 - Multithreading issues
Re: Friday Facts #215 - Multithreading issues
And what has that got to do with creating threads or reusing them?PunkSkeleton wrote:It doesn't matter how long it takes to create a thread. It just throws away the L1 and L2 caches. I was recently able to almost quadruple the throughput of multi-threaded system by getting rid of thread migrations from core to core.
Note: if you can make one thread per core and stick with that then locking each thread to one core is usually a good idea. And then each tick give the same job to the same thread every time. Although given the memory size of factorio the cache hits between ticks are probably minimal.