Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Michael Mol]

On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info> wrote:

> Won't file a bug report, though. I have a feeling that my bug report re:
> emerge failure will be marked WONTFIX thanks to the 'ricer special' CFLAGS

The CFLAGS you showed me weren't any more ricer than "-O2
-march=native". (I didn't know that -D_FORTIFY=2 came from gcc)

They wouldn't have a leg to stand on...

-- 
:wq

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> > Won't file a bug report, though. I have a feeling that my bug report re:
> > emerge failure will be marked WONTFIX thanks to the 'ricer special'
CFLAGS
>
> The CFLAGS you showed me weren't any more ricer than "-O2
> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>
> They wouldn't have a leg to stand on...
>

Mine is:

CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
-floop-strip-mine -floop-block -funsafe-math-optimizations
-fexcess-precision=fast"

If you tell me that's not a ricer's CFLAGS, then you've just made me a very
happy cat :-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 1016 bytes --]

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Mark Knecht]

On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>>
>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info> wrote:
>>
>> > Won't file a bug report, though. I have a feeling that my bug report re:
>> > emerge failure will be marked WONTFIX thanks to the 'ricer special'
>> > CFLAGS
>>
>> The CFLAGS you showed me weren't any more ricer than "-O2
>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>>
>> They wouldn't have a leg to stand on...
>>
>
> Mine is:
>
> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
> -floop-strip-mine -floop-block -funsafe-math-optimizations
> -fexcess-precision=fast"
>
> If you tell me that's not a ricer's CFLAGS, then you've just made me a very
> happy cat :-)
>
> Rgds,
>

I wonder if someone in this thread will help me understand the term
'ricer'. The only origin I know of this term, from the car world, is
really pretty racist, so I wonder if there isn't a more genteel origin
I simply cannot find using Google?

- Mark

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[James Wall]

On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan <pandu@poluan.info> wrote:
>>
>> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>>>
>>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info> wrote:
>>>
>>> > Won't file a bug report, though. I have a feeling that my bug report re:
>>> > emerge failure will be marked WONTFIX thanks to the 'ricer special'
>>> > CFLAGS
>>>
>>> The CFLAGS you showed me weren't any more ricer than "-O2
>>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>>>
>>> They wouldn't have a leg to stand on...
>>>
>>
>> Mine is:
>>
>> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
>> -floop-strip-mine -floop-block -funsafe-math-optimizations
>> -fexcess-precision=fast"
>>
>> If you tell me that's not a ricer's CFLAGS, then you've just made me a very
>> happy cat :-)
>>
>> Rgds,
>>
>
> I wonder if someone in this thread will help me understand the term
> 'ricer'. The only origin I know of this term, from the car world, is
> really pretty racist, so I wonder if there isn't a more genteel origin
> I simply cannot find using Google?
>
> - Mark
>
>

Ricer is used to refer to someone who wants to have the system tweaked
to the hardware it runs on that it is not like the generic binary
distros like ubuntu that is compiled for the lowest common denominator
like i386 or x86_64.
hope this helps clarify the term,
James Wall

-- 
No trees were harmed in the sending of this message. However, a large
number of electrons were terribly inconvenienced.

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Paul Hartman]

On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht <markknecht@gmail.com> wrote:
> I wonder if someone in this thread will help me understand the term
> 'ricer'. The only origin I know of this term, from the car world, is
> really pretty racist, so I wonder if there isn't a more genteel origin
> I simply cannot find using Google?

No, I think it's the same racist term borrowed from the car
tuning/customizing world.

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Stefan G. Weichinger]

Am 28.11.2011 17:54, schrieb Mark Knecht:

> I wonder if someone in this thread will help me understand the term
> 'ricer'. The only origin I know of this term, from the car world, is
> really pretty racist, so I wonder if there isn't a more genteel origin
> I simply cannot find using Google?

Maybe this helps:

http://funroll-loops.info/

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Michael Mol]

On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@poluan.info> wrote:
> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info> wrote:
>> > Won't file a bug report, though. I have a feeling that my bug report re:
>> > emerge failure will be marked WONTFIX thanks to the 'ricer special'
>> > CFLAGS
>>
>> The CFLAGS you showed me weren't any more ricer than "-O2
>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>>
>> They wouldn't have a leg to stand on...
>>
>
> Mine is:
>
> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
> -floop-strip-mine -floop-block -funsafe-math-optimizations
> -fexcess-precision=fast"
>
> If you tell me that's not a ricer's CFLAGS, then you've just made me a very
> happy cat :-)

No, you've got some ugly flags in there. -fexcess-precision and
-funsafe-math-optimizations, in particular. (I must have been talking
to someone else last week; sorry, I'm terrible with names.)

-fomit-frame-pointer shouldn't cause any headaches unless you're
feeding a gdb stack trace, and you're not adding any debugging data,
so your stack traces would be pretty useless, anyway.

I don't know about -floop-interchange, -floop-strip-mine or
-floop-block. I recognize at least one of them from the discussion of
graphite the other day.

However, if you get a *build-time* error that isn't, e.g. a tool
crashing, then there's not *much* reason to doubt the bug report,
IMHO.

-- 
:wq

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[kashani]

On 11/28/2011 9:28 AM, James Wall wrote:
>> I wonder if someone in this thread will help me understand the term
>> 'ricer'. The only origin I know of this term, from the car world, is
>> really pretty racist, so I wonder if there isn't a more genteel origin
>> I simply cannot find using Google?
>>
>> - Mark
>
> Ricer is used to refer to someone who wants to have the system tweaked
> to the hardware it runs on that it is not like the generic binary
> distros like ubuntu that is compiled for the lowest common denominator
> like i386 or x86_64.
> hope this helps clarify the term,
> James Wall
>

	You're missing some history. First Mark is correct that the origin is 
from the derogatory term in the car world, ricer. While the term 
continues to be a derogatory term the racial part of it is generally 
ignored in the computer world because there isn't a made in the US vs 
Japan rivalry. Ricer continues to mean "spending inordinate amount of 
time and money for performance modifications that generally do very 
little for performance and a lot to reduce reliability while poorly 
understanding the system as a whole." At least that's my interpretation 
of the definition.

kashani

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Michael Mol]

On Mon, Nov 28, 2011 at 12:43 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> I wonder if someone in this thread will help me understand the term
>> 'ricer'. The only origin I know of this term, from the car world, is
>> really pretty racist, so I wonder if there isn't a more genteel origin
>> I simply cannot find using Google?
>
> No, I think it's the same racist term borrowed from the car
> tuning/customizing world.

It was explained to me as coming from Western fans of Japanese sports
cars. In particular, the subset of those who would see or slap a brand
sticker on a vehicle and assume it meant it'd go faster. Reminds me of
the time I saw "F150" roughly painted on the side of a dilapidated old
truck.

The implication wrt Gentoo was that people would apply CFLAGS across
their entire system without an actual understanding of their impact or
what they did, under the assumption that it would make their computers
go faster. A more recent way of describing this behavior is "cargo
culting", and I've seen it in largely in discussions of economics and
pseudo-science.

-- 
:wq

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Mark Knecht]

On Mon, Nov 28, 2011 at 10:00 AM, kashani <kashani-list@badapple.net> wrote:
> On 11/28/2011 9:28 AM, James Wall wrote:
>>>
>>> I wonder if someone in this thread will help me understand the term
>>> 'ricer'. The only origin I know of this term, from the car world, is
>>> really pretty racist, so I wonder if there isn't a more genteel origin
>>> I simply cannot find using Google?
>>>
>>> - Mark
>>
>> Ricer is used to refer to someone who wants to have the system tweaked
>> to the hardware it runs on that it is not like the generic binary
>> distros like ubuntu that is compiled for the lowest common denominator
>> like i386 or x86_64.
>> hope this helps clarify the term,
>> James Wall
>>
>
>        You're missing some history. First Mark is correct that the origin is
> from the derogatory term in the car world, ricer. While the term continues
> to be a derogatory term the racial part of it is generally ignored in the
> computer world because there isn't a made in the US vs Japan rivalry. Ricer
> continues to mean "spending inordinate amount of time and money for
> performance modifications that generally do very little for performance and
> a lot to reduce reliability while poorly understanding the system as a
> whole." At least that's my interpretation of the definition.
>
> kashani
>
>

Thanks kashani & others that help fill in the picture. I really like
your wording above, and to be clear, I wasn't offended but more
curious about why it gets used so freely here when in other venues
maybe not so much.

Thanks and out,
Mark

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Alan McKinnon]

On Mon, 28 Nov 2011 08:54:13 -0800
Mark Knecht <markknecht@gmail.com> wrote:

> On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan <pandu@poluan.info>
> wrote:
> >
> > On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> >>
> >> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info>
> >> wrote:
> >>
> >> > Won't file a bug report, though. I have a feeling that my bug
> >> > report re: emerge failure will be marked WONTFIX thanks to the
> >> > 'ricer special' CFLAGS
> >>
> >> The CFLAGS you showed me weren't any more ricer than "-O2
> >> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
> >>
> >> They wouldn't have a leg to stand on...
> >>
> >
> > Mine is:
> >
> > CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
> > -floop-strip-mine -floop-block -funsafe-math-optimizations
> > -fexcess-precision=fast"
> >
> > If you tell me that's not a ricer's CFLAGS, then you've just made
> > me a very happy cat :-)
> >
> > Rgds,
> >
> 
> I wonder if someone in this thread will help me understand the term
> 'ricer'. The only origin I know of this term, from the car world, is
> really pretty racist, so I wonder if there isn't a more genteel origin
> I simply cannot find using Google?



Japanese youngsters doing bizarre mods to cars that produce absolutely
no net gain are indeed the source of the term "ricer".

Yes, it is rude and disparaging but it's also the real root of the
term. There's no need to politically correct it, the origin is what it
is.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

Am 28.11.2011 18:56, schrieb Michael Mol:
> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@poluan.info> wrote:
>> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info> wrote:
>>>> Won't file a bug report, though. I have a feeling that my bug report re:
>>>> emerge failure will be marked WONTFIX thanks to the 'ricer special'
>>>> CFLAGS
>>>
>>> The CFLAGS you showed me weren't any more ricer than "-O2
>>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>>>
>>> They wouldn't have a leg to stand on...
>>>
>>
>> Mine is:
>>
>> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
>> -floop-strip-mine -floop-block -funsafe-math-optimizations
>> -fexcess-precision=fast"
>>
>> If you tell me that's not a ricer's CFLAGS, then you've just made me a very
>> happy cat :-)
> 
> No, you've got some ugly flags in there. -fexcess-precision and
> -funsafe-math-optimizations, in particular. (I must have been talking
> to someone else last week; sorry, I'm terrible with names.)
> 

I doubt -fexcess-precision=fast does anything at all. Pandu uses an
AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
does not have excess precision issues (that's just for the old x87 FPU).
Even if you used that, is redundant because of your other flags. To
quote `man gcc`:
"-fexcess-precision=standard is not implemented for languages other than
C, and has no effect if -funsafe-math-optimizations or -ffast-math is
specified." <-- Therefore you always have ..=fast anyway.

-funsafe-math-optimizations is really terrible. Either you us floating
point arithmetic, then you have to rely on it because it is hard enough
already to gain necessary precision with it, or you don't, then you
don't need that flag because it doesn't improve performance.

> -fomit-frame-pointer shouldn't cause any headaches unless you're
> feeding a gdb stack trace, and you're not adding any debugging data,
> so your stack traces would be pretty useless, anyway.
> 

If you are on an AMD64 system, this flag is implied because it doesn't
affect stack traces on x86_64 anymore.

> I don't know about -floop-interchange, -floop-strip-mine or
> -floop-block. I recognize at least one of them from the discussion of
> graphite the other day.
> 

These definitely need graphite to have any effect. Then they should be
reasonably safe (as far as anything relying on experimental compiler
frameworks can be considered safe).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Michael Mol]

On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 28.11.2011 18:56, schrieb Michael Mol:
>> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@poluan.info> wrote:
>> No, you've got some ugly flags in there. -fexcess-precision and
>> -funsafe-math-optimizations, in particular. (I must have been talking
>> to someone else last week; sorry, I'm terrible with names.)
>>
>
> I doubt -fexcess-precision=fast does anything at all. Pandu uses an
> AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
> does not have excess precision issues (that's just for the old x87 FPU).
> Even if you used that, is redundant because of your other flags. To
> quote `man gcc`:
> "-fexcess-precision=standard is not implemented for languages other than
> C, and has no effect if -funsafe-math-optimizations or -ffast-math is
> specified." <-- Therefore you always have ..=fast anyway.
>
> -funsafe-math-optimizations is really terrible. Either you us floating
> point arithmetic, then you have to rely on it because it is hard enough
> already to gain necessary precision with it, or you don't, then you
> don't need that flag because it doesn't improve performance.

I didn't know (or forgot) what arch he was using.

>> -fomit-frame-pointer shouldn't cause any headaches unless you're
>> feeding a gdb stack trace, and you're not adding any debugging data,
>> so your stack traces would be pretty useless, anyway.
>>
>
> If you are on an AMD64 system, this flag is implied because it doesn't
> affect stack traces on x86_64 anymore.

AMD64 puts the requisite data in its own register, right?

Yeah, it sounds like Pandu's setup CFLAGS can use some cleanup.

>> I don't know about -floop-interchange, -floop-strip-mine or
>> -floop-block. I recognize at least one of them from the discussion of
>> graphite the other day.
>>
>
> These definitely need graphite to have any effect. Then they should be
> reasonably safe (as far as anything relying on experimental compiler
> frameworks can be considered safe).

Upstream devs might take issue with them, but I'm still not sure they
should affect bug reports of build-time failures. I would *hope*
upstream gcc is doing tests on its own build tools compiled with its
graphite optimizations. I don't know about make and autotools, though.

-- 
:wq

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]

On Nov 29, 2011 2:02 AM, "Florian Philipp" <lists@binarywings.net> wrote:
>
> Am 28.11.2011 18:56, schrieb Michael Mol:
> > On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@poluan.info>
wrote:
> >> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info>
wrote:
> >>>> Won't file a bug report, though. I have a feeling that my bug report
re:
> >>>> emerge failure will be marked WONTFIX thanks to the 'ricer special'
> >>>> CFLAGS
> >>>
> >>> The CFLAGS you showed me weren't any more ricer than "-O2
> >>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
> >>>
> >>> They wouldn't have a leg to stand on...
> >>>
> >>
> >> Mine is:
> >>
> >> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
> >> -floop-strip-mine -floop-block -funsafe-math-optimizations
> >> -fexcess-precision=fast"
> >>
> >> If you tell me that's not a ricer's CFLAGS, then you've just made me a
very
> >> happy cat :-)
> >
> > No, you've got some ugly flags in there. -fexcess-precision and
> > -funsafe-math-optimizations, in particular. (I must have been talking
> > to someone else last week; sorry, I'm terrible with names.)
> >
>
> I doubt -fexcess-precision=fast does anything at all. Pandu uses an
> AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
> does not have excess precision issues (that's just for the old x87 FPU).

I use Intel boxes, unfortunately.

> Even if you used that, is redundant because of your other flags. To
> quote `man gcc`:
> "-fexcess-precision=standard is not implemented for languages other than
> C, and has no effect if -funsafe-math-optimizations or -ffast-math is
> specified." <-- Therefore you always have ..=fast anyway.
>
> -funsafe-math-optimizations is really terrible. Either you us floating
> point arithmetic, then you have to rely on it because it is hard enough
> already to gain necessary precision with it, or you don't, then you
> don't need that flag because it doesn't improve performance.
>

Aah, so it's FP only? Okay, one less flag to use, then.

> > -fomit-frame-pointer shouldn't cause any headaches unless you're
> > feeding a gdb stack trace, and you're not adding any debugging data,
> > so your stack traces would be pretty useless, anyway.
> >
>
> If you are on an AMD64 system, this flag is implied because it doesn't
> affect stack traces on x86_64 anymore.
>
> > I don't know about -floop-interchange, -floop-strip-mine or
> > -floop-block. I recognize at least one of them from the discussion of
> > graphite the other day.
> >
>
> These definitely need graphite to have any effect. Then they should be
> reasonably safe (as far as anything relying on experimental compiler
> frameworks can be considered safe).
>

Well, upstream says that graphite in gcc-4.5.3 is stable and production
ready, but the polyhedra analysis slows down compilation significantly. In
addition, one can easily get caught in dependency hell if the ppl package
gets an ABI upgrade.

It's kind of I_KNOW_WHAT_I_AM_DOING flag in /etc/make.conf :-)

That said, I drew the line at -floop-parallelize-all, because after
consulting with some people familiar with that flag, not only will that
flag give just a marginal improvement, but some code apparently got worse
with that flag enabled.

Rgds,

[-- Attachment #2: Type: text/html, Size: 4356 bytes --]

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

Am 28.11.2011 20:14, schrieb Michael Mol:
> On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp <lists@binarywings.net> wrote:
>> Am 28.11.2011 18:56, schrieb Michael Mol:
>>> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@poluan.info> wrote:
>>> No, you've got some ugly flags in there. -fexcess-precision and
>>> -funsafe-math-optimizations, in particular. (I must have been talking
>>> to someone else last week; sorry, I'm terrible with names.)
>>>
>>
>> I doubt -fexcess-precision=fast does anything at all. Pandu uses an
>> AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
>> does not have excess precision issues (that's just for the old x87 FPU).
>> Even if you used that, is redundant because of your other flags. To
>> quote `man gcc`:
>> "-fexcess-precision=standard is not implemented for languages other than
>> C, and has no effect if -funsafe-math-optimizations or -ffast-math is
>> specified." <-- Therefore you always have ..=fast anyway.
>>
>> -funsafe-math-optimizations is really terrible. Either you us floating
>> point arithmetic, then you have to rely on it because it is hard enough
>> already to gain necessary precision with it, or you don't, then you
>> don't need that flag because it doesn't improve performance.
> 
> I didn't know (or forgot) what arch he was using.
> 
>>> -fomit-frame-pointer shouldn't cause any headaches unless you're
>>> feeding a gdb stack trace, and you're not adding any debugging data,
>>> so your stack traces would be pretty useless, anyway.
>>>
>>
>> If you are on an AMD64 system, this flag is implied because it doesn't
>> affect stack traces on x86_64 anymore.
> 
> AMD64 puts the requisite data in its own register, right?
> 

I guess so. Never actually looked up how stack traces are produced. I
just reproduced what `man gcc` tells me :)

> Yeah, it sounds like Pandu's setup CFLAGS can use some cleanup.
> 

I wonder how many CPU cycles you save by reducing the number of
parameters emerge has to pass to gcc. ;)

>>> I don't know about -floop-interchange, -floop-strip-mine or
>>> -floop-block. I recognize at least one of them from the discussion of
>>> graphite the other day.
>>>
>>
>> These definitely need graphite to have any effect. Then they should be
>> reasonably safe (as far as anything relying on experimental compiler
>> frameworks can be considered safe).
> 
> Upstream devs might take issue with them, but I'm still not sure they
> should affect bug reports of build-time failures. I would *hope*
> upstream gcc is doing tests on its own build tools compiled with its
> graphite optimizations. I don't know about make and autotools, though.
> 

Agreed. Even if upstream for failing package doesn't want to handle it,
you can still redirect it to the gcc folks. Even a bug report flagged
WONTFIX or INVALID is helpful for the next user who stumbles upon weird
compile issues.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Michael Mol]

On Mon, Nov 28, 2011 at 2:36 PM, Pandu Poluan <pandu@poluan.info> wrote:
> On Nov 29, 2011 2:02 AM, "Florian Philipp" <lists@binarywings.net> wrote:
>> Am 28.11.2011 18:56, schrieb Michael Mol:
>> > On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@poluan.info>
>> > wrote:
>> >> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>> >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@poluan.info>
>> >>> wrote:
>> >>>> Won't file a bug report, though. I have a feeling that my bug report
>> >>>> re:
>> >>>> emerge failure will be marked WONTFIX thanks to the 'ricer special'
>> >>>> CFLAGS
>> >>>
>> >>> The CFLAGS you showed me weren't any more ricer than "-O2
>> >>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>> >>>
>> >>> They wouldn't have a leg to stand on...
>> >>>
>> >>
>> >> Mine is:
>> >>
>> >> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
>> >> -floop-strip-mine -floop-block -funsafe-math-optimizations
>> >> -fexcess-precision=fast"
>> >>
>> >> If you tell me that's not a ricer's CFLAGS, then you've just made me a
>> >> very
>> >> happy cat :-)
>> >
>> > No, you've got some ugly flags in there. -fexcess-precision and
>> > -funsafe-math-optimizations, in particular. (I must have been talking
>> > to someone else last week; sorry, I'm terrible with names.)
>> >
>>
>> I doubt -fexcess-precision=fast does anything at all. Pandu uses an
>> AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
>> does not have excess precision issues (that's just for the old x87 FPU).
>
> I use Intel boxes, unfortunately.

Are you using a 64-bit x86-derived system? Same difference in this
context. AMD hit the market with a good 64-bit x86-based ISA first,
and devs started calling it AMD64 then. That's mostly stuck even after
Intel released a mostly-compatible competitor, EM64T.

-- 
:wq

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Michael Mol]

On Mon, Nov 28, 2011 at 2:37 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 28.11.2011 20:14, schrieb Michael Mol:
>> Upstream devs might take issue with them, but I'm still not sure they
>> should affect bug reports of build-time failures. I would *hope*
>> upstream gcc is doing tests on its own build tools compiled with its
>> graphite optimizations. I don't know about make and autotools, though.
>>
>
> Agreed. Even if upstream for failing package doesn't want to handle it,
> you can still redirect it to the gcc folks. Even a bug report flagged
> WONTFIX or INVALID is helpful for the next user who stumbles upon weird
> compile issues.

I'd love to see what CSmith is making of graphite.

http://embed.cs.utah.edu/csmith/

-- 
:wq

[gentoo-user] Re: Devs and rice flags (Was: Re: emerge -j, make -j and make -l )

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:

> Japanese youngsters doing bizarre mods to cars that produce absolutely
> no net gain are indeed the source of the term "ricer".
> Yes, it is rude and disparaging but it's also the real root of the
> term. There's no need to politically correct it, the origin is what it is.

True, but there is more.
Motorcycles have always had a greater HorsePower to weight
ratio, hence greater speed than the equivalent (race) car.

When the Japs (oh and I being politically incorrect with Japs?)
started building motorcycles the easiest thing to do to get
noticed was increase the HP  and lower the weight, even to the point
of instability. These earlier bikes where definitely faster.

The Japanese motorcycles where dubbed "rice rockets" way back in the
1970s  ......
Before it was applied to cars, if my recollection is correct.

So the term Ricer has the meanings that other have expressed, but
also, these (kids) ricers change distro to the latest Linux
offering, just to be cool (in their minds). Ricers have come and 
gone from Gentoo (many returned after some maturity and experience
was gained).....

hth,
James

Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Nov 29, 2011 2:53 AM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Mon, Nov 28, 2011 at 2:36 PM, Pandu Poluan <pandu@poluan.info> wrote:
> >
> > I use Intel boxes, unfortunately.
>
> Are you using a 64-bit x86-derived system? Same difference in this
> context. AMD hit the market with a good 64-bit x86-based ISA first,
> and devs started calling it AMD64 then. That's mostly stuck even after
> Intel released a mostly-compatible competitor, EM64T.
>

Ah, okay. I misunderstood your question. (Brain shutting down at 0230 in
the morning).

Rgds,

[-- Attachment #2: Type: text/html, Size: 761 bytes --]