Show HN: Compiler Playground for energy-efficient embedded dataflow processor
efficient.computerHi HN! My team at Efficient Computer (https://efficient.computer) and I are working on a new computer architecture and I am leading the team that is building the compiler for our chip. Our hardware is focused on energy-constrained embedded applications and is super efficient, which lets devices run for years on a small (ie AA) battery. We built a playground for our compiler that has a cool visualizer and debugger that shows how your C code (more languages to come) maps to our Fabric architecture, and an energy model that shows you how much less energy your code uses on our architecture. Check it out: https://www.efficient.computer/resources/effcc-compiler-play...
It seems the product brief is behind a sign-up page. Please indicate to your sales folks that this is highly counterproductive.
I interned at a company that built low power water monitoring devices with a field lifetime of 10 years [0]. It looks like you're trying to hit that niche as well? I'm interested to hear how you handle comms, because my understanding of the low power world is that typically it's peripherals (clocks, PLLs etc) that draw the most power so the majority of effort goes in to minimising their use and pushing them in to sleep modes as much as possible, rather than any secret sauce with the compiler? Happy to be wrong though, I've never done anything meaningful in this space
[0] https://taggle.com/
This seems cool, if a bit over my head. But I fully support high-efficiency software that bucks the general trend of the past 30 years.
Could this sort of tool have applications in more general software dev? Like as a performance profiler perhaps?
This is really cool! What do you mean by "the" compiler for our chip? Is this a compiler backed like LLVM which generates efficient machine code, that other languages can target? I'm an author of a dataflow programming language, what kind of resources do you have that I could read about targeting your hardware? I've been waiting for hardware to catch up with the language I'm building, so that's why I'm interested!
> What do you mean by "the" compiler for our chip?
We are designing a dataflow general-purpose processor that can directly executes the dataflow graph from the compiler.
> Is this a compiler backed like LLVM which generates efficient machine code, that other languages can target?
The compiler itself takes LLVM as the input, so if your framework can output LLVM, you should be able to target our compiler backend and hardware. We had a prototype working with Rust as well. The compiler does not however use LLVM to produce the machine code on our hardware -- custom mapper/assembler and linker is used to produce the machine code that runs on the hardware.
> what kind of resources do you have that I could read about targeting your hardware?
We have published a couple papers about our compiler and hardware design: https://www.efficient.computer/media. Unfortunately we don't have a concrete plan to open up the compiler yet. Please stay tuned!
Thank will follow along with great interest!
Is your processor a good match for ml workflows, or will GPUs still be the way to go there?
Does your system use distributed memory? shared memory? How do you deal with memory bound tasks?
I’d love to see this released in an RF-SOC like the esp32 or. NRF52840, in my experience, RF capabilities are a requirement for the vast majority of edge applications.
What are we looking at in energy savings over best-in-class Harvard designs like the NRF52840?
1. Yes we are a great fit for edge ML inference, but we are also great for DSP and other, general-purpose application logic.
2. Our chip has an integrated memory & integrated non-volatile storage that are shared across the tiles in our architecture.
3. We agree, RF applications are very interesting and are a great fit for our architecture in a lot of cases
4. It's hard to say what the energy savings would be versus that specific chip without doing some benchmarking. We have measured 10-100x improvement in energy consumption against several very competitive Arm implementations that we've tested and I'd expect to see a similar advantage.
I've thought EMF32 are most efficient, but I've looked up NRF52840 and shocked: 150 uA/MHz fo EMF32 and 30 (!) uA/MHz for Nordic part, if I goggled it right.
Yeah, the Nordic part is basically magic if you are careful. If these guys can do 10x on that, a whole market segment could move to energy harvesting / single use battery and battery life for other segments could double or triple. (Often the uC is not the big power draw)
It's not hard at all to get good uA/MHz numbers, it just increases die size and cost. You can push it pretty far by tuning the synthesis, for example the same Cortex-M4 core on the Ambiq Apollo3 Blue advertises "6 μA/MHz executing from flash or RAM at 3.3 V"
These are magnitudes of difference across the Espressif, Nordic, and Ambiq parts. The difference in price is also proportional.
https://ambiq.com/apollo3-blue/
Cool, il check that out!
Is there really no way to access the playground without “signing up for early access” with a company email?
What’s the point? Isn’t that level of friction going to cause the vast majority of people to walk away and forget this exists?
from https://news.ycombinator.com/showhn.html
> Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. You'll get more feedback that way.
Same thing for the "Product Brief" document that maybe goes into detail about the hardware.
The Media section does have some details such as whitepapers and a doctoral thesis. Still it would be nice to have specifications for the actual product if you are trying to sell it...
Really cool stuff! Excited to see what’s next from this awesome team
scrolling on touchpad was like wading through honey