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>
Duncan P. N. Exon Smith
2014-Jun-19 03:38 UTC
[LLVMdev] [RFC] Add a simple soft-float class
> 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>