Cross Compiling with Meson vs Autotools is causing performance regression #9080
Comments
|
I am not sure if you have already done that, but comparing the actual compiler invocations ( |
|
@xclaesse From what I can tell from skimming through dosbox-staging/dosbox-staging#1174 it is a runtime issue. |
|
@mensinda yes I realised that after posting so I deleted the comment, but too late :D |
|
Awesome that there are already feedback coming in on this! Thank you everyone. Yes, correct, this is a runtime issue. Here's a sample output of ninja -v: And here's make V=1: Just to clarify - I have not specified any build flags manually in either case, both are using what's been defined by default in the buildroot environment and the project files |
|
|
|
Could be related to #7760 ? |
I have been trying to figure out where that's coming from since I posted that... it doesn't seem to be getting added manually anywhere and I can't seem to override the flags to omit it. |
-Db_pie=false is hard-coded into the buildroot meson package so it will always be set for any meson compiles. |
|
I did not follow exactly the PIC story lately, @bonzini surely can help. Try with |
|
Just discovered -Db_staticpic=false removes it, about to see if there's any difference in the compile |
|
That does, in fact, seem to be the culprit! Will do some additional compiles to confirm, but it's looking really good! How would I change this to be the new default for meson? Or does it need to be baked into the meson.build files for the project? |
|
Those options should be added to the |
|
Since dosbox-staging presumably really wants this (because it's a performance improvement in this use case), you'd add the -D option to |
|
I don't remember why, but most distro enables pic/pie by default nowadays, so meson did too. IIRC it's a tradeoff between performance and security somehow? Not sure. |
|
The other option might be, doing this in a granular manner per-target for And yes, it's a security tradeoff -- which generally doesn't cause noticeable performance penalties, but might be for dosbox. |
|
Actually, our pic thing is annoying. Setting b_pic=false just means "do the compiler default", which generally means you can't actually turn pic off on Linux. I had patches for that, but they caused a regression, because they changed the meaning of false. I should dust those off again |
|
Thank you ALL! I've issued a PR for dosbox-staging to address, and can confirm it resolves the issue against their head-commit. Closing this. |
|
@dcbaker Currently we have the choice between "enabled" and "compiler's default", right? I wouldn't be surprised the performance hit is worse on ARM, which is why their cross toolchain does not enable it by default? |
|
@xclaesse, yes, exactly. Linux distros turn on PIC by default, IIRC, because ASLR requires PIC for libraries and PIE for executables to work, and the (usually) small performance trade off is worth it for the considerable security benefits for ASLR. |
The meson build system adds -fPIC during compile, which has a negative performance impact. Adding this flags tells meson not to add this flag. Resolves this issue: #1174 Further info: mesonbuild/meson#9080
The meson build system adds -fPIC during compile, which has a negative performance impact. Adding this flags tells meson not to add this flag. Resolves this issue: #1174 Further info: mesonbuild/meson#9080
The meson build system adds -fPIC during compile, which has a negative performance impact. Adding this flags tells meson not to add this flag. Resolves this issue: #1174 Further info: mesonbuild/meson#9080
I've discovered that when building the dosbox-staging repo that there is a performance loss when compiling the exact same code-base on meson versus autotools.
https://github.com/dosbox-staging/dosbox-staging
You can review my research and progress on this issue here:
dosbox-staging/dosbox-staging#1174
I am using the buildroot toolchain and building for an ARM Cortex A53 board. To confirm the issue, I have removed all custom build flags from the buildroot package so that the environment uses all defaults.
In an attempt to resolve, I have modifying the buildroot pkg-meson.mk file in my build so that it includes the same environment variables as autotools. This has had no effect.
I'm going to paste the resulting compile output directly into this comment rather than using a pastebin, since those tend to expire. First the autotools output, then meson output, both with only default flags used.
AUTOTOOLS:
MESON:
As you can see, I have now modified buildroot itself so that when building with meson it includes all the same default environment variables and config settings as it does with autotools.
In buildroot, Meson uses an SED command to create a cross-compilation.conf file that it uses to generate build commands for all files in the project which is then stored in the build/compile_commands.json file within the dosbox_staging source folder at build-time.
Here is an example from the json file for compiling cpu.cpp:
In an attempt to resolve, one other change I did to dosbox-staging was to patch meson.build to use gnu++14 instead of c++14 (since autotools is using gnu). Sadly, no change in behavior here either.
The devs over at dosbox-staging suggested I reach out here next. I've been actively comparing the two build environments and things are looking to line up closely now.
Just to make things exact, I even tried patching gnu.py to use -MT instead of -MQ, but sadly the issue still did not get resolved.
It's possible that the dosbox-staging meson.build file is missing some flags used by the project, but I went as far as pulling ALL defined flags from the autotools configure results and manually setting them in the meson cflags and cxxflags. Sadly this also had no effect.
I theorize that there is an environment variables that meson isn't uses which autotools does which is causing this regression.
My next thought in trying to resolve is trying to figure out how to tell meson to use the defined default linker that autotools is using (in the environment variables) - as meson appears to be listing the compiler as the linker:
DEFAULT_LINKER="/home/adam/output/host/bin/arm-buildroot-linux-gnueabihf-ld"
C linker for the host machine: /home/adam/output/host/bin/arm-buildroot-linux-gnueabihf-gcc ld.bfd 2.32
C++ linker for the host machine: /home/adam/output/host/bin/arm-buildroot-linux-gnueabihf-g++ ld.bfd 2.32
C linker for the build machine: /usr/bin/gcc ld.bfd 2.26.1
C++ linker for the build machine: /usr/bin/g++ ld.bfd 2.26.1
But at this point I am open to any and all ideas, as my box of tricks is about empty and at this point I'm grasping at straws.
The text was updated successfully, but these errors were encountered: