Implement the "unum" representation in D ?

[Don via Digitalmars-d]

On Tuesday, 15 September 2015 at 11:13:59 UTC, Ola Fosheim 
Grøstad wrote:
> On Tuesday, 15 September 2015 at 10:38:23 UTC, ponce wrote:
>> On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim 
>> Grøstad wrote:
>>> http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
>>
>> That's a pretty convincing case. Who does it :)?

I'm not convinced. I think they are downplaying the hardware 
difficulties. Slide 34:

Disadvantages of the Unum Format
* Non-power-of-two alignment. Needs packing and unpacking, 
garbage collection.

I think that disadvantage is so enormous that it negates most of 
the advantages. Note that in the x86 world, unaligned memory 
loads of SSE values still take longer than aligned loads. And 
that's a trivial case!

The energy savings are achieved by using a primitive form of 
compression. Sure, you can reduce the memory bandwidth required 
by compressing the data. You could do that for *any* form of 
data, not just floating point. But I don't think anyone thinks 
that's worthwhile.

The energy comparisons are plain dishonest. The power required 
for accessing from DRAM is the energy consumption of a *cache 
miss* !! What's the energy consumption of a load from cache? That 
would show you what the real gains are, and my guess is they are 
tiny.

So:
* I don't believe the energy savings are real.
* There is no guarantee that it would be possible to implement it 
in hardware without a speed penalty, regardless of how many 
transistors you throw at it (hardware analogue of Amdahl's Law)
* but the error bound stuff is cool.