3 ms·
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/d
by 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 agoYou 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 agoThere'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 agoThere were issues with numpy/scipy because of lapack and fortran. I guess they solved it somehow.
- jeffbee 5y agoThere 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.