Xref: utzoo comp.os.vms:9621 comp.unix.questions:9926 comp.unix.wizards:11952
Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.os.vms,comp.unix.questions,comp.unix.wizards
Subject: Re: UNIX vs. VMS - SYSTEM FUNCTIONS
Message-ID: <302@auspex.UUCP>
Date: 25 Oct 88 17:29:23 GMT
Article-I.D.: auspex.302
References: <82@h.cs.wvu.wvnet.edu>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 28

>I have been timing the relative differences between the speeds
>of the functions "strlen" and "strcpy" as executed on UNIX
>and VMS.  Why is one system so much faster?  Is it just the machine
>mips that accounts for the differences?

Partially, but probably not entirely.

>VMS - We are running vms 4.7 with version 2.3 of the C compiler
>on a Vaxstation 2000. 
>UNIX - We are running Sun 3.5 (UNIX BSD 4.2) on a 3/280 set up
>as a multi-user system with 14 users connected via a multiplexor.

The 3/280 has a 25MhZ zero-wait-state (unless you get a cache miss....)
68020, which may well be faster than a VAXStation 2000 (is the 2000
about equal to a 780?  If so, the 3/280 has a much faster CPU - about 4x
faster...).

However, there is another issue.  C strings are zero-terminated, not
counted.  VAX string instructions don't, as I remember, know about zero
terminator bytes (unless you use "movtuc", but that adds extra overhead
for table lookup).  The 4.3BSD (and, I think, S5) VAX version of
"strcpy" first does a "locc" to find the null terminator, and then a
"movc3" to copy the string.  This requires two passes over the string. 

The 68K, however, isn't "helped" by having those string instructions, so
the 68K assembler-language version searches for the zero terminator
while it copies, so it only makes one pass over the string.  The loop
fits into the on-chip instruction cache on the 68020, so it runs fairly fast.