We will not update ifort to officially support any version of macOS for Mac computers with Intel Processors after macOS 13. In our current plans, macOS 13 is our last supported version for our ifort compiler.
Will Intel provide the Intel® Fortran Compiler for macOS?
No. We have never provided our new LLVM-based Intel® Fortran Compiler, also known as “ifx”, for macOS for Mac computers with Intel® Processors. We have no current plans to do so.
Will Intel provide the Intel® Fortran Compiler for macOS for Mac computers with Apple silicon?
We have no current plans to support non-Intel (or non-Intel-compatible) processors with our compilers. In addition, we do not support our compilers running under emulators.
It is brave to ignore such a big market share. What compilers are still available under macOS and support the Apple silicon chips? Only gfortran (thank the gfortran community)? What about LFortran @certik ?
Yes, LFortran supports Apple Silicon natively (together with Apple Intel, Linux, Windows and it also runs inside a web browser using WebAssembly). Apple M1 is my main development platform in fact. LFortran is available in Conda for all platforms (just do conda install lfortran), the macOS/Linux is well supported, the Windows support is not as well tested, but we will catch up once we reach beta. Right now LFortran is in alpha, you can follow our progress at https://lfortran.org/, there is a nice progress bar there. Our goal is to run on every platform and every accelerator eventually.
Well, Intel is distributing software (compilers, libraries,…) only to support their hardware sales, which is their core business. So the decision looks logical.
At one time, intel was considered as one of the companies that would manufacture Apple’s arm chips. If that had happened, then I might have expected ifort/ifx to support arm chips.
Apple users have gone through hardware changes several times in the past. The first Macs used Motorola 68xxx CPUs, and there were several fortran compilers for them – I used MS Fortran, Language Systems Fortran, and (I think) ABSOFT fortran. Then Apple switched to PowerPC CPUs and I continued to use Language Systems Fortran and ABSOFT fortran, and later when MacOSX was released (big step forward!) I used g77, ABSOFT, IBM XLF, and gfortran. Then Apple switched to intel CPUs, and I used ABSOFT, ifort, and gfortran. When Apple switched to its own arm CPUs I am now using gfortran and NAG fortran. There has always been a compiler that continued through the hardware change, some compilers dropped, and new ones become available. There were other fortran compilers running on Apple Macs during that time too, including f2c if you want to count that, and I think Silverfrost and Portland Group; the ones listed above are just the subset that I used.
In the late 1980s, Apple also sold a unix OS that ran on the 68xxx Macs, called A/UX. It came with a C compiler (as did most unix machines back then), but I think there were also some fortran compilers that ran on it. I did not use A/UX enough to remember which fortran compilers were available. I do remember that many Mac developers used A/UX to develop codes for the classic MacOS because it was easier to use than the Apple MPW environment. I don’t think A/UX survived the Motorola to PowerPC hardware change. Instead there were plans to merge with IBM’s unix called AIX. For some reason, that did not happen, and it would then be several years later when MacOSX would bring unix to the Mac, this time as the main OS, not just a developer OS.
It was a “marketing proposal” from the boss of Intel, but I doubt it has been ever seriously considered… Intel was significantly lagging behind ARM chips founders in terms of processes, and this participated to the decision of Apple to abandon Intel chips. Intel could not really compete with TSMC at that time.
Intel is progressively catching up, and it seems that there are plans to produce ARM chips in Intel factories, but I’m not sure they will be designed by Intel anyway.
Does “they” in that sentence refer to the chips or to the factories?
I think the new intel LLVM compiler compiles to the same intermediate language regardless of the underlying hardware. It is the last compilation step, the translation from the intermediate language to the machine instructions that depends on the hardware. So if they chose to do so, intel could have supported their compilers on arm hardware by using their LLVM front end, unmodified for the most part I would think, and combining it was the arm-specific back end that is supported and maintained by Apple and others. That is the technical side of the issue. Of course, the arm hardware is now a competitor to the intel hardware, so there are business and marketing factors involved too.
Current users of Apple machines will continue to use the intel machines for probably five to ten years. I have a 2013 MacBook Pro (intel) that I used until 2022 when I replaced it with an arm laptop. That was also when the latest MacOS versions were no longer supported on it. I used the ifort compiler on it all that time, and I still boot it up and test things on it with the last installed compilers that worked on it. Ten years is pretty good for a laptop – typically some keys start to break, or some of the ports start to fail, or the screen hinge starts to short out. I was lucky with this one, everything still works on it good as new. I’m typing this now on an intel Mac Pro from 2011. It also no longer runs the latest MacOS versions, and I have an even older version of the intel compiler on it. I replaced the keyboard on it a few years ago, but other than that, everything still works on it too, even the original internal disk drives. I’m expecting to replace this one in the next few months, maybe a Christmas present. You have to give Apple credit for making good hardware, but in my opinion they end-of-life their software too soon. People end up throwing away good working hardware just because the new software no longer supports it. Those are business and marketing decisions by Apple, not technical ones.
For the strict compiler part, yes. But they would also have to port and maintain their libraries, notably the MKL that is finely tuned for the hardware it runs on, with some parts in assembly AFAIK. And have a specific maintenance/support line for ARM, etc…
Still, it’s a pity that they stop the support og Intel Macs beyond macOS 13… This is probably motivated by the declining installed base of Intel Macs, particulary among people who are crunching numbers…
It’s a good point about MKL. I would not have expected them to make an ARM one.
But the loss of the compiler is a huge blow to the overall Fortran community. Having a free production-ready up-to-date compiler with significant developer effort behind it available on all three major platforms was great while it lasted. And now we don’t really have that anymore. We are back to a mix of compilers that are either not free, are free but aren’t fully F2018 compliant or don’t have a lot of developers behind them, and great compilers that don’t work on all platforms.
I do not know any professional handymen that expect their professional tools to be “free”, and even hobbyists like to collect expensive “kit”, yet software professionals all too often seem determined to insist that the fruits of their profession are worthless. Surely that is not sustainable.
Intel at one time made very good ARM chips - they acquired the StrongARM processors from DEC, renamed them Xscale. Then sold off the ARM business.
Compilers from hardware vendors exist to make that vendor’s hardware look good. Apple has always been a pain regarding non-Apple compiler support, making incompatible changes in libraries and refusing to allow enabling Fortran build dependency analysis or debugging in Xcode.
It is a shame - there are some big Mac fans in the Intel Fortran team, but I don’t see that Intel could have done anything different here. Mac support was already hobbled by the lack of Intel MPI there, so coarrays were not supported on Mac. Fixing this by using some other MPI just wasn’t worth it.
Apple offers Accelerate, although it isn’t a 1-to-1 match for MKL. At least BLAS and Sparse BLAS, LAPACK, FFT’s and a few other things are available in Accelerate. The documentation only shows these as Objective-C and Swift API’s, but in practice I’ve found it’s always (pure) C at the bottom. The drudgery of writing bindings is unavoidable however, even if it’s just a 1-time cost.
Intel could have supported Apple without Xcode. For coarrays there might also be some solution. But it’s more work and it’s for non-Intel hardware, so it’s understandable they don’t want to do it.
However, it means the commercial hardware vendors cannot be expected to provide a solution for all platforms. Consequently, an open source community solution (possibly backed by one or more hardware vendors) seems like one way forward that is sustainable. A commercial tool from a non-hardware vendor is another.
I agree. Also, it is good for programmers to be able to use a given compiler on multiple hardware and OS combinations (e.g. gfortran on intel, amd64, and PowerPC and on various Windows, unix, and linux OSs).
But professional handymen also visit public schools and can study their trade from professional books at public libraries. It’s not just about the right to use a certain piece software, but also the freedom to study and change it. Just because something is offered for free, it doesn’t mean it can be characterized as worthless, quite the opposite.
Don’t get me wrong, I have nothing against commercial software. My favorite text editor, Sublime, is also licensed, and I think it is fair that it’s developer can make a living out of it.
