Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

github.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#51

Post by vessenes »

fc417fc802 wrote: post #4

Extremely interesting but I don't understand why it was written by an LLM. Either the frontier models are far better than I realized or else writing this document required a lot of manual work regardless at which point why not keep it in your own voice? > The agent did not know that would also halve the LUT count. It found out by doing it and watching the synthesizer. So I guess this is an example of an LLM anthropom…

Yeah I find this current LLM voice very tiring to read; I get enough of it day-to-day wrangling claude and others. I don’t think ‘writing’ this took very much work though, it was probably a “read the research logs, and write a blog post with charts showing our amazing results and hammering on the idea that verifiers matter” as a prompt. The rest you could go have a coffee for.

That said, the core idea of this — verification matters a lot — is well received, and in fact, this is totally awesome in terms of results. They mention at the end they’re not sure how much of this is microtuned against the benchmark, a sin that many CPU companies cheerfully commit and have committed over the last 40 years btw, so I’d be interested in a followup with more general benchmarking. Either way, amazing.

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#52

Post by vessenes »

bsder wrote: post #17

> The frontier is the verifier. Um, yes? The big value that AMD had in the x86 market over competitors was their verification model. This has been known for decades. > 3-seed nextpnr P&R on a Gowin GW2A-LV18 (Tang Nano 20K) — median Fmax × CoreMark iter/cycle = fitness Every single "improvement" is basically about routing around how absolutely abysmally bad the Gowin FPGAs are. Kudos to that, I guess? Gowin FPGAs hav…

Amazing comment.

As a non-hardware guy, I read, “well, duh, for a 20yr practitioner dealing with the intricacies of specific FPGA series, all this makes tons of sense”.

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#53

Post by fesens »

bsder wrote: post #17

> The frontier is the verifier. Um, yes? The big value that AMD had in the x86 market over competitors was their verification model. This has been known for decades. > 3-seed nextpnr P&R on a Gowin GW2A-LV18 (Tang Nano 20K) — median Fmax × CoreMark iter/cycle = fitness Every single "improvement" is basically about routing around how absolutely abysmally bad the Gowin FPGAs are. Kudos to that, I guess? Gowin FPGAs hav…

The frontier is the verifier not in the sense of this project, but to every project. If we have a good verifier for a task, any task, this type of loop can be applied to it. Today LLMs are good enough to tackle FPGA projects, but what this type of loop will be applicable to many more things

Board should be arriving next week. I will let you know!

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#54

Post by fesens »

bsder wrote: post #17

> The frontier is the verifier. Um, yes? The big value that AMD had in the x86 market over competitors was their verification model. This has been known for decades. > 3-seed nextpnr P&R on a Gowin GW2A-LV18 (Tang Nano 20K) — median Fmax × CoreMark iter/cycle = fitness Every single "improvement" is basically about routing around how absolutely abysmally bad the Gowin FPGAs are. Kudos to that, I guess? Gowin FPGAs hav…

"I would LOVE somebody to bounce AI off of reversing the architecture and bitstreams for the stupid-ass closed-source FPGAs."

The only reason I'm using Gowin is because it has a slightly more mature opensource tooling. Maybe we can apply this loop to nextpnr also

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#56

Post by zby »

thald wrote: post #31
pteetor wrote: post #3

In case you are unfamiliar with Karpathy's Loop[1], it is a genetic algorithm[2] where the genetic "mutations" are clever-but-random ideas generated by an LLM agent, aimed at improving a system. (1) Let the LLM randomly perturbate the system. (2) Measure the system's performance. (3a) If the perturbation improved performance, keep the change. (3b) Otherwise, don't. (4) Repeat [1] https://github.com/karpathy/autoresea…

I was working some time ago on LLM assisted optimizations and algorithm discovery and this does not look like a novel idea. AlphaEvolve from google is evolutionary algorithm which uses LLMs for Idea generation following very similar loop: - https://deepmind.google/blog/alphaevolve-a-gemini-powered-co... - Open source implementation of the algorithm: https://github.com/algorithmicsuperintelligence/openevolve

It is not novel - but with the new models it is just becoming practical.

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#57

Post by ajmurmann »

2ndorderthought wrote: post #49
KronisLV wrote: post #38

Earlier quoted context omitted.

Is it? Evolution also seems to be a result of semi-random crap over the span of millenia and nobody is critiquing it like that. Why should throwing ideas at the wall in regards to optimizing code be any different: as long as you can measure and verify it, are okay with added complexity, and are capable of making the code itself not be crap by the end of it? If an approach is found that improves how well something wor…

It's basically saying to randomly slop something and see if it gets better. Evolution has physical principles and guard rails backing it. Here there are no principals whatsoever, just slopping the slopper to see if it's somehow less sloppy then writing a gist with a slop machine. I wouldn't call it karpathys loop I'd call it slop descent. Or descent into slop. Or something like that

Evolution very much involves random mutations that turn out useless or harmful and thus don't spread.

This is in fact less random than how generic algorithms used to work traditionally which encoded behaviors in some data structure that then got randomly mutated or crossed with other candidates in the pool.

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#59

Post by 2ndorderthought »

ajmurmann wrote: post #57
2ndorderthought wrote: post #49

Earlier quoted context omitted.

It's basically saying to randomly slop something and see if it gets better. Evolution has physical principles and guard rails backing it. Here there are no principals whatsoever, just slopping the slopper to see if it's somehow less sloppy then writing a gist with a slop machine. I wouldn't call it karpathys loop I'd call it slop descent. Or descent into slop. Or something like that

Evolution very much involves random mutations that turn out useless or harmful and thus don't spread. This is in fact less random than how generic algorithms used to work traditionally which encoded behaviors in some data structure that then got randomly mutated or crossed with other candidates in the pool.

I am aware of what biological evolution is. This isn't analogous. I love my software friends, I'm a software person now too, but the level at which people take algorithms that involve any level of biomimicry as a model for actual biology is frustrating.

Re: Show HN: Auto-Architecture: Karpathy's Loop, pointed at a CPU

#60

Post by robviren »

I love genetic algorithms and find using LLMs as part of them super compelling. I always find the fitness functions to be the most difficult part. The algorithm naturally tries to exploit any little gap you leave it in cheating. Best part is not needing back propagation in solving a problem. However that is also the worst part in all the solutions just being one level above a random walk. The LLM augmentation really helps to give it a gradient and intelligence beyond random chaos. Love the idea of it being applied to hardware.
Post reply on HN