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."
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?
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)
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)
It's not true that 2.9x is the only compiler that compiles the kernel. gcc 3.0 and 3.1 also can, indeed kernel compilation was part of the release criteria (maybe you're mixing it up with "2.96" ?) Comparisons would be nice, but FYI, 2.95 is not going to be any faster than gcc 3.0. (and probably slower)
Why only benchmark fringe compilers, when a vast majority of Linux users will be rocking the older compiler?
gcc 3.1 is not a fringe compiler. You are going to see it in the next Redhat release (as well as the distributions that follow Redhat)
it amazes me, the excuses some people come up with.
Why don't you check the glibc drand48 source code. Not that it would matter - icc doesn't include a libc, so the same glibc function is being used by both.
Fascinating, except that icc uses glibc on Linux. :P
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.