From: Bill Fischofer [mailto:[email protected]] Sent: Saturday, September 10, 2016 8:01 PM To: Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> Cc: LNG ODP Mailman List <[email protected]> Subject: Re: [lng-odp] [PATCH] linux-gen: build: de-couple abi compatibility from shared lib
On Fri, Sep 9, 2016 at 5:25 AM, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> wrote: From: Bill Fischofer [mailto:[email protected]] Sent: Thursday, September 08, 2016 9:17 PM To: Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> Cc: LNG ODP Mailman List <[email protected]> Subject: Re: [lng-odp] [PATCH] linux-gen: build: de-couple abi compatibility from shared lib On Thu, Sep 8, 2016 at 5:24 PM, Petri Savolainen <[email protected]> wrote: Building ABI compatible or shared library are two different targets. A shared library may be used also without ABI compatibility. A new --enable-abi-compat configuration option is introduced. By default libraries are not built in ABI compat mode to enable function inlining. There is a noticeable performance difference when e.g. odp_atomic_xxx calls are not inlined. Do we have quantification of this difference? I think the problem is that it's not clear what the use case is for shared-but-not-ABI-compatible builds since these cannot be part of any distro. If they're just being used privately, then why not just specify shared=no and get the full advantages of whatever inlining the implementation can offer? I have no problem with changing the control from today's shared=yes|no to something like profile=embedded|cloud if that would be more descriptive of the intent. With regard to the atomics, it may be possible to inline these and still be ABI compatible, in which case this could be added to the "cloud" (shared) profile standard, however careful testing would be needed and it would also mean that these routines could never be changed since any change would break compatibility. Prohibiting inlines of any kind remains the safest way to ensure that there are no implementation dependencies. Having shared=yes be the default seems to make sense since those interested in running in embedded environments for maximum performance would be expected to have no problem specifying additional options, while those using ODP on an initial/casual basis would enjoy the benefits of ABI compatibility at no extra effort. <answer to HTML mail> --------------------- E.g. with scheduling test I can see 6% performance degradation when inlining is disabled, and it's now disabled by default in the repo. In case of fast path application, building for ABI compatibility is a special case and thus by default inlining should be enabled. Whether I link against shared or static lib is orthogonal to if I what to build against the ABI spec (this same switch would also force that). I'll use --enable-abi-compat only if the same application image needs to run with different implementations or in an unknown environment. In the typical case, the implementation is fixed and I'll build in the normal mode (no ABI spec needed => maximum performance needed => inlining preferred). When a (new) user downloads and tests odp-linux (or odp-dpdk), he'll very likely build, run and measure performance locally (either with shared=yes and/or static=yes linking). If he needs to building an application for cloud also, he'd need to do some extra effort (define --enable-abi-compat and maybe other options as well). So it sounds like you're simply arguing that the default should be changed to --enable-shared=no. Otherwise, what is the use case for wanting a shared library that isn't ABI-compatible? I'll add this to the Monday ARCH call for discussion. <answer to HTML mail> --------------------- If you do: ./configure --help --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] So, by (automake) defaults both variables are "yes" and both libraries are built, which is OK. Some applications are built against static and some against dynamic libraries. Whether those libraries are built against the ABI spec is another option (which my patch set adds). By default, ABI spec is not needed since applications are built against single implementation and libraries are consumed locally (and performance should be maximized). ABI spec is needed when applications and/or libs are built for export (mix of apps and implementation libs is unknown). "what is the use case for wanting a shared library that isn't ABI-compatible" For example, * usage of dynamic libraries decrease L3/L2/icache pressure when multiple programs re-use (the same library) instructions * app image size will be smaller (less memory / disk space) * easy to check the library version used (from the central location rather than embedded into every app) * etc -Petri
