Re: suggest 'make -j2' for SMP machines?
Deskin Miller wrote: Is this worth adding to the book? Most definitely IMHO. Multi-core systems will soon be the norm. It's just crazy not to take advantage. There used to exist a SMP hint somewhere. Maybe this is it: http://www.linuxfromscratch.org/hints/downloads/files/OLD/parallelcompiling.txt A lot of seasoned SMP-building folks work on the basis of make -j X+1 ie: make -j3 if you have 2 cpus or 2 cores. As a person who has been building in parallel for a long time, I strongly disagree with a comment elsewhere in this thread about performance plummeting if overutilizing. I'm continuing building using make -j2, and haven't had any issues with it thus far; if I do discover any, I'll be sure to post about it. For the record, the DIY Refbuild has had optional `make -jX' support for years. Although I implemented it in a slightly sledgehammer fashion by exporting MAKEFLAGS eg: export MAKEFLAGS=-j3 The gotcha with this approach is *ALL* invocations of `make' are affected, even those for `make install'. This can lead to some interesting failures. But it's easy enough to work around, just add `-j1' to the known-to-fail cases. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
Mohan wrote: I've actually seen some improvement on compile times running Athlons and such as well with -j2... I suspect it fills time the compiler spends waiting for this or that read, or write, or something. There are certainly a lot of packages I've run into that have trouble with parallelization, though. Not that it's much of a problem to just start the compile again without -j2. I've only just completed my 1st LFS build, having come from 3 years on Gentoo, where the '-j' flag is one of the standard options. Their recommendation (listed in /etc/make.conf.example) is to set it to the number of cpu's plus one, which for my AthlonXP meant '-j2'... ...I completely forgot it's existence during this LFS build, without it i'm almost positive that my compile-times were faster (toolchain packages more than twice as fast). So now i'm thinking that Gentoo's recommendation is somewhat innacurate, would be better worded as set -j to the number of cpu-cores or some such, having no personal experience of such a configuration, but agreeing with the theories set forth in this thread... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
Greg Schafer wrote: A lot of seasoned SMP-building folks work on the basis of make -j X+1 ie: make -j3 if you have 2 cpus or 2 cores. As a person who has been building in parallel for a long time, I strongly disagree with a comment elsewhere in this thread about performance plummeting if overutilizing. (Note this is all theoretical: I haven't really tested it. I've built a few packages with -j2 on my dual-core machine, but I never looked into the optimal -j setting much. So if you use X+1 and it works well, that probably trumps my guesses.) I recently got access to a dual-core laptop (1.6GHz core 2 duo, 512MB RAM). I measured the machine's SBU using -j1, -j2, -j3, and -j4. The SBU includes unpacking binutils, building, installing, and removing the sources. Configure and Make install are not parallelized. -j1: real 3m20.447s user 2m18.153s sys 0m36.218s -j2: real 1m50.967s user 2m8.160s sys 0m32.510 -j3: real 1m42.912s user 2m7.948s sys 0m33.666s -j4: real 1m46.869s user 2m8.840s sys 0m33.970s -j5 returns almost the same results as -j4. I wonder how many jobs Make actually creates when compiling binutils with make -j... Make -j (with no arguments) creates as many jobs as possible, and the results are interesting: real 2m28.837s user 2m14.148s sys 0m37.246s If you have one CPU, and make runs two jobs, *and* both jobs are CPU-bound, then performance will probably only be slightly worse than running one job. The overhead of switching between the two tasks will take some time, but not very much. I agree with all you say, but I believe you're missing something more important than context switches: cache and bus conflicts. These are the main reason performance suffers when a core is running more than one active thread. The dual-core CPUs are very sensitive to having their data and instructions ready the instant they need it. Also, each application requires special tuning to really, really get every drop of performance out of multicore CPUs. Valgrind or Intel's VTune (an amazing tool) really help here. Make's -j is really a blunt hammer, it just throws tasks to the cores without any special consideration for how it will impact performance. And here's my guess for why X+1 works well: most compiles don't seem to be entirely CPU-bound. When compiling packages, I can see my (per-core) CPU usage, and it's not usually 100%. I suspect the cost of going after the disk to load the source files in and write the object files out (not to mention the temp files if you don't use -pipe) is much greater than the cost of parsing and optimizing a small C file. And lots of packages (maybe most?) seem to be made up of many small C files. I'd say the same thing. -- Miguel Bazdresch -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
On 6/4/07, Greg Schafer [EMAIL PROTECTED] wrote: Deskin Miller wrote: Is this worth adding to the book? Most definitely IMHO. Multi-core systems will soon be the norm. It's just crazy not to take advantage. There used to exist a SMP hint somewhere. Maybe this is it: http://www.linuxfromscratch.org/hints/downloads/files/OLD/parallelcompiling.txt A lot of seasoned SMP-building folks work on the basis of make -j X+1 ie: make -j3 if you have 2 cpus or 2 cores. As a person who has been building in parallel for a long time, I strongly disagree with a comment elsewhere in this thread about performance plummeting if overutilizing. I completely agree with what you're saying and I've been using j3 for quite a while now on a dual core. It's much faster and performance doesn't plummet, AFAIK. Basically, just how much load do you want to put on the cpu? If you have two cpus, eight jobs, and they each use 25% of a single CPU, I don't know if that will finish in less time than two jobs maxing out each CPU. I'm still not sure it deserves a spot in _this_ book, though since we don't even point out the gcc optimizations, either. Anyone with a whiff of experience is going to know about using parallel jobs in make. But... The gotcha with this approach is *ALL* invocations of `make' are affected, even those for `make install'. This can lead to some interesting failures. But it's easy enough to work around, just add `-j1' to the known-to-fail cases. Exactly. You're counting on the Makefile to have well constructed dependencies. With most automaked projects, this is taken care of unless there are also custom rules in Makefile.am. In non-automaked projects, you can almost guarantee that make will race. It would suck to have a bunch of noob questions about broken builds because of this. You make a good point, though, about the simplicity of the workaround. Possible text to appear at an unknown location in the LFS book: The `make' utility allows multiple jobs to be run simultaneously when building packages. This can allow a significant speed increase on multiple processor systems. This is controlled by passing the -jjobs option to `make'. For instance, you might execute `make -j2 install' on a dual-core system. The problem with this approach is that it depends on a well written Makefile to support multiple simultaneous jobs. If there is a build error, it is important to remove the jobs option to ensure that this is not the cause of the error. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: misc observances
El Lunes, 4 de Junio de 2007 02:45, Archaic escribió: On the vim page, where the docs are symlinked, a hardcoded reference to vim70 exists. This one has been fixed in r8148. Thanks. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: extrapaths.sh
On 5/27/07, Dan Nicholson [EMAIL PROTECTED] wrote:
Ah, you're right. LFS used to create /opt/{bin,lib,include,...} for
you. But not anymore.
http://www.linuxfromscratch.org/lfs/view/6.1/chapter06/creatingdirs.html
http://www.linuxfromscratch.org/lfs/view/development/chapter06/creatingdirs.html
So, yeah. I only thought it should be supported because I thought we
should support the setup that LFS has. If people want to support that,
then they can make the setup themselves.
Maybe a note about it should be left in the book with the script you
included above, just to get people's brains going about the
possabilities they can mangle together with the /opt directory. But
in the long run, leave it up in the air as to how it should actually
be done. The reason I suggest to do that is because there isn't
exactly a whole lot of information about /opt around on the net that
is easy to find outside of FHS, and it drives the point that it is
really ultimately up to the user / administrator / monkey on a
typewriter.
Just my two cents on the matter.
Jonathan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
Miguel Bazdresch wrote: I agree with all you say, but I believe you're missing something more important than context switches: cache and bus conflicts. These are the main reason performance suffers when a core is running more than one active thread. Right, I kind of assumed that stuff was part of the context-switch overhead. The cache wouldn't need to flush (and wouldn't suddenly be filled with useless data, which is effectively the same thing) if the same physical addresses were coming from the CPU; once the CPU starts running another process, those physical addresses will all start changing. OTOH, by your numbers, overall performance (at least on binutils) doesn't suffer until you get to 4 jobs on the 2 cores. And even then, it's a fairly small difference. Well, whatever. I like Dan's idea, FWIW (mention the -j option in the text, but put a cautionary note in there saying that compile errors may happen, and to re-try the compile without -j if they do). signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
On 6/5/07, Bryan Kadzban [EMAIL PROTECTED] wrote: I like Dan's idea, FWIW (mention the -j option in the text, but put a cautionary note in there saying that compile errors may happen, and to re-try the compile without -j if they do). That's pretty much what I was thinking initially, before this turned into the 'optimum make -j parameter' thread. A simple paragraph, making it abundantly clear that build failures with make -j should first and foremost be re-done (from a clean tarball unpack) with make -j1 should prevent most newbie complaints, and give everyone more bang for their buck. I think the people have spoken on this one. Thanks all for the useful feedback. -Deskin Miller -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
