Is that with or without the LLM being able to assemble + profile its hypotheses itself? Because “optimize this code to execute in fewer CPU cycles under the test harness” seems like one of those perfect self-contained problems for LLMs (their equivalent of an “embarrassingly parallel problem”: an “embarrassingly-easily-explored solution space with embarrassingly-easily-measured objective success criteria.”)

Sure, they might make all sorts of dumb hypotheses at first, but as long as the results of those stay in their context, they do seem to eventually “run out of ways to be stupid.” (Which is to say, LLMs seem to experience in-context learning even via self-directed trial-and-error, if given a sufficiently-large number of iterations and no way to cheat.)

I was able to use Claude to translate a few thousand lines of assembler from one syntax+toolchain to another. Process was definitely iterative; had to keep adding a few rules along the lines of "don't do this...here's the equivalent pattern." But in the end it did a good job and saved me a ton of time. Allowed me to move a ton of unit tests off a hand rolled broken+bad assembler to a modern production toolchain.

This is definitely not my experience with GLM-5.2. It is writing pretty good ARM SIMD code.

It also is an excellent radare2/rizin/ghidra driver as well. Maybe it's because its ~cyber~ capabilities (pretty much linked with assembly-level knowledge) aren't guardrailed off?