Slashdot Mirror
GCC Turns 25
eldavojohn writes "With the release of GCC 4.7.0, the venerable and stalwart constant that is the GNU Compiler Collection turns twenty five. More ISO standards and architectures supported with this release and surely more memories to come from the compiler that seems to have always been."
pre-javaScript relics
Hey GCC, only one slice of cake for you - you are big and slow enough at the moment (but I love you anyway).
OH NO! It's like I'm married to GCC!
...but I wish its development wasn't so inner-circle. If you thought that Free software = bazaar model, you haven't met gcc.
Is that some faded-out version of Pascal, perhaps?
Are we measuring GCC from the first version called GCC, or are we measuring from the last release of EGCS, which is actually what we're now using and calling GCC? 'cos where the original GCC went, no one followed...
File not found :(
You youngin' have no idea of what kind of crap for compilers we had to put up with until gcc.
25 years of compilation with gcc!
"To those who are overly cautious, everything is impossible. "
Before GCC there were some excellent (for their day) compilers available from what was then an obscure technology company called Microsoft. There were cross-compilers for unusual platforms from Manx Software.
Kids these days. Next thing you know they'll think they invented sex.
I love GCC, don't get me wrong, but it seems to me from the research I've done that it's been left in the dust by Intel's and even Microsoft's compilers, which do a far better job at generating optimized code, especially for x86/x64. I have an application where I'd love to use GCC rather than a horrible vendor-specific C/C++ compiler to generate some ARM firmware, but I'm getting a lot of resistance due to its perceived poor/bloated code generation.
Can anyone confirm or deny this and make me at least able to justify GCC as a possible option again?
Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
Happy Birthday gcc!
Time to take it out back and shoot it.
If you want to use LLVM then use it. If it's really better then GCC will eventually fall out of development naturally. No need to try and force things to go your way by demanding that GCC just give up.
Are you serious? You're a firmware engineer and you can't figure out what compiler to use. Further, you're developing for ARM and you think that Microsoft or Intel may be the best option?
<br><br>
NXP recommends GCC (Code Red IDE which is Eclipse-based), and ST recommends Keil, for their ARM micros. Just FYI.
<br><br>
Good luck on your school project.
sig: sauer
Intel and Microsoft compilers are generally considered better than GCC for IA32 and x86_64, but that's mostly because those are the only platforms those compilers need to target (Microsoft care about ARM now, but I don't know how well MSVCC compares to GCC for any given ARM target). Architecture specific compilers will always be able to take crazy shortcuts in the optimiser and generator. GCC has to jump through all sorts of hoops between the front end and the back end, because the front end can't make any assumptions about the back end.
Yay for gcc, always giving me errors and making me actually try to get it right the first time.
Good luck on your website.
Microsoft's compilers are specific to the Windows platform, while Intel's compilers are only free for non-commercial use. I don't think either company releases compiler source code. So depending on your situation they might not be an option.
I still miss putzing around with the compiler from Rick DeSmet to communicate with my dot-matrix printer trying to get it to change fonts. The GCC is a remarkable achievement, and important, but my fondest memories are elsewhere.
Well, one thing that's happened to me an awful lot is that GCC seems to generate smaller *and* faster code when using -Os rather than -O3. That it'd be smaller was no surprise to me, but the speed-up was. (For reference, I'm using an IA32 2 GHz CPU with 1.5 GB of RAM.)
Maybe this is a good place to turn to for help. I have a C assignment that's due this week, and I can't figure it out!
How do I output a string without outputting in the end of line at the end?!
Like if I have an char firstname[5] that has "Bob\0\0", both printf() and puts() will put a newline at the end. How do I get it so it doesn't insert a newline, so I can output "Bob was here" in one line?
Help me Slashdot, you're my only hope!
Well, one thing that's happened to me an awful lot is that GCC seems to generate smaller *and* faster code when using -Os rather than -O3. That it'd be smaller was no surprise to me, but the speed-up was. (For reference, I'm using an IA32 2 GHz CPU with 1.5 GB of RAM.)
Fewer cache misses, maybe?
Bow-ties are cool.
It's not just been left in the dust by Intel and MS's – it's also been left in the dust by Apple's (now BSDed) clang. It runs faster, produces faster code, produces better error messages, is more amenable for using parts in other tools, has a brilliant static analysis tool that comes with it, ...
If your program is largely compute-bound (small data) rather than memory-bound, smaller code can be faster because more of it fits in the L1 instruction cache.
fuck perceived. show that it works, people will then agree to use it.
I'd reckon a bigger problem is codebases made to compile on specific hard to get versions of say.. arm rvtc.
if the problem for using gcc is just perceived bloat in binaries you're in heaven, stfu and eat cookies.
world was created 5 seconds before this post as it is.
The best part of the entire linked-to page was the email addressing at the bottom of the announcement. UUCP paths. Those truly were the days.
Michael J.
Root, God, what is difference?
If you need a compiler with special optimization options to make your code run fast, then either your algorithm or your data structure is wrong. Implicitly-parallel SIMD problems are a notable exception - same operation on massive amount of data. Everything else is PEBKAC.
Happy birthday gcc - making me think more carefully and write better code for 25 years!
Let's see how well Clang and LLVM do once they support the number of architectures that GCC does, shall we?
Your attitude makes me think that you're not a JavaScript Rockstar. Well I am, and let me tell you, it's not easy being one!
You probably only know Pearl or See Plus Plus or See Sharp or one of those other old hat langs that nobody uses any more. You also probably only write software that's Desktop Scale or maybe even Server Scale. Well that's Old Hat and it's Small Hat!
Us pros, we use JavaScript because it's the best language there is. In fast, it's so good that it's the only one I need to know. It's so fast to work with that I can create five social media applications before you even turn your compiler on! And since I use node.js my web app will scale to the Web And Beyond.
JavaScript has the best dev tools around. I hear that you guys have Visual Studios or something but we have alert(). It's like your Visual Studios but it's a lot more powerful. But we only use it for the Hard Problems because JavaScript makes it so easy to write perfect software. In fact, I haven't created a bug in almost 3 years because JavaScript is perfection and I'm thus perfection because I use JavaScript.
JavaScript is the only option today. If you're not using JavaScript, and only JavaScript, then your code is Old Hat. If your code is Old Hat then you're not a JavaScript Rockstar like me and my colleagues. And if you're not a Rockstar, then you probably shouldn't be talking about programming.
Intel's and microsoft's compilers only handle x86, though. GCC can compile for a rather larger variety of targets...
Why guess when you can know? Measure!
I turn 25 this week too!
Depends largely on the size of your cpu cache, although i was pretty sure gcc (or maybe it was some other compiler) had some options to take cache sizes and relative performance of different level caches vs ram into account when generating optimized code.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Pastel was an extended Pascal compiler developed by LLNL for the S-1 supercomputer project
http://www.cs.clemson.edu/~mark/s1.html
It, and several other significant pieces of software, including the SCALD hardware design language
were made freely available by LLNL. I have one version of the compiler, which was donated to the
Computer History Museum by one of its authors. I have been looking for the other pieces since the
late 80's.
If you look at the GNU Manifesto, RMS was also looking at using the MIT Trix kernel in the early days
of the project.
You can have the best algorithm in the world, and a good compiler will *still* be able to make it run faster than a bad one.
Alignment, branch probabilities, inline functions, hoisting stuff out of loops, loop unrolling, removing unused code, etc.--these sorts of things really can make a difference in code that gets called frequently.
That said, it's not exactly clear that the Intel compiler (icc) is unconditionally better than gcc. There are some benchmarks at http://www.linuxforge.net/docs/bm/bench-gcc-icc.php of a linux-2.6.34 kernel compiled with gcc and icc. The results are close enough that it doesn't make sense for most people to use icc.
Laugh now, just wait until he's got a million Brazilian dollars.
RTFM idiot - Os means to optimize for size. The generally accepted standard flag for GCC is -O2 as it's the best compromise between Size and speed up. The only thing is, Sped Up is dependent upon various elements within the source code such as loops and CPU specific options as we Gentoo users tested. Some apps actually do well with O3 flag, most work fine with O2 and from my experience, Os offered the best performance with smallest size possible from the binaries. Most of the speed increases come from fewer cache misses as the binaries are sometimes small enough to actually fit within the L2-L3 cache when the cpu has sufficient space.
Mod me up/Mod me down: I wont frown as I've no crown
Now, get off my lawn.
--- Liberty in our Lifetime
My admiration belongs with Gimple?
No, my admiration for GCC today is for it's political and open source community contribution.
But technically, I've come to find GCC to be a very obtuse and difficult tool to nurse through my current projects.
I'll always admire and defend GCC as an industry changing tool, but if I'm honest, it's not my day-to-day compiler of choice any longer.
But regardless, Long live GCC.
If you're programming in C, which is very likely if you're doing embedded, you're going to hate your life if you have to use Microsoft's compiler. It doesn't support C99 very well (at all?), it doesn't allow inline functions, forces you to declare all your variables at the top of a function, and a number of other annoying things that I only remember when I have to use it.
Basically stay away from Microsoft compiler for C if you can help it.
"First they came for the slanderers and i said nothing."
Plus, we were always at war with Eurasia.
Unless of course clang generates code that is twice as slow as gcc
SmallPT is one graphics program that seems to be much slower with clang than gcc.
Work bio at MMWD
Is GCC on Windows still treated like a third-class citizen? I remember a resistance to supporting certain features of Windows that the MS computer supported like SEH but I dont know if that has changed.
Linux started on usenet, and what really made it blow up was the ability to use gcc to write software. The first version of linux everyone was running didn't have a login, you just got root. Soon the login program came, (i think getty). But anyway it was Theodore Ts'o who did the heavy lifting. Every new program needed something new in the C library and Theodore somehow got it done.
Thanks Theodore !!
That program uses OpenMP Clang doesn't support OpenMP. Now I have a code that uses Clang blocks with libdispatch. GCC doesn't support blocks so it won't compile with GCC. Ergo Clang is Infinity times faster than GCC using your logic.
It's not just a compiler, it's also a worldwide political movement.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Are you an Apple shill in your spare time?
I'm trying to read this thread, and I have to put up with your repetitive posts about how great clang is. Why don't you read some of the replies to your crap? They do a good job of debunking your claims. I have mod points, but I just hate moderating people down, even if they waste my time repeating unfounded assertions (also known as bullshit).
the reason Microsoft C was a ripoff of Lattice C is that it was equal to and equivalent to Lattice C. They purchased Lattice C to sell with their brand-name.
It's just like how they bought an operating system from someone else and rebranded QDOS as Microsoft DOS.
Seattle Computer Products sold the rights for $75K while MS resold the software for $4M in the first year alone. SCP is pretty much the first of many victims of Microsoft.
It doesn't support C99 very well (at all?), it doesn't allow inline functions, forces you to declare all your variables at the top of a function, and a number of other annoying things that I only remember when I have to use it.
This can be concisely summed up as "doesn't support C99", really, because all other things that you list are the consequence of that. When VC is compiling in C mode, it can be very pedantic about being a C89 compiler - heck, it doesn't even support // comments then. About the only thing you have from C99 is stdint.h.
For all intents and purposes, it really is a C++ compiler, with C support being more or less a legacy feature.
And it's really frustrating when I'm trying to write code which is portable (which is most of the time when I write C) because then I'm basically forced to stick to the lowest common denominator. I wish they would support some of these 12 year old features, some of which would take a day or two to add.
"First they came for the slanderers and i said nothing."
The way things are, basically, 90+% of native code written for Windows is C++ and not C - and hence C++ gets priority. And there's plenty undone in that department as well, particularly now that C++11 is out - VC++ has a few cherry picked features from there since v10, but it's starting to lag behind GCC now, and needs to catch up fast. Those precious few dev resources the core compiler & library team gets, they throw at C++ again to move ahead of schedule - e.g. they didn't originally intend to implement C++11 range-for statement, but it happened because a few people from different teams got together and basically pooled their free time to make it happen.
Simply put, it's something which would not matter to most users of the product, and it's also not something that many people internally feel passionately about to push for it despite objections. So it's not going to happen, unless there is some sudden surge in demand for C99 from the user base.
True, but adding // comments would take 10 minutes (assuming you know the code), and giving the ability to declare variables wouldn't take long either.
Anyway, range-for loops are good too. But let's be honest, is there any reason a company with Microsoft's resources can't keep up with gcc?
"First they came for the slanderers and i said nothing."
The following list shows the microprocessor families supported in Windows CE .NET
True, but adding // comments would take 10 minutes (assuming you know the code), and giving the ability to declare variables wouldn't take long either.
You forget about all the associated red tape. Even a minor feature has to be tested, and some QA ultimately has to sign off for that. It also has to be documented by tech writers, complete with code samples, and said documentation to be translated to all supported languages (I believe over a dozen now for VS). Any associated user-visible output (e.g. new errors/warnings) also has to be proof-readed and translated. It all adds up.
But let's be honest, is there any reason a company with Microsoft's resources can't keep up with gcc?
It can, if that were the goal. But the ultimate goal is to earn money, same as for any other for-profit company. Hence, things aren't done because they are neat or the Right Thing or because everyone else has them. They're done because the expected profit from the feature - whether direct (from sales of the product) or indirect (from sales of other products propped up by the SDK, like, say Windows) - exceeds expenses. Even more importantly, resources being large but still limited, for every feature the question is not whether it is profitable in and of itself, but whether it is more profitable than something else that could be implemented in its place. It's that stack ranking that really kills C99 support - there's always something more important (read: more profitable).
Of course, people aren't cogs, and sometimes they feel hard enough about something - purely out of the desire to do the Right Thing - that they play bureaucracy games to come up with a plausible "business case" for their favorite cause, and ultimately convince the management that calls shots to let them put it in. But, there's no-one there who feels hard about C99 (or at least harder than a dozen other things that need to be done first, preferably yesterday - like, say, variadic templates...)
Long live GCC, IMHO the major reason why we no longer pay for compilers as we used to.
LLVM/Clang is a very interesting project, it's sad it's gaining traction because of GPLv3 haters/fanboys/etc. and not because of its qualities. I fear their actions might even harm it, i.e. users and developers could stop being interested in it being the better compiler as long as it's "more open" (lol).
Kill all hipsters.
As the other poster pointed out, clang does not support OpenMP. If your code uses OpenMP, then this is a very serious limitation. It means that your code will execute on a single thread with clang, but on multiple concurrent threads with gcc. If your program doesn't make use of OpenMP, then this benchmark is highly misleading.
Oh, and if your code does use OpenMP, the odds are that Path64 will be significantly faster than gcc.
The other poster mentioned blocks. I just did some work on Solaris support in LLVM and clang for a customer for exactly this reason. They wanted to use blocks with libdispatch, because it lets them scale their code up very easily to a lot of cores. GCC doesn't support blocks at all. Clang didn't support Solaris at all. Getting clang, LLVM, and libc++ all working on Solaris was a lot easier than adding blocks support to GCC would have been, so now they're using this stack.
I am TheRaven on Soylent News
The depressing thing is that C99 support actually used to be better in the Microsoft compiler. Most of the C99 features that people want are also C++ features. Old versions of the compiler used to compile C as C++ with a few things disabled, so you got a fairly good approximation of C99 (BCPL comments, variables declared anywhere including for loops, inline, although with the Microsoft definition not the C99 definition).
I am TheRaven on Soylent News
GCC can't support SEH because it's patented (although I think the patent expires next year). Win64 supports a new exception model that isn't patented and is quite similar to the DWARF exceptions used on *NIX platforms (although just different enough to be irritating). Support for it is underway in LLVM, so I'd imagine GCC will support it eventually too.
I am TheRaven on Soylent News
That said, it will only produce PE binaries for those platforms. If you want to produce ELF binaries... good luck.
I am TheRaven on Soylent News
Yes, I agree that it looks interesting. I just hate it when someone repeats the same thing again and again in a discussion, when it's not in every discussion he goes. I'm fine with discussing the merits of LLVM, this looks like the appropriate place for it. I just don't want to read the same discussion four or five times because one person ignores what has been said on the topic and just repeats his original message.
Clang is fine. I often find it producing much faster binaries than GCC. Perhaps, instead, it is your own code that sucks, not any compiler?
Brian Fundakowski Feldman
Almost certainly. The big problem for compiler writers today is that measuring performance is insanely hard. Things that improve microbenchmarks will often make code slower overall. A simple example is inlining, which can come with some huge benefits. If you inline a function, then you can do more optimisations across the result, and you avoid the cost of the call, but you increase the code size. You run the result, and it's faster, but now it's using 20% of your instruction cache instead of 5%. Fine? Well, now you run it on the same system that's running some other things as well, and now it's getting an instruction cache miss 1% of the time, when previously it would have no cache misses. If your cache miss penalty is 100 cycles, then you're code is now half the speed it was (a 100 cycle penalty every 100 instructions, assuming an average of one instruction per clock, which is pretty pessimistic for a modern CPU) so those optimisations had better have been worth it...
I am TheRaven on Soylent News
If it's really better then GCC will eventually fall out of development naturally
Eventually can be a long time. For C and C++, there's really not much in it. Clang is nicer to work with as a developer because it provides much better error messages and nicely integrates with your editor of choice (vim, emacs, and eclipse plugins exist) for code completion, but for code generation an end user is unlikely to notice the difference, and even someone running benchmarks is likely to conclude that there's rarely more than 5-10% in it either way.
For Objective-C, there is a massive difference. Clang generates much better code and supports a much newer version of the language. GCC's Objective-C support is positively archaic. It doesn't support (on non-Apple platforms), off the top of my head:
And yet people packaging GNUstep for Linux distributions still insist on compiling it with gcc, even though that disables a number of features that can't be correctly implemented with the old version of the language.
I am TheRaven on Soylent News
ARM licensed technologies for architectures v4, v4T, Thumb, v5TE, and Intel XScale.
All of which are pretty out-of-date versions of the ARM instruction set architecture. Obsolete, even.
GCC, on the other hand, supports all the modern ARM instruction set versions. Optimizes specifically for them upon request, even.
b.g.
Time to take it out back and shoot it.
What he said.
ReactOS struggled with SEH, but they found a way.
Have you heard about SoylentNews?