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."