Re: [gentoo-user] emerge -j, make -j and make -l
On Fri, Dec 9, 2011 at 11:35 PM, Michael Mol wrote: > Quick update...I now have two of these things set up in a distcc cluster > with my Phenom 9650. ~530 packages in 228m 34s. There's an even larger > initial explosion of parallel emerge jobs, but it spreads out very > nicely...I may have to increase the -j parameter in MAKEOPTS. I'm also not > certain if distcc is properly deferring jobs to the local host, but I got > the impression the local machine was getting a doubled workload when I had > 127.0.0.1 in/etc/distccd/hosts. > > ZZ Another update: I've been playing with distcc a fair amount. One of the problems I discovered is that distcc doesn't get leveraged all that much if you have something like: MAKEOPTS="-j16 -l8" EMERGE_DEFAULT_OPTS="--jobs --load-average=8" It seems that "./configure" scripts and other non-distributable load pumps up the master system's load average enough that distributable jobs don't get spawned. (And why should they? Make doesn't know that a job will get shuttled off to another system.) After getting Gentoo set up on my new dual-core i3 laptop, I discovered that it seemed to emerge faster than my 8-core boxes with MAKEOPS="-j16 -l4" EMERGE_DEFAULT_OPTS="-jobs --load-average=3" ...It was doing a good job of shuffling jobs off to the two 8-way machines. (The new laptop only has 100Mbit ethernet, so I've also enabled LZO for distcc) With that in mind, I'm going to be trying these settings on the 8-way machines: MAKEOPTS="-j32 -l16" EMERGE_DEFAULT_OPTS="--jobs --load-average=12" -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, Dec 19, 2011 at 2:58 PM, Stefan G. Weichinger wrote: > Am 2011-11-26 17:03, schrieb Stefan G. Weichinger: > >> Thanks for "quoting" me, Michael ... but I also googled that command >> somewhere ... not my idea ... ;-) > > Just went to that URL to cut and paste the command, the mentioned one > doesn't work! > > My make.conf shows this comment/command: > > gcc -march=native -E -v - &1 | sed -n 's/.* -v - //p' > > which works for me. > > Stefan Yeah, happened to me a couple days ago. Wordpress got a bit too smart with the quotes, and it broke something else, too. Thanks for the re-paste, I'll see if I can fix the post. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
Am 2011-11-26 17:03, schrieb Stefan G. Weichinger: > Thanks for "quoting" me, Michael ... but I also googled that command > somewhere ... not my idea ... ;-) Just went to that URL to cut and paste the command, the mentioned one doesn't work! My make.conf shows this comment/command: gcc -march=native -E -v - &1 | sed -n 's/.* -v - //p' which works for me. Stefan
Re: [gentoo-user] emerge -j, make -j and make -l
Quick update...I now have two of these things set up in a distcc cluster with my Phenom 9650. ~530 packages in 228m 34s. There's an even larger initial explosion of parallel emerge jobs, but it spreads out very nicely...I may have to increase the -j parameter in MAKEOPTS. I'm also not certain if distcc is properly deferring jobs to the local host, but I got the impression the local machine was getting a doubled workload when I had 127.0.0.1 in/etc/distccd/hosts. ZZ On Nov 28, 2011 6:53 PM, "Michael Mol" wrote: > On Mon, Nov 28, 2011 at 1:51 PM, Michael Mol wrote: > > I'm currently timing > > > > MAKEOPTS="-j16 -l13" > > EMERGE_DEFAULT_OPTS="--jobs --load-average=13" > > > > with 493 packages (base plus X plus XFCE and chromium, and, of course, > > USE flags), but I'll start another timed run with > > > > MAKEOPTS="-j16 -l8" > > EMERGE_DEFAULT_OPTS="--jobs --load-average=8" > > > > once that's finished. Last night, I tried with -j16 -l10, and that > > completed in 209 minutes, but that was still with the > > PORTAGE_DEFAULT_OPTS typo, so that datapoint is mostly useless. This > > one has already taken about 240 minutes. At least it's finished > > building Chromium, now; I hope it doesn't still need to build gcc. > > It's at 488/493. > > > > (insert) Just finished: > > > > real208m23.880s > > user604m27.065s > > sys 152m22.848s > > > > Apparently, I misremembered when I started it. > > (/insert) > > > > MAKEOPTS="-j16 -l8" > EMERGE_DEFAULT_OPTS="--jobs --load-average=8" > > finished at > > real217m46.366s > user588m22.397s > sys 149m15.283s > > I'll probably set it to -l10 and leave it there; I need to start using > this box for things. > > -- > :wq >
Re: [gentoo-user] emerge -j, make -j and make -l
Am 29.11.2011 16:39, schrieb Neil Bothwick: > The trouble with --load-average in emerge is that it is only > checked as each ebuild is about to start, so you get the "load > explosion" mentioned previously when many ebuilds start and once > and then get into their compile phases. I'm using --jobs, with no > value, in EMERGE_DEFAULT_OPTS and the -l10 for make seems to take > care of the load very nicely (sorry about the pun there). ok with me ;-) I now use: EMERGE_DEFAULT_OPTS="--jobs" MAKEOPTS="-j18 -l10" and that is rather fast, yes thanks ... I start to "feel" the potential of that new CPU, yes. Stefan
Re: [gentoo-user] emerge -j, make -j and make -l
On Tue, 29 Nov 2011 14:47:49 +0100, Stefan G. Weichinger wrote: > > With the cooling system I currently have, I don't like to push it > > too much (a new watercooler should arrive tomorrow), but > > MAKEOPTS="-j16 -l10" appears to be a definite improvement over the > > old -j8 with no -l. > > I have it in two variables: > > EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=6" > MAKEOPTS="-j18" > > Will try your -l10 as well, that might make a difference, sure. The trouble with --load-average in emerge is that it is only checked as each ebuild is about to start, so you get the "load explosion" mentioned previously when many ebuilds start and once and then get into their compile phases. I'm using --jobs, with no value, in EMERGE_DEFAULT_OPTS and the -l10 for make seems to take care of the load very nicely (sorry about the pun there). -- Neil Bothwick If Satan ever loses his hair, there'll be hell toupee. signature.asc Description: PGP signature
Re: [gentoo-user] emerge -j, make -j and make -l
Am 29.11.2011 12:08, schrieb Neil Bothwick: > On Mon, 28 Nov 2011 17:36:08 +0100, Stefan G. Weichinger wrote: > >> Neil, you run a core-i7-2600 as well ... what is your current >> best-practise with that CPU, concerning the values of N and -l >> ... ? > > With the cooling system I currently have, I don't like to push it > too much (a new watercooler should arrive tomorrow), but > MAKEOPTS="-j16 -l10" appears to be a definite improvement over the > old -j8 with no -l. I have it in two variables: EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=6" MAKEOPTS="-j18" and it doesn't push it much, even without any watercooling in there (and without that "K" in the cpu-name ...) Will try your -l10 as well, that might make a difference, sure. thx, Stefan
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, 28 Nov 2011 17:36:08 +0100, Stefan G. Weichinger wrote: > Neil, you run a core-i7-2600 as well ... what is your current > best-practise with that CPU, concerning the values of N and -l ... ? With the cooling system I currently have, I don't like to push it too much (a new watercooler should arrive tomorrow), but MAKEOPTS="-j16 -l10" appears to be a definite improvement over the old -j8 with no -l. -- Neil Bothwick Scrotum is a small planet near Uranus. True/False? signature.asc Description: PGP signature
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" wrote: > > On Mon, Nov 28, 2011 at 2:36 PM, Pandu Poluan 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,
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, Nov 28, 2011 at 1:51 PM, Michael Mol wrote: > I'm currently timing > > MAKEOPTS="-j16 -l13" > EMERGE_DEFAULT_OPTS="--jobs --load-average=13" > > with 493 packages (base plus X plus XFCE and chromium, and, of course, > USE flags), but I'll start another timed run with > > MAKEOPTS="-j16 -l8" > EMERGE_DEFAULT_OPTS="--jobs --load-average=8" > > once that's finished. Last night, I tried with -j16 -l10, and that > completed in 209 minutes, but that was still with the > PORTAGE_DEFAULT_OPTS typo, so that datapoint is mostly useless. This > one has already taken about 240 minutes. At least it's finished > building Chromium, now; I hope it doesn't still need to build gcc. > It's at 488/493. > > (insert) Just finished: > > real 208m23.880s > user 604m27.065s > sys 152m22.848s > > Apparently, I misremembered when I started it. > (/insert) > MAKEOPTS="-j16 -l8" EMERGE_DEFAULT_OPTS="--jobs --load-average=8" finished at real217m46.366s user588m22.397s sys 149m15.283s I'll probably set it to -l10 and leave it there; I need to start using this box for things. -- :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 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 Mon, Nov 28, 2011 at 2:36 PM, Pandu Poluan wrote: > On Nov 29, 2011 2:02 AM, "Florian Philipp" wrote: >> Am 28.11.2011 18:56, schrieb Michael Mol: >> > On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan >> > wrote: >> >> On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: >> >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan >> >>> 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 )
Am 28.11.2011 20:14, schrieb Michael Mol: > On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp > wrote: >> Am 28.11.2011 18:56, schrieb Michael Mol: >>> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan 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 Nov 29, 2011 2:02 AM, "Florian Philipp" wrote: > > Am 28.11.2011 18:56, schrieb Michael Mol: > > On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan wrote: > >> On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: > >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan 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 )
On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp wrote: > Am 28.11.2011 18:56, schrieb Michael Mol: >> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan 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 )
Am 28.11.2011 18:56, schrieb Michael Mol: > On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan wrote: >> On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan 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: [gentoo-user] emerge -j, make -j and make -l
On Mon, Nov 28, 2011 at 1:51 PM, Michael Mol wrote: > On Mon, Nov 28, 2011 at 12:26 AM, Pandu Poluan wrote: [snip] > FWIW, I strongly suspect that N should be your number of *logical* > cores, not your number of physical cores. I believe most of the > overhead ...and finishing my sentence. I believe most of the overhead comes from context switching between two threads, and hyperthreading adds CPU hardware specifically for the purpose of avoiding that costly context switch when controlling which thread's instructions get sent up the pipeline. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, Nov 28, 2011 at 12:26 AM, Pandu Poluan wrote: > On Nov 28, 2011 11:32 AM, "Michael Mol" wrote: [snip] > Unfortunately, striving for 2*N will inadvertently result in short bursts of >> 2*N, and this potentially induce a stall, which will be very costly. 1.8*N > gives a 10% margin for burst activities, while 1.6*N gives a 20% margin. Actually, I suspect that 2*N is normally beneficial as a way to cover for processes blocked on I/O. I don't believe processes blocked on I/O are counted in the system's instantaneous load, so they wouldn't be noticed when the kernel polls to build a load average. That tells me that, for a load-aware system, you want N for your load-aware calculations, and 2*N (or thereabouts) for numbers which aren't load-aware. Make's -j parameter would be an example of the latter, as it serves as an upper limit when the load average is low, and -l's algorithm keeps saying "go on, go on!" I'm currently timing MAKEOPTS="-j16 -l13" EMERGE_DEFAULT_OPTS="--jobs --load-average=13" with 493 packages (base plus X plus XFCE and chromium, and, of course, USE flags), but I'll start another timed run with MAKEOPTS="-j16 -l8" EMERGE_DEFAULT_OPTS="--jobs --load-average=8" once that's finished. Last night, I tried with -j16 -l10, and that completed in 209 minutes, but that was still with the PORTAGE_DEFAULT_OPTS typo, so that datapoint is mostly useless. This one has already taken about 240 minutes. At least it's finished building Chromium, now; I hope it doesn't still need to build gcc. It's at 488/493. (insert) Just finished: real208m23.880s user604m27.065s sys 152m22.848s Apparently, I misremembered when I started it. (/insert) FWIW, I strongly suspect that N should be your number of *logical* cores, not your number of physical cores. I believe most of the overhead -- :wq
Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )
On Mon, 28 Nov 2011 08:54:13 -0800 Mark Knecht wrote: > On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan > wrote: > > > > On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: > >> > >> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan > >> 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.mckin...@gmail.com
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 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 )
On Mon, Nov 28, 2011 at 12:43 PM, Paul Hartman wrote: > On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht 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 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 11:46 AM, Pandu Poluan wrote: > On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: >> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan 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 )
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 10:54 AM, Mark Knecht 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 )
On Mon, Nov 28, 2011 at 10:54 AM, Mark Knecht wrote: > On Mon, Nov 28, 2011 at 8:46 AM, Pandu Poluan wrote: >> >> On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: >>> >>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan 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 8:46 AM, Pandu Poluan wrote: > > On Nov 28, 2011 10:38 PM, "Michael Mol" wrote: >> >> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan 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 Nov 28, 2011 10:38 PM, "Michael Mol" wrote: > > On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan 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: [gentoo-user] emerge -j, make -j and make -l
Am 28.11.2011 10:27, schrieb Neil Bothwick: > From the description, it should do just that, there may still be > dozens of ebuilds in progress, but only the first few will actually > start compiling. Adding it now. It should also helps when there are > multiple emerge processes running, my desktop acts as a build host > for lower powered systems too. Adding -l10 now. Neil, you run a core-i7-2600 as well ... what is your current best-practise with that CPU, concerning the values of N and -l ... ? Thanks, greets, Stefan
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 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: [gentoo-user] emerge -j, make -j and make -l
On Mon, Nov 28, 2011 at 16:27, Neil Bothwick wrote: > On Sun, 27 Nov 2011 23:34:14 -0500, Michael Mol wrote: > >> >> The problem I found with that is the ebuilds load the system lightly >> >> to start with, before they enter the compile phase, to portage >> >> starts dozens of parallel ebuilds, then the system gets completely >> >> bogged down when they start compiling. > >> > Yes, sometimes that would happen if at the beginning there are >> > network-bound ebuilds all downloading their respective distfiles. The >> > load stays low until they all start ./configure-ing roughly at the >> > same time. Then all hell breaks loose. >> > >> > I successfully mitigate such "load-explosion" by doing a --fetchonly >> > step first, and keeping MAKEOPTS at low -j (which, in my case, is >> > actually required). > > It doesn't help here, as my cron script that runs emerge --sync already > follows it with emerge -f @world. > >> As I noted, "-l" in MAKEOPTS takes care of the load explosion very >> nicely. > > From the description, it should do just that, there may still be dozens > of ebuilds in progress, but only the first few will actually start > compiling. Adding it now. It should also helps when there are multiple > emerge processes running, my desktop acts as a build host for lower > powered systems too. Adding -l10 now. > Just tried adding "-l7.2" to MAKEOPTS ... ... and indeed, emerge -1avuND --changed-use @system @world seems faster than without. What's for sure, the emerge's output shows higher parallelism than without. Hmmm... gotta try it with emerge -e @system @world sometime :-) Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] emerge -j, make -j and make -l
2011/11/28 Jorge Martínez López : > Hi there > > 2011/11/28 Pandu Poluan : > ... >> >> TL;DR : 2*N for non-hyperthreaded cores, N for hyperthreaded cores. >> >> (Disclaimer: Above is my pure speculation. Feel free to debunk it >> based on your tests (: ) >> >> Rgds, > > So with a 6 core Phenom it would look like this: > > MAKEOPTS="-j 12 -l 10" > EMERGE_DEFAULT_OPTS="--with-bdeps=y --jobs --load-average=10" > > Does this make sense? > You can 'push' MAKEOPTS to "-l 10.8", methinks. Although honestly I don't think a difference of 0.8 will make any discernible effect :-) (Yes, 'man make' says that "-l" accepts floating-point numbers. I just checked) But your settings make perfect sense to me :-) Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] emerge -j, make -j and make -l
Hi there 2011/11/28 Pandu Poluan : ... > > TL;DR : 2*N for non-hyperthreaded cores, N for hyperthreaded cores. > > (Disclaimer: Above is my pure speculation. Feel free to debunk it > based on your tests (: ) > > Rgds, So with a 6 core Phenom it would look like this: MAKEOPTS="-j 12 -l 10" EMERGE_DEFAULT_OPTS="--with-bdeps=y --jobs --load-average=10" Does this make sense? Thanks in advance! -- Jorge Martínez López http://www.jorgeml.net Google Talk / XMPP: jorg...@gmail.com
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, Nov 28, 2011 at 16:27, Neil Bothwick wrote: > On Mon, 28 Nov 2011 12:26:48 +0700, Pandu Poluan wrote: > >> Just in case anyone wonders where the multiplier "1.6" comes from: >> >> There had been a discussion somewhere (I forgot where exactly, sorry) >> about load numbers. The final conclusion was that the ideal load number >> for today's processors is 2*N, because with the out-of-order capability >> of modern processors, two instructions can overlap in the pipeline, even >> without hyperthreading. > > Is N the number of physical cores, or does it include hyperthreaded cores > too? > And that... I forgot. However, considering hyperthreading is just a 'trick' where a pair threads of the same context can run together on a core, I'd wager that N here should be considered as the physical core. In other words, my guess is that 2*N is the "implicit hyperthreading" performed by OOO processor cores. On hyperthreaded cores, the 2*N ability of OOO processors is made "explicit". TL;DR : 2*N for non-hyperthreaded cores, N for hyperthreaded cores. (Disclaimer: Above is my pure speculation. Feel free to debunk it based on your tests (: ) Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, 27 Nov 2011 23:34:14 -0500, Michael Mol wrote: > >> The problem I found with that is the ebuilds load the system lightly > >> to start with, before they enter the compile phase, to portage > >> starts dozens of parallel ebuilds, then the system gets completely > >> bogged down when they start compiling. > > Yes, sometimes that would happen if at the beginning there are > > network-bound ebuilds all downloading their respective distfiles. The > > load stays low until they all start ./configure-ing roughly at the > > same time. Then all hell breaks loose. > > > > I successfully mitigate such "load-explosion" by doing a --fetchonly > > step first, and keeping MAKEOPTS at low -j (which, in my case, is > > actually required). It doesn't help here, as my cron script that runs emerge --sync already follows it with emerge -f @world. > As I noted, "-l" in MAKEOPTS takes care of the load explosion very > nicely. From the description, it should do just that, there may still be dozens of ebuilds in progress, but only the first few will actually start compiling. Adding it now. It should also helps when there are multiple emerge processes running, my desktop acts as a build host for lower powered systems too. Adding -l10 now. -- Neil Bothwick The trouble with the world is that everybody in it is three drinks behind. signature.asc Description: PGP signature
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, 28 Nov 2011 12:26:48 +0700, Pandu Poluan wrote: > Just in case anyone wonders where the multiplier "1.6" comes from: > > There had been a discussion somewhere (I forgot where exactly, sorry) > about load numbers. The final conclusion was that the ideal load number > for today's processors is 2*N, because with the out-of-order capability > of modern processors, two instructions can overlap in the pipeline, even > without hyperthreading. Is N the number of physical cores, or does it include hyperthreaded cores too? -- Neil Bothwick Forget the Joneses...I can't keep up with The Simpsons. signature.asc Description: PGP signature
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 12:35 PM, "Michael Mol" wrote: > > On Sun, Nov 27, 2011 at 8:06 PM, Pandu Poluan wrote: > > On Nov 28, 2011 3:21 AM, "Michael Mol" wrote: > >> On Sun, Nov 27, 2011 at 12:56 PM, Pandu Poluan wrote: > > [snip] > > >> Sweet; I didn't know about Portage's --load-average; I'll definitely > >> switch to that instead of -j. Load-driven make plus load-driven > >> portage should work beautifully on my system. > >> > >> I'll steal your 1.6 factor, and give: > >>MAKEOPTS=-j <2*N> -l <1.6*N) > >>PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" > >> a try. > > > Make sure that make supports non-integer values for -l, though. > > I rounded up to 13. Shouldn't you be rounding down, instead? That said, as long as the number falls between 1.6*N and 1.8*N (see my previous post), nothing should blow up. Well, not spectacularly, at least :-) BTW, FYI, --load-average accepts non-integer values. Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 8:06 PM, Pandu Poluan wrote: > On Nov 28, 2011 3:21 AM, "Michael Mol" wrote: >> On Sun, Nov 27, 2011 at 12:56 PM, Pandu Poluan wrote: [snip] >> Sweet; I didn't know about Portage's --load-average; I'll definitely >> switch to that instead of -j. Load-driven make plus load-driven >> portage should work beautifully on my system. >> >> I'll steal your 1.6 factor, and give: >> MAKEOPTS=-j <2*N> -l <1.6*N) >> PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" >> a try. > Make sure that make supports non-integer values for -l, though. I rounded up to 13. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, Nov 28, 2011 at 12:13 AM, Pandu Poluan wrote: > On Nov 28, 2011 11:38 AM, "Michael Mol" wrote: >> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan wrote: >> > On Nov 28, 2011 6:24 AM, "Neil Bothwick" wrote: >> >> On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: >> >> >> >> > I don't know where the 'blame' lies, but I've found myself >> >> > standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs >> >> > --load-average=<1.6*num_of_vCPU>" >> >> > >> >> > (Yes, no explicit number of jobs. The newer portages are smart enough >> >> > to >> >> > keep starting new jobs until the load number is reached) >> >> >> >> The problem I found with that is the ebuilds load the system lightly to >> >> start with, before they enter the compile phase, to portage starts >> >> dozens >> >> of parallel ebuilds, then the system gets completely bogged down when >> >> they start compiling. >> >> >> > >> > Yes, sometimes that would happen if at the beginning there are >> > network-bound >> > ebuilds all downloading their respective distfiles. The load stays low >> > until >> > they all start ./configure-ing roughly at the same time. Then all hell >> > breaks loose. >> > >> > I successfully mitigate such "load-explosion" by doing a --fetchonly >> > step >> > first, and keeping MAKEOPTS at low -j (which, in my case, is actually >> > required). >> > >> > Just to add more info: I use USE=graphite (with some CFLAGS, uh, >> > 'enhancements') with gcc-4.5.3. IIRC, I could push MAKEOPTS up to -j5 >> > (and >> > even more, but I ran out of cores) when I was still using gcc-4.4.x and >> > no >> > USE=graphite. >> > >> > 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 >> >> As I noted, "-l" in MAKEOPTS takes care of the load explosion very nicely. > > Most likely so. I am not aware of -l in MAKEOPTS before, so what I posted > was my workaround to prevent load explosion. Thanks to your very useful tip, > I now no longer have to worry about load explosion :-) > > (I still like doing pre-fetchonly-ing, though. But now for a different main > reason :-) The explosion of information in this thread is going to make for a *great* followup blog post. :) Now I just wish there were a way to get Portage and Make to watch CPU usage and raise or lower the load-average threshold depending on how much CPU was going to 'sys', 'user' and 'wait'; Lower -l if a great deal of time is spent in 'sys'; you're likely burning cycles in context switches. Raise -l if a great deal of time is spent waiting on I/O. It'd also be helpful to be able to give keystone[1] packages and Make recipes a more favorable NICE value than those less important, to induce the scheduler to favor the important packages over less-important packages when we've got more ready work than cores. I don't think Make *can* have the smarts for that, but Portage could conceivably do it for its own parallelization. [1] Where many things depend on them, either directly or indirectly. Getting these out of the way means more parallel-buildable packages being available at the same time. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 11:32 AM, "Michael Mol" wrote: > - >8 snip > > MAKEOPTS would be -j16, -l10. (Which actually goes up to about 12 or > 13 based on that N*1.6 behavior) > - >8 snip Just in case anyone wonders where the multiplier "1.6" comes from: There had been a discussion somewhere (I forgot where exactly, sorry) about load numbers. The final conclusion was that the ideal load number for today's processors is 2*N, because with the out-of-order capability of modern processors, two instructions can overlap in the pipeline, even without hyperthreading. Unfortunately, striving for 2*N will inadvertently result in short bursts of > 2*N, and this potentially induce a stall, which will be very costly. 1.8*N gives a 10% margin for burst activities, while 1.6*N gives a 20% margin. Since emerging packages has a sudden increase in load when autoconfigure finishes and make fires up all the parallel building, I figure 20% margin will be better. Of course, that's before @mikemol made me aware of MAKEOPTS -l, so I am now tempted to raise the load-average to 1.8*N, letting make handle the bursts. Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 11:38 AM, "Michael Mol" wrote: > > On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan wrote: > > > > On Nov 28, 2011 6:24 AM, "Neil Bothwick" wrote: > >> > >> On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: > >> > >> > I don't know where the 'blame' lies, but I've found myself > >> > standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs > >> > --load-average=<1.6*num_of_vCPU>" > >> > > >> > (Yes, no explicit number of jobs. The newer portages are smart enough to > >> > keep starting new jobs until the load number is reached) > >> > >> The problem I found with that is the ebuilds load the system lightly to > >> start with, before they enter the compile phase, to portage starts dozens > >> of parallel ebuilds, then the system gets completely bogged down when > >> they start compiling. > >> > > > > Yes, sometimes that would happen if at the beginning there are network-bound > > ebuilds all downloading their respective distfiles. The load stays low until > > they all start ./configure-ing roughly at the same time. Then all hell > > breaks loose. > > > > I successfully mitigate such "load-explosion" by doing a --fetchonly step > > first, and keeping MAKEOPTS at low -j (which, in my case, is actually > > required). > > > > Just to add more info: I use USE=graphite (with some CFLAGS, uh, > > 'enhancements') with gcc-4.5.3. IIRC, I could push MAKEOPTS up to -j5 (and > > even more, but I ran out of cores) when I was still using gcc-4.4.x and no > > USE=graphite. > > > > 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 > > As I noted, "-l" in MAKEOPTS takes care of the load explosion very nicely. Most likely so. I am not aware of -l in MAKEOPTS before, so what I posted was my workaround to prevent load explosion. Thanks to your very useful tip, I now no longer have to worry about load explosion :-) (I still like doing pre-fetchonly-ing, though. But now for a different main reason :-) Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan wrote: > > On Nov 28, 2011 6:24 AM, "Neil Bothwick" wrote: >> >> On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: >> >> > I don't know where the 'blame' lies, but I've found myself >> > standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs >> > --load-average=<1.6*num_of_vCPU>" >> > >> > (Yes, no explicit number of jobs. The newer portages are smart enough to >> > keep starting new jobs until the load number is reached) >> >> The problem I found with that is the ebuilds load the system lightly to >> start with, before they enter the compile phase, to portage starts dozens >> of parallel ebuilds, then the system gets completely bogged down when >> they start compiling. >> > > Yes, sometimes that would happen if at the beginning there are network-bound > ebuilds all downloading their respective distfiles. The load stays low until > they all start ./configure-ing roughly at the same time. Then all hell > breaks loose. > > I successfully mitigate such "load-explosion" by doing a --fetchonly step > first, and keeping MAKEOPTS at low -j (which, in my case, is actually > required). > > Just to add more info: I use USE=graphite (with some CFLAGS, uh, > 'enhancements') with gcc-4.5.3. IIRC, I could push MAKEOPTS up to -j5 (and > even more, but I ran out of cores) when I was still using gcc-4.4.x and no > USE=graphite. > > 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 As I noted, "-l" in MAKEOPTS takes care of the load explosion very nicely. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 6:21 PM, Neil Bothwick wrote: > On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: > >> I don't know where the 'blame' lies, but I've found myself >> standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs >> --load-average=<1.6*num_of_vCPU>" >> >> (Yes, no explicit number of jobs. The newer portages are smart enough to >> keep starting new jobs until the load number is reached) > > The problem I found with that is the ebuilds load the system lightly to > start with, before they enter the compile phase, to portage starts dozens > of parallel ebuilds, then the system gets completely bogged down when > they start compiling. I did notice that, but it settles back down *very* quickly with the -l parameter to make. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 5:07 PM, Mark Knecht wrote:
> On Sat, Nov 26, 2011 at 7:22 AM, Michael Mol wrote:
>> I just wanted to share an experience I had today with optimizing parallel
>> builds after discovering "-l" for Make...
>>
>> I've got a little more tweaking I still want to do, but this is pretty
>> awesome...
>>
>> http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/
>>
>> ZZ
>
> Good post Michael. Thanks.
>
> I want to verify that in make.conf this is indeed MAKEOPTS we are
> talking about and not EMERGE_DEFAULT_OPTS.
It'd be a combination of them.
EMERGE_DEFAULT_OPTS, for my 8-way system, would have been -j8 (I'll be
changing this to reflect portage's load-aware behavior).
MAKEOPTS would be -j16, -l10. (Which actually goes up to about 12 or
13 based on that N*1.6 behavior)
>
> Currently for my i7-980x (6 physical cores + hyper threading = 12
> logical cores) I have:
>
> MAKEOPTS="-j3"
> EMERGE_DEFAULT_OPTS="--with-bdeps y "
> PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"
>
> I generally keep -j small day-to-day to allow emerge to work more or
> less the background while I'm using the machine for other things. If I
> was going to do an emerge -e @world then in the past I'd push it up
> for 13. (N+1)
>
> I've not used the -l option but it sounds interesting. If I understand
> the then you're suggesting in /etc/make.conf
>
> MAKEOPTS="-j13 -l7"
>
> or something in that range for a full blown emerge -e @world?
Pretty much. Though I wouldn't do it just for @world. I'd leave it in
for all emerges.
--
:wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 3:21 AM, "Michael Mol" wrote: > > On Sun, Nov 27, 2011 at 12:56 PM, Pandu Poluan wrote: > > On Nov 27, 2011 5:12 PM, "Michael Mol" wrote: > > [snip] > > > > > Here's my experience: > > > > I always experience emerge failures on my Gentoo VMs if I use MAKEOPTS=-j>3. > > Not all packages, but many. Including, IIRC, glibc and gcc. > > In my barebones 177-package state, I didn't get any build failures > from parallel building, either via emerge -j or make -j. I did get one > failure when I went to install X that worked fine on the second > attempt. > And in my barebones system (172 packages), there are several packages that reliably fail, even when emerged on their own *sigh* > > This happens even if I make sure that there's just one emerge job being > > done. And this happens even if I allocate more vCPUs than -j, on VMware and > > XenServer alike. > > FWIW, I've been running with MAKEOPTS=-j10 on my Phenom 9650 for over > a year. It's very rare that something breaks due to the parallel > build. I think it's happened perhaps three times, and each time was > resolvable with a retry. YMMV, of course; race conditions are finicky. > I have a hunch that the hypervisor had some effects. Most likely, another VM in the same host has a high enough load that necessitates the Gentoo VM to be shifted to another (physical) core, and this messes up the timing. MAKEOPTS=-j3 always succeeds, though. So I'm disinclined to delve deeper into the issue. > > I don't know where the 'blame' lies, but I've found myself standardizing on > > MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs > > --load-average=<1.6*num_of_vCPU>" > > > > (Yes, no explicit number of jobs. The newer portages are smart enough to > > keep starting new jobs until the load number is reached) > > Sweet; I didn't know about Portage's --load-average; I'll definitely > switch to that instead of -j. Load-driven make plus load-driven > portage should work beautifully on my system. > > I'll steal your 1.6 factor, and give: >MAKEOPTS=-j <2*N> -l <1.6*N) >PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" > a try. > Make sure that make supports non-integer values for -l, though. > How does that interact with distcc, by the way? I've got two of these > octo-core Xeon boxes, and I've still got my Phenom 9650--distcc on my > home network should become very, very nice. And this box is consuming > 255W at the wall with monitor off, 326W with monitor on. That's not > bad. Though perhaps I should move to an apartment where heat isn't > free... > Well, I don't use distcc, so I can't speculate. But with plain single system compilation, my settings have been serving me real well :-) Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 6:24 AM, "Neil Bothwick" wrote: > > On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: > > > I don't know where the 'blame' lies, but I've found myself > > standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs > > --load-average=<1.6*num_of_vCPU>" > > > > (Yes, no explicit number of jobs. The newer portages are smart enough to > > keep starting new jobs until the load number is reached) > > The problem I found with that is the ebuilds load the system lightly to > start with, before they enter the compile phase, to portage starts dozens > of parallel ebuilds, then the system gets completely bogged down when > they start compiling. > Yes, sometimes that would happen if at the beginning there are network-bound ebuilds all downloading their respective distfiles. The load stays low until they all start ./configure-ing roughly at the same time. Then all hell breaks loose. I successfully mitigate such "load-explosion" by doing a --fetchonly step first, and keeping MAKEOPTS at low -j (which, in my case, is actually required). Just to add more info: I use USE=graphite (with some CFLAGS, uh, 'enhancements') with gcc-4.5.3. IIRC, I could push MAKEOPTS up to -j5 (and even more, but I ran out of cores) when I was still using gcc-4.4.x and no USE=graphite. 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 :-P Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 3:55 AM, "Alex Schuster" wrote: > > Michael Mol writes: > > > On Sun, Nov 27, 2011 at 3:16 PM, Michael Mol wrote: > > > I'll steal your 1.6 factor, and give: > > >MAKEOPTS=-j <2*N> -l <1.6*N) > > >PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" > > > a try. > > > > Ah. Which file does PORTAGE_DEFAULT_OPTS go in? It doesn't appear to > > have an impact in /etc/make.conf > > It's EMERGE_DEFAULT_OPTS in make.conf. See man make.conf. > Yes, it's EMERGE_DEFAULT_OPTS >.< I really should stop sending an email when it's 00:44 in the morning... Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Mon, 28 Nov 2011 00:56:17 +0700, Pandu Poluan wrote: > I don't know where the 'blame' lies, but I've found myself > standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs > --load-average=<1.6*num_of_vCPU>" > > (Yes, no explicit number of jobs. The newer portages are smart enough to > keep starting new jobs until the load number is reached) The problem I found with that is the ebuilds load the system lightly to start with, before they enter the compile phase, to portage starts dozens of parallel ebuilds, then the system gets completely bogged down when they start compiling. -- Neil Bothwick If Microsoft made cars: "The airbag system would ask "are you sure?" before deploying." signature.asc Description: PGP signature
Re: [gentoo-user] emerge -j, make -j and make -l
Mark Knecht wrote:
On Sat, Nov 26, 2011 at 7:22 AM, Michael Mol wrote:
I just wanted to share an experience I had today with optimizing parallel
builds after discovering "-l" for Make...
I've got a little more tweaking I still want to do, but this is pretty
awesome...
http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/
ZZ
Good post Michael. Thanks.
I want to verify that in make.conf this is indeed MAKEOPTS we are
talking about and not EMERGE_DEFAULT_OPTS.
Currently for my i7-980x (6 physical cores + hyper threading = 12
logical cores) I have:
MAKEOPTS="-j3"
EMERGE_DEFAULT_OPTS="--with-bdeps y "
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"
I generally keep -j small day-to-day to allow emerge to work more or
less the background while I'm using the machine for other things. If I
was going to do an emerge -e @world then in the past I'd push it up
for 13. (N+1)
I've not used the -l option but it sounds interesting. If I understand
the then you're suggesting in /etc/make.conf
MAKEOPTS="-j13 -l7"
or something in that range for a full blown emerge -e @world?
- Mark
You should also look into this setting if you want to let portage run in
the background:
PORTAGE_NICENESS=5
I have a 4 core system and run this:
MAKEOPTS="-j16 -l10"
EMERGE_DEFAULT_OPTS="-j8 "
I can't even tell portage is running. Heck, I even watch videos and
such. No problems with slowdown at all.
Oh, the -l10 is sort of new. The -j16 is changing a bit over time.
Trying to test speed to see what is fastest. So far, no compile race
problems either.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-user] emerge -j, make -j and make -l
On Sat, Nov 26, 2011 at 7:22 AM, Michael Mol wrote:
> I just wanted to share an experience I had today with optimizing parallel
> builds after discovering "-l" for Make...
>
> I've got a little more tweaking I still want to do, but this is pretty
> awesome...
>
> http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/
>
> ZZ
Good post Michael. Thanks.
I want to verify that in make.conf this is indeed MAKEOPTS we are
talking about and not EMERGE_DEFAULT_OPTS.
Currently for my i7-980x (6 physical cores + hyper threading = 12
logical cores) I have:
MAKEOPTS="-j3"
EMERGE_DEFAULT_OPTS="--with-bdeps y "
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"
I generally keep -j small day-to-day to allow emerge to work more or
less the background while I'm using the machine for other things. If I
was going to do an emerge -e @world then in the past I'd push it up
for 13. (N+1)
I've not used the -l option but it sounds interesting. If I understand
the then you're suggesting in /etc/make.conf
MAKEOPTS="-j13 -l7"
or something in that range for a full blown emerge -e @world?
- Mark
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, 27 Nov 2011 15:16:33 -0500 Michael Mol wrote: [snip] > My day job is C++ on Windows[1], > [1] Well, for most of this year, my task list has been more > PHP-oriented, but I'm still on tap for our C++ work. You have my deepest, deepest, sympathies. Gotta pay the rent something though, hey? [I have a similar thing going myself with SLES] -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge -j, make -j and make -l
Michael Mol writes: > On Sun, Nov 27, 2011 at 3:16 PM, Michael Mol wrote: > > I'll steal your 1.6 factor, and give: > > MAKEOPTS=-j <2*N> -l <1.6*N) > > PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" > > a try. > > Ah. Which file does PORTAGE_DEFAULT_OPTS go in? It doesn't appear to > have an impact in /etc/make.conf It's EMERGE_DEFAULT_OPTS in make.conf. See man make.conf. Wonko
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 3:16 PM, Michael Mol wrote: > I'll steal your 1.6 factor, and give: > MAKEOPTS=-j <2*N> -l <1.6*N) > PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" > a try. Ah. Which file does PORTAGE_DEFAULT_OPTS go in? It doesn't appear to have an impact in /etc/make.conf -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 12:56 PM, Pandu Poluan wrote: > On Nov 27, 2011 5:12 PM, "Michael Mol" wrote: [snip] > > Here's my experience: > > I always experience emerge failures on my Gentoo VMs if I use MAKEOPTS=-j>3. > Not all packages, but many. Including, IIRC, glibc and gcc. In my barebones 177-package state, I didn't get any build failures from parallel building, either via emerge -j or make -j. I did get one failure when I went to install X that worked fine on the second attempt. Parallel operations are finicky things; if you don't define the relationships correctly, you can have things work fine most of the time, and then a race condition between one make recipe and another (or perhaps between one ebuild and another; a revdep-rebuild afterward might not be a bad CYA) causes one thing to fail, just this one time. My day job is C++ on Windows[1], and we do a *lot* with multithreaded code. Race conditions are a PITA; you might not be able to reproduce a race-induced failure on any of the workstations or test systems you have, but then have it crop up consistently on a customer's system. The same principles can and will apply with things like parallel make and parallel emerge. I've even seen it happen in VS2005 and VS2008 parallel builds. > This happens even if I make sure that there's just one emerge job being > done. And this happens even if I allocate more vCPUs than -j, on VMware and > XenServer alike. FWIW, I've been running with MAKEOPTS=-j10 on my Phenom 9650 for over a year. It's very rare that something breaks due to the parallel build. I think it's happened perhaps three times, and each time was resolvable with a retry. YMMV, of course; race conditions are finicky. > I don't know where the 'blame' lies, but I've found myself standardizing on > MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs > --load-average=<1.6*num_of_vCPU>" > > (Yes, no explicit number of jobs. The newer portages are smart enough to > keep starting new jobs until the load number is reached) Sweet; I didn't know about Portage's --load-average; I'll definitely switch to that instead of -j. Load-driven make plus load-driven portage should work beautifully on my system. I'll steal your 1.6 factor, and give: MAKEOPTS=-j <2*N> -l <1.6*N) PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" a try. How does that interact with distcc, by the way? I've got two of these octo-core Xeon boxes, and I've still got my Phenom 9650--distcc on my home network should become very, very nice. And this box is consuming 255W at the wall with monitor off, 326W with monitor on. That's not bad. Though perhaps I should move to an apartment where heat isn't free... [1] Well, for most of this year, my task list has been more PHP-oriented, but I'm still on tap for our C++ work. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 27, 2011 5:12 PM, "Michael Mol" wrote: > > I figure that the optimal number of simultaneous CPU-consuming > processes is going to be the number of CPU cores, plus enough to keep > the CPU occupied while others are blocked on I/O. That's the same > reasoning that drives the selection of a -j number, really. > > If I read make's man page correctly, -l acts as a threshold, choosing > not to spawn an additional child process if the system load average is > above a certain value Since system load is a count of actively running > and ready-to-run processes, you want it to be very close to your > number of logical cores[1]. > > Since it's going to be a spot decision for Make as to whether or not > to spawn another child (if it hits its limit, it's not going to check > again until after one of its children returns), there will be many > race cases where the load average is high when it looks, but some > other processes will return shortly afterward.[2] That means adding a > process or two for a fudge factor. > > That's a lot of guess, though, and it still comes down to guess-and-check. > > emerge -j8 @world # MAKEOPTS="-j16 -l10" > > Was the first combination I tried. This completed in 89 minutes. > > emerge -j8 @world # MAKEOPT="-j16 -l8" > > Was the second. This took significantly longer. > > I haven't tried higher than -l10; I needed this box to do be able to > do things, which meant installing more software. I've gone from 177 > packages to 466. > > [1] I don't have a hyperthreading system available, but I suspect that > this is also going to be true of logical cores; It's my understanding > that the overhead from overcommitting CPU comes primarily from context > switching between processors, and hyperthreading adds CPU hardware > specifically to reduce the need to context-switch in splitting > physical CPU resources between threads/processes. So while you'd lose > a little speed for an individual thread, you would gain it back in > aggregate over both threads. > > [2] There would also be cases where the load average is low, such as > if a Make recipe calls for a significant bit of I/O before it consumes > a great deal of CPU, but a simple 7200rpm SATA disk appears to be > sufficiently fast that this case is less frequent. Here's my experience: I always experience emerge failures on my Gentoo VMs if I use MAKEOPTS=-j>3. Not all packages, but many. Including, IIRC, glibc and gcc. This happens even if I make sure that there's just one emerge job being done. And this happens even if I allocate more vCPUs than -j, on VMware and XenServer alike. I don't know where the 'blame' lies, but I've found myself standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs --load-average=<1.6*num_of_vCPU>" (Yes, no explicit number of jobs. The newer portages are smart enough to keep starting new jobs until the load number is reached) Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
On Nov 28, 2011 12:29 AM, "Michael Hampicke" wrote: > > > Am 26.11.2011 16:22, schrieb Michael Mol: > > parallel builds > > Sweet, I didn't even know about emerges -j option to do parallel builds. > Thx for sharing, I am sure I'll use this in the feature > emerge -j will be useful if the packages being emerged are independent from one another. Packages that depend on another package will be emerged sequentially after their dependencies are emerged. Rgds,
Re: [gentoo-user] emerge -j, make -j and make -l
Am 26.11.2011 16:22, schrieb Michael Mol: > parallel builds Sweet, I didn't even know about emerges -j option to do parallel builds. Thx for sharing, I am sure I'll use this in the feature
Re: Quiet builds Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 10:48 AM, Dale wrote: > Michael Mol wrote: >> Oh! I hadn't realized there was an update to portage that changed >> that. Missed it on my main box, I suppose. > > You have got to crawl out of the hole every once in a while. It was on -dev > then got moved over to the forums with a poll, which the results were > ignored. > > Bad thing is, they won't announce the change until it hits stable. I'm > thinking of adding it to my sig so people will notice it and not have to > ask. Hm. Honestly, I don't know that it's such a terrible default. IMO, it'd be better if builds couldn't be slowed down by slow terminals, but this is probably the simpler solution. -- :wq
Re: Quiet builds Re: [gentoo-user] emerge -j, make -j and make -l
Michael Mol wrote: On Sun, Nov 27, 2011 at 5:58 AM, Dale wrote: cov...@ccs.covici.com wrote: Mickwrote: On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: I just wanted to share an experience I had today with optimizing parallel builds after discovering "-l" for Make... I've got a little more tweaking I still want to do, but this is pretty awesome... http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ ZZ Thanks for sharing! How do you determine the optimum value for -l? How do you get emerge not to display number of jobs and load average -- I only want to compile one at a time -- much safer that way and it is doing that, but now it displays all that load average and how many jobs, etc. -- any way to get rid of that display? Thank Zac for that. He thinks he knows what you want. ;-) Apparently not huh? http://forums.gentoo.org/viewtopic-t-901858.html Just add --quiet-build=n to EMERGE_DEFAULT_OPTS in make.conf and it will do it the old way. Oh! I hadn't realized there was an update to portage that changed that. Missed it on my main box, I suppose. You have got to crawl out of the hole every once in a while. It was on -dev then got moved over to the forums with a poll, which the results were ignored. Bad thing is, they won't announce the change until it hits stable. I'm thinking of adding it to my sig so people will notice it and not have to ask. < sighs > Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Quiet builds Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 5:58 AM, Dale wrote: > cov...@ccs.covici.com wrote: >> >> Mick wrote: >> >>> On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: I just wanted to share an experience I had today with optimizing parallel builds after discovering "-l" for Make... I've got a little more tweaking I still want to do, but this is pretty awesome... http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ ZZ >>> >>> Thanks for sharing! How do you determine the optimum value for -l? >> >> How do you get emerge not to display number of jobs and load average -- >> I only want to compile one at a time -- much safer that way and it is >> doing that, but now it displays all that load average and how many jobs, >> etc. -- any way to get rid of that display? >> > > Thank Zac for that. He thinks he knows what you want. ;-) Apparently not > huh? > > http://forums.gentoo.org/viewtopic-t-901858.html > > Just add --quiet-build=n to EMERGE_DEFAULT_OPTS in make.conf and it will do > it the old way. Oh! I hadn't realized there was an update to portage that changed that. Missed it on my main box, I suppose. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
Dale wrote: > cov...@ccs.covici.com wrote: > > Dale wrote: > > > >> cov...@ccs.covici.com wrote: > >>> Mick wrote: > >>> > On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: > > I just wanted to share an experience I had today with optimizing > > parallel > > builds after discovering "-l" for Make... > > > > I've got a little more tweaking I still want to do, but this is pretty > > awesome... > > > > http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ > > > > ZZ > Thanks for sharing! How do you determine the optimum value for -l? > >>> How do you get emerge not to display number of jobs and load average -- > >>> I only want to compile one at a time -- much safer that way and it is > >>> doing that, but now it displays all that load average and how many jobs, > >>> etc. -- any way to get rid of that display? > >>> > >> Thank Zac for that. He thinks he knows what you want. ;-) > >> Apparently not huh? > >> > >> http://forums.gentoo.org/viewtopic-t-901858.html > >> > >> Just add --quiet-build=n to EMERGE_DEFAULT_OPTS in make.conf and it > >> will do it the old way. > >> > >> Hope that helps. > > Thanks much. Don't these people have anything to do -- like fix ebuild > > bugs? Very strange indeed. > > > > Well, they had the poll but the dev thinks he knows better. So, this > is Gentoo and the devs rule the roost here. It's pretty much been > that way since I started using Gentoo back in 2003. I don't expect it > to change and you shouldn't either. ;-) Just do like I do, when > they change something, override it with your own setting. It works > for me. Yep, that is the nice thing about gentoo. Thanks. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] emerge -j, make -j and make -l
cov...@ccs.covici.com wrote: Dale wrote: cov...@ccs.covici.com wrote: Mick wrote: On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: I just wanted to share an experience I had today with optimizing parallel builds after discovering "-l" for Make... I've got a little more tweaking I still want to do, but this is pretty awesome... http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ ZZ Thanks for sharing! How do you determine the optimum value for -l? How do you get emerge not to display number of jobs and load average -- I only want to compile one at a time -- much safer that way and it is doing that, but now it displays all that load average and how many jobs, etc. -- any way to get rid of that display? Thank Zac for that. He thinks he knows what you want. ;-) Apparently not huh? http://forums.gentoo.org/viewtopic-t-901858.html Just add --quiet-build=n to EMERGE_DEFAULT_OPTS in make.conf and it will do it the old way. Hope that helps. Thanks much. Don't these people have anything to do -- like fix ebuild bugs? Very strange indeed. Well, they had the poll but the dev thinks he knows better. So, this is Gentoo and the devs rule the roost here. It's pretty much been that way since I started using Gentoo back in 2003. I don't expect it to change and you shouldn't either. ;-) Just do like I do, when they change something, override it with your own setting. It works for me. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] emerge -j, make -j and make -l
Dale wrote: > cov...@ccs.covici.com wrote: > > Mick wrote: > > > >> On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: > >>> I just wanted to share an experience I had today with optimizing parallel > >>> builds after discovering "-l" for Make... > >>> > >>> I've got a little more tweaking I still want to do, but this is pretty > >>> awesome... > >>> > >>> http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ > >>> > >>> ZZ > >> Thanks for sharing! How do you determine the optimum value for -l? > > How do you get emerge not to display number of jobs and load average -- > > I only want to compile one at a time -- much safer that way and it is > > doing that, but now it displays all that load average and how many jobs, > > etc. -- any way to get rid of that display? > > > > Thank Zac for that. He thinks he knows what you want. ;-) > Apparently not huh? > > http://forums.gentoo.org/viewtopic-t-901858.html > > Just add --quiet-build=n to EMERGE_DEFAULT_OPTS in make.conf and it > will do it the old way. > > Hope that helps. Thanks much. Don't these people have anything to do -- like fix ebuild bugs? Very strange indeed. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] emerge -j, make -j and make -l
cov...@ccs.covici.com wrote: Mick wrote: On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: I just wanted to share an experience I had today with optimizing parallel builds after discovering "-l" for Make... I've got a little more tweaking I still want to do, but this is pretty awesome... http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ ZZ Thanks for sharing! How do you determine the optimum value for -l? How do you get emerge not to display number of jobs and load average -- I only want to compile one at a time -- much safer that way and it is doing that, but now it displays all that load average and how many jobs, etc. -- any way to get rid of that display? Thank Zac for that. He thinks he knows what you want. ;-) Apparently not huh? http://forums.gentoo.org/viewtopic-t-901858.html Just add --quiet-build=n to EMERGE_DEFAULT_OPTS in make.conf and it will do it the old way. Hope that helps. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 5:39 AM, wrote: > Mick wrote: > >> On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: >> > I just wanted to share an experience I had today with optimizing parallel >> > builds after discovering "-l" for Make... >> > >> > I've got a little more tweaking I still want to do, but this is pretty >> > awesome... >> > >> > http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ >> > >> > ZZ >> >> Thanks for sharing! How do you determine the optimum value for -l? > > How do you get emerge not to display number of jobs and load average -- The display is something emerge will show you if you've asked it to build in parallel (which you did, by passing -j to emerge. That's different from putting -j in MAKEOPTS.) > I only want to compile one at a time -- much safer that way and it is > doing that, It's likely only doing that because there isn't anything it can immediately build that doesn't have what it's *currently* working on as a build dependency. I noted in my blog post that emerge's parallelization has many of the same limitations as make's that's one of the things I was talking about; there can be linchpin and keystone packages which need to be built before many others. libc would be an example. gcc is a frequent example. > but now it displays all that load average and how many jobs, > etc. -- any way to get rid of that display? Forget the display; it sounds like you don't want emerge building in parallel. In that event, don't pass "-j" to emerge. The display will go away. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
Mick wrote: > On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: > > I just wanted to share an experience I had today with optimizing parallel > > builds after discovering "-l" for Make... > > > > I've got a little more tweaking I still want to do, but this is pretty > > awesome... > > > > http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ > > > > ZZ > > Thanks for sharing! How do you determine the optimum value for -l? How do you get emerge not to display number of jobs and load average -- I only want to compile one at a time -- much safer that way and it is doing that, but now it displays all that load average and how many jobs, etc. -- any way to get rid of that display? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] emerge -j, make -j and make -l
On Sun, Nov 27, 2011 at 4:27 AM, Mick wrote: > On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: >> I just wanted to share an experience I had today with optimizing parallel >> builds after discovering "-l" for Make... >> >> I've got a little more tweaking I still want to do, but this is pretty >> awesome... >> >> http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ >> >> ZZ > > Thanks for sharing! How do you determine the optimum value for -l? I'm making an educated guess. >.> I figure that the optimal number of simultaneous CPU-consuming processes is going to be the number of CPU cores, plus enough to keep the CPU occupied while others are blocked on I/O. That's the same reasoning that drives the selection of a -j number, really. If I read make's man page correctly, -l acts as a threshold, choosing not to spawn an additional child process if the system load average is above a certain value Since system load is a count of actively running and ready-to-run processes, you want it to be very close to your number of logical cores[1]. Since it's going to be a spot decision for Make as to whether or not to spawn another child (if it hits its limit, it's not going to check again until after one of its children returns), there will be many race cases where the load average is high when it looks, but some other processes will return shortly afterward.[2] That means adding a process or two for a fudge factor. That's a lot of guess, though, and it still comes down to guess-and-check. emerge -j8 @world # MAKEOPTS="-j16 -l10" Was the first combination I tried. This completed in 89 minutes. emerge -j8 @world # MAKEOPT="-j16 -l8" Was the second. This took significantly longer. I haven't tried higher than -l10; I needed this box to do be able to do things, which meant installing more software. I've gone from 177 packages to 466. [1] I don't have a hyperthreading system available, but I suspect that this is also going to be true of logical cores; It's my understanding that the overhead from overcommitting CPU comes primarily from context switching between processors, and hyperthreading adds CPU hardware specifically to reduce the need to context-switch in splitting physical CPU resources between threads/processes. So while you'd lose a little speed for an individual thread, you would gain it back in aggregate over both threads. [2] There would also be cases where the load average is low, such as if a Make recipe calls for a significant bit of I/O before it consumes a great deal of CPU, but a simple 7200rpm SATA disk appears to be sufficiently fast that this case is less frequent. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
On Saturday 26 Nov 2011 15:22:15 Michael Mol wrote: > I just wanted to share an experience I had today with optimizing parallel > builds after discovering "-l" for Make... > > I've got a little more tweaking I still want to do, but this is pretty > awesome... > > http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ > > ZZ Thanks for sharing! How do you determine the optimum value for -l? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] emerge -j, make -j and make -l
Am 26.11.2011 16:34, schrieb Alex Schuster: > Michael Mol writes: > >> http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ > > 404, but http://funnybutnot.wordpress.com/2011/11/26/ seems to work. Yes, got it now as well. Thanks for "quoting" me, Michael ... but I also googled that command somewhere ... not my idea ... ;-) Stefan
Re: [gentoo-user] emerge -j, make -j and make -l
On Sat, Nov 26, 2011 at 10:34 AM, Alex Schuster wrote: > Michael Mol writes: > >> http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ > > 404, but http://funnybutnot.wordpress.com/2011/11/26/ seems to work. Should work now. Somehow, I triggered WP's "schedule a post" behavior. Might still come up as 404 if you've got caching which caches negatives. -- :wq
Re: [gentoo-user] emerge -j, make -j and make -l
Am 26.11.2011 16:22, schrieb Michael Mol: > I just wanted to share an experience I had today with optimizing > parallel builds after discovering "-l" for Make... > > I've got a little more tweaking I still want to do, but this is pretty > awesome... > > http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ URL ... not found
Re: [gentoo-user] emerge -j, make -j and make -l
Michael Mol writes: > http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ 404, but http://funnybutnot.wordpress.com/2011/11/26/ seems to work. Wonko
[gentoo-user] emerge -j, make -j and make -l
I just wanted to share an experience I had today with optimizing parallel builds after discovering "-l" for Make... I've got a little more tweaking I still want to do, but this is pretty awesome... http://funnybutnot.wordpress.com/2011/11/26/optimizing-parallel-builds/ ZZ
