From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-131669-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1RUtlX-0007wd-4e
for garchives@archives.gentoo.org; Mon, 28 Nov 2011 05:28:32 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C1A7B21C12D;
Mon, 28 Nov 2011 05:28:12 +0000 (UTC)
Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212])
by pigeon.gentoo.org (Postfix) with ESMTP id 12EFE21C0C6
for <gentoo-user@lists.gentoo.org>; Mon, 28 Nov 2011 05:26:53 +0000 (UTC)
Received: from mail-bw0-f53.google.com ([209.85.214.53])
by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128)
(Exim 4.69)
(envelope-from <pandu@poluan.info>)
id 1RUtjy-001O24-3T
for gentoo-user@lists.gentoo.org; Mon, 28 Nov 2011 12:26:54 +0700
Received: by bkaq10 with SMTP id q10so9471856bka.40
for <gentoo-user@lists.gentoo.org>; Sun, 27 Nov 2011 21:26:49 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.12.68 with SMTP id w4mr42965076bkw.31.1322458009212; Sun,
27 Nov 2011 21:26:49 -0800 (PST)
Received: by 10.223.96.72 with HTTP; Sun, 27 Nov 2011 21:26:48 -0800 (PST)
Received: by 10.223.96.72 with HTTP; Sun, 27 Nov 2011 21:26:48 -0800 (PST)
In-Reply-To: <CA+czFiAOv4sq0saX7CwVCA=09rVt4BtK1Ef7k=xUNtG6x6_YYQ@mail.gmail.com>
References: <CA+czFiB4pSTcVTgAbRnL6AUgGoE9E7gsg-1O0LgfU4FVF_DB+Q@mail.gmail.com>
<CAK2H+ecGHe=9_RVtM-FOWmyaJ-S5YJ4+2qtYov49v9n=PSQwtA@mail.gmail.com>
<CA+czFiAOv4sq0saX7CwVCA=09rVt4BtK1Ef7k=xUNtG6x6_YYQ@mail.gmail.com>
Date: Mon, 28 Nov 2011 12:26:48 +0700
Message-ID: <CAA2qdGX_yPj8Yaafk6VMAjV1QU5yDyJ3KC2up_wgG6iAMJtC0A@mail.gmail.com>
Subject: Re: [gentoo-user] emerge -j, make -j and make -l
From: Pandu Poluan <pandu@poluan.info>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=0003255581c2de97ea04b2c4bf33
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com
X-AntiAbuse: Original Domain - lists.gentoo.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - poluan.info
X-Archives-Salt: 98786b8e-7334-4d02-9b40-c8edac7c8df8
X-Archives-Hash: c59b7f1873247f3fd30a7bbc4b201607
--0003255581c2de97ea04b2c4bf33
Content-Type: text/plain; charset=UTF-8
On Nov 28, 2011 11:32 AM, "Michael Mol" <mikemol@gmail.com> 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,
--0003255581c2de97ea04b2c4bf33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p><br>
On Nov 28, 2011 11:32 AM, "Michael Mol" <<a href=3D"mailto:mik=
emol@gmail.com">mikemol@gmail.com</a>> wrote:<br>
></p>
<p>----- >8 snip</p>
<p>><br>
> MAKEOPTS would be -j16, -l10. (Which actually goes up to about 12 or<b=
r>
> 13 based on that N*1.6 behavior)<br>
></p>
<p>----- >8 snip</p>
<p>Just in case anyone wonders where the multiplier "1.6" comes f=
rom:</p>
<p>There had been a discussion somewhere (I forgot where exactly, sorry) ab=
out load numbers. The final conclusion was that the ideal load number for t=
oday's processors is 2*N, because with the out-of-order capability of m=
odern processors, two instructions can overlap in the pipeline, even withou=
t hyperthreading.</p>
<p>Unfortunately, striving for 2*N will inadvertently result in short burst=
s of > 2*N, and this potentially induce a stall, which will be very cost=
ly. 1.8*N gives a 10% margin for burst activities, while 1.6*N gives a 20% =
margin.</p>
<p>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.</p>
<p>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.</p>
<p>Rgds,<br>
</p>
--0003255581c2de97ea04b2c4bf33--