13
$\begingroup$

The initial wave of reviews for Apple's M1 hardware are out, and there's lots of generic benchmarks and data on workflows on professional programs for creative users, but I haven't seen anyone talking about the experience of using something like the scientific computing ecosystem in Python or R.

Does anyone have direct experience with this? Or seen reviews? How fares the Rosetta 2 emulation in terms of either performance in these application spaces or with compilation of packages that don't come in binaries?

Improve this question
$\endgroup$

3 Answers 3

Reset to default
10
$\begingroup$

The way I have been measuring whether the eco-system is ready is how things are going with the transition for the homebrew package manager. They have been carefully documenting the progress of getting things running on apple silicon via a github issue. Beyond @Federico Poloni's point the biggest problem is that GCC itself is not yet working and is the reason why many of the packages on homebrew are not yet working. Now this does not mean a bunch of stuff does not work but I think is a good "canary in the coal mine". It may be that something like Clang and Flang will replace the GCC toolchain more completely on apple silicon in the end.

Improve this answer
$\endgroup$
5
  • 1
    $\begingroup$ This is largely the approach i am taking myself, Homebrew is an excellent bellwether for platform support for macOS hardware because they have a significant percentage of the macOS experts within the FOSS community working with them. Hopefully it won’t be long, but part of me also hopes that GCC is never supported on M1 hardware, because that will be enough of a kick in the pants that many of the holdouts in the FOSS community need to get their projects working properly with the LLVM compiler stack. $\endgroup$
    – Austin Hemmelgarn
    Commented Dec 9, 2020 at 19:36
  • 11
    $\begingroup$ As an open source developer for more than sixteen long years now, your entitlement is showing. Are you paying some developers to make their projects work with LLVM? If not, who do you think you are to insult people who give you free work as "holdouts"? $\endgroup$
    – chx
    Commented Dec 10, 2020 at 8:25
  • 3
    $\begingroup$ @AustinHemmelgarn I'm with chx here. It is work to port codes to a new compiler. There's also the fact that GCC is actually an excellent compiler that has served the community very well for more than 30 years now. $\endgroup$
    – Wolfgang Bangerth
    Commented Dec 10, 2020 at 14:56
  • $\begingroup$ Isn't M1 just ARM? Of course GCC supports ARM. $\endgroup$
    – user21829
    Commented Dec 10, 2020 at 16:08
  • $\begingroup$ @user253751 macOS has slightly different calling convention than GNU/Linux operating systems. $\endgroup$
    – DannyNiu
    Commented Dec 11, 2020 at 0:58
8
$\begingroup$

From this, it looks like there is no functional native Fortran compiler yet. If that is really the case, things look bleak. Almost anything that uses linear algebra includes some Fortran code (Lapack), and it has to run fast.

Improve this answer
$\endgroup$
7
  • 3
    $\begingroup$ Given that M1s appear to run Intel code in emulation faster than existing Intel Macs, is this really an issue? It's faster, it's just not as much faster as a native compiler could achieve. $\endgroup$
    – chepner
    Commented Dec 9, 2020 at 18:21
  • 1
    $\begingroup$ @chepner According to which benchmarks? Scientific code has a very specific workload and uses different instructions than office work or videogames. $\endgroup$
    – Federico Poloni
    Commented Dec 9, 2020 at 19:15
  • 3
    $\begingroup$ Maybe, but until you observe your code running slower, there's no problem. The lack of a native Fortran compiler may simply be sub-optimal, rather than a setback, and it may also only be temporary. $\endgroup$
    – chepner
    Commented Dec 9, 2020 at 19:23
  • 2
    $\begingroup$ @ch I agree, this is just an educated guess. I am not an expert in compilers, but it seems to me that past practice teaches that machine-specific compiler optimizations and vectorized instructions have a big impact on the performance of code. It would be surprising to me if the picture for the M1 were different. I realize that to answer this question properly we need benchmarks --- which is, ultimately, what OP asked for. $\endgroup$
    – Federico Poloni
    Commented Dec 10, 2020 at 7:43
  • 2
    $\begingroup$ There is at least one functional native FORTRAN compiler nag.com/content/nag-fortran-compiler but it is not open source as noted in the link you gave $\endgroup$
    – mmmmmm
    Commented Dec 10, 2020 at 11:42
5
$\begingroup$

Iain Sandoe has been working on porting both gcc and gFortran to this architecture. Based on this, François-Xavier Coudert has created an experimental gFortran release for the M1. I provide a few Fortran benchmarks here. Presumably this was used for the miniforge Python release that provides a M1 native numpy. One also suspects this is what leman used to provide native M1 benchmarks for R. However, it is unclear how that build deals with R's usage of not-a-number values. It is clear Tomas Kalibera and Simon Urbanek are working on a robust native R solution, but they have not provided a timeline.

I provide benchmarks for a lot of neuroimaging data on Github. The challenge with scientific computing is that there are a lot of different niches. The nature of neuroimaging data means that pipelines tend to be limited by memory bandwidth, not computational power. This allows the M1 to excel in this domain, but my findings may not generalize to other domains.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.