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

61–70 of 113 posts

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

#61

Post by icodestuff »

fidotron wrote: post #12
wolfi1 wrote: post #8

reminds me from the architecture of transputers but on the same silicon

Yep, or the old GreenArrays GA144 or even maybe XMOS with more compiler magic. One of the big questions here is how quickly it can switch between graphs, or if that will be like a context switch from hell. In an embedded context that's likely to become a headache way too fast, so the idea of a magic compiler fixing it so you don't have to know what it's doing sounds like a fantasy honestly.

Yep, that’s definitely the question. The article says that there are caches of recently used graphs for use in large loops. Presumably those are pretty fast to swap, but I have to imagine programming a whole new graph in isn’t fast. But maybe the E2 or E3 will have the ability to reprogram partial graphs with good AOT dataflow analysis.

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

#62

Post by esperent »

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…

> it executes instructions in space instead of time. At compile time, the Efficient compiler looks at a graph made up of all the “unrolled” instructions (and data) in the program, and decides how to map it all spatially onto the hardware units.

Naively that sounds similar to a GPU. Is it?

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

#63

Post by Nevermark »

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.

Instead of large cores operating mostly independently in parallel (with some few standardized hardwired pipeline steps per core), …

You have many more very small ALU cores, configurable into longer custom pipelines with each step more or less as wide/parallel or narrow as it needs to be for each step.

Instead of streaming instructions over & over to large cores, you use them to set up those custom pipeline circuits, each running until it’s used up its data.

And you also have some opportunity for multiple such pipelines operating in parallel depending on how many operations (tiles) each pipeline needs.

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

#64

Post by wmf »

reactordev wrote: post #59
pclmulqdq wrote: post #52

Earlier quoted context omitted.

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

Is that a design flaw or a tooling flaw? The dev experience is usually left till the very end of some proof like this.

It 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...)

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

#65

Post by gchadwick »

reactordev wrote: post #59
pclmulqdq wrote: post #52

Earlier quoted context omitted.

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

Is that a design flaw or a tooling flaw? The dev experience is usually left till the very end of some proof like this.

Both? 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.

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

#66

Post by gchadwick »

> The interconnect between tiles is also statically routed and bufferless, decided at compile time. As there's no flow control or retry logic, if two data paths would normally collide, the compiler has to resolve it at compile time.

This sounds like the most troublesome part of the design to me. It's very hard to do this static scheduling well. You can end having to hold up everything waiting for some tiny thing to complete so you can proceed forward in lock step. You'll also have situations where 95% of the time the static scheduling can work but 5% of cases where something fiddly happens. Without any ability for dynamic behaviour and data movement small corner cases dominate how the rest of the system behaves.

Interestingly you see this very problem in hardware design! All paths between logic gates need to be some maximum length to reach a target clock frequency. Often you get long fiddly paths relating to corner cases in behaviour that require significant manual effort to resolve and achieve timing closure.

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

#67

Post by almostgotcaught »

kyboren wrote: post #50
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 o…

I don't what this has to do with what you're responding to - tech mapping and routing are two completely different things and routing is known NP complete.

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

#68

Post by Earw0rm »

AnimalMuppet wrote: post #51
londons_explore wrote: post #40

Earlier quoted context omitted.

One day someone will get it working... Data transfer is slow and power hungry - it's obvious that putting a little bit of compute next to every bit of memory is the way to minimize data transfer distance. The laws of physics can't be broken, yet people demand more and more performance, so eventually the difficulty of solving this issue will be worth solving.

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…

We already do.

Cache hierarchies operate on the principle that the probability of a bit being operated on is inversely proportional to the time since it was last operated on.

Registers can be thought of in this context as just another cache, the memory closest to the compute units for the most frequent operations.

It's possible to have register-less machines (everything expressed as memory to memory operations) but it blows up the instruction word length, better to let the compiler do some of the thinking.

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

#69

Post by schobi »

pedalpete wrote: post #45

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

I would not expect that this becomes competitive against a low power controller that is sleeping most of the time, like in a typical wristwatch wearable.

However, the examples indicate that if you have a loop that is executed over and over, the setup cost for configuring the fabric could be worth doing. Like a continuous audio stream in a wakeup-word detection, a hearing aid, or continous signals from an EEG.

Instead of running a general purpose cpu at 1MHz the fabric would be used to unroll the loop, you will use (up to) 100 building blocks for all individual operations. Instead of one instruction after another, you have a pipeline that can execute one operation in each cycle in each building block. The compute thus only needs to run at 1/100 clock, e. g. the 10kHz sampling rate of the incoming data. Each tick of the clock moves data through the pipeline, one step at a time.

I have no insights but can imagine how marketing thinks: "let's build a 10x10 grid of building blocks, if they are all used, the clock can be 1/100... Boom - claim up to 100x more efficient!" I hope their savings estimate is more elaborate though...

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

#70

Post by regularfry »

gchadwick wrote: post #66

> The interconnect between tiles is also statically routed and bufferless, decided at compile time. As there's no flow control or retry logic, if two data paths would normally collide, the compiler has to resolve it at compile time. This sounds like the most troublesome part of the design to me. It's very hard to do this static scheduling well. You can end having to hold up everything waiting for some tiny thing to c…

Was I misreading, or is this thing not essentially unclocked? There have been asynchronous designs in the past (of ARM6 cores, no less) but they've not taken the world by storm.
Post reply on HN