[R-SIG-Mac] R, FORTRAN and Apple Silicon

[John Helly]

Aloha.

At the risk of being a voice from left-field, there are a few
observations I'd like to add in a constructive spirit.  I see now that
they don't  sounds constructive but think about the strategy for the
next 10-20 years.

 1.

    I have bitten the bullet and switched to macports for most GNU-type
    software.  I still roll-my-own for things like GDAL and GMT since
    macports doesn't always have what I want.  I do use it for compilers
    and related development tools for the most part and it has been ok
    most of the time.  I'm not advocating maports per se but one needs
    an escape hatch from Apple's clutches as long as it's moderately
    useful. 

 2.

    Brew, macports they are headed in the same direction as Red Hat
    Linux but the spirit of the open-source community has deflated
    because of the proliferation of dependencies and the time require to
    make anything work.  Is there any hope of ever getting that back? 
    Probably not, since we're all dying off and being replaced by people
    who have grown up being dependent on vendors.  This is what happened
    in centralized computing in the 70's before the personal computer
    revolution.  Now it's centralization again.

 3. I've also accepted the fact that Apple has been closing-down its
    open-source universe for years (maybe decades) now and I maintain
    *nix servers as an alternate against the day that the next OSX
    release blows everything away.  Catalina came close, maybe still
    will but the pattern is clear.  Apple is going entirely proprietary
    and has been for a long time.  The open-source community will have
    to abandon Apple in the not so distant future.  Many have already. 
    I've got tons of Apple hardware but resigned to the fact that it
    will be only useful for audio-visual 'stuff'.
 4.

    Perhaps a major shift out of Apple hardware is needed to re-vitalize
    the open-source community that has gotten lazily dependent on
    Apple's ex-Unix-like alter ego.  That alter ego is turning into the
    Invisible Man.  Pretty soon we will be stuck between a brick and an
    Apple.

J.

On 8/24/20 15:11, Simon Urbanek wrote:
> Jim,
>
> thanks for the update, yes, we are aware and we have an ADP now, too, and are assessing the issues. I got base R working using f2c as a stop-gap measure, but it doesn't pass all checks due to fp issues (not necessarily related to Fortran) so there are more moving parts to this. It would be good to be involved in the discussions, so any pointers are welcome.
>
> Thanks,
> Simon
>
>
>
>> On Aug 25, 2020, at 2:12 AM, Jim Hester <james.f.hester using gmail.com> wrote:
>>
>> I recently inquired about the progress of gcc (more specifically gfortran)
>> support with Apple's new 'Apple Silicon' architecture. [0]
>>
>> As of today it seems gfortran is not available natively, which has
>> implications for R support on upcoming Apple hardware.
>>
>> Subsequently I have been in email contact with a few people at Apple on
>> their progress and wanted to update those here.
>>
>> They also have some questions on what features we rely on in the R
>> community that I thought some on this mailing list would have better
>> insight in answering than I.
>>
>> I would be happy to give the apple contacts information off-list, or CC you
>> into the email thread if you would like. Alternatively I can communicate
>> our answers back to them myself.
>>
>> Also I have a Developer Transition Kit at home, so I can run tests if it
>> would be beneficial.
>>
>> Apple's response follows
>>
>>> We've been working with Iain on figuring out a path forward for gfortran,
>> they recently published a branch
>> https://urldefense.com/v3/__https://github.com/iains/gcc-darwin-arm64*readme__;Iw!!Mih3wA!XBd8e0aklPimxl7B4w7FK7p3Z_EjeXxQRUyaT8xsKavf2ftfTcos4EzlgerUXig$  with some early support in
>> gcc. We are aware of some of the issues with FP80 vs FP64 and our last
>> internal discussion was trying to ascertain how relevant and important FP80
>> is in the fortran community. There are some complexities with FP80 (and
>> higher) that are going to make it not very timely, even native, on Apple
>> silicon. If we could set aside FP80+ as not critical it would allow us to
>> focus on FP64. What are your thoughts?
>>
>>> I think we are able to support technical discussions if people have
>> questions and we've made hardware available to individuals as
>> needed/requested as well.
>>
>>> I did see those tweets when they were posted, we'd already been
>> discussing Fortran with several vendors that depend on it, like Matlab.  It
>> would also be good to understand example workloads that are important so we
>> can take a look at them on Rosetta today, since any effort to go native
>> will likely rely on some period of Rosetta as a fall back and we'd like to
>> ensure thats feasible.
>>
>> [0]: https://urldefense.com/v3/__https://twitter.com/jimhester_/status/1292821727165194240__;!!Mih3wA!XBd8e0aklPimxl7B4w7FK7p3Z_EjeXxQRUyaT8xsKavf2ftfTcos4EzlsekNOpo$ 
>>
>> 	[[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!Mih3wA!XBd8e0aklPimxl7B4w7FK7p3Z_EjeXxQRUyaT8xsKavf2ftfTcos4EzlIHqWQUQ$ 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac using r-project.org
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!Mih3wA!XBd8e0aklPimxl7B4w7FK7p3Z_EjeXxQRUyaT8xsKavf2ftfTcos4EzlIHqWQUQ$ 

-- 
John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / http://www.sdsc.edu/~hellyj
ORCID ID: orcid.org/0000-0002-3779-0603


	[[alternative HTML version deleted]]