Live data from Hacker News

Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?

morethanmoore.substack.com

111–113 of 113 posts

Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?

#111
post #93

Earlier quoted context omitted.

Yeah, 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…

In academia people use general purpose languages (Notably C++ dialects) for FPGA design quite a lot. And there's definitely a glut of papers published on the development of such "High Level Synthesis" tools. In order to use the FPGA efficiently you need to first pipeline the logic deeply, but then also be able to fill that pipeline. But in my opinion there is just too much of an impedance mismatch between the "do one…

I worked in industry, trying to fit video processing algorithms and filter banks to FPGAs, about a decade ago, so my memories are a bit fuzzy.

The thing about FPGAs is that they are wildly expensive, getting exponentially more so the more you move up the product pallette. They also have a ton of special function blocks (DPRAM, multipliers, shift registers etc), that work differently from vendor to vendor, and even between generations.

Even with HDLs you had to options - either read all the datasheet, the layout and mix of components, and plan your design to fit the hardware - or just wing it and write down what you wanted, and hope for the best - in the latter scenario, the synthesis tool had to figure out how to fit your design best to the hardware, which even if you were mindful of how the chip worked, was still a hit and miss.

When you work in industry and either every cent counts, or you have to design for a fixed target, and somehow you're in the good graces of tooling, finding that changing a small thing suddenly makes your design 3x as big and half as fast is not acceptable.

HLS was this, but on steroids - you never knew what you were going to get, sometimes it worked well, sometimes not at all.

I'm sure tooling has evolved back then but I'd still guess spending the extra engineering effort is often well worth it when your chips cost five figures.

Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?

#112

Earlier quoted context omitted.

That minimizes the data transfer distance from that bit of memory to that bit of compute. But it increases the distance between that bit of (memory and compute) and all the other bits of (memory and compute). If your problem is bigger than one bit of memory, such a configuration is probably a net loss, because of the increased data transfer distance between all the bits. Your last paragraph... you're right that, soon…

So do both. Put a bunch of small processors on every DIMM.

It's been tried. Nothing's really worked yet.

https://en.wikipedia.org/wiki/Computational_RAM

https://research.ibm.com/projects/in-memory-computing

Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?

#113
post #93

Earlier quoted context omitted.

In academia people use general purpose languages (Notably C++ dialects) for FPGA design quite a lot. And there's definitely a glut of papers published on the development of such "High Level Synthesis" tools. In order to use the FPGA efficiently you need to first pipeline the logic deeply, but then also be able to fill that pipeline. But in my opinion there is just too much of an impedance mismatch between the "do one…

I worked in industry, trying to fit video processing algorithms and filter banks to FPGAs, about a decade ago, so my memories are a bit fuzzy. The thing about FPGAs is that they are wildly expensive, getting exponentially more so the more you move up the product pallette. They also have a ton of special function blocks (DPRAM, multipliers, shift registers etc), that work differently from vendor to vendor, and even be…

Yup, HLS is ridiculously fickle in that regard. In our lab we had the case that swapping out a C-style array T[] for a C++ std::array 10x-ed our resource consumption with no explanation.

And also the general problem of scribing resource use to the different components isn't easy, because thz way control flow is structured heavily alters that

Of course, that's what I'm trying to fix with SUS :p

Post reply on HN