ARM architecture

Post all other topics which do not belong to any other category.
Arakasi
Fast Inserter
Fast Inserter
Posts: 108
Joined: Tue Feb 26, 2013 9:43 pm
Contact:

ARM architecture

Post by 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
Fast Inserter
Fast Inserter
Posts: 100
Joined: Sun Sep 21, 2014 3:57 pm
Contact:

Re: ARM architecture

Post by 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...
No, I'm not a piece of cheese! :D

hoho
Filter Inserter
Filter Inserter
Posts: 674
Joined: Sat Jan 18, 2014 11:23 am
Contact:

Re: ARM architecture

Post by 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
Fast Inserter
Fast Inserter
Posts: 108
Joined: Tue Feb 26, 2013 9:43 pm
Contact:

Re: ARM architecture

Post by 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.

User avatar
Alekthefirst
Fast Inserter
Fast Inserter
Posts: 104
Joined: Sat Feb 07, 2015 7:39 pm
Contact:

Re: ARM architecture

Post by 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
Factorio is a game about automating everything. One day, i hope i can automate shitty signatures just like this one.

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

Re: ARM architecture

Post by Arakasi »

Alekthefirst wrote: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
Filter Inserter
Filter Inserter
Posts: 702
Joined: Fri Dec 26, 2014 4:20 pm
Contact:

Re: ARM architecture

Post by kinnom »

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

Kevin94
Inserter
Inserter
Posts: 46
Joined: Mon Dec 08, 2014 10:39 pm
Contact:

Re: ARM architecture

Post by Kevin94 »

Arakasi wrote: 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
Smart Inserter
Smart Inserter
Posts: 1645
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: ARM architecture

Post by 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
Factorio Staff
Factorio Staff
Posts: 1312
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: ARM architecture

Post by Oxyd »

bobucles wrote: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
Fast Inserter
Fast Inserter
Posts: 108
Joined: Tue Feb 26, 2013 9:43 pm
Contact:

Re: ARM architecture

Post by Arakasi »

Kevin94 wrote: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
Fast Inserter
Fast Inserter
Posts: 100
Joined: Sun Sep 21, 2014 3:57 pm
Contact:

Re: ARM architecture

Post by 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...
No, I'm not a piece of cheese! :D

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

Re: ARM architecture

Post by Arakasi »

Gouada wrote: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
Fast Inserter
Fast Inserter
Posts: 108
Joined: Tue Feb 26, 2013 9:43 pm
Contact:

Re: ARM architecture

Post by Arakasi »

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

Are there any changes of plans for ARM version?

Hexicube
Fast Inserter
Fast Inserter
Posts: 194
Joined: Wed Feb 24, 2016 9:50 pm
Contact:

Re: ARM architecture

Post by Hexicube »

Oxyd wrote:
bobucles wrote: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
Factorio Staff
Factorio Staff
Posts: 1312
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: ARM architecture

Post by Oxyd »

Hexicube wrote:
Oxyd wrote:
bobucles wrote: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
Filter Inserter
Filter Inserter
Posts: 950
Joined: Sat May 23, 2015 12:10 pm
Contact:

Re: ARM architecture

Post by ratchetfreak »

Oxyd wrote:
Hexicube wrote: 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
Factorio Staff
Factorio Staff
Posts: 1312
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: ARM architecture

Post by Oxyd »

ratchetfreak wrote:
Oxyd wrote:
Hexicube wrote: 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.

Hexicube
Fast Inserter
Fast Inserter
Posts: 194
Joined: Wed Feb 24, 2016 9:50 pm
Contact:

Re: ARM architecture

Post by Hexicube »

Oxyd wrote:
Hexicube wrote: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?
It would allow threaded pathfinding, which is another step towards using multiple cores better.

User avatar
taiiat
Long Handed Inserter
Long Handed Inserter
Posts: 81
Joined: Sat Apr 02, 2016 8:39 pm
Contact:

Re: ARM architecture

Post by taiiat »

excuse me while i also slightly cry in the corner about direct Processor Core and Hertz comparisons, especially across completely different Architectures.
:v
Hexicube wrote:It would allow threaded pathfinding, which is another step towards using multiple cores better.
a single step is a lot of work for no tangible result at that point.
AI is Single Threaded in EVERY game for good reason - it has to be. nobody on the planet earth has yet to figure out a way to split the calculations to other threads without blowing up some or all of the AI processing. no matter what you split off you create a problem because Processor Cores don't technically talk to each other.

if you split pathfinding, AI will collide with each other constantly and get stuck because they don't know the other AI exist.
actually frankly, if you split basically any segment, this is what happens for everything. once it's in a different Thread, the AI no longer knows that part of the processing exists. and trying to communicate the data back makes the AI Thread even slower, when it's already often a nightmarishly slow Thread in games as it is.

as ever, the story is "making really cool complex AI that acts dynamically to everything is really easy - making that AI actually run on any computer in the world is a different story".

this is why 99% of Video Games still run on 1/2 Threads. usually one Thread for Game state, AI... Physics... the kitchen sink... and one Thread for smaller modules that don't really need to be synced to the core of the game, like User Interface.
inb4 "but i see all 1598276 of my Processor Cores being used, so it must support and utilize that many Threads" - incorrect. software can only utilize as many Threads as it knows how to.
having more Processor Cores doesn't change that. period. a game that can utilize 4 Threads is already something of a rare miracle. pending genre ofcourse. a game that doesn't have any AI to worry about has a huge load lifted and is a lot easier to Multi-Thread.


that's probably more than enough off topic stuff though.

Post Reply

Return to “General discussion”

Who is online

Users browsing this forum: DrParanoia