Well I could have made a Boyer-Moore version or something more sophisticated that's what you focus on, but I pointed
that memory requests are significantly slower on Clang than with a simple VM host. Or a Windows Bootcamp. The code is
just a pretext to test the kernel in this case.
Post
Replies
Boosts
Views
Activity
Well if we get rid of my code and focus on the std::string from the standard library the gap in performance
stays significant between the guests virtual machine and the Mac host.
I find it surprising and probably nothing can be done to reduce this gap.
Well it's surprising that the Linux guests virtual machine codes ( and windows Bootcamp ) run that much faster.
Oh fine ! -march=haswell works perfectly and allows to recover run time performance . Thanks a lot .
So -march=native has no more sense for this Intel architecture.
The right FB is
FB13253046
With option -###
apple-macosx14.0.0 is invoqued is it right ? or apple-macosx15.0.0 ?
the -march=native is effective but it makes code slower . With the previous version -march=native made the code faster.
Is the disk crypted by défault with Sonoma which could make code slower ?
-march=native seems to be critical with Intel
Can you give an example of -###
So -Ofast for example
At this time clang 15.0 is 2 times slower than the previous version on Intel 2020 MacBook Pro and Sonoma
I suppressed -march=native so have g++ -std=c++17 -Ofast -funroll-loops -flto -DNDEBUG -o a prog.cpp
Any idea to improve performance ?
So at this point we notice that gnu c++ or clang++ is 2 times faster than Apple clang on virtual
machines like vmware and virtualbox emulating linux. The guest's compilers are running faster than the host ones !
A strange surprise .
now I added -fslp-vectorize it's getiing better only 2 times slower instead of 5 .
The -Ofast option works fine and has effects with :
Mingw C++ on Windows
gnu c++ on Linux
but not any more with clang 15.0 MacOS
After test -Ofast does not produce anymore optimisations . The problem comes from -Ofast.
It should work with clang 14.3.1 but this not a solution