Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On 01/03/2014 04:03 PM, Mark Lee wrote:
On Fri, 2014-01-03 at 15:55 -0500, Isaac Dupree wrote:
On 01/03/2014 10:37 AM, Anatol Pomozov wrote:
Using -j$(cpunum) is a sane default that saves a lot of time to users.
I agree, but for the record, 'nice' and scheduling are no panacea in my experience. It's fine for CPU loads, but compilations are also disk-heavy (which mattered when I used a spinning disk) and sometimes RAM-heavy (-j8 on my pet C++ project uses 2GB of RAM, which could push other programs I'm using into swap).
-Isaac
Salutations,
I got to ask why you are running make with 8 threads on a system with only 2 GB of ram?
Heh. Well, I have 8 GB of RAM, but I'm often using most of it already. $(nproc) is 8 because there are 4 cores with each with hyperthreading (Intel Core i7). The project builds roughly at the same speed on this box at anywhere from -j4 to -j8; if that generalizes to other projects and there's an easy way to count cores not hyperthreads, cores might be a better Arch default. Shrugs. There are quite a few 4GB i7 systems out there too. Quad core ARM systems are another point on the cores-to-RAM-ratio spectrum. Probably most code doesn't consume 256 MB RAM per GCC invocation. C++'s templates and lack of module system... -Isaac
Isaac Dupree <ml@isaac.cedarswampstudios.org> wrote:
Probably most code doesn't consume 256 MB RAM per GCC invocation. C++'s templates and lack of module system...
Correct...also in special for C and other compilers. Important is to create more parallel instances then the number of available cores in order to have threads waiting for CPU while others are waiting for I/O. A rule of thumb is to invoke aprox. twice as many parallel build processes as the system has cores. This however is a rule derived on Solaris. On Linux, the scheduler may be worse and could impose a lower number. Also note that when doing parallel builds with gmake, the problem is that unlike dmake (as used on Solaris), gmake does not serialize the output. This causes problems when a build error has to be debugged. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
participants (2)
-
Isaac Dupree
-
Joerg Schilling