ARM Build

[selbie]

Dear developers,

I enjoy playing factorio, and I actually own a CubieTruck also known as (cubieboard 3). (DualCore 1GHz, 2GB ram)
This board is running linux debian based on ARM. I use this board for a small homeserver and I would like to run a small factorio server on it.
But since there is no executable for ARM I would need to do some visualization which isn't the best option.

I know more people have asked about it, but they came with the idea to run it on the Pi which isn't that strong to multitask also the limitation of 512MB of ram (on the model B/B+) isn't enough.
I am not asking for a working GUI, just the server part is fine.

If you could honor this request you would make me and probably more players happy to use their ARM hardware for factorio.

Thank you in advance

[quinor]

I seriously doubt whether ARM is powerful enough to run Factorio. Still, preparing (and testing) build for a different platform is non-trivial task...

[Arakasi]

Hello, devs,

are there any plans for ARM support for factorio? I have RasbPi 2 at home and would be nice to run server on that device.

Thanks

[Gouada]

Look at this article: https://forums.factorio.com/forum/vie ... =53&t=7329
I've been waiting for the support for a while too! Unfortunately it's not a priority with the current schedule...

[hoho]

Factorio is rather CPU-heavy game, even when ran in headless-mode. Running a server on RPi would be a slow-mo nightmare for the players involved

[Arakasi]

I don't think that it is so CPU-heavy that RasbPi2 should not handle this. It is 4-core 900MHz processor. My computer is 4-core 1.5GHz and I play it with less than half load. But there are also more powerfull ARM machines which may handle this if RasbPi2 wouldn't be capable.
It is definitely worth to try.

RISC architecture will outrun CISC one soon so ARM support should be there too.

[Alekthefirst]

All this about cores and hertz makes my head hurt!

If you read up a bit, you would see that the performance of any ARM architecture cpus is stupid low when you compare it to a modern x86 cpu.

Example: Say i take a 6700k and let it keep its stock speed of 4GHz, in geekbench2 (cross platform benchmark) it achieves a single-core score of just about 19k, http://browser.primatelabs.com/geekbench2/2572897.
single core because factorio likes single core....

Now compare that to the Raspberry pi. Single core score: 1000, http://browser.primatelabs.com/geekbench2/2536325

[Arakasi]

All this about cores and hertz makes my head hurt!

If you read up a bit, you would see that the performance of any ARM architecture cpus is stupid low when you compare it to a modern x86 cpu.

Example: Say i take a 6700k and let it keep its stock speed of 4GHz, in geekbench2 (cross platform benchmark) it achieves a single-core score of just about 19k, http://browser.primatelabs.com/geekbench2/2572897.
single core because factorio likes single core....

Now compare that to the Raspberry pi. Single core score: 1000, http://browser.primatelabs.com/geekbench2/2536325

Not everybody has new generation of intel processors in black edition. I have 3 years old low-end mobile processor in my laptop (Comal architecture from AMD) and have no performance issues in factorio. And even older CPUs with lower power worked fine.

Benchmarks are usually just marketing stuff. When AMD pays some money to the 3Dmark or another benchmark company their results will be better than from concurrent cpu producer. For a while, until Intel do the same while they introduce another super new cpu generation.

Factorio definetely does not need highe-end computer like your 6700k@4GHz. The CPU sleeps almost all the time while playing the game. I don't care whether RaspPi2 will go 100% all the time, if the game will run fluently, it will be fine.

And I doubt about single core processing of factorio. Devs reworked the engine to be multithreaded long time ago so there is no reason to say "because factorio likes single core".

I still believe that RaspPi2 and a lot of another ARM platforms has more than enough power to run factorio.

And can you please post some articles (not benchmarks) where are compared performace results of ARM and x86 architectures which confirms you theory about "performance of any ARM architecture cpus is stupid low when you compare it to a modern x86 cpu". I read a bit and have opposite opinion.

Thanks

[kinnom]

I have a dual core 1666 Mhz cpu, and I can only get ~20 ups out of it

[Kevin94]

And I doubt about single core processing of factorio. Devs reworked the engine to be multithreaded long time ago so there is no reason to say "because factorio likes single core".

Wrong. They put everything as far as possible in different threads: rendering, saving, game update, etc. But the whole game loop, which takes the most calculation cost, is still single threaded. And this probably won't change in the future.
And therefore it totaly makes sense, that you have with less than half load on a 4-core as factorio runs one core at 100% and the others with only a view percents. On my quadcore factorio runs at around 27% and can't keep up the UPS on bigger maps.

Despite the missing CPU speed of ARM I do not think that a RasPi or Tablet has enough RAM to run bigger factorio maps. For normal playing the VRAM may also be a limiting factor.

[bobucles]

You can code up as many threads as you want. As long as they have causal dependencies they can't run independently. Parallel coding is so insanely difficult because it's ultimately up to the coder to design an engine where threads aren't waiting on each other for instructions or can reasonably function with out of sync data. Otherwise it's just wasted overhead.

There are some aspects of the sim that can run reasonably independently. The pathing AI for example doesn't REALLY need an exacting game state, because the world doesn't change that much. The actors can happily yield their motion until they get a proper result, and the result of a very complex algorithm is a very simple set of instructions. This makes the process easy to branch off into a "work unit" thread that can truly run parallel. The display process similarly is a kind of black hole where you dump sprites and instructions and never hear from again. Once it has its required info it can perform the display calculations entirely of its own accord, making it an ideal process for threading. Unfortunately a sprite based display is insanely simple vs. a 3d output to process, so it wouldn't be very meaningful for the effort involved.

Game saving is pretty simple to handle as its own process, though it depends on an exact game state which means pausing the game while it completes. Compression algorithms have been parallel for a long time now, but once the save data is complete it can easily process on the side and even allow the game to resume.

Kudos to the devs for working in multi threading where they can, it's certainly no easy task.

[Oxyd]

The pathing AI for example doesn't REALLY need an exacting game state, because the world doesn't change that much. The actors can happily yield their motion until they get a proper result, and the result of a very complex algorithm is a very simple set of instructions.

Yes it does because it needs to be deterministic. If the pathfinding algorithm were to finish a tick later on one peer than on another, then one peer's biters would start moving one tick earlier and the game would desync. Also the algorithm needs to see the exact same map on all peers in order to return the exact same results on all peers.

It could of course be run in parallel with some things other than map update (parallel with the rendering thread, perhaps), but it would still have to be tied to game ticks, so that every tick the exact same amount of pathfinding is done on all clients. Nevertheless, it's currently not run in parallel.

The problem in Factorio is that we need to guarantee determinism across different hardware and software configurations. It's not enough for us that A and B happen one after another, we also need a guarantee that A and B will happen in the same order on all computers. If it weren't for this requirement, our map update could perhaps be made parallel, but as things are it's certainly not an easy proposition.

[Arakasi]

Despite the missing CPU speed of ARM I do not think that a RasPi or Tablet has enough RAM to run bigger factorio maps. For normal playing the VRAM may also be a limiting factor.

In original post I mentioned running server factorio where I presume the GPU and VRAM is not a bottleneck.

[Gouada]

Have any of you heard of the Banana Pi or Banana Pi Pro? It is essentially a more powerful raspberry pi and could probably run Factorio quite well...

[Arakasi]

Have any of you heard of the Banana Pi or Banana Pi Pro? It is essentially a more powerful raspberry pi and could probably run Factorio quite well...

I've heard about Banana Pi and that's why I mentioned "another ARM platforms". There is some comparison benchmark among RaspPi 1 + 2 and Banana Pi Pro http://www.htpcguides.com/raspberry-pi- ... enchmarks/. But there are concerns about graphics performance on Banana Pi versions due to low support of Mali GPU chip. Which is not necessary the problem for headless factorio instance. If someday will come of course.

[Arakasi]

Raspberry PI 3 is out and its performance become even more interesting.

Are there any changes of plans for ARM version?

[Hexicube]

The pathing AI for example doesn't REALLY need an exacting game state, because the world doesn't change that much. The actors can happily yield their motion until they get a proper result, and the result of a very complex algorithm is a very simple set of instructions.

Yes it does because it needs to be deterministic. If the pathfinding algorithm were to finish a tick later on one peer than on another, then one peer's biters would start moving one tick earlier and the game would desync. Also the algorithm needs to see the exact same map on all peers in order to return the exact same results on all peers.

It could of course be run in parallel with some things other than map update (parallel with the rendering thread, perhaps), but it would still have to be tied to game ticks, so that every tick the exact same amount of pathfinding is done on all clients. Nevertheless, it's currently not run in parallel.

The problem in Factorio is that we need to guarantee determinism across different hardware and software configurations. It's not enough for us that A and B happen one after another, we also need a guarantee that A and B will happen in the same order on all computers. If it weren't for this requirement, our map update could perhaps be made parallel, but as things are it's certainly not an easy proposition.

Make it so that the biter movement starting is handled by the host, which signals for a biter to move (which will jump ahead according to lag compensation) a set time after the path is worked out (or after all clients signal they've worked out a path), and only allow a certain amount of work to go into the pathfinding each tick (such as 2500 tiles checked) so that there's no desync with paths calculated using different tile data.

[Oxyd]

The pathing AI for example doesn't REALLY need an exacting game state, because the world doesn't change that much. The actors can happily yield their motion until they get a proper result, and the result of a very complex algorithm is a very simple set of instructions.

Yes it does because it needs to be deterministic. If the pathfinding algorithm were to finish a tick later on one peer than on another, then one peer's biters would start moving one tick earlier and the game would desync. Also the algorithm needs to see the exact same map on all peers in order to return the exact same results on all peers.

It could of course be run in parallel with some things other than map update (parallel with the rendering thread, perhaps), but it would still have to be tied to game ticks, so that every tick the exact same amount of pathfinding is done on all clients. Nevertheless, it's currently not run in parallel.

The problem in Factorio is that we need to guarantee determinism across different hardware and software configurations. It's not enough for us that A and B happen one after another, we also need a guarantee that A and B will happen in the same order on all computers. If it weren't for this requirement, our map update could perhaps be made parallel, but as things are it's certainly not an easy proposition.

Make it so that the biter movement starting is handled by the host, which signals for a biter to move (which will jump ahead according to lag compensation) a set time after the path is worked out (or after all clients signal they've worked out a path), and only allow a certain amount of work to go into the pathfinding each tick (such as 2500 tiles checked) so that there's no desync with paths calculated using different tile data.

Why would we do that?

[ratchetfreak]

Make it so that the biter movement starting is handled by the host, which signals for a biter to move (which will jump ahead according to lag compensation) a set time after the path is worked out (or after all clients signal they've worked out a path), and only allow a certain amount of work to go into the pathfinding each tick (such as 2500 tiles checked) so that there's no desync with paths calculated using different tile data.

Why would we do that?

I think the idea is that pathing can be delegated to only a single client that can then forward the resulting path to the others.

This can be a boost if one client can't keep up or there is a client with computation resources to space.

[Oxyd]

Make it so that the biter movement starting is handled by the host, which signals for a biter to move (which will jump ahead according to lag compensation) a set time after the path is worked out (or after all clients signal they've worked out a path), and only allow a certain amount of work to go into the pathfinding each tick (such as 2500 tiles checked) so that there's no desync with paths calculated using different tile data.

Why would we do that?

I think the idea is that pathing can be delegated to only a single client that can then forward the resulting path to the others.

This can be a boost if one client can't keep up or there is a client with computation resources to space.

That would probably have no noticeable effect in vast majority of cases. If you want to go down the parallel computing way, doing this to entity update would make much more sense.

In any case, this would be a huge architectural change, so not happening.