Indirect function call penalties

[Jakob__Wenzel]

The book “Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition” has the following to say about indirect function call penalties due to shared libraries:

The indirect branch predictor assumes that the branch destination is in the same 4 GB chunk of the virtual address-space as the indirect branch instruction (note for these purposes a “ret” is an indirect branch instruction). Since indirect branches are used to enter dynamic shared libraries, which are normally scattered through the virtual address space, calls into DLLs incur two misprediction penalties (one on the call and one on the return).

[..]

An updated version of the dynamic linker (ld.so) is shipped with some OS releases. If requested, it will try to place all shared libraries into the low 4 GB of the address space, to avoid the mispredictions on shared library calls. If this linker is installed, setting the environment variable LD_PREFER_MAP_32BIT_EXEC is likely to improve performance.

Since my application uses function calls into shared libraries as part of a plugin architecture, I'm concerned about these penalties and would like to use LD_PREFER_MAP_32BIT_EXEC.

However: the ld.so feature mentioned here is only supported on glibc>= 2.23, which is newer than the glibc version that ships on the Intel "reference distribution" for Xeon Phi development, which seems to be the latest CentOS/RHEL (this was what was installed on Intel Developer Access machines from dap.xeonphi.com).

Will Intel back-port this patch and ship it with RHEL/CentOS? Or is there some other way that glibc can be updated safely on these systems?

Thanks,
Wenzel

[Jakob__Wenzel]

(FWIS This is on Knight's Landing pedestal machine from http://dap.xeonphi.com/)

[Lukasz_A_Intel]

Hi Wenzel,

If it's an option for you and you have RedHat subscription, please go ahead and try public RHEL7.3 beta:

https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-73-beta-now-available

Let me know if that works for you.

Cheers,
Lukasz

[Jakob__Wenzel]

I thought about this but became corned about the amount of work involved in reinstalling RHEL7.3 beta from scratch (upgrades from RHEL7.2 are not supported by Red Hat) and reinstalling from scratch yet once more when the final RHEL7.3 is released (upgrades from beta releases are also not supported by Red Hat).

If this will be part of RHEL 7.3, I guess I will just have to wait unless you have another suggestion.

[Jakob__Wenzel]

Dear Lukasz,

I'm confused -- I've just installed RHEL 7.3 as recommended by you now that is officially available.  However, the default "ld.so" in RHEL7.3 does not seem to support LD_PREFER_MAP_32BIT_EXEC. The version of glibc that ships with 7.3 is version 2.17 rather than 2.23, and there is no mention of LD_PREFER_MAP_32BIT_EXEC in the "ld.so" man page, which should be the case if RedHat backported the feature.

Please advise.

Thanks,
Wenzel