apple silicon fortran

[James Secan]

Iain,

Thanks for the update and all the work.  I’m looking forward to seeing all this working natively on Apple’s new architecture.

Jim
Seattle, WA
> On Jan 12, 2021, at 2:13 PM, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> Hi Folks,
> 
> Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
>> James Secan <james.secan@gmail.com> wrote:
>>>> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
>> 
>>>> I am testing out the Rosetta 2 alternative (which is, AFAIU, a binary-conversion done at install-time native on macOS).
> 
> OK so I haven’t yet found a way to trigger the install-time translation, perhaps it only works on a fully packaged and signed app.
> 
> - however, the “on demand” conversion clearly works.
> 
>>> I am interested to hear the results of your testing with Rosetta 2.
>> 
>> I bootstrapped x86_64-apple-darwin20 on aarch64-darwin20.3, and currently running the Fortran testsuite - it’s not clear to me if some of the issues (PIE and no-executable stack) will be sidestepped or not.  We shall see.
> 
> Summary : some pretty good parts, but not enough to be a drop-in replacement.
> 
> [ disclaimer : the testsuite is somewhat ‘noisy’ at the moment, we have some tidying to do before release…]
> 
> here’s the native (x86_64-darwin20, on an Intel skylake processor):
> 
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-January/644184.html
> 
> here’s the same branch bootstrapped for aarch64 and x86_64 using Rosetta 2 on an A12Z processor (I don’t have access to an actual M1 yet).
> 
> https://github.com/iains/gcc-darwin-arm64/issues/30#issuecomment-758890255
> 
> — inferences and testing:
> 
> * It seems that Rosetta 2 + whatver sandboxing is in place is allowing diabling PIE (which means that PCH works again) but *NOT* allowing executable stack, which means that [GCC default implementation] nested functions are still broken (and gfortran uses nested functions ‘under the hood’ so to speak)
> 
> * informal testing on a couple of random Fortran benchmarks I have on that machine suggest that the binary translation gives pretty good performance for numerically intensive stuff (but again, disclaimer - that was [a] on an A12Z and [b] not carried out in any strictly controlled manner).  OTOH, I expect it’s not completely misleading.
> 
> Conclusion.
> 
> Rosetta 2 + Arm64 is not a drop-in replacement for x86_64 gfortran, we still need an ABI-compliant solution to the nested function issue - I do have an idea - but it isn’t a stage4 kind of thing.
> 
> If your machine breaks and you have to replace it, or your employer requires you to use an arm64 model, then I would suggest that the native branch is probably a better bet in the short-term - that has a workaround for the nested function issue (but that can give challenges in interworking with C, although those might not be insurmountable) ..
> 
> We’ll get there, I am sure - but not this week ;)
> 
> cheers
> Iain
>