stephent@tekchips.TEK.COM (Steve Tyler) (10/14/87)
Reply-Path: Some code compiled with the Ultrix C compiler runs 40% slower than when compiled with the 4.3BSD C compiler. I discovered this by comparing execution profiles of the same code compiled with the two compilers. In the Ultrix version, frexp(), which is a C library routine that separates a floating point number into mantissa and exponent, was the single most time-consuming routine. By disassembling frexp() in the compiled code with adb, I found that the Ultrix version is 27 instructions and the 4.3BSD version is only 5 instructions. For many C library routines there is a C code version and an assembly language version. Clearly DEC is using the slower, larger C code version of frexp(). This version computes the exponent by repetitively dividing its argument by 2 until it is less than 1 (or multiplying, if the argument already is less than one). The number of divides (or multiplies) is the exponent and the resulting double is the mantissa. The assembly language version simply extracts the appropriate bit fields from the argument to get the exponent and mantissa. Of course this is not portable while the C code is, but does Ultrix run on anything besides DEC/VAX hardware anyway?
bp@pixar.UUCP (The gift to be simple is the gift to be free. - Shaker theme) (10/16/87)
Reply-Path: DEC might be using the C version of frexp() because the assembler version uses instructions that are EMULATED on the microvax. The C version thus might run faster on the uvax. Bruce Perens bp@pixar
howie@cunixc.columbia.edu (Howie Kaye) (10/23/87)
Reply-Path: I was working on the 4.3 ndbm'ized passwd routines and recompiled ls(1) with them. We then timed ls both (old and new) to see what kind of improvement this would lead to. We tried out a pretty much "worst case" scenario: time /bin/ls -l /u/student where each of the 1878 directories had a different owner, all were near the end of the passwd file, and a lot of uid's not in the passwd file. Here are the results: 4.3: Ultrix: real 1m14.98s real 28m49.10s user 0m4.18s user 13m34.71s sys 0m12.38s sys 0m49.38s We thought this was pretty drastic. 29 minutes to do an ls -l, vs 1.25 minutes. It turns out that besides the basic speedup of using ndbm instead of the sequential passwd file, the Ultrix getpwuid/getpwnam routines make calls to try and get the passwd info off of yp. Since we aren't running yp, that seemed to be a bit of a waste. With 1300 entries in our /etc/passwd file, we are switching to a 4.3 passwd scheme. Most of the programs which seemed to be slow seem that way because they access the passwd file in "bad" ways. ------------------------------------------------------------ Howie Kaye howie@columbia.edu Columbia University hlkcu@cuvma.bitnet Systems Group ...!rutgers!columbia!howie