gcc -pipe

[Kinkie]

Hi all,
  is there any reason anyone of you can see NOT to use "-pipe" as a
standard option every time we build using gcc? It would give us
instantly a better parallelization when running on multicore systems,
and as far as I know this option has been stable and in wide use for a
number of years and gcc/g++ releases..


--
    /kinkie

[Henrik Nordstrom-5]

ons 2009-10-28 klockan 15:52 +0100 skrev Kinkie:

>   is there any reason anyone of you can see NOT to use "-pipe" as a
> standard option every time we build using gcc? It would give us
> instantly a better parallelization when running on multicore systems,
> and as far as I know this option has been stable and in wide use for a
> number of years and gcc/g++ releases..

Well, I always build with -j4 or so..

No opinion either way.

Documentations for -pipe says however that "This fails to work on some
systems where the assembler is unable to read from a pipe; but the GNU
assembler has no trouble."

Regards
Henrik

[Kinkie]

On Wed, Oct 28, 2009 at 6:01 PM, Henrik Nordstrom
<henrik@...> wrote:

> ons 2009-10-28 klockan 15:52 +0100 skrev Kinkie:
>
>>   is there any reason anyone of you can see NOT to use "-pipe" as a
>> standard option every time we build using gcc? It would give us
>> instantly a better parallelization when running on multicore systems,
>> and as far as I know this option has been stable and in wide use for a
>> number of years and gcc/g++ releases..
>
> Well, I always build with -j4 or so..
>
> No opinion either way.
>
> Documentations for -pipe says however that "This fails to work on some
> systems where the assembler is unable to read from a pipe; but the GNU
> assembler has no trouble."

We can try and add an explicit configure check if needed (I'd have
liked to avoid it, but we can probably just copy/paste).
-jsomething is IMO slightly more confusing when troubleshooting a
build as the output lines may get intermixed. -pipe doesn't suffer
from this.


--
    /kinkie

[Henrik Nordstrom-5]

ons 2009-10-28 klockan 18:09 +0100 skrev Kinkie:

> We can try and add an explicit configure check if needed (I'd have
> liked to avoid it, but we can probably just copy/paste).
> -jsomething is IMO slightly more confusing when troubleshooting a
> build as the output lines may get intermixed. -pipe doesn't suffer
> from this.

Well, -pipe alone can't saturate any cpu with more than 2 threads.
Probably not even 1 for that matter..

and if I get a build problem then I run make without -j to get a better
error report if the first result is not obvious.

Regards
Henrik

[Kinkie]

On Wed, Oct 28, 2009 at 8:19 PM, Henrik Nordstrom
<henrik@...> wrote:

> ons 2009-10-28 klockan 18:09 +0100 skrev Kinkie:
>
>> We can try and add an explicit configure check if needed (I'd have
>> liked to avoid it, but we can probably just copy/paste).
>> -jsomething is IMO slightly more confusing when troubleshooting a
>> build as the output lines may get intermixed. -pipe doesn't suffer
>> from this.
>
> Well, -pipe alone can't saturate any cpu with more than 2 threads.
> Probably not even 1 for that matter..
>
> and if I get a build problem then I run make without -j to get a better
> error report if the first result is not obvious.

trunk revno 10075 contains a configure test for gcc/g++ -pipe,
enabling it if it's found working.
Performance gain is probably not much, but it won't hurt either :)

It can probably be easily backported to 3.1 too.

--
    /kinkie

[Henrik Nordstrom-5]

tis 2009-11-03 klockan 14:59 +0100 skrev Kinkie:

> Performance gain is probably not much, but it won't hurt either :)

Some says it hurts, but that's probably in low-memory conditions.

Regards
Henrik

[Kinkie]

Let's see the effects on the farm builds :) rolling back is easy if it
doesn't help

On 11/3/09, Henrik Nordstrom <henrik@...> wrote:

> tis 2009-11-03 klockan 14:59 +0100 skrev Kinkie:
>
>> Performance gain is probably not much, but it won't hurt either :)
>
> Some says it hurts, but that's probably in low-memory conditions.
>
> Regards
> Henrik
>
>

--
    /kinkie