Live data from Hacker News

Auto-research with codex: How I achieved a 232x Faster Kernel

sankalp.bearblog.dev

31–40 of 104 posts

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#31

Earlier quoted context omitted.

What do you mean by 2?

LLMs will take shortcuts and cheat in ways that a human would realize are counterproductive.

I've seen this several times now. Disturbing.

IMO, LLMs will be a dead end to anything close to AGI because of this and hallucinations.

We're missing something in the mix, which I suspect is some kind of advanced JEPA model.

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#32

In the last couple of days I wanted to try out the new definitive DeepSeek v4 releases. I gave it the repository of a semi-abandoned video compression codec and I told it to perform the usual benchmark -> profile -> verify -> research -> improve loop. I specifically chose this codec because the authors include a verifier for the bitstream to make sure you don't break stuff if you want to try your own implementation.…

This is the way. Checkout the technique mentioned in the alphaevolve paper and see if it works well for your setting.

Thank you for the reference, I hope to be smart enough to try it out!

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#33

Earlier quoted context omitted.

What do you mean by 2?

LLMs will take shortcuts and cheat in ways that a human would realize are counterproductive.

LLMs take shortcuts if allowed.

Humans do it ignorantly.

The LLMs will improve while average human IQ in the west dips closer and closer to the 80s on the global scale.

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#34
post #10

This is really cool - I really like the beam search idea,

this is the first time ive heard of beam search. i would have reached for a genetic algorithm of some sort, although it seems like some stochastic versions of beam search exist to avoid local minima. i wonder if there are any good frameworks for building these that agents can construct and use.

I think the question is how do you keep track of the ideas that the agent is pursuing - like I was working on this for implementing a fft, and doing the optimizations, but I held its hand and was like - hey let's go back and retry this older thing you discounted because of a 3 % slowdown.

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#35
post #21
post #8

Every step here has an oracle: wall-clock, the profile, pass or fail from the verifier. I had an agent-built app audited task by task, 10 came back done and 7 worked, and the three misses were the ones needing a credential or a setting on someone else's dashboard. Nothing in the loop could tell the agent it had failed, so it said done and moved on.

I’ve tried it on simple UI tasks. Give it screenshot to work towards (or figma MCP), let it get screenshots from chrome to check its work. The existing models are surprisingly bad at it.

It's really difficult to understand what your definition of surprisingly bad is. What was it continuously having problems with?

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#37

Earlier quoted context omitted.

What do you mean by 2?

LLMs will take shortcuts and cheat in ways that a human would realize are counterproductive.

you specify the goal. if the goal is achieved, it's achieved.

the code the LLM writes will be read and maintained and developed further by LLMs. so it doesn't really matter what it produces as long as all the tests are green and it achieves exactly what you want it to achieve.

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#39

Damn! If a solo engineer can do this, it makes the most around OAI/Anthropic start to look pretty weak.

This was nowhere near the top submission. But even if a solo engineer could get a top kernel, you don't think that having thousands of engineers, infinite tokens, and stronger models than are available to the public would give the labs a significant edge?

That’s not what a moat is =]

Which I believe was the word intended.

Re: Auto-research with codex: How I achieved a 232x Faster Kernel

#40

In the last couple of days I wanted to try out the new definitive DeepSeek v4 releases. I gave it the repository of a semi-abandoned video compression codec and I told it to perform the usual benchmark -> profile -> verify -> research -> improve loop. I specifically chose this codec because the authors include a verifier for the bitstream to make sure you don't break stuff if you want to try your own implementation.…

I have used Opus 5 and some Fable 5 to finally get realtime transcoding of 4K 10-bit HEVC (to 1080p or smaller SDR AVC) working on a Raspberry Pi 4. It was very good at writing optimized NEON kernels. the Argon HEVC hardware decoder outputs SAND30 which is a tiled format that is annoying to work with and not really supported by anything else, the big performance issue has been with converting and scaling it, but as it turned out a lot of it was really with just moving memory around, so by fusing multiple steps into a single kernel it became fast enough. Experimenting with writing the NEON kernels for the different combinations would have taken forever by hand.

I do wonder if auto-research would have reached something similar, it did take a significant amount of steering from me to get it to the point where it was working realtime.

For anyone interested the ffmpeg is at https://github.com/poizan42/jellyfin-rpi-ffmpeg and a shim for using it with stock jellyfin at https://github.com/poizan42/jellyfin-rpi-ffmpeg-shim

Post reply on HN