Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I hate compilers

xeiaso.net

Post reply on HN
Print view View original

11–20 of 182 posts

Re: I hate compilers

#11

Post by pjmlp »

klodolph wrote: post #5
dyauspitr wrote: post #3

LLMs should be trained on and directly output binary.

On the off chance that you’re serious, that would result in disastrously bad output. The difference between “jmp $+15” and “jmp $+16” is inscrutable and the LLM would not be able to pick the right one without tooling. That tooling is a compiler. The higher level, the better chance the LLM can be steered to good output. Machine code is hopeless, don’t bother.

That compiler does wonders with languages that have UB on their specs, especially when having optimizations passes with heuristics.

Also there are dynamic compilers were the shape of machine code changes as the code executes, and each single execution will certainly generate different sequences, depending on the program execution and where it is running.

Deterministic JIT compiler code generation, at least on optimising ones, is not a solved problem.

Re: I hate compilers

#12

Post by dyauspitr »

xiaoyu2006 wrote: post #8
dyauspitr wrote: post #3

LLMs should be trained on and directly output binary.

It should not. Abstraction in software engineering brings intelligence. (compression correlates to intelligence)

Why? I mean this is all emergent, right? And it’s not like humans ever work at this level. It would be very interesting to see what sort of outputs and abstractions an LLM comes up with.

Re: I hate compilers

#13

Post by ComputerGuru »

These seem very reasonable, the workarounds used are natural, and overall the article is not at all congruous with the conclusion in the (clickbait?) title?

Compilers literally made your project possible!

Re: I hate compilers

#16

Post by jdw64 »

Reading this, I think low level engineering is actually more dependent on specific environments. Hardware also has its own points of change. Usually, when you think at a high level, environmental changes are less significant than you might expect. But low level thinking tends to be tied to specific environments, which is what makes it difficult. The reason low level is hard is that even if the code itself is short, the hidden assumptions inside it are difficult and place a heavy cognitive load on the programmer. For example, even a short snippet in C like `int value = (int)buffer` requires a lot of implicit knowledge about the 4 byte alignment of the buffer, or whether int is exactly 32 bits. LLMs do not seem to be very good at knowing these things. Rather, they are strong at high level wrapping, but at the low level, they seem surprisingly difficult and somewhat useless. Hardware has CPU generation changes, and in the case of PLCs, where I mainly work, the protocol differences between vendors are far too severe. There does not seem to be any technology with a very long lifecycle.

Re: I hate compilers

#17

Post by heavensteeth »

xena wrote: post #6
mathisfun123 wrote: post #4

[flagged]

Tell me the flags I'm missing then: https://github.com/TecharoHQ/anubis/blob/Xe/wasm4/utils/wasm...

I'm surprised by the amount of heckling this post received almost immediately! And a lack of constructive input.

I for one enjoyed the article and understand what you're getting at.

Re: I hate compilers

#18

Post by pertymcpert »

If Clang generated non-deterministic output due to pointer addresses then that's a bug (happens regularly) that should be fixed. The most common way this happens if it some code path is iterating over a DenseMap which is non-deterministic. Sometimes that's fine and sometimes that's not depending on how that map is used. The common way to fix that is to switch to a MapVector which pays some additional runtime/memory cost to guarantee deterministic iteration order.

Re: I hate compilers

#20

Post by klodolph »

jenadine wrote: post #10
klodolph wrote: post #5

Earlier quoted context omitted.

On the off chance that you’re serious, that would result in disastrously bad output. The difference between “jmp $+15” and “jmp $+16” is inscrutable and the LLM would not be able to pick the right one without tooling. That tooling is a compiler. The higher level, the better chance the LLM can be steered to good output. Machine code is hopeless, don’t bother.

> The difference between “jmp $+15” and “jmp $+16” is inscrutable I don't see why that's the case. LLM trained on binary would totally see it, not? Also the tool can also be running the test and a debugger.

> I don't see why that's the case. LLM trained on binary would totally see it, not?

It would not. You find the correct version by counting the number of bytes to the destination. LLMs are famously bad at this kind of problem (counting).

> Also the tool can also be running the test and a debugger.

The test needs to provide a good amount of signal. That’s too hard if you are throwing machine code at the wall.

In order for debuggers to work, you need some kind of model that describes what the code should do and what state the computer should be in after each instruction. That model is high-level code.

I can understand the intuitive appeal of training LLMs with machine code, but all of my experience with LLMs suggest that they are incredibly ill-suited to the task, and we just don’t have the capacity to train them to make useful machine code.

Post reply on HN