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

Claude’s C Compiler vs. GCC

harshanu.space

Post reply on HN
Print view View original

161–170 of 377 posts

Re: Claude’s C Compiler vs. GCC

#161

Post by AstroBen »

simianwords wrote: post #139
AstroBen wrote: post #108

Earlier quoted context omitted.

You're right. It's been pretty incredible. It's also frustrating as hell though when people extrapolate from this progress Just because we're here doesn't mean we're getting to AGI or software developers begging for jobs at Starbucks

Sure then make your prediction? It’s always easy to hand wave and dismiss other people’s predictions. But make yours: what do you think llms can do in 2 years?

You're asking me to do the thing I just said was frustrating haha. I have no idea. It's a new technology and we have nothing to draw from to make predictions. But for the sake of fun..

New code generation / modification I think we're hitting a point of diminishing returns and they're not going to improve much here

The limitation is fundamentally that they can only be as good as the detail in the specs given, or the test harnesses provided to them. Any detail left out they're going to make up, and hopefully it's what you want (often it's not!). If you make the specs detailed enough so that there's no misunderstanding possible: you've just written code, what we already do today

Code optimization I think they'll get quite a bit better. If you give them GCC it's probable they'll be able to improve upon it

Re: Claude’s C Compiler vs. GCC

#162

Post by simianwords »

mdavid626 wrote: post #159
simianwords wrote: post #158

Earlier quoted context omitted.

How do I know that? The code is not similar to GCC at any level except conceptual. If you can point out the similarity at any level I might agree with you.

I have a feeling, you didn't look at the code at all.

I would love to see and be proved wrong that the code is not similar to gcc. Please point it out

Re: Claude’s C Compiler vs. GCC

#163

Post by Rygian »

Rapzid wrote: post #96
marcus_holmes wrote: post #8

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…

Two completely valid perspectives. Unless you need a correctly compiled Linux kernel. In that case one gets exhausting real quick.

The perspective that says "a whole compiler in just a few hours" is making false claims. So not a valid perspective.

Re: Claude’s C Compiler vs. GCC

#164

Post by simianwords »

AstroBen wrote: post #161
simianwords wrote: post #139

Earlier quoted context omitted.

Sure then make your prediction? It’s always easy to hand wave and dismiss other people’s predictions. But make yours: what do you think llms can do in 2 years?

You're asking me to do the thing I just said was frustrating haha. I have no idea. It's a new technology and we have nothing to draw from to make predictions. But for the sake of fun.. New code generation / modification I think we're hitting a point of diminishing returns and they're not going to improve much here The limitation is fundamentally that they can only be as good as the detail in the specs given, or the t…

Hmm. It’s not clear what specific task it can’t handle. Can you come up with a concrete example?

Re: Claude’s C Compiler vs. GCC

#165

Post by nvrmnd »

fourthark wrote: post #147
nvrmnd wrote: post #19

Earlier quoted context omitted.

> It's not fair to compare them like this! As someone who leans pro in this debate, I don't think I would make that statement. I would say the results are exactly as we expect. Also, a highly verifiable task like this is well suited to LLMs, and I expect within the next ~2 years AI tools will produce a better compiler than gcc.

But only if there is a competent compiler engineer running the AI, reviewing specs, and providing decent design goals. Yes it will be far easier than if they did it without AI, but should we really call it “produced by AI” at that point?

Yes, we will certainly go that way, probably code already added to gcc has been developed through collaborative AI tools. Agree we don't call that "produced by AI".

I think compilers though are a rare case where large scale automated verification is possible. My guess is that starting from gcc, and all existing documentation on compilers, etc. and putting ridiculous amounts of compute into this problem will yield a compiler that significantly improves benchmarks.

Re: Claude’s C Compiler vs. GCC

#166

Post by bjackman »

DSMan195276 wrote: post #37

Something that bothers me here is that Anthropic claimed in their blog post that the Linux kernel could boot on x86 - is this not actually true then? They just made that part up? It seemed pretty unambiguous to me from the blog post that they were saying the kernel could boot on all three arch's, but clearly that's not true unless they did some serious hand-waving with kernel config options. Looking closer in the rep…

My guess is that CCC works if you disable static keys/DKMS/etc.

In the specific case of __jump_table I would even guess there was some work in getting the Clang build working.

Re: Claude’s C Compiler vs. GCC

#167

Post by simgt »

Alupis wrote: post #39
marcus_holmes wrote: post #8

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…

I'm reminded, once again, of the recent "vibe coded" OCaml fiasco[1]. The PR author had zero understanding why their entirely LLM-generated contribution was viewed so suspiciously. The article validates a significant point: it is one thing to have passing tests and be able to produce output that resembles correctness - however it's something entirely different for that output to be good and maintainable . [1] https:/…

I'm humbled by the maintainer's answer [0]. Must be great to work with people like him who have infinite patience and composure.

[0] https://github.com/ocaml/ocaml/pull/14369#issuecomment-35565...

Re: Claude’s C Compiler vs. GCC

#168

Post by AstroBen »

simianwords wrote: post #164
AstroBen wrote: post #161

Earlier quoted context omitted.

You're asking me to do the thing I just said was frustrating haha. I have no idea. It's a new technology and we have nothing to draw from to make predictions. But for the sake of fun.. New code generation / modification I think we're hitting a point of diminishing returns and they're not going to improve much here The limitation is fundamentally that they can only be as good as the detail in the specs given, or the t…

Hmm. It’s not clear what specific task it can’t handle. Can you come up with a concrete example?

Are you saying you've never had them fail at a task?

I wanted to refactor a bunch of tests in a TypeScript project the other day into a format similar to table driven tests that are common in Golang, but seemingly not so much in TypeScript. Vitest has specific syntax affordances for it, though

It utterly failed at the task. Tried many times with increasing specificity in my prompt, did one myself and used it as an example. I ended up giving up and just doing it manually

Re: Claude’s C Compiler vs. GCC

#169

Post by nopurpose »

kuerbel wrote: post #54
ares623 wrote: post #14

Earlier quoted context omitted.

Pretty much. It's missing a tiny detail though. One side is demanding we keep giving hundreds of billions to them and at the same time promising the other side's unemployment.

And no-one ever stops and thinks about what it means to give up so much control. Maybe one of those companies will come out on top. The others produce garbage in comparison. Capital loves a single throat to choke and doesn't gently pluralise. So of course you buy the best service. And it really can generate any code, get it working, bug free. People unlearn coding on this level. And some day, poof, Microsoft is comin…

You could make same argument in "information superhighway" days, but it turned out to be the opposite: no company monopolised internet services, despite trying hard.

With so many companies in AI race it is already pretty competitive landscape and it doesnt seem likely to me that any of them can build deep enough moat to come ahead.

Re: Claude’s C Compiler vs. GCC

#170

Post by _zagj »

marcus_holmes wrote: post #8

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…

The "Anti" stance is only tenable now if you believe LLMs are going to hit a major roadblock in the next few months around which Big AI won't be able to navigate. Something akin to the various "ghosts in the machine" that started bedeviling EEs after 2000 when transistors got sufficiently small, including gate leakage and sub-threshold current, such that Dennard Scaling came to an abrupt end and clock speeds stalled.

I personally hope that that happens, but I doubt it will. Note also that processors still continued to improve even without Dennard Scaling due to denser, better optimized onboard caches, better branch prediction, and more parallelism (including at the instruction level), and the broader trend towards SoCs and away from PCB-based systems, among other things. So at least by analogy, it's not impossible that even with that conjectured roadblock, Big AI could still find room for improvement, just at a much slower rate.

But current LLMs are thoroughly compelling, and even just continued incremental improvements will prove massively disruptive to society.

Post reply on HN