From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24840 invoked by alias); 20 Jun 2011 13:35:59 -0000 Received: (qmail 24753 invoked by uid 22791); 20 Jun 2011 13:35:58 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta13.emeryville.ca.mail.comcast.net (HELO qmta13.emeryville.ca.mail.comcast.net) (76.96.27.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 13:35:42 +0000 Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta13.emeryville.ca.mail.comcast.net with comcast id yD7M1g0071wfjNsADDbgH5; Mon, 20 Jun 2011 13:35:40 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta23.emeryville.ca.mail.comcast.net with comcast id yDbs1g00A0BKwT48jDbsKH; Mon, 20 Jun 2011 13:35:53 +0000 Subject: Re: [PATCH] parallelize g++ testing a bit more Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: Date: Mon, 20 Jun 2011 13:41:00 -0000 Cc: Nathan Froyd , gcc-patches@gcc.gnu.org, jason@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110617174709.GA3443@nightcrawler> To: Rainer Orth X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01460.txt.bz2 On Jun 20, 2011, at 4:06 AM, Rainer Orth wrote: > I've got a patch to do this, prompted by the use of UltraSPARC-T2 > machines with 8 cores/8 strands which are quite slow on their own: >=20 > [build, testsuite, v3] Increase gcc, g++, gfortran and libstdc++-v3 test= suite parallelism > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01633.html >=20 > but haven't yet incorporated Jakub's comments. Yeah, I would not even consider a patch that was count based. :-) Ideally= , what you want to do is to bin pack the completed in N seconds in B bins, = where B is related to the physical number of cores. The, there is _no_ ext= ra overhead for subdivision on 1 core, and on 10,000 core, it still works, = though, one is going to need slightly better 1 to B code. Anyone know of a= bin packer command line argument? We don't care if it is slow, because we= can bin pack every 10th run, and start with idealized times. I would have= contributed that sort of change a while ago, but didn't spot a bin packer.= I also did up code to pull from a single work list, but, dejagnu isn't st= ructured to do that. :-( That would be the best solution, but is much mor= e work.