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

51–60 of 113 posts

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

#51

Post by AnimalMuppet »

londons_explore wrote: post #40
jnpnj wrote: post #36

Earlier quoted context omitted.

That was my first thought too. I really like the idea of interconnected nodes array. There's something biological, thinking in topology and neighbours diffusion that I find appealing.

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, sooner or later, something will have to give. There will be some scale such that, if you create clumps either larger or smaller than that scale, things will only get worse. (But that scale may be problem-dependent...) I agree that sooner or later we will have to do something about it.

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

#52

Post by pclmulqdq »

RossBencina wrote: post #49
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.

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.

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

#53

Post by pclmulqdq »

elseless wrote: post #44
pclmulqdq wrote: post #41

Earlier quoted context omitted.

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…

Oh, many embedded architectures don't have a cache hierarchy and instead place dynamic objects in one SRAM. Access latency is constant anywhere you go.

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

#56

Post by markhahn »

bobmcnamara wrote: post #48
darksaints wrote: post #6

Earlier quoted context omitted.

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.

haha! very droll.

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

#57

Post by montymintypie »

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

Human interfaces, sure, but there's a good chunk of industrial sensing IoT that might do some non-trivial edge processing to decide if firing up the radio is even worth it. I can see this being useful there. Potentially also in smart watches with low power LCD/epaper displays, where the processor starts to become more visible in power charts.

Wonder if it could also be a coprocessor, if the fabric has a limited cell count? Do your dsp work on the optimised chip and hand off the the expensive radio softdevice when your codesize is known to be large.

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

#59

Post by reactordev »

pclmulqdq wrote: post #52
RossBencina wrote: post #49

Earlier quoted context omitted.

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.

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.

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

#60

Post by markhahn »

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…

I think that footnote is close to the heart of it: on a modern OoO superscalar processor, there are hundreds of instructions in-flight. that means a lot of work done to maintain their state and ensure that they "fire" when their operands are satisfied. I think that's what this new system is about: a distributed, scalable dataflow-orchestration engine.

I think this still depends very much on the compiler: whether it can assemble "patches" of direct dependencies to put into each of the little processing units. the edges between patches are either high-latency operations (memory) or inter-patch links resulting from partitioning the overall dataflow graph. I suspect it's the NOC addressing that will be most interesting.

Post reply on HN