llvm dev - Jun 2014 - [LLVMdev] [RFC] Add a simple soft-float class

On Jun 18, 2014, at 1:20 PM, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
> I'm certainly not suggesting this would be better in general than IEEE
754.
> 
> But I think it's suitable for the sorts of places we currently use
> hard-floats.  I guess you (and Philip) are saying there are dragons here?
Numerical analysis is hard.  Every numerics expert I have ever worked with
considers trying to re-invent floating point a cardinal sin of numerical
analysis.  Just don’t do it.  You will miss important considerations, and you
will pay the price for it later.  Plus, anyone in the future who wants to modify
your code has to learn a new set of non-standard floating point numerics, and
without a well-defined specification it’s not always clear what the correct
semantics in a particular case are.
> Although "making APFloat not suck" might be ideal, we don't
have the code
> written for that.
I don’t think we should let expedience get in the way of Doing The Right Thing. 
IMO, there are two real issues with APFloat today:

1) The interface is really clunky.  We can fix this by fixing/extending the
interface, or by adding a convenience wrapper.

2) It *may* be too slow for this use case.  Assuming this is actually true,
there’s a lot of room for improvement in APFloat’s performance by special-casing
common paths (default rounding mode, normal formats).  We could even conceivably
detect if we’re compiled for a platform that has sane hard float support and
fall back to that transparently.

None of these seem particularly difficult to me, and saves us from a future
world of pain.  I know Michael Gottesman has some WIP code for cleaning up
APFloat.  Perhaps he could share it with you?

—Owen

On Thu, Jun 19, 2014 at 8:29 AM, Owen Anderson <resistor at mac.com>
wrote:
> Numerical analysis is hard.  Every numerics expert I have ever worked with
> considers trying to re-invent floating point a cardinal sin of numerical
> analysis.  Just don’t do it.  You will miss important considerations, and
> you will pay the price for it later.
>
I don't think anyone is planning to use it to write climate models. Or
simulate airflow over a 787. Or even invert a near-singular matrix.

This is for jobs that *could* perfectly well be done with a simple integer
with an implied scale factor, if you could easily and reliably predict in
advance exactly what scale factor is appropriate for each value.

This simply keeps track of the scale factor for you, so you can't get it
wrong.

Perhaps the mistake is in calling it "software floating point" (which
carries a lot of baggage), rather than "automatic scaled integer"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140619/23370256/attachment.html>

On Jun 18, 2014, at 3:05 PM, Bruce Hoult <bruce at hoult.org> wrote:
> On Thu, Jun 19, 2014 at 8:29 AM, Owen Anderson <resistor at mac.com>
wrote:
> Numerical analysis is hard.  Every numerics expert I have ever worked with
considers trying to re-invent floating point a cardinal sin of numerical
analysis.  Just don’t do it.  You will miss important considerations, and you
will pay the price for it later.
> 
> I don't think anyone is planning to use it to write climate models. Or
simulate airflow over a 787. Or even invert a near-singular matrix.
> 
> This is for jobs that *could* perfectly well be done with a simple integer
with an implied scale factor, if you could easily and reliably predict in
advance exactly what scale factor is appropriate for each value.
> 
> This simply keeps track of the scale factor for you, so you can't get
it wrong.
If you couldn’t get it wrong, we wouldn’t have had so much difficulty getting
the current version to work.

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/ae4d963a/attachment.html>

> On 2014 Jun 18, at 13:29, Owen Anderson <resistor at mac.com> wrote:
> 
> Numerical analysis is hard.  Every numerics expert I have ever worked with
considers trying to re-invent floating point a cardinal sin of numerical
analysis.  Just don’t do it.  You will miss important considerations, and you
will pay the price for it later.  Plus, anyone in the future who wants to modify
your code has to learn a new set of non-standard floating point numerics, and
without a well-defined specification it’s not always clear what the correct
semantics in a particular case are.
Okay.  To me this sounds like dogma, but I'll defer to your judgement.
> I don’t think we should let expedience get in the way of Doing The Right
Thing.
FWIW, we also balance idealism with pragmatism.
> IMO, there are two real issues with APFloat today:
> 
> 1) The interface is really clunky.  We can fix this by fixing/extending the
interface, or by adding a convenience wrapper.
> 
> 2) It *may* be too slow for this use case.  Assuming this is actually true,
there’s a lot of room for improvement in APFloat’s performance by special-casing
common paths (default rounding mode, normal formats).  We could even conceivably
detect if we’re compiled for a platform that has sane hard float support and
fall back to that transparently.
> 
> None of these seem particularly difficult to me, and saves us from a future
world of pain.  I know Michael Gottesman has some WIP code for cleaning up
APFloat.  Perhaps he could share it with you?
When working on BFI, I considered (1).  However, for that use case, I
needed simple saturation of unsigned quantities.  The wrapper seemed to be
heading somewhere more bug prone than a simple hand-rolled implementation
(and with as many lines of code), so I switched gears.

You're saying that these semantics were wrong-headed from the get-go.
They were useful for modeling block frequency, but I'm not a numerics
expert.
> Making our existing soft float implementation (APFloat) more convenient and
faster is a win-win.  It solves this particular use case without introducing
risk of defining the representation wrong, AND it makes it easier and more
convenient to use for other clients within the compiler.
Yup.  That'd be good work to do even if UnsignedFloat *were* a good idea.
It's fairly tangential to cleaning up BFI, though, so I won't be
tackling
it right now (anyone motivated should go ahead!).

I'll continue with the post-commit plan for BFI that Chandler, Andy and I
mapped out, which was/is something like this:

  - Model the "bias" metric.
  - Approximate loop scales by their lg (with a special case for 3) and
    reorganize calculations to avoid quantities less than 1/UINT64_MAX.
  - Factor out the useful parts of UnsignedFloat into helper functions
    that actually have tests in tree.
  - Replace uses of UnsignedFloat with helpers (and delete its shell).
  - Look at sharing float-like helper algorithms with APFloat.

-- dpnes

On Jun 18, 2014, at 8:38 PM, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
>> 
>> On 2014 Jun 18, at 13:29, Owen Anderson <resistor at mac.com>
wrote:
>> 
>> Numerical analysis is hard.  Every numerics expert I have ever worked
with considers trying to re-invent floating point a cardinal sin of numerical
analysis.  Just don’t do it.  You will miss important considerations, and you
will pay the price for it later.  Plus, anyone in the future who wants to modify
your code has to learn a new set of non-standard floating point numerics, and
without a well-defined specification it’s not always clear what the correct
semantics in a particular case are.
> 
> Okay.  To me this sounds like dogma, but I'll defer to your judgement.
Is there any way we have this utility and just not claim that it is for use with
a numerics package? The only claim we’re making is that it is a useful utility
for writing compiler heuristics. We can do that without waking any Dragons, and
Duncan’s design is quite straightforward.

I think calling it a “soft-float” implementation was a mistake (even though
that’s what it is), and has completely derailed this thread.

The goal is to factor and reuse the code that we need to reinvent every time we
need to extend the dynamic range of some of cost metric. The question here is
whether that in itself a worthwhile goal, independent of how the compiler models
language level floats. I have nothing *against* repurposing APFloat. After all,
we only have a couple metrics in tree that need this new utility. But let’s be
clear that APFloat's purpose is completely different, so it’s not like we’re
reinventing any existing utility.

I honestly think we should consider not calling this a Float at all just to
avoid the obvious confusion. I’m fine calling it a ScaledNumber or something.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/3af59c6b/attachment.html>