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

71–80 of 113 posts

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

#71

Post by majkinetor »

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…

> meaning there’s a very limited ability for data-dependent branching, looping, etc. to occur compared to a CPU

Not very useful then if I can't do this very basic thing?

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

#72

Post by torginus »

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.

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 comes from having to interact with memory, and handling other data hazards.

If this was reducible complexity, they'd have done so already.

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

#73

Post by pbhjpbhj »

From a position of naive curiosity -- Would this work as a coprocessor, take the most inefficient/most optimisable procedures and compile (#) them for the fabric? It would you lose all your gains in turn being extra processes to ship data between cores/processors?

How 2D is it: compiling to a fabric sounds like it needs lots of difficult routing. 3D would seem like it would make the routing much more compact?

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

#74

Post by actionfromafar »

torginus wrote: post #72
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.

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…

Then I have a thought experiment. Replace the execution cores on a state of the art GPU and CPU with FPGAs.

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

#75

Post by actionfromafar »

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…

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

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

#76

Post by santaboom »

actionfromafar wrote: post #74
torginus wrote: post #72

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…

Then I have a thought experiment. Replace the execution cores on a state of the art GPU and CPU with FPGAs.

See amdahls law Edit: [0] https://en.m.wikipedia.org/wiki/Amdahl%27s_law

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

#77

Post by Earw0rm »

Earw0rm wrote: post #68
AnimalMuppet wrote: post #51

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…

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

Indeed you can take this further and think of three address spaces:

- Visible register file. 4-6 bit address space, up to 2kb in size. Virtualized as hidden (hardware) registers. Single cycle access. Usually little or no access controls or fault handling, if it exists you can read/write it.

- Main memory, 32-64 bit address space. Virtualized as caches, main RAM and swap. Access may be as low as 5 cycles for L1d, hundreds for main RAM, up into millions if you hit the swap file. Straightforward layer of access controls: memory protection, segfault exceptions and so on.

- Far storage, URIs and so on. Variable-length address space, effectively infinite. Arbitrarily long access times, arbitrarily complex access controls and fallbacks.

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

#79

Post by santaboom »

pbhjpbhj wrote: post #73

From a position of naive curiosity -- Would this work as a coprocessor, take the most inefficient/most optimisable procedures and compile (#) them for the fabric? It would you lose all your gains in turn being extra processes to ship data between cores/processors? How 2D is it: compiling to a fabric sounds like it needs lots of difficult routing. 3D would seem like it would make the routing much more compact?

Curios what you mean by 3D and also how 3D is used. Assuming something like [0] I can pretty confidently tell you that it is not 3D as it is a low power microcontroller and this technology is mostly used in large expensive HPC/AI chips also afaik 3D stacking of logic die is not really a thing (if anyone knows counterexamples pls provide) it is much more common for stacking memory die ex HBM. As for your proposed coprocessor that actually might benefit from 3D integration with the trad cpu as >> # of interconnect / memory channels could allow you to route data more directly to processing elements. Something like this is proposed with “2.5D” stacking in [1] where HBM (3D) is connected to an FPGA with 128 channels.

[0] https://resources.pcb.cadence.com/blog/2023-2-5d-vs-3d-packa...

[1] page 6: https://bu-icsg.github.io/publications/2024/fhe_parallelized...

Post reply on HN