A new and power efficient CPU architecture - Page 1
Forum section: electronics / general

author: zapta
author_rank: Super Contributor
timestamp: July 28, 2025, 01:13:20 am
content: An video about an interesting CPU model that is claimed to be more power efficient by an order of magnitude. The computation is done by a network of tiles that is configured each time to implement the logic of the next chunk of commands, while using the data left in the tiles by the previous chunk.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 28, 2025, 02:04:40 am
content: Color me skeptical. Dataflow processing is as old as the computer. It's great for certain applications. But as a general purpose architecture it's never been a practical option. And even for applications that are a good fit, you normally have to write the code in a dataflow aware format. A generic C++ to dataflow compiler sounds like a pipe dream.

author: brucehoult
author_rank: Super Contributor
timestamp: July 28, 2025, 03:25:55 am
content: Quote from: ejeffrey on July 28, 2025, 02:04:40 amYup. Samsung ULP-SRP was doing this a decade ago. I worked on the LLVM-based compiler for it for a short time before being pulled on to another project. It had a conventional CPU (with 16&24 bit instructions ... ho hum, let's check ... yessss, the opcodes match Xtensa) that controlled a systolic array of ALUs that was reconfigurable via IIRC extra instruction bits on potentially every clock cycle.It got used in a Samsung watch (perhaps more to this day, I don't know) where as I understand it the main task was to be awake and listening for "Hi, Bixby"https://dl.acm.org/doi/abs/10.1145/2629610

author: zapta
author_rank: Super Contributor
timestamp: July 28, 2025, 03:34:29 am
content: Quote from: ejeffrey on July 28, 2025, 02:04:40 amMy understanding is that they provide a C compiler that breaks the program into chunks of small dataflows that are executed by a network of 'tiles' or computational units. The compiler needs to do more optimization work than usual but this makes sense if you want efficient runtime.https://www.efficient.computer/technology

author: brucehoult
author_rank: Super Contributor
timestamp: July 28, 2025, 03:42:44 am
content: Quote from: zapta on July 28, 2025, 03:34:29 amYes, on ULP-SRP we pretty much took basic blocks and treated then the same as you would trying to fit a computation in Verilog to LUTs, though the building blocks were a little higher level. You put as much as you can into one clock cycle, store the outputs into CPU registers, then next cycle reconfigure the systolic array and take some register values to produce (a smaller number of) new register values.So, really very much like fitting bits of HDL into 6-LUTs, especially in that a Xilinx 6-LUT can either produce one output bit from 6 input bits, or 2 output bits from 5 input bits. But the inputs and outputs are 32 bit values not single bits, and the operations are add / sub / and / or / xor/ shift etc.

author: zapta
author_rank: Super Contributor
timestamp: July 28, 2025, 03:54:37 am
content: If I got it correctly, they don't user central registers and instead each chunk, continue with the values in tiles that produced the values in the previous chunks. In that video, he explains that moving data in a conventional CPU consumes significant power and that the saving is done because they don't move data as much. Also, each chunk can results in multiple cycles and a tile may wait for the data to arrive to it and only then it triggers to perform its computation (I wander why they can't plan each cycle statically, possibly becuase of runtime branches).They have a 'playgound' area that require registration.

author: brucehoult
author_rank: Super Contributor
timestamp: July 28, 2025, 04:16:13 am
content: Quote from: zapta on July 28, 2025, 03:54:37 amThe set of tiles can not be infinite in size, so inevitably you have to have registers at the inputs and outputs of the array, ready for a new computation cycle. Just as you do in a multi-cycle or pipelined CPU design.QuoteThat seems pointless and counter-productive.Once you start doing that you're just devolving to a standard OoO back end.

author: zapta
author_rank: Super Contributor
timestamp: July 28, 2025, 04:21:51 am
content: > The set of tiles can not be infinite in size, so inevitably you have to have registers at the inputs and outputs of the arrayThe data can be stored internally in the tiles themselves such that the input for each chunk is the data left in the tiles by the previous chunks.

author: Berni
author_rank: Super Contributor
timestamp: July 28, 2025, 05:54:30 am
content: This CPU sounds like it is only fast when it has to do a lot of repeated computation on a large pile of data... exactly the sort of thing existing GPUs are really good at.We already have a problem with most code not being multithreaded so it can't make good use for modern high core count CPUs. So don't think there is a high likelihood in having software rewritten for these kind of "streaming CPUs". We have a way of compiling C code for running on GPU with CUDA, but it is not like you can throw an entire application in there and magically have it run lightning fast on a GPU. The The C code is just to be familiar to existing programmers, the program still has to be specifically written with a GPU in mind.Not saying it is a bad idea, but the problem is that it is hard to compete with GPUs due to the mountains of money being dumped into developing them (especially now with AI shoveling bilions more into it)

author: brucehoult
author_rank: Super Contributor
timestamp: July 28, 2025, 06:46:47 am
content: Quote from: Berni on July 28, 2025, 05:54:30 amThat's true of all modern CPUs whether conventional wide OoO, DSP, GPU, TPU, just in different patterns of the data and processing.QuoteThat's not what this is. This is for running normal single-threaded code. nothing special, no rewriting.QuoteGPUs don't suit all problems. Already they are being beaten on certain tasks by specialised matrix multiplication hardware (TPU) and indeed Nvidia are incorporating TPU into their GPUs.Very long vector processing can do everything GPUs can, if they have support for masks and divergence/convergence, and are better than GPUs at certain things because of their tighter integration into conventional CPUs. Length-agnostic vectors (RVV and SVE) mean the same code can run efficiently on different vector lengths without recompilation.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 28, 2025, 09:01:59 am
content: Quote from: zapta on July 28, 2025, 03:54:37 amWhich neatly misses mentioning the energy needed to reload the computational units, as well as the speed hit from having reload-able units in the first place.Intel had cores in the past that had very high performance peaks, but the software was never good enough to actually hit them.This looks like a very niche use product, but maybe they can carve out enough 'data-flow' niches to hit commercial critical mass?

author: tszaboo
author_rank: Super Contributor
timestamp: July 28, 2025, 09:10:49 am
content: Quote from: Berni on July 28, 2025, 05:54:30 amI think the point is that it has never really been tried for low power application. Usually the goal was to reduce delay, like in a DSP or increase performance. It's somewhere between an FPGA and DSP.Like if we write a 15 nested if/then does this thing run out of blocks? Or it needs to reconfigure itself and then it's using a bunch of power doing that.I'm not sure what's the target application. They mention a few on their website but all it seems to focus on is wireless. If you are wireless, the core isn't your primary consumer. If you are wired, power consumption isn't a concern. Maybe it allows wireless to process more data on site to reduce the RF payload. I'm also not sure what performance metric they use for the power improvement claim.

author: woofy
author_rank: Frequent Contributor
timestamp: July 28, 2025, 10:04:10 am
content: Well Ian does show suitable caution in his video but Efficient Computer claims to have working silicon that will be available to developers soon, so we'll see if the claims are upheld.Would I use it? Nope!Even if its claims are met, CPU power has long ago fell below the levels that mater to me. An M0+ at 5MHz is going to take around 1mA (based on a typical 180uA/MHz), enough performance for most of my jobs. Everything else around it will make that irrelevant. I can blow double that power budget lighting a single LED.Most of my work is very long term, 10-20 year lifespans. I would never trust a startup with a novel architecture to be there when I need them. That's why I use Microchip and only recently STM32.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 28, 2025, 10:19:50 am
content: Generally, news about new CPU breakthroughs are similar to news about new battery tech breakthroughs - 99.99% are either pure scams, borderline scams, unpractical ideas made in good will, or expensive specialties for tiny niche special markets. This is because thousands of the brightest minds are working with these things with large R&D budgets, and most of the progress has slowed down into tiny micro-optimizations pushing things 0.1 or 1% better, not 100% or 1000%.That being said, sometimes real breakthroughs do happen; some common blind spot to everyone else. Just that they are extremely rare. For example, with 50 years of news in CPUs or battery technology, and 10000 headlines of breakthroughs,nonewas, ever. But all the small 0.1% or 1% inventions together formed a cumulative breakthrough. If you skipped the time in 25-year steps, this evolution would look like steps of breakthroughs.Invention of the blue LED could be an example of an actual breakthrough; something which was significantly completely different, no one else had it, and the invention directly became very important and wide-spread.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 28, 2025, 10:36:09 am
content: A while back I read an article (or did I see a video) about some renewed research into analog computers for AI applications. The idea is that you don't need much precision to simulate a neuron, and with smaller analog blocks you can put more of them on a die.Quote from: woofy on July 28, 2025, 10:04:10 amIf you're not interested, then just don't respond. That should not be very difficult.

author: woofy
author_rank: Frequent Contributor
timestamp: July 28, 2025, 10:53:06 am
content: Quote from: Doctorandus_P on July 28, 2025, 10:36:09 amThere are plenty of applications where low power is required, battery operated devices, especially where only a tiny battery is possible such as smart watches.Don't confuse lack of intent to use with lack of interest.

author: madires
author_rank: Super Contributor
timestamp: July 28, 2025, 11:25:47 am
content: I'm sceptical. If a CPU architecture is optimized for a specfic feature or set of features it will perform worse at others. It's always a tradeoff. A classic example is the length of pipelines. Long pipelines are great for some applications but a disaster for others, and the same for short ones. Therefore the pipeline length for a general purpose CPU is a compromise, i.e. to provide a benefit in many cases but not to cause too much performace loss in problematic cases. Another - extreme - example are ASICs. They are so highly optimzed for a few specific tasks that they can't do anything else. Or CISC vs RISC. I'd say that any general improvements are to be expected from new semiconductor processes, not new CPU architectures. As a side note, the current development around RISC-5 is interesting. Especially, if mistakes by AMD and Intel are repeated or if RISC-5 developers do better.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 28, 2025, 03:28:05 pm
content: The problem with relying entirely on the compiler to do rather sophisticated work to map some actual, high-level source code to this architecture is that it's often doomed from its inception.It has been tried before, and caused all kinds of issues. Almost all of these attempts have failed.Now maybe one can consider this architecture as something like FPGAs, for which, yes, sophisticated and often proprietary tools are required to translate some HDL to actual logic cells. But FPGAs are ultra-versatile. I'm not sure such a specific architecture would have a real future.Now, another example could be the XMOS architecture. Yes, they require proprietary tools, but at least the underlying architecture can be understood by humans. And they are still niche after all this time.But again, from experience, CPUs that rely too much on compilers to be effective are often set up for failure.Think of the Mill architecture and how they've been struggling to get traction - and yet, it's way closer to a conventional CPU architecture than these "Efficient" things appear to be.

author: tggzzz
author_rank: Super Contributor
timestamp: July 28, 2025, 04:03:28 pm
content: Quote from: madires on July 28, 2025, 11:25:47 amI agree with your other points, but not that one: semiconductor process improvements have become comparatively glacial.Hence I think major future improvements will be related to highly parallel hardware/softwaresystems. Parallel hardware is easy. Software is the greater problem: Amdahl's law, compilers detecting and extracting parallelism, designers "thinking parallel", tools and techniques supporting parallel designs.There are hopeful signs, but many more are needed.

author: tggzzz
author_rank: Super Contributor
timestamp: July 28, 2025, 04:12:52 pm
content: Quote from: SiliconWizard on July 28, 2025, 03:28:05 pmIt seems easier for hardware people to "think parallel" in hardware and software systems. Softies seem to be fixated on sequential mutation.QuoteItanic anyone?QuoteThat stuff is indeed interesting and impressive, and they've been careful to patent many of the concepts. They appear to be able to get an order-of-magnitude improvement while still being able to run conventional C/Unix code. In terms ofpastCPU/semiconductor performance improvements, that's only a few yearsWhat's not clear to me is whethersomeof their concepts can be used in less radical architectures, or whether it is an all-or-nothing leap.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 28, 2025, 04:48:35 pm
content: Yes, speaking of the Mill, it's very interesting but the fact they were too keen to protect everything (which is understandable) makes it hard for third-parties to check any of their claims for real, or even contribute.So yeah... looks great, but we don't know for sure.

author: Berni
author_rank: Super Contributor
timestamp: July 28, 2025, 06:33:06 pm
content: Quote from: brucehoult on July 28, 2025, 06:46:47 amI did count TPUs in with GPUs since that's how you usually find them these days. Tho yeah sometimes they call them NPUs instead. Even smaller chips with ARM cores are getting those due to AI hype, so you can already do a lot of repetitive fast math on existing chips. The speed of it mostly just limited by how many there are in parallel and how fast they can be fed new data.So i think this new architecture is mostly just a niche optimized chip for accelerating large amounts of math in cases where it is too messy for existing chips. But if used as a general purpose CPU would have the same problems with unpredictable branching (since this special CPU couldn't sensibly hold an entire multi megabyte program wired up ready to run). All while existing CPUs already strive to not move things around too much by doing most of the work in CPU registers. So don't think this new chip would be anywhere near as impressively fast and efficient at regular CPU tasks of say running a web server.

author: zapta
author_rank: Super Contributor
timestamp: July 28, 2025, 08:12:53 pm
content: Quote from: tggzzz on July 28, 2025, 04:12:52 pmHave you heard of map-reduce? Go to any large hi-tech company and they are the workhorses that run the massive backend computations.(I am including also map reduce generalizations such as Flume).

author: zapta
author_rank: Super Contributor
timestamp: July 28, 2025, 08:17:24 pm
content: Quote from: Berni on July 28, 2025, 06:33:06 pmI wonder if moving data to/from the microcontrollers main registers is expensive, power wise, since these are global busses with high fanout and capacitance.

author: tggzzz
author_rank: Super Contributor
timestamp: July 28, 2025, 08:23:07 pm
content: Quote from: zapta on July 28, 2025, 08:12:53 pmI'll bet most of those massive back-end computations fall into he "embarrassingly parallel" category; Monte-carlo sensitivity analyses. and similar. Important but a relatively uninteresting subset of parallel computation, and definitely not relevant to this new chip.Yes I have heard of the map-reduce algorithm. We need more such algoithms, plus more general tools, as I hinted when I ended that post withQuote from: tggzzz on July 28, 2025, 04:03:28 pm

author: zapta
author_rank: Super Contributor
timestamp: July 29, 2025, 06:44:32 pm
content: Quote from: tggzzz on July 28, 2025, 08:23:07 pmI wouldn't call building computations such as building a search index, building geo maps, massive image processing, or 3D model extractions, 'uninteresting', or 'embarrassingly parallel'. Those parallel computations and algorithms are everywhere.

author: tggzzz
author_rank: Super Contributor
timestamp: July 29, 2025, 07:42:10 pm
content: Quote from: zapta on July 29, 2025, 06:44:32 pmI was using the term "embarrassingly parallel" in this sense:https://en.m.wikipedia.org/wiki/Embarrassingly_parallel

author: zapta
author_rank: Super Contributor
timestamp: July 29, 2025, 08:31:39 pm
content: Quote from: tggzzz on July 29, 2025, 07:42:10 pmThese are rare, for example deleting expiring items when each item is independent. Typically there is dependency between the shards, sometimes stitching the interfaces between adjacent shards, sometime global collection of related data items. For example, let's say you want to find the most popular word in 10B documents, after analyzing each document there is a less scaleable phase of identifying the top word.But as you said, this parallelism is in a very different scale as the one here.

author: tggzzz
author_rank: Super Contributor
timestamp: July 29, 2025, 08:54:07 pm
content: Quote from: zapta on July 29, 2025, 08:31:39 pmEmbarrassingly parallel problems are common and commercially important. Examples: telecoms servers handling independent calls, ditto web servers, or monte carlo sensitivity analyses where each analysis is identical except for parameter differences.Examples where one parallel computation can depend on the others are difficult to analyse and are subject to Amdhal's Law. There is usually a tradeoff betweensmaller computations with higher synchronisation costslarger computations with higher communication costs (more environment/state has to be transmitted)

author: zapta
author_rank: Super Contributor
timestamp: July 30, 2025, 04:31:36 pm
content: > Examples: telecoms servers handling independent calls,I am not sure how independent they are since they compete on shared resources.To summarize, parallelism is a big part of modern software engineering.

author: tggzzz
author_rank: Super Contributor
timestamp: July 30, 2025, 05:55:43 pm
content: Quote from: zapta on July 30, 2025, 04:31:36 pmI'm sureThe sharing is negligible, with the exception of the charges associated with multiple data streams debiting a single pot of gold.The generic issue of provisioning sufficient server capacity is not relevant to this discussion, any more than it would be for map-reduce.QuoteIt is a spectrum, of course.The interesting problems are not with embarrassingly parallel problems.You can't, as the famous observation puts it, reduce latency to one month by adding eight pregnant women to the job

author: zapta
author_rank: Super Contributor
timestamp: July 30, 2025, 06:24:27 pm
content: It reduces the latency of having 8 babies.BTW, in our times, all geneders can be pregnant.;-)