[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] bourn_cast version 1.0
Re: [lmi] bourn_cast version 1.0
Wed, 19 Apr 2017 16:50:29 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
On 2017-04-19 14:16, Vadim Zeitlin wrote:
> On Wed, 19 Apr 2017 13:59:55 +0000 Greg Chicares <address@hidden> wrote:
> GC> But our official goal is to keep lmi running for the next forty years,
> Wait, have I missed another end-of-world event scheduled for 2058? If not,
"Forty years" is just a way of saying "forever", or at least for the lifetime
of the youngest person whose insurance policy requires an illustration (though
we're still issuing policies to twenty-year-olds today). The only way to make
code work for forty years is to write it to last forever anyway.
It would make sense to give a moment's thought now to what computers will
look like forty years hence. I think the registers will still be 64 bits wide
(otherwise, I'd have emulated a 128-bit integral type for bourn_cast testing;
but 2^64 is 16 exbibytes, and we won't have that amount of RAM by mid-century).
32-bit code will have only legacy support, so we'll want to build a 64-bit lmi.
I think GNU/Linux will still be widely used--either that, or BSD, so it would
not hurt if we paid some attention to BSD compatibility (which I guess would
affect only makefiles). With less certainty, I foresee that gcc and C++ will
still be in broad use. CPUs will run at about the same clock rate as today,
but they'll have many cores, so perhaps we should consider threading in lmi.
> I do hope it can continue running in 2058 and beyond... although I'm not
> sure if we're not going to have some problems at the half point between now
> and then (lmi doesn't use time_t much, but I'm not sure if wxWidgets, for
> example, is fully y2038-compliant).
If we leave the 32-bit world behind, and run 64-bit lmi on a 64-bit OS, then
won't that solve this problem automatically? (At least for *nix, because I
don't see msw surviving until Y2038.) By the time we need a 128-bit time_t,
we'll be in a galaxy that hasn't been born yet.
> GC> This is a good time to compare the performance of bourn_cast versus
> GC> boost::numeric_cast. Here are median-of-three timings with gcc-4.9 on
> GC> i686:
> I have some trouble reading this table as it has "boost" and "bourn"
> columns, but also "static" and "bourn" rows. What exactly is found at the
> intersection of the "bourn" row and "boost" column?
I should have edited that. The rows might have been labeled "bo.*cast" to
suggest either "bourn_cast" or "boost::numeric_cast", thus:
---boost--- ---bourn--- -ratio-
static_cast<U>(S): 319266 317606 99%
bo.*_cast<U>(S): 317838 316214 99%
where "317838" is the number of nanoseconds for boost::numeric_cast to
convert an integer from signed to unsigned.
> GC> This work also gave me reason to study IEEE 754, which I had never read
> I admit that I haven't read it neither. You should leave your review of it
> as it doesn't seem to have any, for some reason -- maybe this will motivate
> me to do it.
Wow--that's like a curated search engine: DMOZ meets gopher in the 21st
century. Of course, their TOS are unacceptable:
| You agree to defend OCLC against claims or lawsuits related to your posting.
because frivolous lawsuits abound. If I were to review it nonetheless, then
in the spirit of the times I suppose I would say "IEEE 754 rocks my world,
and props to Kahan".