Performance: -fno-semantic-interposition compiler flag
dumblob opened this issue · 9 comments
I'd propose using -fno-semantic-interposition for -prod builds to get slightly increased performance (for Python 3 it's up to 27%).
It prevents LD_PRELOAD tricks in V itself, but I don't think it's a big issue as external libraries (e.g. libc) shouldn't be affected.
See http://hubicka.blogspot.com/2015/04/GCC5-IPA-LTO-news.html (scroll quite far down).
This could break some aspects of hot code reloading but is probably the correct thing to do.
Just tried it for v self on M1.
Alas, no difference. Will test x64 machines too.
i.e. at least for V itself, there is no difference on Linux x64 too; the produced executables are identical.
For a smaller program like examples/hello_world.v, there was a difference in the produced executables:
When combined with LTO, it provides higher gains than if LTO is used without -fno-semantic-interposition.
For pure-V apps this will make either no difference or very marginal gains. But for real apps where one calls out to shared libraries etc. this has nice gains as demonstrated on Python.
When combined with LTO, it provides higher gains than if LTO is used without
-fno-semantic-interposition.
-prod does pass -O3 -fno-strict-aliasing -flto
I've also tested other computationally intensive programs like examples/path_tracing.v and examples/gg/mandelbrot.v - there is no meaningful difference at runtime, besides making the compilation a few seconds slower.
The "real" apps that can benefit and are sure about that, can pass this already using -cflags -fno-semantic-interposition as demonstrated. That flag however is not beneficial for most V apps => there is no point in adding it by default, since it will just slow down -prod compilation.
as demonstrated on Python.
Note that Python programs by their nature, to have any hope of being performant, have to call to other libraries much more often, than V programs have to, so what may be beneficial for them, will not necessarily benefit V programs.
That flag however is not beneficial for most V apps
Oh, I did not know that. Does that mean than V's important goal is to put interoperability at the binary library level at a backburner (and instead promote interoperability at the source code level)?
I was not aware of this goal in which case -fno-semantic-interposition makes no sense, of course.
there is no point in adding it by default, since it will just slow down -prod compilation.
Yep, this might be an issue and a reason to not add it by default if the goal is really to give source-level interoperability 100% precedence over binary library level interoperability.