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