From owner-freebsd-sparc Mon Dec 9 8:25:51 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 91D9F37B401 for ; Mon, 9 Dec 2002 08:25:48 -0800 (PST) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFF5E43E4A for ; Mon, 9 Dec 2002 08:25:44 -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 gB9GPVjJ070768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 9 Dec 2002 11:25:32 -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 Subject: Re: why would Sparc be soo sloow? Date: Mon, 9 Dec 2002 11:28:52 -0500 User-Agent: KMail/1.4.3 References: <3DF45D27.AC42361B@sun.com> <200212090921.00890.mi+mx@aldan.algebra.com> <3DF4AA47.2462C72@sun.com> In-Reply-To: <3DF4AA47.2462C72@sun.com> Cc: freebsd-sparc@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200212091128.52038.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 09:35 am, you wrote: = > = - 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. = = if this really is the case, patch 111722-01 may help you. Aha, thanks. Will investigate. = > 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 = = you're contradicting yourself: first you say "all .. computation" and next = you say "are read using scanf(3) from a file" Yes, I should've said "almost all". Technically, you are correct. Common sense-wise, however, serial reading of a single file, using the stdio in the most simple and vanilla way should not be causing such tremendous performance degradation... = > -- 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... = = but they're being read! And written. Let's see. The size of the input is 102053 bytes: % time cat ../tasks.txt > /dev/null 0.00u 0.01s 0:00.01 100.0% If scanf() reading and printf() writing is, indeed, over 80000 times slower than simple cat(1)-ing, than Sun has a lot more serious problem than a slow CPU... Awk(1) is, indeed, somewhat slower in user-time: % time awk '{ printf("%s", $0) }' ../tasks.txt > /dev/null 0.09u 0.01s 0:00.12 83.3% but the same nowhere near the observed 800+ seconds of sys time. This is why I was ignoring the IO from the beginning -- without _really_ contradicting myself :-) = > Very suprising, for, according even to truss(1), the program makes no = = which truss options are you using? you can use -u option to see = whether you're stuck in a library, and -d to get time stamps - this = can be quite illuminating. Indeed. Here is the snippet of ``truss -d'' output (-u and -d can not be combined, apparently?): 0.0070 read(0, " 0 . 0 1 0 8 4 0 1 0\t 0".., 8192) = 8192 0.0087 ioctl(1, TCGETA, 0xFFBEECA4) Err#6 ENXIO 0.0092 fstat64(1, 0xFFBEED18) = 0 0.0093 brk(0x00029A38) = 0 0.0094 brk(0x0002BA38) = 0 0.0099 brk(0x0002BA38) = 0 0.0100 brk(0x00033A38) = 0 72.9734 write(1, " 1\t 0 . 0 1 0 8 4 0 1\t".., 8192) = 8192 130.4944 read(0, " 0 0 0 0 0\t 0 . 0 0 0 0".., 8192) = 8192 149.3667 write(1, " 0\t 0\t 0 . 0 2 4 6 5 7".., 8192) = 8192 223.3566 write(1, " 8 2 7 9\t - 0 . 0 0 0 2".., 8192) = 8192 291.1369 read(0, " 0 4 1 8 2\t 0 . 0 9 6 6".., 8192) = 8192 329.6329 write(1, " 3\t 0\t 0\t 0 . 1 4 5 2".., 8192) = 8192 408.1788 write(1, " 5 0 9 1 4 9\t 1 1 3 7 .".., 8192) = 8192 444.3458 read(0, " 0 . 3 8 3 5 6 2\n 0 . 0".., 8192) = 8192 Notice the time between the read(2) and write(2) (some more is being written, so writes are more frequent). = > Is there a known problem with sys-time accounting on these systems: = = not that I'm aware of. = > Very suprising, for, according even to truss(1), the program makes = > no system calls at all =You're seeing the effects of trap handling. You mean, there are math-related exceptions? That's possible, but why are they so expensive on Sun? Or is FreeBSD/GNU making some potentially unsafe assumptions? The output is identical, so, may be, I can somehow turn off the extra safety on Solaris? Thank you, -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message