# Why is the Intel compiled executable that much faster than gnu? **URL:** \ **Category:** Uncategorized\ **Created:** [July 24, 2025, 11:15am UTC](https://fortran-lang.discourse.group/t/why-is-the-intel-compiled-executable-that-much-faster-than-gnu/9947 "2025-07-24T11:15:17Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 24, 2025, 5:38pm UTC](https://fortran-lang.discourse.group/t/why-is-the-intel-compiled-executable-that-much-faster-than-gnu/9947/5 "2025-07-24T17:38:04Z")
> [@apetros85](#): > > I’ll try the trick with the Mac but I don’t own a mac, so the user will have to do it. On the mac, you will find that `-framework Accelerate` is much faster than `-lopenblas`, however, I think you lose some fine control over the multithreading behavior because the apple library does some of its own multithreading internally. Also, if you need to use some of the single precision blas functions, the apple library has some of the common precision errors that occur in many blas libraries. The openblas library on the Mac does **NOT** have these errors. This is discussed here. [How many BLAS libraries have this error?](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454) There is a workaround for these errors, so that is another option. Apple has been notified of these library errors, several years ago now, but I think they still persist because the library test suite also has the error, so if you just correct the error in the library, it appears to fail the tests. One must also correct the test code together with the library code. We all have the K&R C compiler convention to thank for this decades long programmer mess. --- _[View the full topic](https://fortran-lang.discourse.group/t/why-is-the-intel-compiled-executable-that-much-faster-than-gnu/9947)._