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-dev+bounces-40786-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1O22Fw-0004bm-Iv
for garchives@archives.gentoo.org; Wed, 14 Apr 2010 13:03:51 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9B710E087C;
Wed, 14 Apr 2010 13:03:45 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 88324E0907
for <gentoo-dev@lists.gentoo.org>; Wed, 14 Apr 2010 13:03:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 34F701B4022
for <gentoo-dev@lists.gentoo.org>; Wed, 14 Apr 2010 13:03:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 required=5.5 tests=[AWL=0.050,
BAYES_00=-2.599]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id patSVmpUQQDL for <gentoo-dev@lists.gentoo.org>;
Wed, 14 Apr 2010 13:03:31 +0000 (UTC)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
by smtp.gentoo.org (Postfix) with ESMTP id 780F11B4014
for <gentoo-dev@gentoo.org>; Wed, 14 Apr 2010 13:03:28 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
id 1O22FY-00079A-LV
for gentoo-dev@gentoo.org; Wed, 14 Apr 2010 15:03:24 +0200
Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Wed, 14 Apr 2010 15:03:24 +0200
Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Wed, 14 Apr 2010 15:03:24 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-dev] Re: [RFC] RESTRICT=parallel for builds that can't be executed in
parallel
Date: Wed, 14 Apr 2010 13:03:10 +0000 (UTC)
Message-ID: <pan.2010.04.14.13.03.10@cox.net>
References: <4BC52478.3020303@gentoo.org> <4BC564B7.2090103@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net
User-Agent: Pan/0.133 (House of Butterflies)
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 1e37d387-0e77-4e50-b606-c3a6ca24fa6d
X-Archives-Hash: bb558baa0736a42e4b4f97e9d5ae4d0a
Justin posted on Wed, 14 Apr 2010 08:46:15 +0200 as excerpted:
> On 14/04/10 04:12, Zac Medico wrote:
>> Hi everyone,
>>=20
>> Should we add a RESTRICT=3Dparallel value for ebuilds that can't be bu=
ilt
>> at the same time as other ebuilds? Brian says we need it for things
>> like xorg-server which calls eselect opengl.
>=20
> There is at least one other example which benefits from singlular build=
,
> atlas libs. They run a benchmark suite to create platform specific
> headers, which is heavily influenced by the system load. So having
> RESTRICT=3Dparallel would make the emerge more reliable.
sci-libs/blas-atlas (and perhaps lapack-atlas, etc, too), right? =20
"Automatically tuned..."
Wow! Yeah, that sounds like a reasonable example. Sort of like the=20
kernel does for md/RAID-5 and 6 at boot, I'd guess, choosing the fastest=20
algorithm on the platform, only they're doing it during system runtime=20
when who /knows/ what else is running! Having a second highly=20
parallelizable (MAKEOPTS version) build go from config to build and its=20
load go from say .8 to 8. in the middle of those benchmarks /could/ screw=
=20
things up "just a little!"
Thanks. That's just the sort of additional practical example I was askin=
g=20
for to try to get my mind around this. Excellent example as, unlike the=20
various xorg/mesa/drivers thing, it's pretty hard to argue "just code=20
around it", for this one. The only technical way out of it here would=20
seem to be to change the build-and-benchmark strategy itself, which would=
=20
rather defeat the "automatically tuned" bit entirely.
BTW, gcc seems to do some stage output comparing in its bootstrap=20
process. Is that all absolute code correctness, or is there some=20
performance benchmarking there that could benefit from this as well?
--=20
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman