Re: apple silicon fortran

[Iain Sandoe <idsandoe@googlemail.com>]

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