It should work with clang 14.3.1 but this not a solution

After test -Ofast does not produce anymore optimisations . The problem comes from -Ofast.

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

now I added -fslp-vectorize it's getiing better only 2 times slower instead of 5 .

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 .

So -Ofast for example

Can you give an example of -###

-march=native seems to be critical with Intel

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 ?

The right FB is FB13253046

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.

Well it's surprising that the Linux guests virtual machine codes ( and windows Bootcamp ) run that much faster.

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 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.