Article: MAQSIP-RT: An HPC Benchmark
By: Mark Roulo (nothanks.delete@this.xxx.com), June 24, 2010 11:17 am
Room: Moderated Discussions
ajensen (@.) on 6/24/10 wrote:
---------------------------
>Gabriele Svelto (gabriele.svelto@gmail.com) on 6/24/10 wrote:
>What's wrong with it?
>
>Well as far as I can gather, the problem is not the feature richness, but the monolithic
>architecture. A large project buildt more modular would be easier to maintain and
>move forward as some parts gets outdated and new ones are added. Am I wrong? Its
>not like I'm trying to force feed this into capabilities like mr. Schmidt here,
>but I'd really like to know why it is often seen as convoluted and unmaintainable.
I suspect that one of the issues making GCC larger/more-complicated/harder-to-maintain is that the architectures that it supports are much more varied (weirder) as a group than any one is individually. The compiler internals have to handle the collective strangeness.
A few examples:
*) Some of the older RISC architectures (I'm thinking SPARC) have these things called "branch delay slots." If GCC wants to support SPARC, then some parts of GCC need to be aware of this concept. My guess is that this concept impacts internal data structures over large parts of GCC and code that needs to deal with this concept is also all over GCC. The concept of "branch delay slot" isn't (and can't be) neatly encapsulated in a small, modular part of GCC.
*) Itanium EPIC is substantially odder than many of the RISC architectures we had in the 1990s and 2000s (explicit instruction bundles that *logically* execute together, predication [yes, ARM has this to a degree]). Again, as with "branch delay slots", these oddities probably spread throughout GCC.
*) Unless you want a totally different instruction scheduler for each target architecture (and maybe you do ... maybe this is what GCC already does?), then you need some sort of super-set of all the constraints one can have when building instruction sequences (the branch-delay-slot is one example of this sort of constraint). The super-set is going to be more complicated than any one constraint set.
The only obvious way to simplify things is to either:
a) Cut down on the architectures supported, not because of number but because of differences, or
b) Maybe (but I doubt it), totally re-architect the whole thing with the idea that we have a better idea of the range of capabilities/limitations and can do a better job designing the internals with this knowledge (my opinion is that this approach won't work).
-Mark Roulo
---------------------------
>Gabriele Svelto (gabriele.svelto@gmail.com) on 6/24/10 wrote:
>What's wrong with it?
>
>Well as far as I can gather, the problem is not the feature richness, but the monolithic
>architecture. A large project buildt more modular would be easier to maintain and
>move forward as some parts gets outdated and new ones are added. Am I wrong? Its
>not like I'm trying to force feed this into capabilities like mr. Schmidt here,
>but I'd really like to know why it is often seen as convoluted and unmaintainable.
I suspect that one of the issues making GCC larger/more-complicated/harder-to-maintain is that the architectures that it supports are much more varied (weirder) as a group than any one is individually. The compiler internals have to handle the collective strangeness.
A few examples:
*) Some of the older RISC architectures (I'm thinking SPARC) have these things called "branch delay slots." If GCC wants to support SPARC, then some parts of GCC need to be aware of this concept. My guess is that this concept impacts internal data structures over large parts of GCC and code that needs to deal with this concept is also all over GCC. The concept of "branch delay slot" isn't (and can't be) neatly encapsulated in a small, modular part of GCC.
*) Itanium EPIC is substantially odder than many of the RISC architectures we had in the 1990s and 2000s (explicit instruction bundles that *logically* execute together, predication [yes, ARM has this to a degree]). Again, as with "branch delay slots", these oddities probably spread throughout GCC.
*) Unless you want a totally different instruction scheduler for each target architecture (and maybe you do ... maybe this is what GCC already does?), then you need some sort of super-set of all the constraints one can have when building instruction sequences (the branch-delay-slot is one example of this sort of constraint). The super-set is going to be more complicated than any one constraint set.
The only obvious way to simplify things is to either:
a) Cut down on the architectures supported, not because of number but because of differences, or
b) Maybe (but I doubt it), totally re-architect the whole thing with the idea that we have a better idea of the range of capabilities/limitations and can do a better job designing the internals with this knowledge (my opinion is that this approach won't work).
-Mark Roulo
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 |