Comment by garganzol

1 month ago

LLM writes a better ASM then a C compiler? From running the demo in the browser, it seems so performance-wise and size-wise, but the ultimate test should be performed on a real hardware that I have no direct access to.

Anyone can validate the performance on a real PC of the era? If it's confirmed, LLMs may be one of the ways of creating highly optimizing compilers in the future.

I was curious about this and had a look. The code doesn't look much better than what a good C compiler might produce, and I found quite a few opportunities to optimize. It doesn't look much at all like the 8088 code I wrote when I was a teen. Among other things, so much pushing and popping.

Take the irow loop in vga12.inc[1] (of course I'm going to look at the graphics code). Each iteration does push di; rep stosb; pop di; add di, ROW_BYTES (and some other stuff). Why not save the push/pop and add (ROW_BYTES - count), which could be stored in a register (dx is free here)? Just the push+pop is 15+12 cycles.

[1]: https://github.com/jggonz/os8088/blob/1f2fae44180fadaf85368c...

  • True, that piece can be optimized better, but quality of the assembly code in general is not far away from what I had been writing in 1993-96. Back then, push/pops in function prologues/epilogues were a sign of experienced assembly programmer who avoided register clobbering by using standard calling conventions.

I've built custom exotic architectures in Verilog with their own bespoke ISAs and weird assembler and found LLMs entirely competent at writing for them, and even building compilers to target it.

It's a weird world we live in now.

  • Yes, just like early optimising compilers eventually got their heuristics.

    Many still haven't understood that dynamic compilers, and machine learning based optimisations are equally not deterministic, which is why benchmarks are hard to implement properly.

    • Hell, the internal complexities of scheduling/branch-prediction etc inside the processor may strictly be defined as "deterministic" but in reality cannot be fully kept in the head of a software engineer at this point, too.

      It's been a long time since I've worked on a machine I could describe as "understandable."

      Aside: One of the niceties of using agentic LLMs to do optimization work is letting them do the drudgery of creating a pile of microbenchmarks for different scenarios (scalar popcount on a this-shaped vector, or SIMD on another? which wins? sometimes the answer is surprising!). I've built all sorts of bespoke tools / harnesses for forcing them to evaluate their findings empirically, and it's amazing what can be done that would take me weeks by hand.