[std-interval] PODs and parameter passing

[first.i.last at comcast.net]

 -------------- Original message ----------------------
From: Steve Clamage <Stephen.Clamage at Sun.COM>
> first.i.last at comcast.net wrote:
> >  -------------- Original message ----------------------
> > From: Gabriel Dos Reis <gdr at integrable-solutions.net>
> > 
> >>first.i.last at comcast.net writes:
> >>
> >>[...]
> >>| OK, I did not ask a sufficiently precise question.  Why is
> >>| "implementation defined" unacceptable?  I.e., why does PODness have
> >>| to be a constant for all implementations? 
> >>
> >>Because whether the operations in question are permitted or not would
> >>depend on the compiler; I don't see any compelling reason for that
> >>sort of non-portability.
> > 
> > It is only non-portable if it is not detectable at compile time.
> 
> Scenario: A programmer develops on one platform, unaware that the code depends 
> on a feature that varies among implementations. A colleague tries the code on a 
> different platform, and it doesn't compile. The code requires a significant 
> re-write to accomodate the differences.
> 
> Don't you agree this is a portability issue?
> 
> I'm a compiler developer. I find that the majority of customer questions and 
> complaints are of the form, "My code works with compiler X, why doesn't it work 
> with your compiler?"  Often the answer is that the code is not portable, in the 
> sense of the scenario above.
> 
> Every time the standard says "undefined", "unspecified", or "implementation 
> defined", it opens the door to problems like these. We need a compelling reason 
> to leave issues like POD-ness and function signatures up to individual 
> implementations.

I understand and agree with everything you wrote.  But you ignored the point I made, which is that "implementation defined and not detectable" is quite distinct from "implementation defined and detectable".  The former is a problem and typically involves user-supplied configuation variables/scripts/macros -- quite a hassle.  The latter is portable.  It takes a modicum of effort, but it is portable.

The whole point of things like std::numeric_limits<> is that machines differ.  Those differences matter.  Some of those differences matter a lot.  Thus for portable _performance_ rather than portable _compilation_, it is worth the investment of time to handle potential performace issues rather than glossing them over.

Now std::interval is not going to save the world WRT portable numeric software.  But if there ever was or will ever be time to address platform variations _with_which_users_must_contend_ then that time is prior to the adoption of the standard.  If the issues can be delegated to the implementors, leaving the users safely isolated, then there is no need for the standard to address them and we should not spend a lot of time on them.

Given the discussions over the impact of calling conventions it appears that many writers to this list belive calling conventions are important user-visible aspects performance.

> 
> [...]
> >>
> >>It all depends on the degree of non-PODness; there are ABIs out there
> >>on popular platforms that make optimization decisions based on degree
> >>of PODness.
> 
> Gaby, PODness is binary. If a type does not satisfy all the requirements of a 
> POD, it is not a POD.
> 
>  > Let's see if we can mutate a classic into something useful:
>  >
>  >     Intervals should be as POD as possible and no PODer.
>  >           -- apologies to Albert?
>  >
>  > -- Lee Winter
> 
> Let's paraphrase Tolstoy's "Anna Karenina" instead:
>     All PODs are alike. Every non-POD is non-POD in its own way.
> 
> In particular, a POD does not have a user-defined constructor. If the only 
> departure from PODness is the presence of user-defined initialization or 
> converting constructors (but still no copy constructor), a compiler can generate 
> efficient code for copying and passing values in and out of functions. (I think 
> we could also allow private or protected members.)

Are you implying that the existence or non-existence of copy ctors is a key determinant in efficiency?  If so, what portability would be lost if the standard stated that intervals are non-PODs and implementations varied in their support for copy ctors?

You didn't mention destructors, I assume because they has less impact on the callinc convention topic.  How much efficiency is lost due to the simpl presence of a desctructor?  I'm particularly concerned with temporaries generated during expression evaluation rather than copies generated during parameter passing.

Classic implementations of C's math.h always had to wrestle with speed versus correctness.  Some vendors appeased their customers by delegating the decision to them -- they provided a fast RTL and a good RTL that could be selected at link time.  As intervals become pervasive we should expect the kind of adaptive radiation that would drive vedors to offer alternative implementations.  The standard should not forbid that tradeoff without some compelling jusitification.

It is my expectation that some implementations might have variants of both forms.  For example, a blunt variant might be useful where fat intervals were rare and the extra overhead in time and space for dependency detection and correction was not desired.  A sharp variant would be useful where fat intervals are common and the extra overhead in time and space were worth it in order to obtain narrow results.

AFAIK dependency detection and correction are the only features that would require elaborate construction and destruction of interval objects.  All of the other features of which I have ever heard are simple state variables.  Does anyone have a contrary example?

-- Lee Winter