Implement the "unum" representation in D ?

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 16 16:24:35 PDT 2015


On Wed, Sep 16, 2015 at 08:06:42PM +0000, deadalnix via Digitalmars-d wrote:
[...]
> When you have a floating point unit, you get your 32 bits you get 23
> bits that go into the mantissa FU and 8 in the exponent FU. For
> instance, if you multiply floats, you send the 2 exponent into a
> adder, you send the 2 mantissa into a 24bits multiplier (you add a
> leading 1), you xor the bit signs.
> 
> You get the carry from the adder, and emit a multiply, or you count
> the leading 0 of the 48bit multiply result, shift by that amount and
> add the shit to the exponent.
> 
> If you get a carry in the exponent adder, you saturate and emit an
> inifinity.
> 
> Each bit goes into a given functional unit. That mean you need on wire
> from the input to the functional unit is goes to. Sale for these
> result.
> 
> Now, if the format is variadic, you need to wire all bits to all
> functional units, because they can potentially end up there. That's a
> lot of wire, in fact the number of wire is growing quadratically with
> that joke.
> 
> The author keep repeating that wire became the expensive thing and he
> is right. Meaning a solution with quadratic wiring is not going to cut
> it.

I found this .pdf that explains the unum representation a bit more:

	http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf

On p.31, you can see the binary representation of unum. The utag has 3
bits for exponent size, presumably meaning the exponent can vary in size
up to 7 bits.  There are 5 bits in the utag for the mantissa, so it can
be anywhere from 0 to 31 bits.

It's not completely variadic, but it's complex enough that you will
probably need some kind of shift register to extract the exponent and
mantissa so that you can pass them in the right format to the various
parts of the hardware.  It definitely won't be as straightforward as the
current floating-point format; you can't just wire the bits directly to
the adders and multipliers. This is probably what the author meant by
needing "more transistors".  I guess his point was that we have to do
more work in the CPU, but in return we (hopefully) reduce the traffic to
DRAM, thereby saving the cost of data transfer.

I'm not so sure how well this will work in practice, though, unless we
have a working prototype that proves the benefits.  What if you have a
10*10 unum matrix, and during some operation the size of the unums in
the matrix changes?  Assuming the worst case, you could have started out
with 10*10 unums with small exponent/mantissa, maybe fitting in 2-3
cache lines, but after the operation most of the entries expand to 7-bit
exponent and 31-bit mantissa, so now your matrix doesn't fit into the
allocated memory anymore.  So now your hardware has to talk to druntime
to have it allocate new memory for storing the resulting unum matrix?

The only sensible solution seems to be to allocate the maximum size for
each matrix entry, so that if the value changes you won't run out of
space.  But that means we have lost the benefit of having a variadic
encoding to begin with -- you will have to transfer the maximum size's
worth of data when you load the matrix from DRAM, even if most of that
data is unused (because the unum only takes up a small percentage of the
space).  The author proposed GC, but I have a hard time imagining a GC
implemented in *CPU*, no less, colliding with the rest of the world
where it's the *software* that controls DRAM allocation.  (GC too slow
for your application? Too bad, gotta upgrade your CPU...)

The way I see it from reading the PDF slides, is that what the author is
proposing would work well as a *software* library, perhaps backed up by
hardware support for some of the lower-level primitives.  I'm a bit
skeptical of the claims of data traffic / power savings, unless there is
hard data to prove that it works.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."


More information about the Digitalmars-d mailing list