From owner-freebsd-sparc64@FreeBSD.ORG Tue Aug 12 20:33:58 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C3F37B404 for ; Tue, 12 Aug 2003 20:33:58 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832F443F85 for ; Tue, 12 Aug 2003 20:33:56 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id AD1E444 for ; Tue, 12 Aug 2003 21:33:55 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7D3XtX05750 for sparc64@freebsd.org; Tue, 12 Aug 2003 21:33:55 -0600 Date: Tue, 12 Aug 2003 21:33:55 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030812213355.M22214@seekingfire.com> References: <20030807062536.GA68747@dragon.nuxi.com> <20030809084019.GA4704@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from drosih@rpi.edu on Mon, Aug 11, 2003 at 11:51:00AM -0400 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 03:33:58 -0000 On Mon, Aug 11, 2003 at 11:51:00AM -0400, Garance A Drosihn wrote: > At 1:40 AM -0700 8/9/03, Kris Kennaway wrote: > >On Sat, Aug 09, 2003, Garance A Drosihn wrote: > > > >> So, apparently the problem is something a bit more subtle than > >> just gcc 3.3 being slower to compile than gcc 3.2. Apparently > >> the August 9th system is a lot slower at *running* than the > >> early system. Do we have some other benchmarks we could run? > > > >This suggests that something might have been pessimized with > >the gcc 3.3 code generation on sparc. > > Well, I'm thinking that maybe we're blaming the wrong thing > for this slowdown. I have the results for a few more builds: > > realtime user sys > ---------- ------------- ------------ > build 1: 347m 33.407s 283m 0.162s 53m 45.805s > build 2: 387m 4.205s 315m 25.441s 59m 44.648s > build 3: 1238m 11.386s 1064m 31.148s 136m 54.366s > build 4: 384m 30.479s 312m 54.407s 59m 7.338s > I don't know where the slowdown is occurring. Obviously it is > something which clobbers a buildworld, so maybe disk access or > something like that (I have enough real memory that my system > never pages). That's why I was wondering if there were some > other benchmarks we could run. The only thing that I really do > with my freebsd/sparc machine is buildworld's of freebsd/sparc, > so there is nothing else where I would notice a major slowdown > (even if it were occurring). Disk access could indeed be a problem. Here's the build times and bonnie++ results on the original EIDE drive in my Ultra 5: time make buildworld: real 1485m0.214s user 915m40.322s sys 98m56.775s time make buildkernel: real 487m44.136s user 400m55.723s sys 24m34.634s bonnie++: # bonnie++ -d /usr/scratch/ -m caliban -u 0 Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP caliban 300M 8 92 1999 10 924 5 15 92 1887 6 72.4 21 Latency 2260ms 519ms 2964ms 1117ms 161ms 3688ms Version 1.93c ------Sequential Create------ --------Random Create-------- caliban -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 856 68 2968 89 2478 94 811 60 2817 84 2770 94 Latency 1589ms 250ms 3365us 1674ms 477ms 10394us 1.93c,1.93c,caliban,1,1060744776,300M,,8,92,1999,10,924,5,15,92,1887,6,72.4,21,16,,,,,856,68,2968,89,2478,94,811,60,2817,84,2770,94,2260ms,519ms,2964ms,1117ms,161ms,3688ms,1589ms,250ms,3365us,1674ms,477ms,10394us That's a slow disk. I have a 25Mhz decstation that outperforms the Ultra 5 on disk I/O. Unfortunately, I don't have drive timings from when the buildworlds where faster to compare, so this could be a red herring :-( Drive details: # dmesg | grep ad0 ad0: 8223MB [16708/16/63] at ata2-master WDMA2 > On build #3 I noticed that 'top' constantly reported the CPU > was 0.0% idle. Unfortunately I couldn't check that for build #4, > because I didn't have a 'top' which matched the running kernel... I also have the the 0% idle top during buildworld, even though I'm not using -jX. It seems odd to me - with disk I/O that slow, I would think that the CPU should be partially/occasionally idle during a buildworld. -T -- 1. Get enough food to eat, and eat it. 2. Find a place to sleep where it is quiet, and sleep there. 3. Reduce intellectual and emotional noise until you arrive at the silence of yourself, and listen to it. 4. - Richard Brautigan