6 ms·

Are there architectural or other challenges to building processors for this? How compatible are unums with modern processors? Would LAPACK et al have to be re

Are there architectural or other challenges to building processors for this? How compatible are unums with modern processors? Would LAPACK et al have to be re-written?

yoklov 11y ago
My understanding is that it's not compatible with modern processors, and new hardware would be required to efficiently execute it. It seems to be a superset of floating point (and fixed point?) though, so maybe LAPACK could still work? I may be misreading or misunderstanding this however.
- methodOverdrive 11y ago
  New hardware would be needed. I think libraries like LAPACK basically are fast because they do a good job taking advantage of the hardware implementation of floating point math, and are written with sufficient understanding of the format to mitigate approximation errors. Therefore you would probably need to rewrite huge parts of such libraries to use the new Unum hardware or software - though doing so might be relatively straightforward - as you say, Unum can be seen as a superset of floating point and it does support all of the same operations.
trsohmers 11y ago
It requires additional complexity than what is in modern FPUs, but it arguably more efficient when actually operating due to being able to have the same accuracy while using fewer bits. Most people don't realize that it is the data movement that is most expensive thing in a processor... It takes 100 picojoules to do a double precision (64 bit) floating point operation, but a humongous 4200 picojoules to actually move the 64 bits from DRAM to your registers. The really crazy thing is that around 60% of that power used to move the data is wasted in the processor itself, in the logic powering the hardware cache hierarchy. My startup (http://rexcomputing.com http://rexcomputing.com) is solving this with our new processor, and are working with John Gustafson in experimenting with unum for future generations of our chip.
- semi-extrinsic 11y ago
  There's an even worse disparity in the amount of time required for those two processes. How is that ratio affected by your technology?
  - trsohmers 11y ago
    We bring the ratio down as well... A load/store to a cores local scratchpad (Our software managed and power efficient version of a traditional L1 cache) is 1 cycle, compared to 4 cycles for an Intel processor. Add in the fact that we have 128KB of memory per scratchpad (compared to 16 to 32KB L1 D$ for Intel), you don't need to go to DRAM as much, greatly increasing performance/throughout on top of the 10x+ efficiency gain. Even in the case of a core access accessing another cores local scratchpad when they are on opposite corners of the chip, it takes only one cycle per hop on the Network on Chip... meaning for our 256 core chip, you can go all away across the chip (and access a total of 32MB of memory) in 32 cycles... Less than the ~40 cycles it takes to access L3 cache on an Intel chip.
    - Scaevolus 11y ago
      Comparing a 1 cycle scratchpad latency to Intel's 4 cycle L1 latency is misleading. Are you making chips that operate at up to 4GHz, or is this just 128KB of local SRAM attached to a ~1GHz core?
      - davisourus 11y ago
        If you have 4 GHz of processing IEEE but getting a wrong answer at the end, how do you compare that to a smaller number of FLOPS with a rigorously-bounded answer? I'm not saying they're apples to oranges, I'm saying that you can't just compare the quality of two foods based on calorie count alone.
      - trsohmers 11y ago
        If you care about efficiency, then you are burning significantly more energy to run at 4GHz, and are still moving the same amount of data in and out of your local memory. If that is your bottleneck, then you are running at 4x the clock speed for no real gain, as your memory can't keep up with the speed of your functional units. But to answer your question directly, we are targeting 1GHz conservatively...we think it could do more, but as we are focused on efficiency, we think it is a good middle ground between performance and energy usage. We'll be able to make a more informed decision (and possibly change that) when we have silicon in hand.

Are there architectural or other challenges to building processors for this? How compatible are unums with modern processors? Would LAPACK et al have to be re-written?

yoklov 11y ago

My understanding is that it's not compatible with modern processors, and new hardware would be required to efficiently execute it. It seems to be a superset of floating point (and fixed point?) though, so maybe LAPACK could still work? I may be misreading or misunderstanding this however.

methodOverdrive 11y ago
New hardware would be needed. I think libraries like LAPACK basically are fast because they do a good job taking advantage of the hardware implementation of floating point math, and are written with sufficient understanding of the format to mitigate approximation errors. Therefore you would probably need to rewrite huge parts of such libraries to use the new Unum hardware or software - though doing so might be relatively straightforward - as you say, Unum can be seen as a superset of floating point and it does support all of the same operations.

trsohmers 11y ago

It requires additional complexity than what is in modern FPUs, but it arguably more efficient when actually operating due to being able to have the same accuracy while using fewer bits. Most people don't realize that it is the data movement that is most expensive thing in a processor... It takes 100 picojoules to do a double precision (64 bit) floating point operation, but a humongous 4200 picojoules to actually move the 64 bits from DRAM to your registers. The really crazy thing is that around 60% of that power used to move the data is wasted in the processor itself, in the logic powering the hardware cache hierarchy. My startup (http://rexcomputing.com http://rexcomputing.com) is solving this with our new processor, and are working with John Gustafson in experimenting with unum for future generations of our chip.

semi-extrinsic 11y ago
There's an even worse disparity in the amount of time required for those two processes. How is that ratio affected by your technology?
- trsohmers 11y ago
  We bring the ratio down as well... A load/store to a cores local scratchpad (Our software managed and power efficient version of a traditional L1 cache) is 1 cycle, compared to 4 cycles for an Intel processor. Add in the fact that we have 128KB of memory per scratchpad (compared to 16 to 32KB L1 D$ for Intel), you don't need to go to DRAM as much, greatly increasing performance/throughout on top of the 10x+ efficiency gain. Even in the case of a core access accessing another cores local scratchpad when they are on opposite corners of the chip, it takes only one cycle per hop on the Network on Chip... meaning for our 256 core chip, you can go all away across the chip (and access a total of 32MB of memory) in 32 cycles... Less than the ~40 cycles it takes to access L3 cache on an Intel chip.
  - Scaevolus 11y ago
    Comparing a 1 cycle scratchpad latency to Intel's 4 cycle L1 latency is misleading. Are you making chips that operate at up to 4GHz, or is this just 128KB of local SRAM attached to a ~1GHz core?
    - davisourus 11y ago
      If you have 4 GHz of processing IEEE but getting a wrong answer at the end, how do you compare that to a smaller number of FLOPS with a rigorously-bounded answer? I'm not saying they're apples to oranges, I'm saying that you can't just compare the quality of two foods based on calorie count alone.
    - trsohmers 11y ago
      If you care about efficiency, then you are burning significantly more energy to run at 4GHz, and are still moving the same amount of data in and out of your local memory. If that is your bottleneck, then you are running at 4x the clock speed for no real gain, as your memory can't keep up with the speed of your functional units. But to answer your question directly, we are targeting 1GHz conservatively...we think it could do more, but as we are focused on efficiency, we think it is a good middle ground between performance and energy usage. We'll be able to make a more informed decision (and possibly change that) when we have silicon in hand.