Hardware support for UNUM floating point arithmetic [pdf]

https://hal.inria.fr/hal-01618698/document

by g0xA52A2A • 9 years ago

50 17 9 years ago

hal.inria.fr

screeny05• 9 years ago

please add a [PDF] to the header

gjem97• 9 years ago

Just wondering: why is it useful to know it's a PDF before clicking?

dEnigma• 9 years ago

In my case, while I'm on my phone, the pdf is automatically downloaded and opened in a different app; so it is nice to have a warning.

noahdesu• 9 years ago

Woah, really cool. My understanding is that Posit, the successor to unum versions 1 and 2, is the future and is much easier to implement in hardware [0].

[0] https://posithub.org/about

j_s• 9 years ago

There is a Posit BoF at SC17 (supercomputing) Nov 14 DEN: http://sc17.supercomputing.org/presentation/?id=bof135&sess=...

Posit Paper: http://johngustafson.net/pdfs/BeatingFloatingPoint.pdf

A new data type called a posit is designed as a direct drop-in replacement for IEEE Standard 754 floating-point numbers (floats). Unlike earlier forms of universal number (unum) arithmetic, posits do not require interval arithmetic or variable size operands; like floats, they round if an answer is inexact. However, they provide compelling advantages over floats, including larger dynamic range, higher accuracy, better closure, bitwise identical results across systems, simpler hardware, and simpler exception handling.

source: https://twitter.com/daniel_bilar/status/920252363159539712

petermonsson• 9 years ago

I am confused. I see half the performance and 3-5x the area of IEEE754, but the conclusion is that UNUM is comparable. That would not be my conclusion. What am I missing?

fdej• 9 years ago

The idea is that computers spend much more energy moving data between the processor and memory than actually processing the data. Unums use a variable length encoding which makes processing more costly but reduces the amount of data transfer. At least in theory; whether this is a net benefit remains to be proven.

iainmerrick3• 9 years ago

If it's exactly reproducible on different hardware and software configurations, as seems to be one of the goals, that alone would be a useful improvement on IEEE754.

wolfgke3• 9 years ago

If it's exactly reproducible on different hardware and software configurations, as seems to be one of the goals, that alone would be a useful improvement on IEEE754.

IEEE754 already supports that (except for the minor fact that the NaN types can in theory be represented by different bit sequences - in practise all the same are used). The problem rather is that typical programming languages (such as C, C++) have no proper support for IEEE754.

And you have to be very precise in your intentions: For each of the operations defined in IEEE754 you have to define which of the four (+ one optional one in the 2008 revision) rounding modes is to be used. Or you have to be precise whether a MAC or and multiply (then round) and add (then round again) is to be used. This of course has again implications that depending on what the compiler makes out of it either the program will not run on processors with no MAC support or the code has to use a software emulation (slow).

jcranmer• 9 years ago

One of the ideas behind UNUM is that we're using extra bits to guard against the possibility that we see catastrophic cancellation (the mass loss of significant figures between two nearly-equal values), and using intervals would allow us to only use those extra bits when necessary (as it's a variable-width format). The argument is that unums instead of floats would allow for better packing of memory, and by counting the energy cost per value of memory, it's an overall win.

That argument is rather mendacious, though. Yes, it does cost energy to maintain large register files, caches, and DIMMs, but hardware already aggressively turns that stuff off when not in use. Thus the lowest-power solution is generally the one that maximizes the use of everything. Furthermore, the cache and RAM is generally a fixed cost anyways: you're not going to say "oh, I only need 12GB of RAM instead of 16GB because I can store on average 3 bytes/value instead of 4". Thus the only component you can really claim counts as part of the enum power usage is the register file, and this paper appears to be going with a fixed-width format for doing the hardware computations anyways, so the win there isn't going to happen.

Hardware support for UNUM floating point arithmetic [pdf]

Related Stories