Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-05 14:03:17

Steven Watanabe wrote:
> Stewart, Robert wrote:
> > Steven Watanabe wrote:
> >
> > You've dragged this far afield.  The original contention
> > was that functions in a .cpp would be inlined.
>
> And you claimed that they can't be inlined.

I claimed they wouldn't be, because I assumed -O2 or -O3 as the usual sort of optimizations settings, such as offered by Boost out of the box, unless I'm much mistaken.

> > I countered that as not being portable, which is to say
> > that it will only work on select platforms and only when
> > configured to do so.
>
> Like all optimizations.

True, but putting inlineable function definitions in a header doesn't require any special settings, so it isn't the same.

> > The only way to have any chance of inlining for the widest
> > range of platforms and configurations possible is to put the
> > function definitions in a header and mark them inline if they
> > aren't in the class definition.  That won't force any
> > compiler to inline them, but that gives the best chance for
> > it.  I hardly think that's controversial.
>
> It's more likely that they'll be inlined, sure.  But why do you care?

Chad was operating under the assumption that those functions would be inlined and they wouldn't be for most library users.

> inlining these functions probably won't have much effect on
> performance.

It is good to develop a new library without inlining any or most functions.  That gives the most flexibility to users without imposing frequent recompilation.  I assume the use of profiling to show where optimizations are most needed.  However, when writing a library, the author cannot foresee all use cases, so avoiding obvious inlining opportunities is typically bad and likely a premature pessimization.

> At most you save one function call and one conditional branch.

If that occurs 1,000,000 times, you just might care, depending upon the processor hosting your app.

> If I really care about differences like this, I'm probably going to be
> turning on whole program optimization.  Further, I highly
> doubt that we're
> going to do the micro-optimizations to make it run as fast as possible
> on less widely used compilers, anyway.

This has little to do with micro-optimizations for less used compilers.  Few people I have worked with make any use of any of the options that would lead to inlining those functions from the .cpp file, and some potential library users don't even have the option, so the suggested change means an easy optimization for all.  That's a good reason to consider the change.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.