4 ms·
This is a CGRA. It's like an FPGA but with bigger cells. It's not a VLIW core. I assume that like all past attempts at this, it's about 20x more efficient when
by pclmulqdq 1y ago
This is a CGRA. It's like an FPGA but with bigger cells. It's not a VLIW core.
I assume that like all past attempts at this, it's about 20x more efficient when code fits in the one array (FPGAs get this ratio), but if your code size grows past something very trivial, the grid config needs to switch and that costs tons of time and power.
- rf15 1y agoI agree this is very "FPGA-shaped" and I wonder if they have further switching optimisations on hand.
- RossBencina 1y agoMy understanding is that they have a grid configuration cache, and are certainly trying to reduce the time/power cost of changing the grid connectivity.
- pclmulqdq 1y agoAn FPGA startup called Tabula had the same thesis and it didn't work out well for them. Their configurable blocks had 16 configurations that they would let you cycle through. Reportedly, the chips were hell to program and the default tools were terrible.
- reactordev 1y agoIs that a design flaw or a tooling flaw? The dev experience is usually left till the very end of some proof like this.
- wmf 1y agoIt doesn't matter. You have to get both right or you go out of business. (And then your IP is thrown away so the next startup also has to get both right...)
- reactordev 1y agoYeah, merely asking for posterity in case someone wants to iterate on it. The dev tools need just as much attention as the hardware. Sometimes the community can surprise you. Take fritzing for example. I think the hardware design is novel but to benchmark it fully requires dev tooling that knows how to utilize it all, and in such a way that it abstracts those details from the average developer. A good example of this is abstracting SIMD instructions for vector multiplication, or CUDA with torch. Normal people don’t care how it’s done, only that it’s done, as fast as can be done.
- gchadwick 1y agoBoth? Theoretically amazing hardware that just needs the magic compiler to work well is a well worn path in the hardware world (The itanium being a notable example). A design can be impossible to compile well for and very hard to program manually if it hasn't been developed well. Equally you can indeed have a bad toolchain for that hard to use design making it even harder to get the best out of it.
- djmips 1y agoI'm thinking of the Sony Toshiba IBM Cell processor. In the end with experience you could deliver impressive performance and the lessons learned proved to be valuable on any multi core system. But everyone knows the reputation that the PS3 had and certainly in retrospect it was challenging to say the least.
- reactordev 1y agoNah, the issue with PS3 was everyone coming from a specific set of instructions and having, that, hard wired into their brains. Yes, the cell processor did things differently but it was us engineers who had to learn to think of a world beyond x86. This was a good thing. It let us learn. And when Arm came around, we were ready.
- djmips 1y agoVery much agree. It was a positive experience.
- torginus 1y agoYeah, I have worked with FPGAs a while ago and still casually follow the space. There have been many attempts of mapping general purpose/GPU programming languages to FPGA and none of them worked out. The first leading claim they make - that this is a general purpose CPU, capable of executing anything - I suspect is false. CPUs are hard because they have to interact with memory, basically 95% of CPU design complexity comes from having to interact with memory, and handling other data hazards. If this was reducible complexity, they'd have done so already.
- actionfromafar 1y agoThen I have a thought experiment. Replace the execution cores on a state of the art GPU and CPU with FPGAs.
- santaboom 1y agoSee amdahls law Edit: [0] https://en.m.wikipedia.org/wiki/Amdahl%27s_law https://en.m.wikipedia.org/wiki/Amdahl%27s_law
- actionfromafar 1y agoYes but we are also talking about energy efficiency
- santaboom 1y agoSee figure 1 in [0] operation execution is just 0.1pj of 70pj required for a 32 bit int addition… how do you think I was applying amdahls law? Edit: I was using amdahls law as it applies to parallel processors. However in terms of energy usage … See amdahls laws and use your imagination [0] https://semiengineering.com/more-data-drives-focus-on-ic-energy-efficiency/ https://semiengineering.com/more-data-drives-focus-on-ic-ene...
- LargoLasskhyfv 1y agoSee 'Apple-Core', Microgrids, SVP, UTLEON3 In theory, in practice this seems to have failed, but still... Also related: https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/
- DesiLurker 1y agoI recall Mathstar's FPOA (field programmable object arrays) have had similar architecture. it seems they have done a mixture of stack computer, this and some async programming to get this level of optimization. The other one I had seen with pretty good on chip fabric was Tilera who were using something like a packet switch to interconnect tonnes of on-chip cores. My first reaction watching this video was that they are just shifting the problem to compiler, which is actually worse and also does not works for dynamic code with tonnes of branches. Also, didnt Intel burn a lot of money trying to do this with Itanium? Overall, interesting idea but I filed it under 'solution looking for a problem' desk.