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) <petri.savolainen@nokia-bell- > labs.com> > 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. > > -Petri > > >
