Just a data point. Apple replaced GCC with Clang some years ago. GCC produces faster binaries for SWI-Prolog. GCC is rumoured to be better in optimizing large functions and the Prolog virtual machine is a giant function. The SWI-Prolog VM can also be compiled (due to the work by @dmchurch) implementing each VM instruction as a function. This introduces function call overhead. On Clang, both versions have roughly the same performance.
When the Apple M1 came out, Apple Clang was the only available compiler. At some point Macports came with GCC (I think 11). The gcc version suffered from stability issues and the performance difference was small. I just tested with the latest GCC (15). Now the default benchmark set runs at an average of 0.063 sec using Clang and 0.043 using GCC. Unlike on x86_64, using PGO (Profile Guided Optimization) or not makes little difference (0.043 (PGO) vs 0.045). Tests on Macbook Air M1.
Unfortunately GCC cannot produce “fat” binaries, which makes it impractical to use GCC for releases
So, if you use MacOS, compile from source and care about performance, use GCC!
The bottom line seems to be that Clang is required to produce fat binaries but is less performant than GCC on both Intel and Apple silicon CPU’s.
Currently, for stable releases only, there is an Intel GCC build for MacOS. Is it worth considering a similar “slim binary” for stable versions running on Apple silicon? This would be a useful “stake in the ground” for those evaluating whether they need to build from scratch, and might benefit those who aren’t in a position to do their own MacOS builds (he says, raising his hand).
That is one line of thinking. I’m not sure. One of the problems is that the not-signed version of the bundle raises a lot of security alerts. That must be solved by splitting SWI-Prolog into a Framework (library) and application. I’m still hoping someone can help getting that done. I’m ok paying for an Apple developers status to do the actual signing. I don’t know how to do the split giving the CMake/CPack based build and bundle generation.
That is of course a bit of a side issue, but part of the whole picture getting a good version for MacOS. Other things on the table:
Get Homebrew to include xpce/swipl-win. I’m trying to get into contact. So far without luck.
Get Both Homebrew and Macports into using gcc, either as default or variant. The Macport maintainers are very cooperative, so that can probably be done.
Somehow neither Macports nor Homebrew provide a cross compiler version of gcc to generate x86_64 code on Apple Silicon. They do have several cross compilers, including x86_64, but building ELF executables. I do not know the purpose of that. I think I’m missing something. If we had that, we could build a performant fat binary by building both for arm64 and x86_64 and then combine the two using the Apple lipo tool. That requires a bit of scripting, but that should not be too hard. Currently I do the same for the dependencies as some of them cannot be cross-compiled. So, I build on an Intel and M1 mac and then combine them.
