6 ms·

Do ARM compatibility issues still exist?

cassianoleal 5y ago
Of course. Any time you try to run a non-ARM binary on an ARM CPU without some form of translation or emulation, it will fail. This is also true for any other CPU architecture. If you want to know about specific compatibility issues, I'm happy to try to help as I've been using an M1 Air as my daily driver for many months now.
- grp000 5y ago
  Did they finally get Docker working on the M1 chips?
  - cassianoleal 5y ago
    Docker works mostly fine. ARM images are pretty common, and for those that don't have it, it runs a QEMU emulated x86 machine. I have hit issues with it but they're rare enough that I don't care.
  - X-Istence 5y ago
    Docker has been working for months.
  - lstamour 5y ago
    Yes. https://docs.docker.com/desktop/mac/apple-silicon/ https://docs.docker.com/desktop/mac/apple-silicon/
  - fulafel 5y ago
    Native ARM containers work but there are various things that break with Docker x86 emulation, eg with Node.
  - solarkraft 5y ago
    It’s somewhat unreliable and file system interaction is slow, but from what I’ve heard that means it’s no different from x86 Docker Desktop.
  - jamesgeck0 5y ago
    Mostly. Docker for Mac's internal VM consistently kernel panics the first time I launch it after a reboot. I also have containers freeze up every now and then, something that never happened on my Intel machine.
- friseurtermin 5y ago
  > without some form of translation or emulation IIRC that's why Rosetta2 exists. The question is more whether there are issues despite that
  - cassianoleal 5y ago
    I don't think I've ever had an issue related to Rosetta2. Everything I had to run on it worked flawlessly and without any noticeable performance hit. This is only my own anecdote though.
    - sebazzz 5y ago
      There have been some font rendering issues in Ultimaker Cura (which is written in Python) that ran as x86 on M1. These have been resolved in the Python library.
      - zlsa 5y ago
        In fairness, I've seen font rendering in Cura on Linux as well.
        cassianoleal 5y ago
        I've seen font rendering issues in Cura on Intel Macs as well. Cura's GUI and UX are pretty bad in general IMO though, so I don't use it.
    - eknkc 5y ago
      I also had everything working fine but performance is really bad when you go through rosetta. For example, discord client is still x86 and while it works without any issues, the heaviness is noticeable. Also, .NET 5 does not have an arm build (.NET 6 does but it is still in beta). The entire toolchain works but compiling a binary can be 3-4 times slower on the emulated one. Things work without any issues though. They are just slow.
      - 5y ago
- solarkraft 5y ago
  You’re missing the point, it’s an ecosystem question. I personally don’t experience many issues at all. If I do they’re usually solved by switching to Rosetta (but that does introduce some hairiness for command line stuff).
porcc 5y ago
Close to no https://isapplesiliconready.com/for/developer https://isapplesiliconready.com/for/developer
- drdaeman 5y ago
  I wonder about games, and sadly this website doesn't list any. I want a new laptop and those new M1 MBPs look interesting, with low TDP high performance. I primarily use it for development and browsing when I'm not home (I have a family overseas), but I also want to play games now and then. I know Steam has native ARM support and some games I play are ported as well, but I really wonder how much can I get from double translation layers (x86 to ARM + Wine or derivatives).
  - porcc 5y ago
    Games are decent to good, I had a good experience using CrossOver--though I was playing 2d (spelunky, omori at the time). https://www.codeweavers.com/compatibility/ https://www.codeweavers.com/compatibility/ Retro emulation is phenomenal, PS1 PSP DS no problem, everything earlier great. YMMV as I have separate gaming machines
smoldesu 5y ago
I mean, yeah. You're not going to be running anything 32-bit, and you can't use OpenGL or Vulkan, which already rules out a decent handful of workflows (including but not limited to my own). On top of that, there's legendary Docker issues that plague pretty much anything running MacOS, and there still isn't a competitive, complete package manager. eGPUs are almost completely off the table, and if they do work you won't be allowed to run an Nvidia card, you can't use CUDA, and OpenCL is fully depreciated. So yeah, there's still quite a few holdouts on the MacOS and ARM side of things. Unless you're confident that your workflow functions perfectly on ARM, you should probably stick with a nice x86 machine for the foreseeable future. Apple will definitely improve on this model, so if you are dead-set on buying one I probably wouldn't spring for the first-gen anyways. Just my two cents though.
- Encounter 5y ago
  OpenGL still works on the M1 (Apple designed their own GL-over-Metal driver), albeit with the OpenGL version limitations from modern macOS in general. Vulkan works over MoltenVK. Other than old games, I'm not sure why 64-bit only is an issue. I've not hit any Docker-on-macOS issues with what I've used it for, at least.
  - smoldesu 5y ago
    Is MoltenVK usable right now? I was under the impression that it's a loooooooong ways behind DXVK in it's current state.
    - Encounter 5y ago
      I've seen plenty of projects that use MoltenVK as a drop-in backend for macOS. It seems complete enough for general use, but I haven't used it directly so I'm not sure what's missing.
fayten 5y ago
Yes, but it's very rare now a days. I live in JVM land and there are quite a few native JNA libraries that I have run into issues with. One example is vlcj [1] I just ran into yesterday. I have yet to dig deeply into the issue just yet, but it's giving me the fun "no compatible architecture found error". SWT and JavaFX both fully works with arm now though, so I am pretty happy on that front. GraalVM native-image also does not support building ARM on Mac yet either. On the C/C++ side of things I have not ran into any incompatibility issues in the last 5 months. I'd say 99% of my time is smooth sailing at this point. [1] https://github.com/caprica/vlcj https://github.com/caprica/vlcj
- chrisseaton 5y ago
  They really need to get on and support macOS ARM for GraalVM. It's clearly not going away - it just needs doing.
  - smoldesu 5y ago
    While we're asking, would it really be that much trouble getting Vulkan working? It falls in the same category of 'not going away but needs doing'.
    - my123 5y ago
      Vulkan already works ok through MoltenVK.
      - smoldesu 5y ago
        It's far from a complete solution though, and it's still going to have worse performance than a native implementation. Apple needs to prioritize Vulkan support on these devices if they don't want to repeat the last 15 years of Mac GPU issues.
chomp 5y ago
I haven't run into any issues. Homebrew seems to be (mostly) working, and most vendors have created universal images at this point. I think the only thing I'm personally waiting on is VMware Fusion (currently in beta). Swift still doesn't have an Arm docker image from the official Swift.org group.
jeffbee 5y ago
In my experience the main issue with the M1+macOS experience is not the ISA, it's the big-little thread scheduling. I'm not sure what they were thinking but there's some heuristic that schedules background or batch work on the little cores. This includes manually-triggered software updates which unfortunately can take forever on those little cores. I waited almost 4 hours for an Xcode update to complete. All four little cores were maxed out the whole time, and these new chips only have two of them.
- drcongo 5y ago
  Doesn't an Xcode update _always_ take about 4 hours?
rezahussain 5y ago
youtube-dl didn't work when I tried it 3 weeks ago
- stu2b50 5y ago
  YouTube dl is just python, whether or not it runs just depends on whether or not python’s interpreter runs on ARM, which it definitely does.
- jsjohnst 5y ago
  I’ve used youtube-dl for the better part of a year now on M1 without issues. If it didn’t work for you, then you need to look into what’s broken on your specific machine.
calebm 5y ago
I have an M1, and I was unable to install tensorflow in a docker container on the M1 host (as of last time I tried, a few months ago).
- abledon 5y ago
  I run tensorflows yolov4 no problem on m1 macbook air, cool thing is that you can fit larger models in memory than if you had a 8GB NVIDIA Card
  - lostmsu 5y ago
    Training or inference? How's training performance compared to 8GB NVIDIA, if you have one?
immutology 5y ago
Full version of MS SQL Server doesn't work. The X86-64 Docker image won't start under QEMU emulation and the installer won't install it in the ARM64 insider builds of Windows 10/11 running in Parallels. You can use the ARM64 build of Azure SQL Edge, but it lacks many features that may or may not be important depending on your use. Here's the GH issue related to the Docker issue if curious: https://github.com/microsoft/mssql-docker/issues/668 https://github.com/microsoft/mssql-docker/issues/668
- my123 5y ago
  > Full version of MS SQL Server doesn't work Stay tuned. (to avoid emulation) > the installer won't install it in the ARM64 insider builds of Windows 10/11 Yeah, that was a bug: https://support.microsoft.com/en-us/topic/kb4530084-fix-error-occurs-when-you-try-to-install-sql-server-2019-on-a-low-power-cpu-f2ab38f7-1def-c6a3-790e-bfff86f89820 https://support.microsoft.com/en-us/topic/kb4530084-fix-erro... The solution that works is running the SQLS installer, see that error, install that CU update, then restart the SQL Server installer that _then_ continues. But that's an unreliable process, would need new install media to be fixed properly.
shp0ngle 5y ago
Yes, and they will never go away entirely You can never run x86 dockers as easily and as quickly as on intel. If you have bunch of scripts in some deployment/development pipeline that depend on docker being x86, they will fail. Other things…I’m not sure about October 2021, but last time I looked, R was still only available through Rosetta, because parts of R are in FORTRAN and that does not have native M1 support (yes FORTRAN), but honestly it’s so fast with emulation that it does not matter. Same SciPy… or was it NumPy? One of those two have parts in FORTRAN and can only be run through Rosetta (so it can wreak havoc as you might need python pipeline parts in ARM and parts emulated). But I have not hit that personally as I don’t use Python directly you cannot run Windows either dual boot or in virtual machine. Same with x86 linux.
- mackatsol 5y ago
  You can run Windows ARM in emulation, as the MS Surface uses ARM and has a version of Windows available. I have run Windows ARM in Parallels on an M1 on a client's machine.
- jeffbee 5y ago
  There's no problem with either scipy or numpy running natively on Apple Silicon. The problem is with the 3rd-party package managers, which are all junk, and that's not new: they've always been hot garbage, especially homebrew. Just don't use homebrew, and then after you get used to that, don't use it on x86, either.
  - shp0ngle 5y ago
    There were issues with numpy/scipy because of lapack and fortran. I guess they solved it somehow.
    - jeffbee 5y ago
      There were problems with homebrew finding a fortran compiler for this platform, there were not problems with fortran on macos/arm64 itself. fortran for macos/arm64 has existed since the platform was available. OpenBLAS has worked fine as far as I can tell with `make FC=gfortran`. The only problems have been with package managers.
jimmont 5y ago
they're largely resolved--my air no longer panics and I cannot recall when it last did, though it did panic frequently the first several point-releases; my web development is largely unaffected since around the 2nd quarter of 2021 and actively developed software either has a release for apple silicon and when that's not the case it mostly works with occasional crashes (eg inkscape); obviously this will depend on what applications you use however homebrew, node modules, deno, rust, etc all are working well in various long-lists of items that are less relevant beyond my generalization here; I intend to use applications running in windows and qemu but haven't taken time yet
upbeat_general 5y ago
Yes. Most user applications have been updated but plenty of libraries have not been. Most of the python packages that have significant C deps often have issues compiling (e.g. Scipy, igraph, etc). It's almost always possible to work around these issues but it gets tiring since it's compounded with the usual macOS breaking changes every year. Any binary compiled with AVX-512 instructions (e.g. Tensorflow, MuJoCo, etc.) will also need to be recompiled. So tl;dr most (but far from all) popular closed source programs have been updated/recompiled for ARM (or at least run decently with Rosetta), but many libraries/open-source projects require some painful recompiling.

Of course. Any time you try to run a non-ARM binary on an ARM CPU without some form of translation or emulation, it will fail. This is also true for any other CPU architecture. If you want to know about specific compatibility issues, I'm happy to try to help as I've been using an M1 Air as my daily driver for many months now.

grp000 5y ago
Did they finally get Docker working on the M1 chips?
- cassianoleal 5y ago
  Docker works mostly fine. ARM images are pretty common, and for those that don't have it, it runs a QEMU emulated x86 machine. I have hit issues with it but they're rare enough that I don't care.
- X-Istence 5y ago
  Docker has been working for months.
- lstamour 5y ago
  Yes. https://docs.docker.com/desktop/mac/apple-silicon/ https://docs.docker.com/desktop/mac/apple-silicon/
- fulafel 5y ago
  Native ARM containers work but there are various things that break with Docker x86 emulation, eg with Node.
- solarkraft 5y ago
  It’s somewhat unreliable and file system interaction is slow, but from what I’ve heard that means it’s no different from x86 Docker Desktop.
- jamesgeck0 5y ago
  Mostly. Docker for Mac's internal VM consistently kernel panics the first time I launch it after a reboot. I also have containers freeze up every now and then, something that never happened on my Intel machine.
friseurtermin 5y ago
> without some form of translation or emulation IIRC that's why Rosetta2 exists. The question is more whether there are issues despite that
- cassianoleal 5y ago
  I don't think I've ever had an issue related to Rosetta2. Everything I had to run on it worked flawlessly and without any noticeable performance hit. This is only my own anecdote though.
  - sebazzz 5y ago
    There have been some font rendering issues in Ultimaker Cura (which is written in Python) that ran as x86 on M1. These have been resolved in the Python library.
    - zlsa 5y ago
      In fairness, I've seen font rendering in Cura on Linux as well.
      - cassianoleal 5y ago
        I've seen font rendering issues in Cura on Intel Macs as well. Cura's GUI and UX are pretty bad in general IMO though, so I don't use it.
  - eknkc 5y ago
    I also had everything working fine but performance is really bad when you go through rosetta. For example, discord client is still x86 and while it works without any issues, the heaviness is noticeable. Also, .NET 5 does not have an arm build (.NET 6 does but it is still in beta). The entire toolchain works but compiling a binary can be 3-4 times slower on the emulated one. Things work without any issues though. They are just slow.
    - 5y ago
solarkraft 5y ago
You’re missing the point, it’s an ecosystem question. I personally don’t experience many issues at all. If I do they’re usually solved by switching to Rosetta (but that does introduce some hairiness for command line stuff).

porcc 5y ago

Close to no https://isapplesiliconready.com/for/developer https://isapplesiliconready.com/for/developer

drdaeman 5y ago
I wonder about games, and sadly this website doesn't list any. I want a new laptop and those new M1 MBPs look interesting, with low TDP high performance. I primarily use it for development and browsing when I'm not home (I have a family overseas), but I also want to play games now and then. I know Steam has native ARM support and some games I play are ported as well, but I really wonder how much can I get from double translation layers (x86 to ARM + Wine or derivatives).
- porcc 5y ago
  Games are decent to good, I had a good experience using CrossOver--though I was playing 2d (spelunky, omori at the time). https://www.codeweavers.com/compatibility/ https://www.codeweavers.com/compatibility/ Retro emulation is phenomenal, PS1 PSP DS no problem, everything earlier great. YMMV as I have separate gaming machines

smoldesu 5y ago

I mean, yeah. You're not going to be running anything 32-bit, and you can't use OpenGL or Vulkan, which already rules out a decent handful of workflows (including but not limited to my own). On top of that, there's legendary Docker issues that plague pretty much anything running MacOS, and there still isn't a competitive, complete package manager. eGPUs are almost completely off the table, and if they do work you won't be allowed to run an Nvidia card, you can't use CUDA, and OpenCL is fully depreciated. So yeah, there's still quite a few holdouts on the MacOS and ARM side of things. Unless you're confident that your workflow functions perfectly on ARM, you should probably stick with a nice x86 machine for the foreseeable future. Apple will definitely improve on this model, so if you are dead-set on buying one I probably wouldn't spring for the first-gen anyways. Just my two cents though.

Encounter 5y ago
OpenGL still works on the M1 (Apple designed their own GL-over-Metal driver), albeit with the OpenGL version limitations from modern macOS in general. Vulkan works over MoltenVK. Other than old games, I'm not sure why 64-bit only is an issue. I've not hit any Docker-on-macOS issues with what I've used it for, at least.
- smoldesu 5y ago
  Is MoltenVK usable right now? I was under the impression that it's a loooooooong ways behind DXVK in it's current state.
  - Encounter 5y ago
    I've seen plenty of projects that use MoltenVK as a drop-in backend for macOS. It seems complete enough for general use, but I haven't used it directly so I'm not sure what's missing.

fayten 5y ago

Yes, but it's very rare now a days. I live in JVM land and there are quite a few native JNA libraries that I have run into issues with. One example is vlcj [1] I just ran into yesterday. I have yet to dig deeply into the issue just yet, but it's giving me the fun "no compatible architecture found error". SWT and JavaFX both fully works with arm now though, so I am pretty happy on that front. GraalVM native-image also does not support building ARM on Mac yet either. On the C/C++ side of things I have not ran into any incompatibility issues in the last 5 months. I'd say 99% of my time is smooth sailing at this point. [1] https://github.com/caprica/vlcj https://github.com/caprica/vlcj

chrisseaton 5y ago
They really need to get on and support macOS ARM for GraalVM. It's clearly not going away - it just needs doing.
- smoldesu 5y ago
  While we're asking, would it really be that much trouble getting Vulkan working? It falls in the same category of 'not going away but needs doing'.
  - my123 5y ago
    Vulkan already works ok through MoltenVK.
    - smoldesu 5y ago
      It's far from a complete solution though, and it's still going to have worse performance than a native implementation. Apple needs to prioritize Vulkan support on these devices if they don't want to repeat the last 15 years of Mac GPU issues.

chomp 5y ago

I haven't run into any issues. Homebrew seems to be (mostly) working, and most vendors have created universal images at this point. I think the only thing I'm personally waiting on is VMware Fusion (currently in beta). Swift still doesn't have an Arm docker image from the official Swift.org group.

jeffbee 5y ago

In my experience the main issue with the M1+macOS experience is not the ISA, it's the big-little thread scheduling. I'm not sure what they were thinking but there's some heuristic that schedules background or batch work on the little cores. This includes manually-triggered software updates which unfortunately can take forever on those little cores. I waited almost 4 hours for an Xcode update to complete. All four little cores were maxed out the whole time, and these new chips only have two of them.

drcongo 5y ago
Doesn't an Xcode update _always_ take about 4 hours?

rezahussain 5y ago

youtube-dl didn't work when I tried it 3 weeks ago

stu2b50 5y ago
YouTube dl is just python, whether or not it runs just depends on whether or not python’s interpreter runs on ARM, which it definitely does.
jsjohnst 5y ago
I’ve used youtube-dl for the better part of a year now on M1 without issues. If it didn’t work for you, then you need to look into what’s broken on your specific machine.

calebm 5y ago

I have an M1, and I was unable to install tensorflow in a docker container on the M1 host (as of last time I tried, a few months ago).

abledon 5y ago
I run tensorflows yolov4 no problem on m1 macbook air, cool thing is that you can fit larger models in memory than if you had a 8GB NVIDIA Card
- lostmsu 5y ago
  Training or inference? How's training performance compared to 8GB NVIDIA, if you have one?

immutology 5y ago

Full version of MS SQL Server doesn't work. The X86-64 Docker image won't start under QEMU emulation and the installer won't install it in the ARM64 insider builds of Windows 10/11 running in Parallels. You can use the ARM64 build of Azure SQL Edge, but it lacks many features that may or may not be important depending on your use. Here's the GH issue related to the Docker issue if curious: https://github.com/microsoft/mssql-docker/issues/668 https://github.com/microsoft/mssql-docker/issues/668

my123 5y ago
> Full version of MS SQL Server doesn't work Stay tuned. (to avoid emulation) > the installer won't install it in the ARM64 insider builds of Windows 10/11 Yeah, that was a bug: https://support.microsoft.com/en-us/topic/kb4530084-fix-error-occurs-when-you-try-to-install-sql-server-2019-on-a-low-power-cpu-f2ab38f7-1def-c6a3-790e-bfff86f89820 https://support.microsoft.com/en-us/topic/kb4530084-fix-erro... The solution that works is running the SQLS installer, see that error, install that CU update, then restart the SQL Server installer that _then_ continues. But that's an unreliable process, would need new install media to be fixed properly.

shp0ngle 5y ago

Yes, and they will never go away entirely You can never run x86 dockers as easily and as quickly as on intel. If you have bunch of scripts in some deployment/development pipeline that depend on docker being x86, they will fail. Other things…I’m not sure about October 2021, but last time I looked, R was still only available through Rosetta, because parts of R are in FORTRAN and that does not have native M1 support (yes FORTRAN), but honestly it’s so fast with emulation that it does not matter. Same SciPy… or was it NumPy? One of those two have parts in FORTRAN and can only be run through Rosetta (so it can wreak havoc as you might need python pipeline parts in ARM and parts emulated). But I have not hit that personally as I don’t use Python directly you cannot run Windows either dual boot or in virtual machine. Same with x86 linux.

mackatsol 5y ago
You can run Windows ARM in emulation, as the MS Surface uses ARM and has a version of Windows available. I have run Windows ARM in Parallels on an M1 on a client's machine.
jeffbee 5y ago
There's no problem with either scipy or numpy running natively on Apple Silicon. The problem is with the 3rd-party package managers, which are all junk, and that's not new: they've always been hot garbage, especially homebrew. Just don't use homebrew, and then after you get used to that, don't use it on x86, either.
- shp0ngle 5y ago
  There were issues with numpy/scipy because of lapack and fortran. I guess they solved it somehow.
  - jeffbee 5y ago
    There were problems with homebrew finding a fortran compiler for this platform, there were not problems with fortran on macos/arm64 itself. fortran for macos/arm64 has existed since the platform was available. OpenBLAS has worked fine as far as I can tell with `make FC=gfortran`. The only problems have been with package managers.

jimmont 5y ago

they're largely resolved--my air no longer panics and I cannot recall when it last did, though it did panic frequently the first several point-releases; my web development is largely unaffected since around the 2nd quarter of 2021 and actively developed software either has a release for apple silicon and when that's not the case it mostly works with occasional crashes (eg inkscape); obviously this will depend on what applications you use however homebrew, node modules, deno, rust, etc all are working well in various long-lists of items that are less relevant beyond my generalization here; I intend to use applications running in windows and qemu but haven't taken time yet

upbeat_general 5y ago

Yes. Most user applications have been updated but plenty of libraries have not been. Most of the python packages that have significant C deps often have issues compiling (e.g. Scipy, igraph, etc). It's almost always possible to work around these issues but it gets tiring since it's compounded with the usual macOS breaking changes every year. Any binary compiled with AVX-512 instructions (e.g. Tensorflow, MuJoCo, etc.) will also need to be recompiled. So tl;dr most (but far from all) popular closed source programs have been updated/recompiled for ARM (or at least run decently with Rosetta), but many libraries/open-source projects require some painful recompiling.