Percentage chance this is 100X more efficent at the general purpose computing ARM is optimized for: 1/100%
Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
11–20 of 113 posts
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#12reminds 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.
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#13I don't know much about CPUs so maybe someone can clarify. Is this effectively having a bunch of tiny processors on a single chip each with its own storage and compute?
[deleted]
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#14reminds 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.
Also, how would cycle-accurate assembly look like for this chip?
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#15Is there a dev board available? Seems hard to find. I am curious.
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#16Is 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.
I disagree; Itanium was fundamentally flawed for general purpose computing and especially time-shared generally purpose computing. VLIW is not practical in time-sharing systems without completely rethinking the way cache works, and Itanium didn't really do that.
As soon as a system has variable instruction latency, VLIW completely stops working; the entire concept is predicated on the compiler knowing how many cycles each instruction will take to retire ahead of time. With memory access hierarchy and a nondeterministic workload, the system inherently cannot know how many cycles an instruction will take to retire because it doesn't know what tier of memory its data dependencies live in up front.
The advantage of out-of-order execution is that it dynamically adapts to data availability.
This is also why VLIW works well where data availability is _not_ dynamic, for example in DSP applications.
As for this Electron thing, the linked article is too puffed to tell what it's actually doing. The first paragraph says something about "no caches" but the block diagram has a bunch of caches in it. It sort of sounds like an FPGA with bigger primitives (configurable instruction tiles rather than gates), which means that synchronization is going to continue to be the problem and I don't know how they'll solve for variable latency.
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#17This 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.
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#18This 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.
I agree this is very "FPGA-shaped" and I wonder if they have further switching optimisations on hand.
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#19Earlier 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.
I disagree; Itanium was fundamentally flawed for general purpose computing and especially time-shared generally purpose computing. VLIW is not practical in time-sharing systems without completely rethinking the way cache works, and Itanium didn't really do that. As soon as a system has variable instruction latency, VLIW completely stops working; the entire concept is predicated on the compiler knowing how many cycles…
> VLIW is not practical in time-sharing systems without completely rethinking the way cache works
Just curious as to how you would rethink the design of caches to solve this problem. Would you need a dedicated cache per execution context?
Re: Efficient Computer's Electron E1 CPU – 100x more efficient than Arm?
#20I don't know much about CPUs so maybe someone can clarify. Is this effectively having a bunch of tiny processors on a single chip each with its own storage and compute?
I think it's more like having the instructions your program does spread accross mulitple tiny processors.
So one instruction gets done.. output is pass to the next.
Hopefully i've made somebody mad enough to explain why i am wrong.