Re: [lmi] Performance of bourn_cast

[Greg Chicares]

On 2017-03-19 00:21, Vadim Zeitlin wrote:
> On Sat, 18 Mar 2017 23:55:06 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Anyway, I reached for a thesaurus, came across the word "bourn", and
> GC> thought, of course, of

[Hamlet III.i.79]

> GC> That tickled my fancy: no value "returns" across this fence, because an
> GC> exception is thrown.
> 
>  I'm not an English literature scholar, but I'm not totally certain that
> the original author has thought to imply this meaning by using this word
> here.

You make an interesting point: the word can mean either a border, or the
region that lies beyond it. I had thought he meant 'realm' as opposed to
'boundary'--i.e., Hades rather than the Styx (though I didn't let that
hold me back in naming this cast, because I had always thought Ritchie
invented the 'return' statement and I was so delighted to learn that it
had been anticipated by an even greater poet, hundreds of years before);
but apparently scholars, although unsure, favor the latter reading:

http://www.dictionary.com/browse/bourn
| "destination," 1520s, from French borne, apparently a variant of bodne
| (see bound (n.)). Used by Shakespeare in Hamlet's soliloquy (1602),
| from which it entered into English poetic speech. He meant it probably
| in the correct sense of "boundary," but it has been taken to mean "goal"
| (Wordsworth, Matthew Arnold) or sometimes "realm" (Keats).
|   The dread of something after death, The vndiscouered Countrey;
|   from whose Borne No Traueller returnes.

(I'm still unconvinced. One would return "across" the Styx, not "from" it.]

> GC> That can be worked around as follows, but is it worth it?
[...experimental patch...]
>  I wonder if this has any bearing on performance, in either -O0 or -O2
> builds? If not, I agree that it it's not really worth it, although I still
> think we might want to return to this function and stick "constexpr" in
> front of it when we start using C++17.

I'll add "constexpr", conditional on __cplusplus. With gcc-4.9.1, it
doesn't clearly make any difference. Median of three runs with the
"C++11 constexpr" patch:

'-O0':
  direct: 2.266e-003 s =    2265566 ns, mean of 100 iterations
  S to U: 2.744e-002 s =   27435643 ns, mean of  37 iterations
  U to S: 2.688e-002 s =   26880553 ns, mean of  38 iterations

'-O2':
  direct: 4.199e-004 s =     419908 ns, mean of 100 iterations
  S to U: 4.207e-004 s =     420652 ns, mean of 100 iterations
  U to S: 4.872e-004 s =     487221 ns, mean of 100 iterations

...and without that patch:

'-O0':
  direct: 2.269e-003 s =    2269479 ns, mean of 100 iterations
  S to U: 2.724e-002 s =   27243943 ns, mean of  37 iterations
  U to S: 2.673e-002 s =   26726629 ns, mean of  38 iterations

'-O2':
  direct: 4.186e-004 s =     418593 ns, mean of 100 iterations
  S to U: 4.209e-004 s =     420856 ns, mean of 100 iterations
  U to S: 5.077e-004 s =     507690 ns, mean of 100 iterations

The largest difference is in the "U to S" case with '-O2', but
the three measurements without the patch were:
  411607 ns
  507690 ns = median
  509265 ns
so I don't think there's enough evidence to justify making the code
more obscure--and 500000 ns for one million iterations is half a
nanosecond per invocation anyway.