[HN Gopher] Show HN: Compiler Playground for energy-efficient em...
___________________________________________________________________
Show HN: Compiler Playground for energy-efficient embedded dataflow
processor
Hi 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...
Author : keyi
Score : 26 points
Date : 2025-02-27 18:38 UTC (4 hours ago)
(HTM) web link (www.efficient.computer)
(TXT) w3m dump (www.efficient.computer)
| cmontella wrote:
| 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!
| keyi wrote:
| > 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!
| cmontella wrote:
| Thank will follow along with great interest!
| ptmcc wrote:
| 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?
| webdevver wrote:
| scrolling on touchpad was like wading through honey
| K0balt wrote:
| 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?
| blacklion wrote:
| 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.
| K0balt wrote:
| 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)
| keyi wrote:
| 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.
| skavi wrote:
| 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?
| skavi wrote:
| 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.
| musicnarcoman wrote:
| 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...
| nynx wrote:
| It seems the product brief is behind a sign-up page. Please
| indicate to your sales folks that this is highly
| counterproductive.
| pinkberry12 wrote:
| Really cool stuff! Excited to see what's next from this awesome
| team
___________________________________________________________________
(page generated 2025-02-27 23:01 UTC)