Live data from Hacker News

Claude’s C Compiler vs. GCC

harshanu.space

291–300 of 377 posts

Re: Claude’s C Compiler vs. GCC

#291

I think this is a great example of both points of view in the ongoing debate. Pro-LLM coding agents: look! a working compiler built in a few hours by an agent! this is amazing! Anti-LLM coding agents: it's not a working compiler, though. And it doesn't matter how few hours it took, because it doesn't work. It's useless. Pro: Sure, but we can get the agent to fix that. Anti: Can you, though? We've seen that the more c…

> Pro: but it's only been a few years since we started using LLMs, and a year or so since agents. This is only the beginning!

The billion dollar question is, can we get from 80% to 100%? Is this going to be a situation where that final gap is just insurmountable, or will the capabilities simply keep increasing?

Re: Claude’s C Compiler vs. GCC

#292
post #233
post #173

Earlier quoted context omitted.

Admittedly, his handling of this aspect was perhaps less than ideal, but I cannot see any impoliteness here whatsoever. As a matter of fact, I struggle to think how you could think otherwise. But I am biased. After having lived a number of years in a country where I would say the average understanding of politeness is vastly different from where I've grown up, I've learned that there is just a difference of opinion o…

You sound like you'd characterize a thief as polite if he asked you please when taking your wallet.

Ah, I see what you mean - you're making a distinction between someone's speech and someone's acts. Fair enough. In that sense, you would argue that the action of dropping a 13k loc PR is impolite, and I can see that.

It's just that in my reading, I did not find his demeanor in the comment thread to be impolite. He was trying to sell his contribution and I think that whatever he wrote was using respectful language.

Re: Claude’s C Compiler vs. GCC

#293
post #176
post #51

Earlier quoted context omitted.

Exactly. This flawed argument by which everything will be fixed by future models drives me crazy every time.

So far it has been accurate though. Models have gotten much better than even the most optimistic predictions.

... Eh? A few years back, the usual suspects were predicting AGI by, usually, either 2026 or 2027. Think that's gonna happen?

(Such predictions have been quietly forgotten or revised forward, in general.)

Re: Claude’s C Compiler vs. GCC

#294
post #173

Earlier quoted context omitted.

Admittedly, his handling of this aspect was perhaps less than ideal, but I cannot see any impoliteness here whatsoever. As a matter of fact, I struggle to think how you could think otherwise. But I am biased. After having lived a number of years in a country where I would say the average understanding of politeness is vastly different from where I've grown up, I've learned that there is just a difference of opinion o…

interpreting his words on a literal basis , the PR submitter isn't being directly impolite ... if you will , place yourself in the shoes of the repository maintainer. a random person (with a personal agenda) has popped up trying to sell you a solution (that he doesn't understand) to a problem (that you don't see as problematic). after you spending literal hours patiently explaining why the proposition is not acceptab…

I think there's nothing wrong with trying to sell your solution, and I'm skeptical about the "literal hours" that you claim.

The way I interpret this thread is that the PR poster had a certain itch and came up with a vibe-coded solution that helped him. Now he's trying to make that available for others too. The maintainers don't want it because it's too large a PR to review properly and because they don't want to have to maintain it afterwards.

I can totally see both positions.

I was just referring to the fact that - in my opinion - unlike others here, his writing did not appear impolite to me. But you know, that's just me. I thought that he was trying to sell his code, and it's not unusual to get rejected at first, so I can't blame him for trying to defend his contribution. All I'm saying is that I thought he did so in a respectful manner, but of course you could argue that the whole endeavor was already an act of impoliteness, in a way?!

Re: Claude’s C Compiler vs. GCC

#295
post #208
post #173

Earlier quoted context omitted.

Admittedly, his handling of this aspect was perhaps less than ideal, but I cannot see any impoliteness here whatsoever. As a matter of fact, I struggle to think how you could think otherwise. But I am biased. After having lived a number of years in a country where I would say the average understanding of politeness is vastly different from where I've grown up, I've learned that there is just a difference of opinion o…

> but I cannot see any impoliteness here whatsoever. Ah yes. "It's AI I don't care" and "AI has very deep reasoning about code, prove me wrong" are the height of politeness.

Well, I wouldn't necessarily call it "going out of your way to be accommodating", but impolite is just not the word I'd choose to characterize it. I can see why others might but it's just my personal feeling that I don't think that this is the correct adjective here.

That said, I don't feel like this topic is important enough to go on about it, I probably spend enough keystrokes on it already.

Re: Claude’s C Compiler vs. GCC

#296

> Combined over a billion iterations: 158,000x total slowdown I don't think that's a valid explanation. If something takes 8x as long then if you do it a billion times it still takes 8x as long. Just now instead of 1 vs 8 it's 1 billion vs 8 billion. I'd be curious to know what's actually going on here to cause a multiple order of magnitude degradation compared to the simpler test cases (ie ~10x becomes ~150,000x). R…

That stuck out to me as well.

I wonder if there could be a bug where extra code runs but the result is discarded (and the code that runs happens to have no side effects).

The post also says

> That is roughly 1 billion iterations

but that doesn't sound right because GCC's version runs in only 0.047s, and no CPU can do a billion iterations that quickly.

Re: Claude’s C Compiler vs. GCC

#297
post #93

Earlier quoted context omitted.

I just read that whole thread and I think the author made the mistake of submitting a 13k loc PR, but other than that - while he gets downvoted to hell on every comment - he's actually acting professionally and politely. I wouldn't call this a fiasco, it reads to me more that being able to create huge amounts of code - whether the end result works well or not - breaks the traditional model of open source. Small contr…

simple: search that user. He's a grifter with many failed venues that recently started flooding big project with useless PRs everybody should collectively tell him to fuck off

That may or may not be the case - I really was just going off this one thread, and how I personally read it. I completely appreciate that others read it differently.

Re: Claude’s C Compiler vs. GCC

#298
post #12

Earlier quoted context omitted.

Lexical parsing C is simple, except that typedef's technically make it non-context-free. See https://en.wikipedia.org/wiki/Lexer_hack When handwriting a parser, it's no big deal, but it's often a stumbling block for parser generators or other formal approaches. Though, I recall there's a PEG-based parser for C99/C11 floating around that was supposed to be compliant. But I'm having trouble finding a link, and maybe it…

I think you're referring to this one: https://github.com/jhjourdan/C11parser

What I had specifically in mind definitely wasn't using OCaml or Menhir, but that's a very useful resource, as is the associated paper, "A simple, possibly correct LR parser for C11", https://jhjourdan.mketjh.fr/pdf/jourdan2017simple.pdf

This is closer to what I remember, but I'm not convinced it's what I had in mind, either: https://github.com/edubart/lpegrex/blob/main/parsers/c11.lua It uses LPeg's match-time capture feature (not a pure PEG construct) to dynamically memorize typedef's and condition subsequent matches. In fact, it's effectively identical to what C11Parser is doing, down to the two dynamically invoked helper functions: declare_typedefname/is_typedefname vs set_typedef/is_typedef. C11Parser and the paper are older, so maybe the lpegrex parser is derivative. (And probably what I had in mind, if not lpegrex, was derivative, too.)

Re: Claude’s C Compiler vs. GCC

#299

My 2 cents: just like Cursor's browser, it seems the AI attempted a really ambitious technical design, generally matching the bells and whistles of a true industrial strength compiler, with SSA optimization passes etc. However looking at the assembly, it's clear to me the opt passes do not work, an I suspect it contains large amounts of 'dead code' - where the AI decided to bypass non-functioning modules. If a human…

> My 2 cents: just like Cursor's browser, it seems the AI attempted a really ambitious technical design, generally matching the bells and whistles of a true industrial strength compiler, with SSA optimization passes etc.

Per the article from the person who directed this, the user directed the AI to use SSA form.

> However looking at the assembly, it's clear to me the opt passes do not work, an I suspect it contains large amounts of 'dead code' - where the AI decided to bypass non-functioning modules.

That is quite possibly true, but presumably at least in part reflects the fact that it has been measured on completeness, not performance, and so that is where the compiler has spent time. That doesn't mean it'd necessarily be successful at adding optimisation passes, but we don't really know. I've done some experiments with this (a Ruby ahead-of-time compiler) and while Claude can do reasonably well with assembler now, it's by no means where it's strongest (it is, however, far better at operating gdb than I am...), but it can certainly do some of it.

> So while I don't want to make predictions, but it seems for now, the human-in-the-loop method of coding works much better (and cheaper!) than getting AI to generate a million lines of code on its own.

Yes, it absolutely is, but the point in both cases was to test the limits of what AI can do on their own, and you won't learn anything about that if you let a human intervene.

$20k in tokens to get to a surprisingly working compiler from agents working on their own is at a point where it is hard to assess how much money and time you'd save once considering the cleanup job you'd probably want to do on it before "taking delivery", but had you offered me $20k to write a working C-compiler with multiple backends that needed to be capable of compiling Linux, I'd have laughed at the funny joke.

But more importantly, even if you were prepared to pay me enough, delivering it as fast if writing it by hand would be a different matter. Now, if you factor in the time used to set up the harness, the calculation might be different.

But now that we know models can do this, efforts to make the harnesses easier to set up (for my personal projects, I'm experimenting with agents to automatically figure out suitable harnesses), and to make cleanup passes to review, simplify, and document, could well end up making projects like this far more viable very quickly (at the cost of more tokens, certainly, but even if you double that budget, this would be a bargain for many tasks).

I don't think we're anywhere near taking humans out of the loop for many things, but I do see us gradually moving up the abstraction levels, and caring less about the code at least at early stages and more about the harnesses, including acceptance tests and other quality gates.

Re: Claude’s C Compiler vs. GCC

#300
post #282
post #207

Earlier quoted context omitted.

It’s in Rust…

It's an LLM, surely it could read gcc source code and translate it to Rust if it really tried hard enough

It wasn't given gcc source code, and was not given internet access. It the extent it could translate gcc source code, it'd need to be able to recall all of the gcc source from its weights.
Post reply on HN