On Sun, Jun 15, 2014 at 09:10:12AM -0500, William Harrington wrote: > > Also, you should consider using number of processors with +1. > Also, some build systems will fail to complete with even number of jobs. (In > the past CD Paranoia would fail to build in such an instance and the > Makefile would need to be patched) All of the packages in LFS should be > fine with an even number, but don't use it with the idea that because it has > always worked in the past, it will work with all future build systems. > > A system with lots of RAM will have a limiting factor of CPU time with a > long build (test this with a gcc build). > One task per CPU plus one pending task for occasional I/O blocks is a good > setting. > > With little amount of RAM there is a limiting factor of nat having very many > jobs, which will make them swap out. There's no general figure. Most > machines these days will not have that problem. So this can probably be > disregarded. > > It may be beneficial to have more jobs. If each compiler process is small > and touches a lot of data then then disk I/O could be a blocking factor. In > that case, you'll want several jobs per cpu at once so there is always one > job using each CPU while others are waiting for I/O > > All of this is variable depending on the build job and available RAM. There > is an optimum setting, which after having too many jobs will pollute the > cache too much. > > You will need to experiment. Normally with your quad core machine, -j5 will > be fine. > William, many thanks for that detailed exposition. I have (often) seen people recommending N+1 jobs, but without any explanation of why it could be a good idea. Until a couple of years ago, all my machines were single processor : and when I tested, -j2 seemed to be a lot slower than -j1. I have also seen kernel devs mentioning that they use large numbers of jobs. You persuaded me to take the time to build my normal kernel configs (for 3.15.0) on each of my desktop boxes. Each of these machines has motherboard graphics, which steal some of the RAM, and in 32-bit mode there might be other things stealing memory from the 32-bit address space (I do not use PAE - bounce buffers offend me :)
On my least-powerful box (AMD A4-5300, 2x3.4GHz) in 64-bit mode my most recent system is LFS-7.4. There, -j3 is slightly slower than j2. Remaining notes are for LFS-svn-20140514. The A4 in 32-bit mode reports 2.5GB memory. There. -j3 is faster (by 30 seconds) than -j2, and -j4 is similar to -j2. The Phenom (4x3.4GHz, 7.9GB reported memory, 64-bit only) takes approximately the same time for -j4 to -j8. -j6 is fastest by about two seconds, then it starts to slow down again, but these differences are really lost in the noise. My intel SandyBridge i3-2120 is interesting. 64-bit only, 3.9GB of RAM is reported. It has two real cores, but 4 with hyperthreading (so, four penguins). This is actually faster than the Phenom (for their own respective configs - the contents might be very different) at -j1 and -j2, but it gains not much benefit from the third and fourth jobs. At -j5 it is slightly slower than with -j4. Of course, the results of running multiple C++ jobs in parallel might be very different. I also suspect that things do change with different versions of the toolchain. So, test now, and test again in the future! ;-) Brief summary - on my system which still does 32-bit builds, -j N+1 appears to be beneficial. For all of my 64-bit builds, -j N is about as good as it gets. This is with (cheap, slow) spinning rust (and ext4). I'm sure that people using SSDs might get very different results. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
