Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!amdcad!bcase
From: bcase@amdcad.UUCP
Newsgroups: comp.arch
Subject: Re: String Processing Instruction
Message-ID: <15315@amdcad.UUCP>
Date: Fri, 27-Mar-87 18:56:42 EST
Article-I.D.: amdcad.15315
Posted: Fri Mar 27 18:56:42 1987
Date-Received: Sat, 28-Mar-87 16:03:48 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <909@spar.SPAR.SLB.COM> <230@winchester.mips.UUCP>
Reply-To: bcase@amdcad.UUCP (Brian Case)
Distribution: na
Organization: Advanced Micro Devices, Sunnyvale, California
Lines: 49

In article <230@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes:
>At one point, I did some hunting around for statistics on the use of the
>str* routines, how much time was spent in them, the distribution of
>string lengths, etc [you may have seen postings to such effect in
>the last few years in this group].  Weirdly enough, either nobody knows
>very much about the global nature of this, or nobody's telling.
>We did some rummaging and profiling of code, and were astonished to find
>the actual amount of time spent in the str* routines to be pretty small.
>[This was very non-intuitive to me.] Maybe we looked at the wrong things.
>So, now a few questions:
>1) for Brian: could you say which programs you got the big improvements on?

Well, there is, of course, dhrystone.  Now, now, calm down, we here know
very well that dhrystone is *quite* skewed away from reality.  But we
have to pay homage to dhrystone for pointing this out to us and making us
find a solution (I think it is so typical that something we thought was
at least a little original happens to have been thought of by many other
people long before us!  Oh well, "All the good ideas have already been
had.")  We are at this moment dredging up our early results.  However,
most have been deleted by this time.  But, and I think I remember
correctly, dhrystone and our assembler were the two big ones.  However,
I think the compiler will also show a benefit as will any program that
does some comparing against fixed strings (e.g. I usually implement opcode
lookups and such with a binary search through a sorted array of strings).

So, I would like to turn the question around, John, and ask you to do
what we might find difficult:  look at the dynamic execution of your
compiler.

Well, Tim just resimulated nroff:  the conclusion is that strcpy() isn't
worth talking about.

Sigh, it may be that there are just a few important programs that will
benefit.  Out of the 100 most popular programs, maybe two benefit sub-
stantially from the compare-bytes instruction.  But if those two are the
most popular (or close to it), it might still be worthwhile to have the
instruction.  Dhrystone is either important or not depending upon how
much time you spend running benchmarks or how paranoid one is. :-)

Ok, so now Tim tells me that the assembler spends about 17% of its time
in strcmp() (strcpy() is less than 1% in this case).  And note that this
17% is *including* the effect of our compare-bytes instruction, without
the instruction the percentage would be much larger (how much?  I don't
think we have the old version of strcmp() sitting around.  Sorry).

I agree, there is an MS thesis here (and the CS community would thank
you a lot!).

    bcase