ARM architecture

Post all other topics which do not belong to any other category.
quadrox
Long Handed Inserter
Long Handed Inserter
Posts: 72
Joined: Tue Apr 05, 2016 9:09 am
Contact:

Re: ARM architecture

Post by quadrox »

Since sharing state between threads is an issue for parallellism, wouldn't it be possible to make each thread use the previous state as input? Since the state from the previous tick will no longer be updated, it can safely be shared across threads. This would introduce a tiny amount of lag before collisions and similar would be resolved, but should otherwise work fine.

As for collisions, they will only be detected after the fact and the previous position should be restored, but this should not matter much. I am somewhat confident that other special cases could be resolved as well (e.g. two inserters inserting into the same chest with only one slot left, etc.) through a small amount of clever code (e.g. inserters reserving a slot before inserting). Some of these tricks would reduce performance slightly, but the net gain should still be positive.

This would preserve determinism 100%. As I don't have access to the codebase, I can't show off a prototopye implementation though :)

EDIT: My inserter example would, in fact, not preserve determinism. hmm... I suppose you could implement a priority system based on the id/memory address of the involved objects. The higher/lower number wins the race, and the other must restore previous state.

Please note that I am not saying this should be implemented, I just can't help trying to come up with solutions to problems :) Implementing something like this would most likely require a huge amount of effort, and the gains remain questionable.

ratchetfreak
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: ARM architecture

Post by ratchetfreak »

quadrox wrote:Since sharing state between threads is an issue for parallellism, wouldn't it be possible to make each thread use the previous state as input? Since the state from the previous tick will no longer be updated, it can safely be shared across threads. This would introduce a tiny amount of lag before collisions and similar would be resolved, but should otherwise work fine.

As for collisions, they will only be detected after the fact and the previous position should be restored, but this should not matter much. I am somewhat confident that other special cases could be resolved as well (e.g. two inserters inserting into the same chest with only one slot left, etc.) through a small amount of clever code (e.g. inserters reserving a slot before inserting). Some of these tricks would reduce performance slightly, but the net gain should still be positive.

This would preserve determinism 100%. As I don't have access to the codebase, I can't show off a prototopye implementation though :)

EDIT: My inserter example would, in fact, not preserve determinism. hmm... I suppose you could implement a priority system based on the id/memory address of the involved objects. The higher/lower number wins the race, and the other must restore previous state.

Please note that I am not saying this should be implemented, I just can't help trying to come up with solutions to problems :) Implementing something like this would most likely require a huge amount of effort, and the gains remain questionable.
It's possible but will increase the memory footprint and require quite a bit of duplicate calculations.

Or some extra lag.

For example an inventory can check which inserters are trying to pull from it and then assign the stack they pull as appropriate. The next tick the inserter sees what it pulled and then goes to deposit to the destination.

There is also the option to use message queues, each entity has a message queue that can be pushed to each tick from any thread. The next tick it will sort the messages deterministically and then process them, possibly sending out messages of its own. In this method a pull from an inventory would be a multi stage process: first the inserter sends WantToPull (possible detailing which items can be pulled), then the inventory gets the message and checks whether the pull request can be handled. After it completes it'll send a reply PullSucceeded with the details of the item pulled.

quadrox
Long Handed Inserter
Long Handed Inserter
Posts: 72
Joined: Tue Apr 05, 2016 9:09 am
Contact:

Re: ARM architecture

Post by quadrox »

ratchetfreak wrote:
It's possible but will increase the memory footprint and require quite a bit of duplicate calculations.
Absolutely!
ratchetfreak wrote: Or some extra lag.
With an update frequency of 60Hz, lagging for one tick should not be noticeable.
ratchetfreak wrote: For example an inventory can check which inserters are trying to pull from it and then assign the stack they pull as appropriate. The next tick the inserter sees what it pulled and then goes to deposit to the destination.
Yeah, this could work quite well I imagine.
ratchetfreak wrote: There is also the option to use message queues, each entity has a message queue that can be pushed to each tick from any thread. The next tick it will sort the messages deterministically and then process them, possibly sending out messages of its own. In this method a pull from an inventory would be a multi stage process: first the inserter sends WantToPull (possible detailing which items can be pulled), then the inventory gets the message and checks whether the pull request can be handled. After it completes it'll send a reply PullSucceeded with the details of the item pulled.
I think such a solution would be too heavy, both memory and performance wise. But yeah, possible.

ratchetfreak
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: ARM architecture

Post by ratchetfreak »

there is another factor to consider

A thread-safe engine like that would need a specialized moding api that can only read and request changes to entities getting the success value through a callback the next tick. The current one won't work or be the major bottleneck.

Arakasi
Fast Inserter
Fast Inserter
Posts: 108
Joined: Tue Feb 26, 2013 9:43 pm
Contact:

Re: ARM architecture

Post by Arakasi »

Hello Devs,

years passed and I would ask again, whether any ARM version is planned or not. Since v0.16 received portion of optimizations and in v0.17 more may come, the situation could have changed.

Thanks

nuhll
Filter Inserter
Filter Inserter
Posts: 830
Joined: Mon Apr 04, 2016 9:48 pm
Contact:

Re: ARM architecture

Post by nuhll »

If i read some posts about factorio performance correct, it isnt so hard the CPU, mostly RAM Bandwidth.. i dont know how good that is on rasp, but i guess, its crap.

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

Re: ARM architecture

Post by posila »

No plans to support ARM version.

Jap2.0
Smart Inserter
Smart Inserter
Posts: 2211
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: ARM architecture

Post by Jap2.0 »

Arakasi wrote:Hello Devs,

years passed and I would ask again, whether any ARM version is planned or not. Since v0.16 received portion of optimizations and in v0.17 more may come, the situation could have changed.

Thanks
I'd say probably not. It's not something they've ever announced, there isn't much demand (they're not supporting mobile and PCs generally aren't ARM). CPUs in Raspberry Pis are meh at best (they'd never run a megabase above 1 UPS), they only have 1GB RAM (so it's questionable whether you could run the game in the first place), and, as nuhll pointed out, RAM latency/bandwidth is... bad. Really bad. With a lot of overclocking, you can get it to reach 600 MHz, which is (iirc) somewhere around the performance of DDR2.

Also, Posila confirmed that in the time I took writing this (and reading Wikipedia).
There are 10 types of people: those who get this joke and those who don't.

Post Reply

Return to “General discussion”

Who is online

Users browsing this forum: Qon