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…
Claude’s C Compiler vs. GCC
211–220 of 377 posts
Re: Claude’s C Compiler vs. GCC
#212I 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…
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
#213Earlier 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…
Re: Claude’s C Compiler vs. GCC
#214Earlier 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.
Re: Claude’s C Compiler vs. GCC
#215Earlier 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.
Re: Claude’s C Compiler vs. GCC
#216Earlier 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.
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
#217Earlier 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…
Re: Claude’s C Compiler vs. GCC
#218Re: Claude’s C Compiler vs. GCC
#219Can 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?
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
#220I 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.