Live data from Hacker News

Claude’s C Compiler vs. GCC

harshanu.space

211–220 of 377 posts

Re: Claude’s C Compiler vs. GCC

#211

It's really cool to see how slow unoptimised C is. You get so used to seeing C easily beat any other language in performance that you assume it's really just intrinsic to the language. The benchmark shows a SQLite3 unoptimised build 12x slower for CCC, 20x for optimised build. That's enormous! I'm not dissing CCC here, rather I'm impressed with how much speed is squeezed out by GCC out of what is assumed to be alread…

The speed of C is still largely intrinsic to the language. The primatives are directly related to the actual silicon. A function call is actually going to turn into a call instruction (or get inlined). The order of bytes in your struct are how they exist in memory, etc. A pointer being dereferenced is a load/store. The converse holds as well. Interpreted languages are slow because this association with the hardware i…

Right - maybe we're saying the same thing. C is naturally amenable to being blazing fast, but if you compile it without trying to be efficient (not trying to be inefficient, just do the simplest, naive thing) it's still slow - by 1-1.5 order of magnitude.

Re: Claude’s C Compiler vs. GCC

#212

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 mean - who would honestly expect an LLM to be able to compete with a compiler with 40 years of development behind it? Even more if you count the collective man years expended in that time. The Claude agents took two weeks to produce a substandard compiler, under the fairly tight direction of a human who understood the problem space.

At the same time - you could direct Claude to review the register spilling code and the linker code of both LLVM/gcc for potential improvements to CCC and you will see improvements. You can ask it not to copy GPL code verbatim but to paraphrase and tell it it can rip code from LLVM as long as the licenses are preserved. It will do it.

You might only see marginal improvements without spending another $100K on API calls. This is about one of the hardest projects you could ask it to bite off and chew on. And would you trust the compiler output yet over GCC or LLVM?

Of course not.

But I wager, that if you _started_ with the LLVM/gcc codebases and asked it to look for improvements - it might be surprising to see what it finds.

Both sides have good arguments. But this could be a totally different ball game in 2, 5 and 10 years. I do feel like those who are most terrified by it are those whose identity is very much tied to being a programmer, and seeing the potential for their role to be replaced and I can understand that.

Me personally - I'm relieved I finally have someone else to blame and shout at rather than myself for the bugs in the software I produce. I'm relieved that I can focus now on the more creative direction and design of my personal projects (and even some work projects on the non-critical paths) and not get bogged down in my own perfectionism with respect to every little component until reaching exhaustion and giving up.

And I'm fascinated by the creativity of some of the projects I see that are taking the same mindset and approach.

I was depressed by it at first. But as I've experimented more and more, I've come to enjoy seeing things that I couldn't ever have achieved even with 100 man years of my own come to fruition.

Re: Claude’s C Compiler vs. GCC

#213
post #80

Earlier quoted context omitted.

As an Anti, my argument is "if AI will good in future, then come back in the future"

As a pro, my argument is "it's good enough now to make me incredibly productive, and it's only going to keep getting better because of advancements in compute". I'd rather get really good at leveraging AI now than to bury my head in the sand hoping this will go away. I happen to agree with the saying that AI isn't going to replace people, but people using AI will replace people who don't. So by the time you come back…

Why would anything you learn today be relevant tomorrow if AI keeps advancing? You would need less and less of all your tooling, markdown files and other rituals and just let the AI figure it out altogether.

Re: Claude’s C Compiler vs. GCC

#214

Earlier quoted context omitted.

> People aren't prompting LLMs to write good, maintainable code though. Then they're not using the tools correctly. LLMs are capable of producing good clean code, but they need to be carefully instructed as to how. I recently used Gemini to build my first Android app, and I have zero experience with Kotlin or most of the libraries (but I have done many years of enterprise Java in my career). When I started I first ha…

Not trying to be rude, but in a technology you're not familiar with you might not be able to know what good code is, and even less so if it's maintainable. Finding and fixing that subtle, hard to reproduce bug that could kill your business after 3 years.

The framing is key here. Is three years a long time? Both answers are right. Just getting a business off the ground is an achievement in the first place. Lasting three years? These days, I have clothes that don't even last that long. And then three years isn't very long at all. Bridges last decades. Countries are counted by centuries. Humanity is a millennia old. If AI can make me a company that's solvent for three years? Well, you decide.

Re: Claude’s C Compiler vs. GCC

#215
post #206

Earlier quoted context omitted.

When I started I first had a long discussion with the AI... and made a big Markdown file with a detailed architecture description. Yep, that's how you get better output from AI. A lot of devs haven't learned that yet. They still see it as 'better autocomplete'.

"It's just another Markdown file, bro". LLMs do not learn. So every new session for them will be rebuilding the world from scratch. Bloated Markdown files quickly exhaust context windows, and agents routinely ignore large parts of them. And then you unleash them on one code base that's more than a couple of days old, and they happily duplicate code, ignore existing code paths, ignore existing conventions etc.

That's why I'm very careful about how the context is constructed. I make sure all the relevant files are loaded with the prompt, including the project file so it can see the directory structure. Also keep a brief summary of the app functionality and architecture in the AGENTS.md file. For larger tasks, always request a plan and look through it before asking it to start writing code.

Re: Claude’s C Compiler vs. GCC

#216

Earlier quoted context omitted.

> People aren't prompting LLMs to write good, maintainable code though. Then they're not using the tools correctly. LLMs are capable of producing good clean code, but they need to be carefully instructed as to how. I recently used Gemini to build my first Android app, and I have zero experience with Kotlin or most of the libraries (but I have done many years of enterprise Java in my career). When I started I first ha…

Not trying to be rude, but in a technology you're not familiar with you might not be able to know what good code is, and even less so if it's maintainable. Finding and fixing that subtle, hard to reproduce bug that could kill your business after 3 years.

I think we are going to have to find out what maintenance even looks like when LLMs are involved. "Maintainable" might no longer mean quite the same thing as it used to.

But it's not going to be as easy as "just regenerate everything". There are dependencies external to a particular codebase such as long lived data and external APIs.

I also suspect that the stability of the codebase will still matter, maybe even more so than before. But the way in which we define maintainability will certainly change.

Re: Claude’s C Compiler vs. GCC

#217
post #30

Earlier quoted context omitted.

This to me sounds a lot like the SpaceX conversation: - Ohh look it can [write small function / do a small rocket hop] but it can't [ write a compiler / get to orbit]! - Ohh look it can [write a toy compiler / get to orbit] but it can't [compile linux / be reusable] - Ohh look it can [compile linux / get reusable orbital rocket] but it can't [build a compiler that rivals GCC / turn the rockets around fast enough] - T…

> This to me sounds a lot like the SpaceX conversation The problem is that it is absolutely indiscernible from the Theranos conversation as well… If Anthropic stopped making lies about the current capability of their models (like “it compiles the Linux kernel” here, but it's far from the first time they do that), maybe neutral people would give them the benefit of the doubt. For one grifter that happen to succeed at…

[deleted]

Re: Claude’s C Compiler vs. GCC

#218
I curious, maybe AI learn too much code from human writed compilers. What if invent a fresh new language, and let AI write the compiler, if the compiler works well I think that is the true intelligent.

Re: Claude’s C Compiler vs. GCC

#219

Can someone explain to me, what’s the big deal about this? The AI model was trained on lots of code and spit out sonething similar than gcc. Why is this revolutionary?

If someone told you 5 years ago that a computer generated a working C compiler, would you think it was a big deal or not?

A computer generating a compiler is nothing new. Unzip has done this many many times. The key difference is that unzip extracts data from an archive in a deterministic way, while LLMs recover data from the training dataset using a lossy statistical model. Aid that with a feedback loop and a rich test suite, and you get exactly what Anthropic has achieved.

While I agree that the technology behind this is impressive, the biggest issue is license infringement. Everyone knows there's GPL code in the training data, yet there's no trace of acknowledgment of the original authors.

Re: Claude’s C Compiler vs. GCC

#220
> 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). Rather than I-cache misses I wonder if register spilling in the nested loop managed to completely overwhelm L3 causing it to stall on every iteration waiting for RAM. But even that theory seems like it could only account for approximately 1 order of magnitude, leaving an additional 3 (!!!) orders of magnitude unaccounted for.

I think there's a lot more to the story here.

Post reply on HN