Article: MAQSIP-RT: An HPC Benchmark
By: anon (a.delete@this.b.c), July 2, 2010 12:17 pm
Room: Moderated Discussions
rwessel (robertwessel@yahoo.com) on 7/2/10 wrote:
---------------------------
>Max (max@a.com) on 7/2/10 wrote:
>---------------------------
>>Michael S (already5chosen@yahoo.com) on 7/1/10 wrote:
>>---------------------------
>>>I don't think so. AFAIK, the following code is not legal in standard C90.
>>>
>>>int foo(int x)
>>>{
>>>x += 1;
>>>int y = 10 * x;
>>>y += 1;
>>>return y;
>>>}
>>
>>But this is...
>>
>>int foo(int x)
>>{
>>x += 1;
>>{
>>int y = 10 * x;
>>y += 1;
>>return y;
>>}
>>}
>>
>>A pet peeve of mine is that functions are external by default. So you have to declare
>>almost all functions as "static", and if somebody is too lazy to do that you end
>>up with global pollution and worse code (some compiler optimizations can't be done with external functions).
>
>
>IMO, that's not the solution either, although it would help. The problem is that
>static functions only help if you have fairly large source modules. If you try
>to keep source modules fairly small, you tend to need many routines to have external linkage anyway.
>
>A different grouping/namespace mechanism, one that's *not* related to the source
>files, is what's actually required, and the packaging of functions (methods) inside
>of classes in C++ deals with that quite well.
>
>In any event, LTCG is the solution to the optimization issue.
C++ has its own namespace mechanism, orthogonal to OOP/classes, that could be useful in C as well.
---------------------------
>Max (max@a.com) on 7/2/10 wrote:
>---------------------------
>>Michael S (already5chosen@yahoo.com) on 7/1/10 wrote:
>>---------------------------
>>>I don't think so. AFAIK, the following code is not legal in standard C90.
>>>
>>>int foo(int x)
>>>{
>>>x += 1;
>>>int y = 10 * x;
>>>y += 1;
>>>return y;
>>>}
>>
>>But this is...
>>
>>int foo(int x)
>>{
>>x += 1;
>>{
>>int y = 10 * x;
>>y += 1;
>>return y;
>>}
>>}
>>
>>A pet peeve of mine is that functions are external by default. So you have to declare
>>almost all functions as "static", and if somebody is too lazy to do that you end
>>up with global pollution and worse code (some compiler optimizations can't be done with external functions).
>
>
>IMO, that's not the solution either, although it would help. The problem is that
>static functions only help if you have fairly large source modules. If you try
>to keep source modules fairly small, you tend to need many routines to have external linkage anyway.
>
>A different grouping/namespace mechanism, one that's *not* related to the source
>files, is what's actually required, and the packaging of functions (methods) inside
>of classes in C++ deals with that quite well.
>
>In any event, LTCG is the solution to the optimization issue.
C++ has its own namespace mechanism, orthogonal to OOP/classes, that could be useful in C as well.
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 |