Date: Mon, 9 Dec 2002 11:28:52 -0500 From: Mikhail Teterin <mi+mx@aldan.algebra.com> To: Michael.Schuster@sun.com Cc: freebsd-sparc@freebsd.org Subject: Re: why would Sparc be soo sloow? Message-ID: <200212091128.52038.mi%2Bmx@aldan.algebra.com> In-Reply-To: <3DF4AA47.2462C72@sun.com> References: <3DF45D27.AC42361B@sun.com> <200212090921.00890.mi%2Bmx@aldan.algebra.com> <3DF4AA47.2462C72@sun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212091128.52038.mi%2Bmx>