Article: MAQSIP-RT: An HPC Benchmark
By: Vincent Diepeveen (diep.delete@this.xs4all.nl), June 26, 2010 1:50 pm
Room: Moderated Discussions
? (0xe2.0x9a.0x9b@gmail.com) on 6/24/10 wrote:
---------------------------
>Rohit (@.) on 6/24/10 wrote:
>---------------------------
>>? (0xe2.0x9a.0x9b@gmail.com) on 6/24/10 wrote:
>>---------------------------
>>>Bottom line: Not counting the support for new C/C++ features, how exactly is GCC 4.5 better than GCC 3.4 ?
>>>
>>
>>SSE intrinsics and/or C++ templates improved a lot in 4.2
>
>OK, that is true, but I would put these two things into the bag "new language features".
>The question I asked is more in the line of: If you can compile a program both with
>GCC version X *and* without any changes with version Y, is there a difference between GCC-X and GCC-Y?
>
>Let me present some comparison from a project of mine, maybe that will persuade
>you that the "newer GCC is better than older GCC"-idea suffers from a placebo effect:
>
>Application type: C++ code with some template classes, no floating-point arithmetic, no STL
>
>Compilers: GCC 4.5.0, GCC 4.1.2
>
>Compilation options: identical in both cases
>
>Compilation time: GCC-4.5.0 took 4.4% longer than GCC-4.1.2
Compilation time is really not a big problem. Even the largest projects you can compile, be it with some tools, in parallel. The amount of people where compilation time of a C/C++ compiler is a crucial bottleneck is quite limited on this planet, with all respect, by accident a few of them post on this newsgroup.
>Performance of generated code: There do not seem to be any significant differences
>in performance (well, at least in the places where I am measuring performance).
>Most certainly, there is *nothing* which would support the conjecture that "4.5.0
>produces strictly faster code than 4.1.2".
You are completely correct here.
Besides some major bugfixes in GCC (i remember some important bugfixes that allowed my software to bugfree run parallel suddenly - so possibly in the 'volatile' keyword in C), its model of generating code is strictly seen the same spaghetti, which to say it in a black and white mode, basically SABOTAGES its possibilities for getting a big speedup out of profile guided optimizations.
If we compare the better commercial compilers with GCC it is obvious that the commercial compilers manage to use less instructions to get something done and this simply always wins in the battle for execution speed of the code.
Now it is true that in vectorisation towards SIMD a lot has happened, but that's not the main cause of GCC being a suck slow compiler.
SIMD optimizations are 'a bonus' if i may say so. The core logics of the GCC compiler producing code seems to have been the same always, even though i'm aware some big rewrites there have happened.
If we look to other compilers i'm also not really very impressed by the speed they manage to get out of todays processors, yet that's not the discussion; GCC simply is not even close to being on par to that 'default level' of a copmiler like visual c++ 2005.
Now this software program is over 5 years old. We're far into 2010 and it is beating handsdown GCC for simple integer code. Though simple, it's a lot of integer code, and GCC gets total annihilated there.
SIMD is not a big issue there.
It is the core logics of the produced code that is seemingly at a fundamental different conceptual level between GCC and the commercial compilers. I could be total wrong there, as i didn't really dive into the GCC codes.
Realize Compiler technology is not my core expertise, yet i have the impression i would be able to really speedup some parts of GCC there for a lot of software running on x64 type hardware, if i look at the total clumsy, seemingly sabotaged code that gets produced by GCC.
That basically tells me that the problem is not a lack in brilliancy, but the problem is a lot of beginners mistakes somewhere in the compilation proces.
>-----
>
>So, if I may ask: Do you happen to have a normal Linux application (C/C++ integer
>code) where you are sure you are seeing GCC-4.5 producing better code than GCC-4.1?
GCC 4.0 to 4.5 is same speed for my application. If we realize that in the meantime visual c++ in 2005 got a boost of say 22% or so by means of an added PGO stage, GCC is missing that boost simply.
Its PGO, for whatever reason, is total junk; and i say that polite.
Vincent
---------------------------
>Rohit (@.) on 6/24/10 wrote:
>---------------------------
>>? (0xe2.0x9a.0x9b@gmail.com) on 6/24/10 wrote:
>>---------------------------
>>>Bottom line: Not counting the support for new C/C++ features, how exactly is GCC 4.5 better than GCC 3.4 ?
>>>
>>
>>SSE intrinsics and/or C++ templates improved a lot in 4.2
>
>OK, that is true, but I would put these two things into the bag "new language features".
>The question I asked is more in the line of: If you can compile a program both with
>GCC version X *and* without any changes with version Y, is there a difference between GCC-X and GCC-Y?
>
>Let me present some comparison from a project of mine, maybe that will persuade
>you that the "newer GCC is better than older GCC"-idea suffers from a placebo effect:
>
>Application type: C++ code with some template classes, no floating-point arithmetic, no STL
>
>Compilers: GCC 4.5.0, GCC 4.1.2
>
>Compilation options: identical in both cases
>
>Compilation time: GCC-4.5.0 took 4.4% longer than GCC-4.1.2
Compilation time is really not a big problem. Even the largest projects you can compile, be it with some tools, in parallel. The amount of people where compilation time of a C/C++ compiler is a crucial bottleneck is quite limited on this planet, with all respect, by accident a few of them post on this newsgroup.
>Performance of generated code: There do not seem to be any significant differences
>in performance (well, at least in the places where I am measuring performance).
>Most certainly, there is *nothing* which would support the conjecture that "4.5.0
>produces strictly faster code than 4.1.2".
You are completely correct here.
Besides some major bugfixes in GCC (i remember some important bugfixes that allowed my software to bugfree run parallel suddenly - so possibly in the 'volatile' keyword in C), its model of generating code is strictly seen the same spaghetti, which to say it in a black and white mode, basically SABOTAGES its possibilities for getting a big speedup out of profile guided optimizations.
If we compare the better commercial compilers with GCC it is obvious that the commercial compilers manage to use less instructions to get something done and this simply always wins in the battle for execution speed of the code.
Now it is true that in vectorisation towards SIMD a lot has happened, but that's not the main cause of GCC being a suck slow compiler.
SIMD optimizations are 'a bonus' if i may say so. The core logics of the GCC compiler producing code seems to have been the same always, even though i'm aware some big rewrites there have happened.
If we look to other compilers i'm also not really very impressed by the speed they manage to get out of todays processors, yet that's not the discussion; GCC simply is not even close to being on par to that 'default level' of a copmiler like visual c++ 2005.
Now this software program is over 5 years old. We're far into 2010 and it is beating handsdown GCC for simple integer code. Though simple, it's a lot of integer code, and GCC gets total annihilated there.
SIMD is not a big issue there.
It is the core logics of the produced code that is seemingly at a fundamental different conceptual level between GCC and the commercial compilers. I could be total wrong there, as i didn't really dive into the GCC codes.
Realize Compiler technology is not my core expertise, yet i have the impression i would be able to really speedup some parts of GCC there for a lot of software running on x64 type hardware, if i look at the total clumsy, seemingly sabotaged code that gets produced by GCC.
That basically tells me that the problem is not a lack in brilliancy, but the problem is a lot of beginners mistakes somewhere in the compilation proces.
>-----
>
>So, if I may ask: Do you happen to have a normal Linux application (C/C++ integer
>code) where you are sure you are seeing GCC-4.5 producing better code than GCC-4.1?
GCC 4.0 to 4.5 is same speed for my application. If we realize that in the meantime visual c++ in 2005 got a boost of say 22% or so by means of an added PGO stage, GCC is missing that boost simply.
Its PGO, for whatever reason, is total junk; and i say that polite.
Vincent
Topic | Posted By | Date |
---|---|---|
New article online: MAQSIP RT | David Kanter | 2010/06/21 10:57 AM |
Why no GCC? | Rohit | 2010/06/22 08:25 PM |
Why no GCC? | David Kanter | 2010/06/22 11:45 PM |
sun 's cc better than GCC? | Rohit | 2010/06/23 04:04 AM |
sun 's cc better than GCC? | anon | 2010/06/23 06:49 AM |
Where is the GCC optimization effort directed? | Mark Roulo | 2010/06/23 09:42 AM |
GCC is very ugly bad everywhere in 64 bits | Vincent Diepeveen | 2010/06/23 01:49 PM |
even for 64-bit arch? | anon | 2010/06/23 01:59 PM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/23 10:03 PM |
GCC is very ugly bad everywhere in 64 bits | Gabriele Svelto | 2010/06/24 01:33 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 04:32 AM |
GCC is very ugly bad everywhere in 64 bits | Gabriele Svelto | 2010/06/24 06:18 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 08:50 AM |
Why GCC is big and complicated (my guess) | Mark Roulo | 2010/06/24 11:17 AM |
Why GCC is big and complicated (my guess) | Gabriele Svelto | 2010/06/28 03:00 AM |
GCC is very ugly bad everywhere in 64 bits | Bernd Schmidt | 2010/06/24 04:46 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 08:43 AM |
GCC is very ugly bad everywhere in 64 bits | Vincent Diepeveen | 2010/06/26 01:12 PM |
GCC is very ugly bad everywhere in 64 bits | Rob Thorpe | 2010/06/24 06:47 AM |
GCC is very ugly bad everywhere in 64 bits | Anon | 2010/06/24 04:23 PM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/23 09:45 PM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 12:48 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 01:29 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 02:13 AM |
Where is the GCC optimization effort directed? | Andi Kleen | 2010/06/24 02:15 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 03:08 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 02:54 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 03:15 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 06:22 AM |
Where is the GCC optimization effort directed? | Rohit | 2010/06/24 02:04 AM |
Placebo effect | ? | 2010/06/24 05:37 AM |
Placebo effect | Rohit | 2010/06/24 07:45 AM |
Placebo effect | Vincent Diepeveen | 2010/06/26 01:50 PM |
Compile time | Mark Roulo | 2010/06/26 04:28 PM |
Compile time | Richard Cownie | 2010/06/27 03:44 AM |
Compile time | Mark Roulo | 2010/06/27 09:12 AM |
Compile time | Mark Roulo | 2010/06/27 09:21 AM |
Compile time | EduardoS | 2010/06/27 10:37 AM |
Compile time | Richard Cownie | 2010/06/27 03:07 PM |
Compile time & efficiency | ? | 2010/06/27 11:03 PM |
Compile time & efficiency | Mark Christiansen | 2010/06/28 05:08 AM |
Compile time & efficiency | Linus Torvalds | 2010/06/28 06:48 AM |
kernel programming language | John Simon | 2010/06/29 05:46 PM |
Compile time & efficiency | Richard Cownie | 2010/06/28 08:29 AM |
Compile time & efficiency | Linus Torvalds | 2010/06/28 10:17 AM |
Compile time & efficiency | Richard Cownie | 2010/06/28 01:16 PM |
Compile time & efficiency | Richard Cownie | 2010/06/28 05:23 PM |
Compile time & efficiency | Mark Roulo | 2010/06/29 07:31 AM |
Compile time & efficiency | Richard Cownie | 2010/06/29 10:48 AM |
Compile time & efficiency | rwessel | 2010/06/29 11:28 AM |
C is a crappy | dev | 2010/06/29 06:12 PM |
C is a crappy, but only when you push it out of it's niche | Rohit | 2010/06/30 01:11 AM |
C is a crappy | anon | 2010/06/30 01:17 AM |
C is a crappy | dev | 2010/06/30 06:59 AM |
C is a crappy | Max | 2010/07/01 03:30 AM |
C is a crappy | Michael S | 2010/07/01 06:00 AM |
C is a crappy | Konrad Schwarz | 2010/07/01 07:02 AM |
C is a crappy | Michael S | 2010/07/01 07:50 AM |
C isn't so crappy | anon | 2010/07/01 09:11 AM |
C isn't so crappy | Mikael Tillenius | 2010/07/01 10:39 AM |
C is a crappy | Konrad Schwarz | 2010/07/01 10:22 AM |
C is a crappy | Max | 2010/07/02 07:44 AM |
C is a crappy | rwessel | 2010/07/02 11:33 AM |
C is a crappy | anon | 2010/07/02 12:17 PM |
C is a crappy | Max | 2010/07/02 01:56 PM |
C is a crappy | Max | 2010/07/02 02:13 PM |
C is a crappy | rwessel | 2010/07/02 02:32 PM |
C is a crappy | Max | 2010/07/02 03:19 PM |
C is a crappy | Gabriele Svelto | 2010/07/05 04:25 AM |
C is a crappy | gallier2 | 2010/07/01 11:14 PM |
C is a crappy | Ian Ollmann | 2010/07/06 02:07 PM |
Portability | Max | 2010/07/06 02:37 PM |
C is a crappy | hobold | 2010/07/07 01:31 AM |
C is a crappy | Ian Ollmann | 2010/07/07 04:18 PM |
failure to standardize types | Carlie Coats | 2010/07/07 03:11 AM |
C is a crappy | Konrad Schwarz | 2010/07/07 07:34 AM |
C is a crappy | Ian Ollmann | 2010/07/07 04:29 PM |
C is a crappy NOT | Konrad Schwarz | 2010/07/07 11:29 PM |
C is a crappy | anon | 2010/07/01 09:40 PM |
C type safety | ? | 2010/07/02 12:10 AM |
C type safety | anon | 2010/07/02 10:02 PM |
C is a crappy | dev | 2010/07/03 03:51 PM |
C is a crappy | anon | 2010/07/03 06:02 PM |
C is a crappy | dev | 2010/07/05 06:27 AM |
C is a crappy | ? | 2010/07/05 08:05 AM |
C is a crappy | anonymous | 2010/07/07 07:32 AM |
C is a crappy | ? | 2010/07/07 09:48 PM |
C is a crappy | Anon | 2010/07/07 11:53 PM |
C is a crappy and a crappie is a fish | anonymous | 2010/07/03 06:24 PM |
Compile time & efficiency | Michael S | 2010/06/29 02:18 AM |
Compile time & efficiency | rwessel | 2010/06/29 11:20 AM |
Compile time & efficiency | someone | 2010/06/30 10:03 AM |
Compile time & efficiency | Jouni Osmala | 2010/07/02 04:29 AM |
Compile time & efficiency | Max | 2010/06/28 04:05 PM |
Compile time & efficiency | EduardoS | 2010/06/28 04:11 PM |
Compile time & efficiency | Michael S | 2010/06/29 02:33 AM |
Compile time | Foo_ | 2010/06/28 08:03 AM |
sun 's cc better than GCC? | Silent | 2010/06/23 05:19 PM |
sun 's cc better than GCC? | Foo_ | 2010/06/23 06:06 PM |
sun 's cc better than GCC? | Andi Kleen | 2010/06/24 01:49 AM |
sun 's versus gcc | Vincent Diepeveen | 2010/06/23 02:07 PM |
Why no GCC? | Carlie Coats | 2010/06/23 04:11 AM |