Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

morethanmoore.substack.com

Post reply on HN
Print view View original

41–50 of 113 posts

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

#41

Post by pclmulqdq »

elseless wrote: post #39
Imustaskforhelp wrote: post #26

Pardon me but could somebody here explain to me like I am 15? Because I guess Its late night and I can't go into another rabbithole and I guess I would appreciate it. Cheers and good night fellow HN users.

Sure. You can think of a (simple) traditional CPU as executing instructions in time , one-at-a-time[1] — it fetches an instruction, decodes it, performs an arithmetic/logical operation, or maybe a memory operation, and then the instruction is considered to be complete. The Efficient architecture is a CGRA (coarse-grained reconfigurable array), which means that it executes instructions in space instead of time. At com…

Pointers and dynamic objects are probably fine given the ability to do indirect loads, which I assume they have (Side note: I have built b-trees on FPGAs before, and these kinds of data structures are smaller than you think). It's actually pure code size that is the problem here rather than specific capabilities, as long as the hardware supports those instructions.

Instead of assembly instructions taking time in these architectures, they take space. You will have a capacity of 1000-100000 instructions (including all the branches you might take), and then the chip is full. To get past that limit, you have to store state to RAM and then reconfigure the array to continue computing.

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

#42

Post by trhway »

> spatial data flow model. Instead of instructions flowing through a centralized pipeline, the E1 pins instructions to specific compute nodes called tiles and then lets the data flow between them. A node, such as a multiply, processes its operands when all the operand registers for that tile are filled. The result then travels to the next tile where it is needed. There's no program counter, no global scheduler. This native data-flow execution model supposedly cuts a huge amount of the energy overhead typical CPUs waste just moving data.

should work great for NN.

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

#43

Post by kannanvijayan »

pclmulqdq wrote: post #41
elseless wrote: post #39

Earlier quoted context omitted.

Sure. You can think of a (simple) traditional CPU as executing instructions in time , one-at-a-time[1] — it fetches an instruction, decodes it, performs an arithmetic/logical operation, or maybe a memory operation, and then the instruction is considered to be complete. The Efficient architecture is a CGRA (coarse-grained reconfigurable array), which means that it executes instructions in space instead of time. At com…

Pointers and dynamic objects are probably fine given the ability to do indirect loads, which I assume they have (Side note: I have built b-trees on FPGAs before, and these kinds of data structures are smaller than you think). It's actually pure code size that is the problem here rather than specific capabilities, as long as the hardware supports those instructions. Instead of assembly instructions taking time in thes…

Hmm. You'd be able to trade off time for that space by using more general configurations that you can dynamically map instruction-sequences onto, no?

The mapping wouldn't be as efficient as a bespoke compilation, but it should be able to avoid the configuration swap-outs.

Basically a set of configurations that can be used as an interpreter.

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

#44

Post by elseless »

pclmulqdq wrote: post #41
elseless wrote: post #39

Earlier quoted context omitted.

Sure. You can think of a (simple) traditional CPU as executing instructions in time , one-at-a-time[1] — it fetches an instruction, decodes it, performs an arithmetic/logical operation, or maybe a memory operation, and then the instruction is considered to be complete. The Efficient architecture is a CGRA (coarse-grained reconfigurable array), which means that it executes instructions in space instead of time. At com…

Pointers and dynamic objects are probably fine given the ability to do indirect loads, which I assume they have (Side note: I have built b-trees on FPGAs before, and these kinds of data structures are smaller than you think). It's actually pure code size that is the problem here rather than specific capabilities, as long as the hardware supports those instructions. Instead of assembly instructions taking time in thes…

Agree that code size is a significant potential issue, and that going out to memory to reprogram the fabric will be costly.

Re: pointers, I should clarify that it’s not the indirection per se that causes problems — it’s the fact that, with (traditional) dynamic memory allocation, the data’s physical location isn’t known ahead of time. It could be cached nearby, or way off in main memory. That makes dataflow operator latencies unpredictable, so you either have to 1. leave a lot more slack in your schedule to tolerate misses, or 2. build some more-complicated logic into each CGRA core to handle the asynchronicity. And with 2., you run the risk that the small, lightweight CGRA slices will effectively just turn into CPU cores.

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

#45

Post by pedalpete »

Though I'm sure this is valuable in certain instances, thinking about many embedded designs today, is the CPU/micro really the energy hog in these systems?

We're building an EEG headband with bone-conduction speaker so in order of power, our speaker/sounder and LEDs are orders of magnitude more expensive than our microcontroller.

In anything with a screen, that screen is going to suck all the juice, then your radios, etc. etc.

I'm sure there are very specific use-cases that a more energy efficient CPU will make a difference, but I struggle to think of anything that has a human interface where the CPU is the bottleneck, though I could be completely wrong.

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

#46

Post by smlacy »

wood_spirit wrote: post #10
Grosvenor wrote: post #4

Is this the return if Itanium? static scheduling and pushing everything to the compiler it sounds like it.

The Mill videos are worth watching again - there are variations on NaT handling and looping and branching etc that make DSPs much more general-purpose. I don’t know how similar this Electron is, but the Mill explained how it could be done. Edit: aha, found them! https://m.youtube.com/playlist?list=PLFls3Q5bBInj_FfNLrV7gGd...

I love these videos and his enthusiasm for the problem space. Unfortunately, it seems to me that the progress/ideas have floundered because of concerns around monetizing intellectual property, which is a shame. If he had gone down a more RISC-V like route, I wonder if we would see more real-world prototypes and actual use cases. This type of thing seems great for microprocessor workloads.

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

#47

Post by Tempest1981 »

hencoappel wrote: post #38
Imustaskforhelp wrote: post #26

Pardon me but could somebody here explain to me like I am 15? Because I guess Its late night and I can't go into another rabbithole and I guess I would appreciate it. Cheers and good night fellow HN users.

Found this video a good explanation. https://youtu.be/xuUM84dvxcY?si=VPBEsu8wz70vWbX4

Thanks. (Why does he keep pointing at me?)

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

#48

Post by bobmcnamara »

darksaints wrote: post #6
Grosvenor wrote: post #4

Is this the return if Itanium? static scheduling and pushing everything to the compiler it sounds like it.

It kinda sounds like it, though the article explicitly said it's not VLIW. I've always felt like itanium was a great idea but came too soon and too poorly executed. It seemed like the majority of the commercial failure came down to friction from switching architecture and the inane pricing rather than the merits of the architecture itself. Basically intel being intel.

Itanic did exactly what it was supposed to do - kill off most of the RISCs.

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

#49

Post by RossBencina »

pclmulqdq wrote: post #17

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.

My understanding is that they have a grid configuration cache, and are certainly trying to reduce the time/power cost of changing the grid connectivity.

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

#50

Post by kyboren »

variadix wrote: post #29

Pretty interesting concept, though as other commenters have pointed out the efficiency gains likely break down once your program doesn’t fit onto the mesh all at once. Also this looks like it requires a “sufficiently smart compiler”, which isn’t a good sign either. The need to do routing etc. reminds me of the problems FPGAs have during place and route (effectively the minimum cut problem on a graph, i.e. NP), hopefu…

> The need to do routing etc. reminds me of the problems FPGAs have during place and route (effectively the minimum cut problem on a graph, i.e. NP)

I'd like to take this opportunity to plug the FlowMap paper, which describes the polynomial-time delay-optimal FPGA LUT-mapping algorithm that cemented Jason Cong's 31337 reputation: https://limsk.ece.gatech.edu/book/papers/flowmap.pdf

Very few people even thought that optimal depth LUT mapping would be in P. Then, like manna from heaven, this paper dropped... It's well worth a read.

Post reply on HN