From owner-freebsd-sparc Mon Dec 9 6:18: 9 2002 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF4737B401 for ; Mon, 9 Dec 2002 06:18:06 -0800 (PST) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6478C43EB2 for ; Mon, 9 Dec 2002 06:18:02 -0800 (PST) (envelope-from mi+mx@aldan.algebra.com) Received: from misha.murex.com (250-217.customer.cloud9.net [168.100.250.217]) by corbulon.video-collage.com (8.12.6/8.12.6) with ESMTP id gB9EHkjJ070316 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 9 Dec 2002 09:17:47 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) Content-Type: text/plain; charset="iso-8859-1" From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Michael.Schuster@sun.com, freebsd-sparc@freebsd.org Subject: Re: why would Sparc be soo sloow? Date: Mon, 9 Dec 2002 09:21:00 -0500 User-Agent: KMail/1.4.3 References: <3DF45D27.AC42361B@sun.com> In-Reply-To: <3DF45D27.AC42361B@sun.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212090921.00890.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Monday 09 December 2002 04:06 am, Michael Schuster wrote: = Mikhail, = = (I read -digest, so this may already be answered) = = > I'm puzzled by the poor performance of our SparcIII @900MHz. = = You need to give us some more information to even give an educated guess, = things like = - memory installed = - no# of CPUs installed Two SparcIIIs on the SunFire, one Pentium4 on the Dell. But the program is single threaded/processed. = - other HW config aspects, like storage in use, etc for both (!) = machines, as well as characteristic of the application, such = as = - memory footprint = - I/O behaviour, etc. Very little -- all the program is doing is computations -- the CPU is the bottleneck on both machines. It calls the same financial formula over and over -- for the same set of numbers. The numbers -- 8 double values per call -- are read using scanf(3) from a file, and the result -- 7 double values per call are written with a printf(3) to /dev/null. There are no file being opened/closed by the program at all... = Is anything else happening while you're testing, or do you have = exclusive access to the machines? Yes, there is. But not very much. And, once again, I'm measuring the CPU time, not the total time. = - iostat = - vmstat * = - mpstat * = - prstat = For obvious reasons, I cannot offer to analyse any data for you, I = hope though that this will get you going. I don't believe those utilities are going to help much -- this is a very simple program, with virtually no IO. The simple top(1) shows, that it is only limited by the CPU, and I remain puzzled by the speed difference, as well as by the high "system" time component on Solaris: mi@attila:~/fxpr/test (70) time ./fxprt < ../tasks.txt > /dev/null 819.11u 819.41s 28:35.00 95.5% mi@attila:~/fxpr/test (71) /usr/bin/time ./fxprt < ../tasks.txt > /dev/null real 28:27.5 user 13:35.6 sys 13:39.1 Very suprising, for, according even to truss(1), the program makes no system calls at all after the few at startup -- except for the very occasional read(2) and write(2) (to /dev/null). Indeed, on FreeBSD the "sys" part is negligeable. Is there a known problem with sys-time accounting on these systems: mi@attila:~/fxpr/test (76) uname -a SunOS attila 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R mi@attila:~/fxpr/test (77) uname -X System = SunOS Node = attila Release = 5.8 KernelID = Generic_108528-13 Machine = sun4u BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 Yours, -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message