This is really cool - I really like the beam search idea,
Auto-research with codex: How I achieved a 232x Faster Kernel
41–50 of 104 posts
Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#42Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#43Isn't cholesky - used to substitute householder at a point - faster but less stable in some cases? I'm just recalling from memory since I had done a small project on qr decomposition with householder for an exam this year. I mean, if it is faster than the standard torch operation probably there are good reasons for which it is not the default standard torch operation. Might as well be wrong, I'm not sure
Also QR is a primitive for operations like finding eigenvalues, and I don't think Cholesky can be used there.
Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#44Earlier quoted context omitted.
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
#45Earlier quoted context omitted.
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?
I don't know. That just sounds like throwing money at a problem until it goes away. I'm not convinced that is the correct path forward.
Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#46Earlier quoted context omitted.
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.
the claude loop/goal just decides it doesnt feel like doing it anymore and ends the loop or goal
Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#47In 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.…
Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#48- accelerated launch of our new backends like polars, including a new lazy mode & planner, which are fundamentally new paths
- while we initially aimed for top GPU benchmark scores, we now also maintain top CPU scores too!
Long-term, more interesting to me is this opens rethinking what it means to be a query engine. Right now we are making it the fastest in general, especially on workloads from our own use, major industry benchmarks, and our users. At the same time, similar to jit and multistage computing, we're looking at new ahead-of-time optimization techniques users can do that are more interesting than plugging in custom indexes. Essentially, if our agents can do fast specializations, there should be safe hooks that we can expose to our user's agents too!
Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#49Re: Auto-research with codex: How I achieved a 232x Faster Kernel
#50Meta commentary but it felt fresh to read a long wall of text that didn't seem to be AI generated. Thanks.
welcome! check out my featured section