Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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 )
On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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,
Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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 )
On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht markkne...@gmail.com wrote: On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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 )
On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht markkne...@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 )
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 )
On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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 )
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 )
On Mon, Nov 28, 2011 at 12:43 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht markkne...@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 )
On Mon, Nov 28, 2011 at 10:00 AM, kashani kashani-l...@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 )
Am 28.11.2011 18:56, schrieb Michael Mol: On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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). signature.asc Description: OpenPGP digital signature
Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp li...@binarywings.net wrote: Am 28.11.2011 18:56, schrieb Michael Mol: On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan pa...@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 )
On Nov 29, 2011 2:02 AM, Florian Philipp li...@binarywings.net wrote: Am 28.11.2011 18:56, schrieb Michael Mol: On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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,
Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
Am 28.11.2011 20:14, schrieb Michael Mol: On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp li...@binarywings.net wrote: Am 28.11.2011 18:56, schrieb Michael Mol: On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan pa...@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 signature.asc Description: OpenPGP digital signature
Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
On Mon, Nov 28, 2011 at 2:36 PM, Pandu Poluan pa...@poluan.info wrote: On Nov 29, 2011 2:02 AM, Florian Philipp li...@binarywings.net wrote: Am 28.11.2011 18:56, schrieb Michael Mol: On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 28, 2011 10:38 PM, Michael Mol mike...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan pa...@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 )
On Mon, Nov 28, 2011 at 2:37 PM, Florian Philipp li...@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
Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
On Nov 29, 2011 2:53 AM, Michael Mol mike...@gmail.com wrote: On Mon, Nov 28, 2011 at 2:36 PM, Pandu Poluan pa...@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,
