Nobody Reviews Compiler Output
skiplabs.io
Nobody Reviews Compiler Output
1–10 of 36 posts
Re: Nobody Reviews Compiler Output
#2"""
we need to build:
Formal specification layers that agents execute against, not just promptsIt is probably easier to just write that program.
Re: Nobody Reviews Compiler Output
#3ah yes.
Lets indeed treat non-deterministic output exactly like we treat deterministic output.
Re: Nobody Reviews Compiler Output
#4this take is peak dunning-kruger:
https://github.com/llvm/llvm-project/tree/main/llvm/test/Cod...
Re: Nobody Reviews Compiler Output
#5""" we need to build: Formal specification layers that agents execute against, not just prompts """ It is probably easier to just write that program.
Right, because to trust that those "formal specifications" are correct, you will have to write them by hand.
Re: Nobody Reviews Compiler Output
#6""" we need to build: Formal specification layers that agents execute against, not just prompts """ It is probably easier to just write that program.
Talked with someone this morning who is using "formal methods" to validate their AI generated code.
They are using the same AI to generate the proofs.
Re: Nobody Reviews Compiler Output
#7""" we need to build: Formal specification layers that agents execute against, not just prompts """ It is probably easier to just write that program.
Talked with someone this morning who is using "formal methods" to validate their AI generated code. They are using the same AI to generate the proofs.
That's why you should just subscribe to multiple LLM vendors. One model to write specs, one to write code against the specs and another to validate the code. Problem solved. (I have heard this proposed at work.)
Re: Nobody Reviews Compiler Output
#8Just like LLMs, compilers are just another layer of abstraction and no they're not deterministic.
Just yesterday I've reported a codegen bug in MSVC. (Luckily they've fixed it very fast.) Can you realise that it's an optimiser bug without inspecting the assembly? Hardly.
All the arguments people claim against LLMs are similarly applicable to compilers, but compilers are old technology and LLMs are new.
If you're an expert, just about every compiled function contains obvious inefficiencies, and a skilled assembly programmer can speed it up by in the ballpark of 3x. If we're talking about your average webapp, you can usually get 1000x better resource usage in most ways, including CPU, RAM, storage and so on.
And the output isn't deterministic either - the bugs no withstanding, code generation is highly chaotic, optimisations have non-local impacts and you can't easily predict optimised codegen output from source.
LLMs aren't much worse. They have non-deterministic output, but you can steer it - similarly to a compiler. An expert can use it to gain great speed and efficiency, but in the hands of someone not as capable, you can make something awful just as fast. Both tools are force multipliers.
Re: Nobody Reviews Compiler Output
#9ah yes. Lets indeed treat non-deterministic output exactly like we treat deterministic output.
We could make it deterministic
Re: Nobody Reviews Compiler Output
#10> Compilers have type systems, formal contracts about what code means before it runs.
This is a complete misunderstanding of what makes compilers trustworthy. Those are all properties of the language, not the compiler. The compiler is trustworthy to the extent that it is well built, internally. It is trustworthy to the extent that the mapping from source code to machine code is well defined, and implemented correctly.
You can have the best type system you want, but if the compiler is badly implemented, it won't be trustworthy. A perfect example is C - a language that barely has a type system, yet has some of the most trustworthy and optimized compilers. And it also has, or at least had, plenty of buggy compilers, typically for small embedded platforms with complicated mappings between C constructs and the limited CPU instruction set.