Interview with Mark Mitchel, GCC's Release Engineer

ICC-Rocks writes "In light of the imminent release of the first 'stable' version of GCC version 3, OSNews features an interview with Mark Mitchel, GCC's Release Engineer. They are talking about GCC 3.x, the future and the competition."

Comments

Summary

[cjpez]

Question: Blah blah blah irrelevant blah.
Answer: Blah blah blah I don't know blah.

Brilliant, really.

GCC white tower.

[Zapman]

8. What did you think about the Intel Compiler v6 that came out recently? Did you have time to have a look at it?

Mark Mitchel: I do not have enough information about that compiler to comment on it.

I know that x86 is just 1 arch for gcc, however it is an important one, being the most common. I would think that those heavily involved with gcc (and especially the x86 backend) would be much more interested in how well the other compilers performed since they are 'the competition' as it were.

It's kind of depressing that he 'doesn't have enough information to comment'.

if intel's compiler had been released last month or thereabouts, I could understand, but IIRC, it was released about 6 months ago.

Re:GCC white tower.

[4of12]

I know that x86 is just 1 arch for gcc, however it is an important one,

Yes, indeed.

Not knowing the first thing about compilers or the details of how gcc looks on the back end, I'm curious:

Does the instruction set agnostic nature of gcc severely impede how optimizing the compiler can be?

Not to complain too much, though. I've always been impressed that gcc runs on such an incredibly broad range of platforms. I've used for over 10 years and would frequently build it on new machines either where the compiler was not bundled and licensed for general use, or where the vendor supplied compiler was unable to compile my code.

Re:GCC white tower.

[Zeio]

I have used that compiler, ICC, it is impressive. I would recommend it to anyone. It increases speed by at least 15%, and this happens to Athlon as well. It is the best x86 compiler out there bar none - in terms of performance and x86.

Keep in mind this compiler has strange licensing, weird runtime restrictions that curiously favor the use of IA-64. A way around the linked restrictions in licensing is to build statically.

It would be nice if Intel gave the GCC team the secret sauce which makes this one some much better at optimizing code. I do not flame GCC at all, I like it , and clearly it is superior at going across architectural boundaries. I just wish HP/DEC/Compaq, Sun and Intel were more willing to show them a 'thing or two' about insightful ways to optimize the compiler.

Also, note that ICC can not compile the kernel. I know and have been told that there are things present in GCC that allow the successful build of the kernel that do no (CAN NOT?) exist in ICC. It would interesting to see if someone could get the kernel to build with ICC by hacking a mixture of the two compilers.

Another strange thing about ICC is that they are not entire GNU aware, and have an odd licensing file and install procedure. We had some problems with linking that were an obvious kluge and required a workaround. It would be nice to see the source for this, but that will not happen in the near future.

Best of luck to both teams, and I suggest that Intel, if you want the world to love x86 (even more), drive the stake in, and show us the source so that we can make GCC considerably better on x86.

I recommend that people try ICC whenever possible and take measurements.

I appreciate his honesty in not commenting on it, but seriously, this guy is way too smart to ignore what else is going on in compiler-land, and if he isn't measuring himself to the "competition," then he has stuck his head in the sand. I recommend that where ever possible he builds with the respective compilers every piece of code and looks for comparative anomalies and or performance differentials in order to learn from that.

Best of luck to the GNU GCC team!

Re:GCC white tower.

[V. Mole]

The goal of GCC is to work on a wide variety of architectures, which it does.Another goal is to comply with various language standards, which is getting there. Performance is a much lower priority -- it's "good enough" for most uses, and if you seriously need to crunch some numbers, well, then you need to spring for the vendor's compiler. My experience (several years working on software that ran on SunOS/Solaris, AIX, HP-UX, and (Open)VMS) was that GCC was a superior tool for developement and debugging (much better compliance and error messages), but then we went with the vendor compilers for final testing and release to get the performance we needed.

GCC is *not* competing with ICC, because they have different goals and different target markets. As far as Mr. Mitchel evaluating ICC, he probably can't due to fears of copyright or patent infringement.

Re:GCC white tower.

[Micah]

> As far as Mr. Mitchel evaluating ICC, he probably can't due to fears of copyright or patent infringement.

That seems pretty unlikely. For patents, if gcc were to step on an icc patent, it would do so whether or not he used ICC.

For copyrights, I don't think he'd even potentially be liable unless he saw the ICC source code. And Intel keeps the source secret, right?

IANAL of course.

Re:GCC white tower.

[yellowstone]

Does the instruction set agnostic nature of gcc severely impede how optimizing the compiler can be?

It turns out that compiler optimizations divide nicely into two categories:

1. Optimizations on the Intermediate Representation (i.e. not specific to any platform)

2. Optimizations on the generated (CPU sepcific) code

So the only drawback is that optimizations for a specific CPU may or may not be appropriate for other CPUs. However, even at the CPU-specific level, there's a lot of stuff (e.g. register allocation, instruction scheduling) that could use the same code base, just using CPU-specific callbacks as needed (i.e. use the Framework Pattern).

Re:GCC white tower.

[dvdeug]

I like gcc... but it is currently losing the race.

Any given compiler will lose some races. If the rules of your race call for the most optimizing compiler for the ix86, then GCC loses. If your race calls for a compiler that's portable to the various Linux, Windows and BSD platforms and that your users can get easily (i.e. comes with their OS, preferably), or they call for an Objective C, Java, Fortran or Ada compiler, then GCC leaves icc in the dust.

Re:GCC white tower.

[leastsquares]

I agree with what you say, but would like to add a few comments:

- If speed is an issue, then you'd nearly always choose the native compiler. (Supporting multiple compilers does introduce extra issues because lazy programmers will rely on a portable compiler instead of writing portable code.) gcc couldn't be expected to compete, speed-wise, on a huge range of systems.

- In the case where you ship code, you shouldn't rely on the end-user having a particular compiler. I really, really wish that every system did have gcc though.

- If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.

Re:GCC white tower.

[dvdeug]

If speed is an issue, then you'd nearly always choose the native compiler.

This isn't automatically true. When GCC was first ported to the Sun, it beat the native compiler by, IIRC, 30%. While I have no recent numbers, it wouldn't surprise me if this were still true in some cases; GCC has a lot of optimization work done on it, and the hardware vendor may not have the ability to produce a highly optimizing stable compiler. The ix86, a CISC chip that brings in loads of cash for its maker, is of course an exception.

Supporting multiple compilers does introduce extra issues because lazy programmers will rely on a portable compiler instead of writing portable code.

The set of strictly conforming C or C++ programs isn't very large, and the set of C or C++ compilers guarenteed to work correctly is empty. How much work one should take to work around the bugs and hideous malfeatures of many compilers instead of dealing with the bugs and hideous malfeatures of just one compiler is up to the programmer; many programs aren't worth the trouble to get them running for the people who insist on compiling them with WeirdC (we've been working towards ANSI C for almost twenty years now!).

If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.

OpenMP isn't available, but threading is; you can use various forms of native threads for C or C++, or you can go straight to Java or Ada and let the compiler deal with the native threads.

If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.

Re:GCC white tower.

[leastsquares]

If speed is an issue, then you'd nearly always choose the native compiler.

This isn't automatically true.
What? You don't think that it isn't automatically true that you would nearly always choose the native compiler?

OpenMP isn't available, but threading is; you can use various forms of native threads for C or C++, or you can go straight to Java or Ada and let the compiler deal with the native threads.

So I assume that you've tried debugging multi-threaded C/C++ code with gdb then? Java isn't an option for typical CPU intensive code. I'd love to use Ada, except I'm not about to migrate half a million lines of code.

Free content isn't supposed to mean content-free..

[Jerf]

I respect the guy for saying he doesn't know the answer rather then trying to make it up, but I don't see why the original website ran the story, let alone why it should be posted on Slashdot. The percentage of sentences with useful information seems to be in the low teens, and it's not like it's a terribly long article where that can be expected...

Re:short intro

[Zapman]

I'm not sure that I'd spin the story like that, especailly about the "linux buying out egcs.com".

Gcc seamed like it had been stagnant forever at the 2.7.* branch. If you look at the release history, you'll see that 2.7 was first released in June 95, and 2.7.2.3 was released in August of 97. Two years of point releases, with nothing new.

Well, some folks got tired of it, and forked the code. They made something called pgcc, which had more optimizations for the pentium (I) arch. Some of you may remember that the main distinction between redhat and the origional mandrake release was that Mandrake compiled all of redhat's packages with pgcc (except the kernel)

One thing led to another, and the pgcc fork got folded into the egcs versions. People were dismayed that there were 2 competing versions of gcc lying around but only one of them seemed to be moving: the egcs one. Egcs released version 1.*

Finally, the egcs and the gcc folks got to talking, and the egcs board became the gcc steering committee. If you look at the gcc release history, you'll see the egcs versions listed there too, because egcs became gcc 2.95.*

The gcc release history can be found at: http://gcc.gnu.org/releases.html

Re:Free content isn't supposed to mean content-fre

[clem.dickey]

The message is between the lines. If there were ever an interview with a developer working in "go away and don't bug me" mode, this is it.

Re:Free content isn't supposed to mean content-fre

[Permission Denied]

I respect the guy for saying he doesn't know the answer rather then trying to make it up

An essential difference between engineers and politicians or marketing droids. Refreshing, really.

Re:GCC 3.0 has some great features

[Permission Denied]

This is hilarious - did anyone else catch this?

This guy got a +1 Informative for this:

-Just In Time assembling (JITa)
-pipeline overflow caching
-memory protection beyond the 4 MB barrier
-interlaced object replacement with error redundancy cycles

He just made that all up. Memory protection beyond the "4 MB barrier?!" Lol. This is classic, really.

Re:Very thorough, indepth interview

[Snowfox]

Is it me, or did he sound like compiler output?
"Not to my knowledge"
"No, It's not."

Never anything helpful ;)

To the contrary - if this had been an interview with a commercial product, he'd never have said no, he would have implied that they were working on or investigating every feature mentioned, and he'd have turned bad points into positive spin.

This was frank, refreshing and to the point. Short and factual is good.

MM is a C++ front-end guy.

[Per Abrahamsen]

MM is primarily a C++ front-end guy (when not being a release manager), and the interesting aspects of ICC is mostly in the i32 backend, so ICC is unlikely to be that interesting once MM has time.

I believe ICC use a version of the generic Edison C++ front-end (most good C++ compilers do), which MM is most likely already familiar with.

Can you blame him?

[devphil]

And since the 3.1 release is now nearly a month behind, due to no fault of Mitchell's, I'm not surprised that he's busy. :-)

Re:This is something you might want to consider

[elflord]

I use GCC 3.0.4, and it's a lot more standard-compliant than 2.96, has better error messages, and seems just as stable as 2.96.

Then why won't any distributor use 3.0.x as its compiler ? Why have RH released 7.3 instead of moving to gcc 3.0? The answer is that gcc 3.0 have some fatal bugs which prevent it from compiling KDE correctly. Fancy that-- they actually released something as big as 3.0, without checking that it could compile KDE correctly. Apparently, they've ramped up the C++ requirements for the 3.1 release, which means they're at least starting to take the issue seriously. However, this "ball dropping" exercise has kind of vindicated RH, who unlike the gcc project, need to ship a compiler that will compile the bulk of their distribution.

Re:This is something BERO BARF. Regugitate.

[elflord]

That's only because a lot of software includes workarounds for broken gcc releases. It doesn't compile anything that uses the sstream header. It compiles a lot of nonstandard code. The 2.95 compiler has several severe problems with its standard library.

Re:This is something BERO BARF. Regugitate.

[elflord]

Breaking C to fix C++ is kind of silly, wouldn't you say? I know it's not perfect, but it's a release, people build to it as a point of reference, and its anomalies are clearly documents as much time has passed since its release. Your "RH" secret sauce approach with no one knows what the f**k you did approach is so much worse, and it is ANTI OSS philosophy.

Horseshit. Part of the "OSS philosoppy" is that the users have the right to revolt and fork a project when the maintainer drops the ball. gcc shipped a gcc 3.0 release that was (a) late, and (b) too broken to use as the base for a distribution. The fact that the gcc 3.0 series was not fit to be used for a distribution vindicates Redhats decision to fork, IMO. RH need a compiler that can build a number of software packages, and gcc didn't provide that.

Re:Maybe RedHat should start releaseing the real v

[elflord]

Note: About my insinuations about GCC 2.96 brokenness, I work side by side with a person who used to be on the GCC/GNU team, and has found strange bugs in certain version of the glibc that has been compiled by the 2.96 series. It went away when using release glibc compiled by release GCC.

gcc 2.96 contained bugs, but so did 2.95. Improving a compiler sometimes results in bugs that weren't there earlier ("regressions"), and we can see examples of this sort of thing in gcc 3.0. There are a number of improvements in gcc 2.96. As someone who writes C++ code, I've observed some important improvements in support for ISO/ANSI C++.

It has been said that if a broken compiler compiles a library the library can be strangely broken and very difficult to debug.

I've got news for you -- all this emotive rhetoric about "broken" gcc 2.96 isn't supported by facts. There are a number of things in gcc 2.95 that are also "broken", and on the balance of it, gcc 2.96 comes out as a somewhat stronger compiler.

On a side note, as far as GCC 3.X not being prime time, for C is surely is, I don't know about the rest, but for C its, as far as I can see, quite useable, stable and reliable with some interesting new optimizations.

Hmmmm... I've had some very wierd bugs pop up with the "interesting new optimisations". Seriously, gcc 3.0 is a tremendous improvement in a number of ways, but there are some fairly show-stopping bugs (including a substantial C++ ABI bug which means that it can't compile KDE correcty) Because of this bug, gcc 3.0 is unsuitable as a compiler for a Linux distribution, and this is why no distributor is going to ship it as the primary compiler.

I think that GNU has been a great force in the world, and to uselessly outpace them or point fingers at them is frustrating and bad for both sides of the camp

It's not "useless" outpacing. gcc 3.0 was late, and the 3.1 release that dealt with the stuff that needed fixing in gcc 3.0 was almost a year later. What Redhat did is released their own derivative version of the gcc 3 CVS that was customised for use as a distribution compiler. gcc 3.0 on the other hand is not useful as a distro compiler.

Programmers ignore in favor of GNU releases. Debian ignores it.

Programmers ignoring Redhat ? Laughable in the extreme. Programmers don't ignore it, but even if they did, it wouldn't matter, because anything that will copmile with gcc 3.0 and gcc 2.95 will compile with gcc 2.96. A number of distributors have included it.

Re:This is something you might want to consider

[dvdeug]

Why have RH released 7.3 instead of moving to gcc 3.0?

Because RH 7.0 used 2.96 because they needed a new compiler (for various reasons) and 3.0 was going to be too far away. Instead of moving to 3.0 for 8.0 a month or two before 3.1 was put out (and having to use it throughout the 8.0 series), they waited for gcc 3.1.

In any case, with my experiance with Debian and GCC, whether they released 7.3 had little to do with when 8.0 came out came out. They had important changes for 7.2, and released them.

Fancy that-- they actually released something as big as 3.0, without checking that it could compile KDE correctly.

It wasn't a good thing that they did that. However, gcc only has so many people working on it. I know, short of a huge last minute mistake, that my important code will work with GCC 3.1. There are Linux kernel developers who use kernels compiled on GCC 3.1. It should be worth it to someone in the KDE world to compile KDE on GCC snapshots and catch stuff that doesn't work.