Slashdot Mirror
Benchmarks For gcc-3.1
Isle writes: "Another good story found via OSNews.
Scott Robert Ladd has updated his
GCC vs Intel C++ compiler benchmark. Now you can find gcc 3.1 benchmarked against gcc 3.0.4 and icc 6.0.
The summary must be that gcc 3.1 is a lot faster than gcc 3.0.4 for very abstract C++ code, but icc is still slightly faster overall."
In reality, what the article is showing is that the GCC team have optimised the gcc compiler by a great deal in a very short amount of time. They deserve recognition for this. One of the reasons for using gcc is that it compiles my code everywhere without any headaches. I develop on GNU/Linux, and run the code on Solaris (sometimes on SGI, but not too often). The code runs as expected. What would be interesting to see is how well gcc compares to optimised compilers on other non-x86 architectures. For my code, gcc is slower than Sun's CC, but I am using an oldish version of gcc.
I'm really am curious of how you develop.
I personally just write the code down, compile, run with debugger. I note worst mistakes, write them down, correct values in memory and continue test run until it've gone as far as it can without modifying code.
After this all is done, I correct code with my notes, and begin it all over again.
With this use, actual compiling is not slow if it takes 3-5 mins.
yeah, daily recompile load is about 700k C++ code + 200k headers (+100k vendors).
Some time ago I had to recompile with P133, and it took (with watcom 11.0c) approx 7min, which _felt_ like a lot. at the same time I was able to modify code in emacs, so that wasn't such a bad deal until we had a really fast call.
fucktard is a tenderhearted description
Check out the Borland C++ compiler. It produces some crappy code but it sure is fast doing it. I use it to start off my projects - I use gcc to finish them off and make them cross platform. Using two comilers can also have debugging benefits - one will balk on somthig that the other passes by, or a logical error will become apparent on one and not the other.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
You'd end up with the same compiler in the end. GCC compiles itself in two phases, the first using the native compiler, and the second recompiling itself into the final product. Not much gain in doing that all over again, sorry. ;-)
Is your browser retarded?
After looking through the benchmark results and noting how large the difference is for the Monte-Carlo algorithm between gcc and icc, it seems that this may be caused the underlying standard C library that gcc is using. Perhaps the GNU version of drand48 is being more "random" by using some "random" system function of the kernel (or glibc), whereas icc may be unaware of these more-random system/glibc functions and substituting something of its own instead (which may be faster but probably not-as-random as the gcc version).
Paul.
only if you "make bootstrap"
Actually you can make yourself a faster compiler, by build gcc with icc. (libstdc++ and other compiler libraries are always build using the newly build compiler, so no speedup there)
Absolutely. Anybody who uses a single compiler on an important project (at least during the development stage) is just begging for problems later on down the road.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I've been coding long enough that I don't make too many mistakes. The problem is that if I change something low down in the dependency tree, lots of stuff gets rebuilt, and this takes time.
;)
Also, thanks to the complexity of C++, there is no refactoring browser (that I know of) so if I change a method signature, I have to use the compiler to tell me what needs 'fixing'.
Of course, vim is able to jump to warnings/errors generated by gcc, which helps quite a bit.
I'm currently working on about 50k lines of C++ code, where a rebuild can take anywhere from 3.5s for one file (no problem) to 90s for a change that affects more code. I'm currently using gcc 2.95.3. gcc 3.1 is much slower.
I'm using make -j 2 on a dual athlon, and I forward declare where possible to save time.
I would just prefer the focus of gcc development to shift from execute speed to compile speed. But the gcc people are free to do what they wish, it's not like I'm paying them
Rik
I use Design by Contract, and program by writing the assertions first. By the time the program runs without violating any assertions, it needs very little interactive debugging.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Considering that GCC 2.9x is still shipping with most distros, and is the only one that compiles the kernel yet, why not show some comparisons with it, in addition to GCC 3.x and ICC? Why only benchmark fringe compilers, when a vast majority of Linux users will be rocking the older compiler?
my sig's at the bottom of the page.
True, there are certain things that cannot be captured by executable assertions. However, I disagree that it's a matter of "level". You can have high-level, abstract assertions just as well as low-level ones. The examples you gave are just assertions of a kind that can't be checked automatically at runtime, not a level.
Having said that, I think the examples you gave are more amenable to runtime checking than you might think. Checking time constraints is trivial--all you need is a couple calls to gettimeofday--though the challenge here would be to find a systematic way to put these checks in all the right places. A more fundamental challenge is to reason about the delay that might occur during various operations, in order to convince yourself that you will indeed satisfy the assertions. However, none of this is impossible, as you seem to imply. For instance, using timeouts can help you put an upper bound on the delay of I/O operations.
GUI assertions are different, though these are still possible. The key is that you should Design by Contract, just as the hardware folks design for testability. In other words, don't simply code the way you already do, and just throw in a few assertions; rather, you change the way you code in order to make it amenable to assertions to the greatest possible extent.
In the case of a GUI, the idea is to leave everything in data structures as late as possible, and then make the actual rendering stage trivial. Then, right up to the renderer, you can assert that the text has a certain colour. The rendering stage itself may not be amenable to assertions, but the idea is to keep that as small, as simple, and as widely-used as possible.
Assertions don't replace testing; rather, Design by Contract multiplies the tests' effectiveness.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
But gcc 3.1 optimises more heavily. gcc 3.1 with -O1 compiles almost as fast as older releases with -O2, and the optimisation levels are comparable (that is, -O2 on gcc 3.1 should compare with -O1 on an earlier release)
gcc's compilation speed can certainly be a problem for very large projects or even smaller projects on slower machines. Unfortunately, things have actually been getting worse for newer releases. Part of this is due to additional optimizations, but there are some genuine performance problems that the gcc developers would very much like to solve.
Now that this has become a major priority, I expect things to start improving in the not too distant future.
I wouldn't call it a fringe compiler, the only sense in which it's "fringe" is that it's only used on Linux. That said, gcc 3.1 is likely to be widely used and deployed, because it really is a lot better than gcc 2.9x, and because it addresses the primary obstruction to gcc 3.0 becoming a mainstream compiler -- bugs. In fact, I suspect that even gcc 3.0 is used by a number of developers for testing purposes. I have used it to test ISO compliance and "std::-cleanliness" of my code.
Red Hat is not linux.
That may be so, but it's also true that Redhat and Redhat based distributions make up a substantial portion of Linux users.