Factorio Forums

If you’re still interested I would write to wube now.

[insert gaming on mac meme]

ssilk wrote: ↑

Wed Sep 28, 2022 5:06 am

If you’re still interested I would write to wube now.

Exciting! I'd be very excited to see more work on both a macOS ARM and generic LInux ARM port (aarch64 of course, nobody wants or needs 32 bit Factorio)

I wonder if Wube could save some time in future ports by writing a maths C library with more strictly defined behavior than libc. Idea is if a desync is identified, it is fixed by reimplementing the math function in the library and writing tests to ensure consistent results on all platforms. You could also write tests comparing the results of standard library maths functions with their equivalents on various platforms. This may also mean figuring out why compilers on some platforms are producing different results for the same code, so it sounds like very "fun" kind of systems programming.

chexo4 wrote: ↑

Wed Sep 28, 2022 6:39 pm

Idea is if a desync is identified, it is fixed by reimplementing the math function in the library and writing tests to ensure consistent results on all platforms.

It will be easier not to use floating point numbers in critical places. Even if you take the task of compiling a list of ALL the mathematical functions that factorio uses, it will take a very long time.
You have the wrong approach to solving the problem. One should not look for all the features and all possible differences in the result. I would find bottlenecks in the code where the desync occurs and work on solving the problem in this bottleneck.

SerhiiS wrote: ↑

Wed Sep 28, 2022 9:51 pm

chexo4 wrote: ↑

Wed Sep 28, 2022 6:39 pm

Idea is if a desync is identified, it is fixed by reimplementing the math function in the library and writing tests to ensure consistent results on all platforms.

It will be easier not to use floating point numbers in critical places. Even if you take the task of compiling a list of ALL the mathematical functions that factorio uses, it will take a very long time.
You have the wrong approach to solving the problem. One should not look for all the features and all possible differences in the result. I would find bottlenecks in the code where the desync occurs and work on solving the problem in this bottleneck.

If you don't use float/double then you have to implement all the mathematical functions anyway.

mrvn wrote: ↑

Thu Sep 29, 2022 6:08 am

If you don't use float/double then you have to implement all the mathematical functions anyway.

Reread repeatedly what I wrote. The bottleneck of synchronization for you is ALL mathematical functions??? It's good that you are not in the development team

SerhiiS wrote: ↑

Thu Sep 29, 2022 10:03 am

mrvn wrote: ↑

Thu Sep 29, 2022 6:08 am

If you don't use float/double then you have to implement all the mathematical functions anyway.

Reread repeatedly what I wrote. The bottleneck of synchronization for you is ALL mathematical functions??? It's good that you are not in the development team

I think the synchronization is done already. There shouldn't be a difference between different ARM cpus in that regard.

I think the bigger problem would be the build system and GFX support for different SOCs.

mrvn wrote: ↑

Thu Sep 29, 2022 4:17 pm

I think the synchronization is done already. There shouldn't be a difference between different ARM cpus in that regard.

I think the bigger problem would be the build system and GFX support for different SOCs.

If they didn't have sync issues, they wouldn't be posting this here. Again, so read the thread and don't build or write guesses. And secondly, the build system for M1 mac is xcode-select. There is no need to invent any custom build system. In addition, you can only build on a poppy through xcode-select and nothing else. Therefore, assembling the system on a poppy is decided only by the presence of a purchased macbook and xcode installed there. They have a version of intel mac for a long time, you just need to change the architecture to M1 in xcode and that's it. But the developers wrote that they are building on the M1, the problem is not in the assembly, the problem is in synchronization.

I also want to add that now on m1 the game works very well through rosetta. On my m1 pro works megabases and shows high ups. And I don't know if it makes sense to make an arm build and how much faster it will be than the current one...

I think we all have no good idea what are the real problems, what hinders wube to make an arm version. We can make clever guesses, which are in their eyes might look quite naive (because they have solved those things already).


So I currently think the problems are not as simple as described here.

Or … it’s already working and it’s too slow yet.

Or everything works and they cannot re-port it to v 1.1 and wait till release of 1.2.

But the essence is: we cannot know.

I think the main problem is that it's a request for the 30 geeks that want a factorio server to run on ARM and that it's in the lowest priority possible :p thus with the work done for the switch built I think it's reduced the work need to have a factorio build on AArch64 a lot.

And even with the dev answer of the note patch I have still hope.

ssilk wrote: ↑

Fri Sep 30, 2022 5:41 am

I think we all have no good idea what are the real problems, what hinders wube to make an arm version.

People have been porting all kinds of software to new platforms and maintaining that software for a very long time; the types of problems that come up and challenges are well understood. That of course is general, but combined with explicit information from the developers, other evidence and strong hints, I think there is a pretty firm idea of the problems for Factorio.

The greater uncertainty comes in when considering the scale of those problems. Ultimately, it's software; the only "real problem" is the time of suitably skilled individuals. For a business, the leads to the question of if or how much return on investment (in the broadest sense) will be achieved compared to some other use of time... In other words, priority.

SoShootMe wrote: ↑

Fri Sep 30, 2022 7:30 am

For a business, the leads to the question of if or how much return on investment (in the broadest sense) will be achieved compared to some other use of time... In other words, priority.

- it already exists and is working
- took much longer than expected
- financial success is questionable (right target group for nintendo switch?)

Which leads me to thinking that the switch port was just to test if it’s possible and wube looks now how to port it onto other devices.

Raspberry Pis have horrible memory bandwidth, even on 64-bit RasPi hardware the memory bus to the CPU is only 32-bits. No matter what the CPU specs are, the memory bandwidth on a Pi is what's going to choke it more than anything else.

Is that a problem for Factorio? No idea. I'm not going to pretend to know, either.

I'd be happy with a native build of Factorio for Apple Silicon. These have excellent performance and excellent memory bandwidth, especially on the higher-end models.

The NVidia Jetson boards are solid desktops, as well, and they deserve native builds when feasible.

The infrastructure needed to support releases on ARM would also be useful for managing micro-architecture builds (compiler option "-march=<whatever>"), which supposedly should improve performance on many systems.

If there is development ongoing for ARM, I'd gladly participate in beta testing on my Mac M1. But I don't just want headless, I want to play on the Mac directly.

I could offer a Rock 5B to run tests on. It's a Rockchip 3588 with 8 cores (4 big and 4 little cores that are somewhat slower), a MALI GPU common on many ARM SoCs and 16GB of ram. A little more umph than a switch or Raspberry Pi.

Doing a slight necro-bump on this thread. And adding my +1 for headless Linux AArch64 builds.

Increasingly, cloud/infrastructure providers are offering Arm server types (Graviton, Ampere). I think the demand for Arm builds of Factorio is only going to continue to increase.

My hope is that the next iteration of Steam Deck is some kind of AArch64-based monster, thus forcing the game industry to finally take this platform seriously

I'd like to add as well that it would be greate to have Linux AArch64 builds (especially to run a server). Ampere CPU's in the cloud are becoming more and more available, and they offer great performance, so it's quite sad that factorio runs linux/amd64, macos/arm but not linux/arm

samcday wrote: ↑

Thu Apr 13, 2023 6:44 am

Increasingly, cloud/infrastructure providers are offering Arm server types (Graviton, Ampere). I think the demand for Arm builds of Factorio is only going to continue to increase.

My hope is that the next iteration of Steam Deck is some kind of AArch64-based monster, thus forcing the game industry to finally take this platform seriously

As they said here earlier, the developers will not do this labor-intensive task for the sake of a group of geeks with ARM servers and Steam Decks