Comment by Almondsetat
2 days ago
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 gave the agents access to the compiler's profiler and also Intel's VTune, which has fantastic output. In a couple of hours the LLM generated SSE and AVX implementations of the compression and decompression algorithms that almost doubled performance with a single core. Then I asked it to create a CUDA implementation using NVIDIA's NSIGHT profiler as a guide and it also started doing some good work.
Personally, I believe that LLMs should be treated like an advanced version of Prolog or linear programming: you give the constraints, you have a way of verifying correctness, and you give it a clear goal. If the LLM can verify itself and course-correct you can basically leave it on autopilot
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
I did something similar recently with Google's C# protobuf library. I had spotted I was getting CPU bound rather than memory bandwidth bound when doing streaming of uint32 buffers in dotnet gRPC.
I then asked claude to compare the C#/.NET implementation in the library with the C++ version, and it quickly identified that the C# library was missing a couple of fairly cheap optimisations that were present in the C++ version.
If I can help get a PR merged, then it'll be by far the biggest impact of any work I've ever done.
I also compared the Rust version, it had this specific optimisation. The far more popular Tokio/Prost library did not.
Given appropriate guardrails, LLMs are impossibly fast at iterating to find root causes and specific performance bottlenecks.
You presented another thing LLMs excel at: integrating something from a project that is not present in another one. I think they work so well at this because both the starting and ending points have an already existing structure, so the LLM can guide itself effectively. In your case it's even more egregious because we are talking about the same exact algorithm/functionality implemented in two different, but rather similar, programming languages.
Could you have manually profiled and compared the execution paths? Sure. Could you have translated the C++ optimizations to C#? Sure. But in such an obvious case, the LLM managed itself.
Yeah. LLMs are also great at reading and understanding thousands of lines of code quickly. It can find things like this - or compare disparate implementations.
I’ve been using fable recently not to write code, but to write briefing notes on projects. “Read and compare these three libraries. What are the unique differences in their implementations? Why were those ideas chosen? What are the pros and cons of those designs? What ideas would you copy into a new project? Write a report on your findings.”
I've had a lot of success decompiling old video game ROMs in exactly this way. Like you say - give it a way of verifying correctness - put it in a loop - and they are quite surprising.
https://github.com/qarl/arcade-js
Same. I love reverse engineering embedded stuff.
Even the cheap LLMs are great in doing the awful crud work in the beginning: finding offsets, firmware update file structures, brute forcing checksums, etc.
It still produces a lot of crap in the later steps (understanding the implementation itself) but I'm happy doing this stuff myself then.
> It still produces a lot of crap in the later steps (understanding the implementation itself)
I've had success here by adding a phase called "grounding" that attempts to verify its "understanding" by creating tests that modify the running executable to ensure its made the right inference.
Is this variable really MARIO_X? Change it and see if Mario moves. Etc.
As an example in Donkey Kong - the system had trouble deciding if an array controlled barrels or fireballs. There was conflicting evidence.
After many trips through the loop - it realized it does BOTH, depending on which level you're on.
So the "understanding" grows with each iteration.
Oh wow, this is almost exactly what I’ve been doing with Zelda LTTP. I have it in rust now, but just finished the “first pass” you reference. Mine is still not really readable, second step is the modernizing the actual code. I’ve really struggled with needing to handhold it though, I’ll see if I can plagiarize from you!
I'm working on getting the "handholding" down to zero. Frogger is almost done and I haven't had to intervene once.
Very cool, me too! I've been working on Final Fantasy Legend (Game Boy and WonderSwan Color) and King's Bounty (PC - DOS). It's great for reversing. Really interesting to see the guts of the games, including bugs.
The most interesting thing I've found so far is the anti-tampering mechanisms.
In Time Pilot - there are three routines that are called constantly from inside the main loop. Each routine computes the checksum of the other routine's code to see if it's been modified. If so it jumps into random junk data.
There are other less exotic routines that make sure the copyright string hasn't been modified, etc.
https://github.com/qarl/arcade-js/blob/main/games/timeplt/id...
Fascinating.
I wonder if this will result in discovery of edge cases in the logic that could be exploited to get higher scores (glitches/bugs and such!)
Possibly. Do you have agents? Pull my repo and ask them to see if they can see any bugs in Donkey Kong.
I tried kernel autoreasearch using DeepSeek-V4-Flash as well. It spent about 1-2 hours to complete the FlashAttention optimization job (https://github.com/fengwang/FA5090/tree/main/v7) and cost me only $0.2. I believe we are ready to offload a lot of this kind well-defined constrained optimization problems to AI Agent autoresearch.
> I tried kernel autoreasearch using DeepSeek-V4-Flash as well. It spent about 1-2 hours to complete the FlashAttention optimization job
Doing the same, re-implementing a lot of LLM/diffusion models in Rust+CUDA for my own usage, usually the initial implementation takes 1-2 days (of 100% autonomous work) then I put an agent to optimize the implementation which tends to get close to SOTA performance within another day or two.
As long as you can point the agent at "This is the correct baseline, make sure any optimizations still pass this", seemingly you can leave them and they come back after N hours with a faster program that just works.
If you have access to SOTA implementations, LLMs can often find, understand and copy their best optimisation ideas.
It's very much how I've been using claude code in the past 5 month: brainstorm -> generate specs (constraints) -> generate exact plan -> implementation + review -> test / validate. The last stage is the most crucial one, and it's the most difficult to get it right for a complex solution (it's tough to cover every variation). But so far, it's been working great..
Had a similar experience with my Rust implementation for JSONLogic expression evaluation engine. As it has a full test suite with 1000s of cases and a benchmarking script, I was able to give some basic hints to try different optimization techniques and the end result was impressive. Reached from 1.6s to 200ms for a full benchmarking test. https://github.com/GoPlasmatic/datalogic-rs First 3 versions were hand written and maintained for 3yrs, and now 4th version came out in less than a month's time with impressive performance.
This is exactly how I use it. I mean not on abandoned repos, but in a benchmark - profile - verify - research - improve loop.
What’s the best way to loop it?
6 months ago I would have said the ralph loop plugin.
with opus 5, I'm finding that asking itself to write such a loop skill that does benchmark - profile - verify - research - improve, keep logs for each iteration, etc. (just like autoresearch), and then using the skill, works very nicely.
I'm hoping to release a native Wine for MacOS w/ Win32 FEX support in the next few days.
Watching claude and codex play winquake and age of empires, and debug support for Firefox 52 has been wild.
> Personally, I believe that LLMs should be treated like an advanced version of Prolog or linear programming: you give the constraints, you have a way of verifying correctness, and you give it a clear goal. If the LLM can verify itself and course-correct you can basically leave it on autopilot
This!
People keep measuring how good AI is by one-shotting a problem, but I e found that a back and fourth via the Superpowers SKILL.md is how the model builds these constraints… then when it has all the holes, it gets to work
Is Mojo programming language useful in the age of AI?
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!
It's a straightforward "prompting" + single evolutionary algorithm technique, The paper looks like well, a paper, but the actual thing is simple.
[dead]