froydnj

It's hard to say without reference to specifics; certainly the MD files have been around since time-immemorial, even if they've been augmented with new features over the years. And the gimple bits were primarily aimed at making the in-memory representation more efficient, a goal which they accomplished.

In any event, as you say, things have been revamped, so whatever issues there were with the old internals no longer apply, right? So there's no point in dragging out old chestnuts like "GCC can't support modern architectures or modern optimization techniques", because that's not true anymore, right?

(I apologize if this comes across as harsh; I'm just tired of seeing LLVM articles where commenters appear to be drinking the LLVM Kool-Aid without having any idea what the LLVM folks are grousing about. Sometimes the LLVM folks have a point, sometimes they're just asserting their engineering decisions are superior, which is debatable, and sometimes they're just grousing because they don't seem to like GCC. It's hard to say exactly what's in view from commenters and from the LLVM folks themselves.

GCC currently supports 8-bit microcontrollers, 32/64-bit desktop chips, a few "nonstandard" VLIW and DSP architectures, and lots of other chips in between. I, for one, am impressed with how much Clang and LLVM have done, but I'll also be more impressed if, in a decade and a half, LLVM's architecture hasn't acquired some warts and it seriously supports more than two architectures. After all, GCC was, in many ways, state-of-the-art when it first came out too...)

> That's one problem gcc has, that its architecture description is aged and doesn't have a good way of specifying some things that are very important for 2010s performance, so has had to undergo some major surgery (still in progress). LLVM currently avoids that partly by being newer.

LLVM also currently avoids that by not generating code that's as good for those 2010 architectures.

I would also be interested in hearing you expound upon those things that are "very important for 2010s performance".

> I enjoyed this article, I always find the argument that "these days you can't beat the compiler" fishy.

I enjoyed your example; very clever. I think the "these days you can't beat the compiler" should really be understood to carry a qualifier like "for compiling things that we understand well enough and that occur often enough that it's worth teaching the compiler how to optimize them". Knuth's maxim "Science is what we understand well enough to explain to a computer. Art is everything else we do." seems particularly apt here.

Problems where humans can apply very domain-specific knowledge to come up with clever solutions are not the sort of problems that a general-purpose compiler is going to generate good code for. Knowing when you're dealing with one of those problems (e.g. writing inner loops for multi-precision arithmetic or vectorizing multimedia codecs) is part of being a good programmer. But to a first or even second approximation, you are not dealing with one of those problems, so you might as well just sit back and let the compiler do its job.

This is a great point; see also http://news.ycombinator.com/item?id=2589331 The big thing about that article is that the tracking capabilities come from things people actually want in their devices, not from nefarious schemes to follow people around. And most people aren't going to inquire about the larger purposes to which these technologies can be put.

The context of the copy-on-write win was the bytecode for modules. I don't know that you'd have anybody meddling with the reference counts for that...but I haven't really looked.

Sounds very similar to some of the themes William Gibson's recent novels have been riffing on (particularly _Zero History_).

Some linkers do what you describe. Not all.

FWIW, none other than Guy Steele has cited Java as dragging C++ programmers halfway to Lisp: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

Wow, Computation Structures looks like an excellent book; thanks for the reference.

I think having Lisp in Small Pieces and SICP is reasonable. Lisp in Small Pieces dives pretty deep, but doesn't cover anything comparable to what chapters 3 and 4 of SICP do.

Counterpoint: Elements of Programming is an exercise in overengineering written by architecture astronauts. I was not impressed by it.

After two years and a rant that happened to get posted to a major tech news site. Doesn't really sound like "paying attention to customers" to me. How many times has this happened in the past two years and why haven't things gotten any better?

It's worth noting that proposals, like JSR 83 (http://jcp.org/en/jsr/detail?id=83), to address Java's multi-dimensional array shortcomings have been around for quite some time. Of course, JSR 83 just sat around for five years before being abandoned; maybe Java folks don't think efficient multi-dimensional arrays are useful and/or common.

Surprisingly enough, this was not among the reasons cited in RMS's original "Why you should not use Tcl" post: http://www.vanderburg.org/OldPages/Tcl/war/0000.html

I think you're illustrating the point of the author: such an option should be the default. The user shouldn't have to go looking for it.

Yes, that's the same thing. It's always fun to realize that $HOT_FEATURE in $LANGUAGE is several decades old, instead of several years.

The long-term goal of the Go frontend is to be usable with both GCC and LLVM. GCC has excellent medium to long term prospects, too, you know.

There was a SoC project for a Python front-end to GCC this past summer. I don't know how far it got.

You are correct (you do have to check that the symbol is actually bound prior to dereferencing). But they don't (generally) work that way for symbols with a function binding. I think the rationale here is that it's much more common to have BOUNDP symbols than FBOUNDP symbols. So sticking an extra slot for the value in a symbol is worth it, space-wise, whereas an extra slot for the function is not, so function lookups go through some sort of global table.

Note too that Common Lisp forbids you from modifying the function binding of symbols in the COMMON-LISP package for precisely this reason: the compiler can do a better job reasoning about the effects of calls to those functions.

Alpha is most definitely not a bi-endian architecture; it's little-endian only. PowerPC chips can be either, but the vast, vast majority are big endian.

Seriously! Reading the article made me think, "wow, trying to piece together where companies go and who owns what sounds like fun!" (No, I'm not a lawyer.) Certainly sounds like an optimization problem where a computer could do an especially good job (assuming that you can represent everything efficiently).

Just because Apple has a copyright assignment on file (i.e. saying that they are able to assign copyright to the FSF) does not mean that every piece of code Apple writes--even if it's connected to GCC--is assigned to the FSF.

So Apple can write GCC patches, Apple can release GCC patches, but it does not follow that those patches are assigned. I guess that means they've actively stopped.

Networking equipment is another place where 64-bit systems are useful. See chip offerings from places like NetLogic and Cavium, for instance: their multicore MIPS chips are 64-bit.

Databases are another place where 64-bit systems shine. Maybe you already assumed that was included under "HPC-type applications", though. When I hear HPC, I think number-crunching, not databases, though.

I don't have a good sense of pain points in LLVM; the inliner hacking was a while ago, I don't remember many of the details, and LLVM has surely changed quite a bit since then.

As for GCC, I think the pain points are twofold: the documentation for the middle-end is somewhat scattered. I honestly think enough information for figuring things out is present, it's just not always obvious where to look. There are lots of other passes to look at too, which can be extremely helpful. Assumptions of the interface, or side-effects, are not always stated, which can be surprising at times. The other pain point is contributing upstream: you're going to get dinged on formatting, documentation (usually just "did you do it"; the review is generally not as thorough as say, GDB's documentation review), compilation time, etc. etc.

Also, GCC's hash tables (htab_t) are a pain to use correctly.

Of course, my experience is somewhat slanted towards the middle-end; the set of pain points is somewhat different if you are working in the front-end or the back-end. And my set of pain points from the middle-end might be different if I had worked on different optimization passes. (My passes cared very little about things like aliasing, for instance.)

It's surprising to me that you mention memory management as a pain point, though I can see how the variety can be bewildering. The only distinction that really matters is between GC'd and non-GC'd memory. obstacks and alloc pools are only ways of providing specialized malloc interfaces. A useful rule of thumb is that if your data is only needed for one pass of the compiler, then you can allocate it any way you like; if the data is longer-lived than that, it needs to go in GC'd memory. I can elaborate if you'd like, but that's the basic idea.

FWIW, I agree that the whole GC system is somewhat baroque. The GC was a decent solution to an engineering problem and the whole mechanism nicely solved memory management problems and provided the basis for precompiled headers, but it causes problems in other ways nowadays and trying to get rid of it would be a huge effort.

I don't know the full story about Apple and GCC; I haven't read all of the mailing list traffic during the relevant period, nor was I around to hear about offline conversations. Certainly I can see Apple modifying bits of GCC to make it more suitable for IDE integration and upstream not caring about that. Apple did have ways of getting such changes in, though; it's possible they didn't care enough to push them upstream.

As for "elitist arrogance", I think what you are getting at is that you see the FSF's policies as erecting a moat and a wall around GCC and telling the rabble to stay out while the nobility quietly hack away at their desks. If I have understood you correctly, then I see the argument, but I do not agree with it. As long as GCC is an FSF project, that's just the way things are going to be. I don't think the FSF has set out with the intent to be "elitist"; it's unfortunate if that's the way the policy is perceived. Feel free to correct me; it's possible that I've misunderstood you.

The FSF does not, on the whole, dictate the technical direction of the project. So the goodness or badness of technical changes and any "elitism" associated with acceptance or rejection of such changes is another issue.

Perhaps things will change if GCC ever disassociated itself from the FSF: another egcs-style fork or something more dramatic. There have been small rumblings of such a change, but I think such an event is quite unlikely.

I wasn't thinking about the ObjC frontend; the ObjC frontend, AIUI, was contributed by NeXT before NeXT became a part of Apple.

If you go grab the GCC tarball Apple provides, it has many, many changes from the GCC 4.2 sourcebase. Lots of those changes have not been submitted back upstream. The code is available, granted, but it's not available in a way that's helpful to anybody but Apple.

I think the dislike of LLVM stems mostly from the company behind it. As you may know, Apple contributed a fair amount of code to GCC, but they also kept a lot of code for themselves. (They did, of course, make it available per GPL, but did not try to submit it upstream.) There have also been problems in the way Apple contributed code; see the mailing list archives for details.

I think there's also some dislike of the project itself, or perhaps the people behind it. But that's another discussion.

> The problem are always an excessive centralisation of stewardship... which is kind of ironic coming from the guy who most strongly supported free software.

I don't think it's so much centralization of stewardship for technical decisions, but stewardship of the rights to the code; i.e. you need to sign copyright papers before committing non-trivial patches. And I can assure you that the FSF sees doing so as strongly supporting the cause of free software. There are obvious counterexamples (the Linux kernel's more lax Signed-off-by policy comes to mind), but there are reasons why this centralization is done.

I know this centralization causes problems. Getting assignment papers submitted if you are at a university is a pain; your employer may not be keen on signing them either. It'd be nice to see the process streamlined, or even banished entirely, but I doubt that's going to happen.

> I think it's got only itself to blame, and a certain type of elitist arrogance.

I'm curious where you think this "elitist arrogance" comes from or even what sort of behaviors you're referring to. Can you elaborate?

Disclaimer up-front: my day job is hacking on GCC and related GNU pieces of infrastructure, so that colors my opinions somewhat. I speak only for myself, not for my employer.

My level of experience in both: I hacked a specialized LLVM inlining pass in graduate school. I've written two middle-end passes for GCC and tweaked GCC's inliner in similar, though less invasive, ways. I found the level of difficulty to be similar between the two projects.

Other people may have different opinions. I remember reading a claim of a graduate school project that tried for four months to get started on a middle-end optimization pass in GCC and got nowhere; after switching to LLVM, they made progress in a month or so. Personally, I think that meant they weren't trying very hard with GCC.

> I can't imagine how C++ standardization efforts could possibly correlate in any way with industry adoption. The two things are completely orthogonal.

I don't think they're orthogonal: standardization efforts don't happen until you have significant industry adoption of technology X from several vendors and they (and/or their customers) decide it'd better if their implementations could interoperate. Why do you think they're completely orthogonal?

It's possible, of course, that the C++0x (C++1x?) standardization round is taking place on the peak or the decreasing side of C++ adoption (due to the increased complexity of C++, users finding benefits to non-C++ languages, movement into areas where C++ doesn't help much, etc.). But I don't think that's the case; perhaps we're on a plateau of C++ adoption, if anything.

Fair enough. Perhaps all the C++ effort is simply a dying gasp from the collective industry.

In any event, we're talking to different sets of embedded vendors. The embedded vendors I talk to are still using C++ and so are their customers. Maybe I'm talking to the less profitable ones, though. ;)

I don't buy that. Maybe it's true in the "reads Hacker News" monoculture (or the "comments on Hacker News" monoculture), but that sample is not representative of the wider programming world.

Apple's not going to spend several million dollars of engineering effort to create another C++ compiler if nobody's writing C++. Companies aren't going to spend money on sending representatives to C++0x standards meetings if their customers aren't using C++.

People are realizing that they don't have to program in C++ for many different areas. That doesn't mean that they're aren't still writing parts of their apps in C++. And there's a lot of existing C++ code out there that still has to be extended, debugged, and maintained.