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>