ARM architecture

Post all other topics which do not belong to any other category.
quadrox
Long Handed Inserter
Long Handed Inserter
Posts: 73
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: 73
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: 109
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: 901
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: 5147
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: 2338
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.

User avatar
Stargateur
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sat Oct 05, 2019 6:17 am
Contact:

Re: ARM architecture

Post by Stargateur »

It's was my understanding that factorio change its server, now it's should be not a problem to have a server on whatever machine. I wonder what could block to just try to have a build for ARM ?

(I'm disappointed cause I buy a raspberry pi 4B, 8go of ram, and I wanted to put some server on it, well not factorio I guess :p)

<insert here a US candatate> I ask once again for your charity

nr2117
Long Handed Inserter
Long Handed Inserter
Posts: 52
Joined: Tue Dec 13, 2016 9:24 pm
Contact:

Re: ARM architecture

Post by nr2117 »

would be interesting to see if it can be done, like "running doom on an X".

Anyone remember the transmeta CPU's? I was told theyw eren't x86, but emulated x86 so windows and linux could be run on it. A friend had a laptop with a 1ghz chip in, he reckoned it was equivalent to a 500mhz pentium 3. This was in, 2002? I thought that was impressive for the era.

hvenev
Manual Inserter
Manual Inserter
Posts: 2
Joined: Mon Dec 09, 2019 11:33 am
Contact:

Re: ARM architecture

Post by hvenev »

My 60 SPM factory runs at 30 UPS (headless) on a Pi 4 with qemu.

Breizh
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Apr 04, 2021 4:13 pm
Contact:

Re: ARM architecture

Post by Breizh »

I’m running a server on an Intel(R) Atom(TM) CPU N2800 @ 1.86GHz without problem for ~10 players, so I think that an ARM server on an Odroid N2 for example, which is more powerful than the Intel CPU mentioned could be worth it. And modern Raspberry Pi (3 or 4, in 64-bits) could probably run the game without problem too, at least until the firsts rockets (didn’t try to make megabases on this server at this moment).

Gummiente27
Inserter
Inserter
Posts: 35
Joined: Mon Jul 16, 2018 2:59 am
Contact:

Re: ARM architecture

Post by Gummiente27 »

The problem wirth supporting ARM is that factorio source contains handwritten optimized x86-assembly.

astroshak
Filter Inserter
Filter Inserter
Posts: 514
Joined: Thu May 10, 2018 9:59 am
Contact:

Re: ARM architecture

Post by astroshak »

Always expect an ARM to go up. (That’s what Adjustable Rate Mortgages do, eventually.)

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

Re: ARM architecture

Post by Jap2.0 »

Gummiente27 wrote:
Wed Mar 02, 2022 9:34 pm
The problem wirth supporting ARM is that factorio source contains handwritten optimized x86-assembly.
To the best of my knowledge it does not, from what I've gathered the main reasons against supporting ARM are low market share and ensuring determinism.
There are 10 types of people: those who get this joke and those who don't.

Gummiente27
Inserter
Inserter
Posts: 35
Joined: Mon Jul 16, 2018 2:59 am
Contact:

Re: ARM architecture

Post by Gummiente27 »

Jap2.0 wrote:
Tue Mar 08, 2022 2:49 am
Gummiente27 wrote:
Wed Mar 02, 2022 9:34 pm
The problem wirth supporting ARM is that factorio source contains handwritten optimized x86-assembly.
To the best of my knowledge it does not, from what I've gathered the main reasons against supporting ARM are low market share and ensuring determinism.
I remember that some FFF talked about assembly being used, but that might've been replaced.

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

Re: ARM architecture

Post by Jap2.0 »

Gummiente27 wrote:
Wed Mar 09, 2022 2:18 pm
Jap2.0 wrote:
Tue Mar 08, 2022 2:49 am
Gummiente27 wrote:
Wed Mar 02, 2022 9:34 pm
The problem wirth supporting ARM is that factorio source contains handwritten optimized x86-assembly.
To the best of my knowledge it does not, from what I've gathered the main reasons against supporting ARM are low market share and ensuring determinism.
I remember that some FFF talked about assembly being used, but that might've been replaced.
Per here (and others) they'll look at the assembly produced by various pieces of code occasionally, but don't write it by hand.
There are 10 types of people: those who get this joke and those who don't.

8x13b
Manual Inserter
Manual Inserter
Posts: 3
Joined: Sun May 29, 2022 10:55 pm
Contact:

[Arm64 Linux Server] Running in ARM64 using Box64

Post by 8x13b »

Hello!

I would like to share how I am running a Factorio server on ARM64 and my struggles, so maybe one of you can help me. I am using an Oracle Ampere A1 server, quad-core, 24G RAM.

Benchmarks (Geekbench 5.4.0):
Single-Core Score: 870
Multi-Core Score: 3368

For comparison, here is an i5-7500 quad-core. Decent CPU.
Single-Core Score: 972
Multi-Core Score: 3285

Not that big of a difference.

The server is more than capable of running Factorio, however, since there isn't an ARM64 native build I am stuck with a compatibility layer (kinda like wine but for CPU architectures) called box64. It came at a big cost of performance. My guess is that since the Factorio build is statically linked, box64 can't find the native libraries to use, and has to use the interpreted version included in the binary.

If the developers want to maybe try to fix this issue as easily as possible, dynamically linking the headless binary may help.

If the developers want to compile this game for ARM, Oracle Ampere A1 servers are free forever, and, maybe a Raspberry Pi can be used as a small server for a small group of friends \:P

Forgot to add, but I get a *lot* of desyncs and CatchUp errors with box64 on the server.

8x13b
Manual Inserter
Manual Inserter
Posts: 3
Joined: Sun May 29, 2022 10:55 pm
Contact:

Re: ARM architecture

Post by 8x13b »

box64 seems to be the easiest way for developers to support Factorio on ARM.

Nidan
Long Handed Inserter
Long Handed Inserter
Posts: 96
Joined: Sat Nov 21, 2015 1:40 am
Contact:

Re: [Arm64 Linux Server] Running in ARM64 using Box64

Post by Nidan »

8x13b wrote:
Mon May 30, 2022 10:46 pm
box64 seems to be the easiest way for developers to support Factorio on ARM.
Are you sure? Since you also wrote
8x13b wrote:
Sun May 29, 2022 11:19 pm
Forgot to add, but I get a *lot* of desyncs and CatchUp errors with box64 on the server.
It might be useful to provide some desync reports here so someone (not me) can analyze them to see why the game desynced. My bet is on box64 having problems with floating point rounding.


Back to the first quote: Providing an ARM build is the easy part. I recently had the task of making our product run on ARM. Most of my time was spent on OS-level stuff (which wouldn't matter for factorio). In our actual code I had to fix a grand total of one compile error, which is certainly less than I expected in a code base ranging from ancient C++-in-name-only to modern C++20.

The hard part is supporting it and making sure it doesn't desync.

Post Reply

Return to “General discussion”