Article: MAQSIP-RT: An HPC Benchmark
By: rwessel (robertwessel.delete@this.yahoo.com), June 29, 2010 11:28 am
Room: Moderated Discussions
Mark Roulo (nothanks@xxx.com) on 6/29/10 wrote:
---------------------------
>Richard Cownie (tich@pobox.com) on 6/28/10 wrote:
>---------------------------
>>Second, there's a trade-off to be made between the effort
>>put into making builds go fast, and the total time spent
>>by all developers waiting for slow builds. If you're
>>planning to have hundreds or even thousands of developers,
>>as for the Linux kernel, then it's good to spend a lot of
>>effort making builds go fast (and use compute resources
>>efficiently); if you have 20-50 developers, then it may
>>make more sense to spend $20K on a compile farm rather
>>than say 2 man-years on making single-machine builds go
>>fast. Horses for courses.
>>
>
>Yes.
>
>Another way to look at this, though, is that the compiler developers (ICC, GCC,
>MSVC++) should be willing to spend *their* developer resources ensuring that their
>tools run quickly. After all, their user base is 10s of thousands, if not 100s of thousands.
>
>Kinda the same logic by which we expect/hope that the OS kernel is very parsimonious with RAM and clock cycles.
Actually I want the tool chain developers spending their time making *me* more productive. They need to focus on compiler performance to the extent that faster compiles help my productivity.
FWIW, the thing that's generated the biggest increase in build time for me in the last few years is link time code generation. It not only reduces the incremental nature of most builds (the compiler ends up doing most of the hard work when building the executable, and then having to do *all* of that work each time anything in the executable is touched), it also reduces the scope for parallelism in the build process.
---------------------------
>Richard Cownie (tich@pobox.com) on 6/28/10 wrote:
>---------------------------
>>Second, there's a trade-off to be made between the effort
>>put into making builds go fast, and the total time spent
>>by all developers waiting for slow builds. If you're
>>planning to have hundreds or even thousands of developers,
>>as for the Linux kernel, then it's good to spend a lot of
>>effort making builds go fast (and use compute resources
>>efficiently); if you have 20-50 developers, then it may
>>make more sense to spend $20K on a compile farm rather
>>than say 2 man-years on making single-machine builds go
>>fast. Horses for courses.
>>
>
>Yes.
>
>Another way to look at this, though, is that the compiler developers (ICC, GCC,
>MSVC++) should be willing to spend *their* developer resources ensuring that their
>tools run quickly. After all, their user base is 10s of thousands, if not 100s of thousands.
>
>Kinda the same logic by which we expect/hope that the OS kernel is very parsimonious with RAM and clock cycles.
Actually I want the tool chain developers spending their time making *me* more productive. They need to focus on compiler performance to the extent that faster compiles help my productivity.
FWIW, the thing that's generated the biggest increase in build time for me in the last few years is link time code generation. It not only reduces the incremental nature of most builds (the compiler ends up doing most of the hard work when building the executable, and then having to do *all* of that work each time anything in the executable is touched), it also reduces the scope for parallelism in the build process.
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 |