🚀 go-pugleaf

r
Keywords: 

In article <909@spar.SPAR.SLB.COM> freeman@spar.UUCP (Jay Freeman) writes:
>In article <978@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes:
>
>> My question is this:  How likely is it that a compiler itself will be able to
>> detect the case when it can use an instruction like this and generate code 
>> automatically to use it.  One of the positive points to the RISC debate is
>> that it brought out the point that useful instructions which are hard for a
>> compiler to generate are not always a win.  
>
>Note that this particular instruction may well win even if no compiler EVER
>generates it:  BCase's posting stated that hand-modifying the object code
>for two string-processing routines in the standard C library to use the
>instruction, and arranging that the compiler word-align strings where
>possible, effected consequent frequent improvements in run time of 15-20
>percent.  That sounds like a substantial win for C programming, and surely a
>fair amount of the code that does get written for this processor will be in
>C.  That may be reason enough for the instruction's existence.
>
>Although the point from the RISC debate, that LaMaster summarizes above, is
>carefully qualified, it is perhaps nonetheless too narrow a view:  Surely
>there are many other cases in which a well-planned library of calls to
>functions coded with particular care, will allow efficient use of highly
>specialized instructions.  Proper analysis of whether or not to include a
>given instruction in an instruction set should include the effect of such
>cases.

This is a fairly interesting and useful discussion, especially if we
can generate a few answers. Amusingly enough, neither MIPS nor IBM
put this instruction in, although Marty Hopkins (IBM) once offered a desire to
have it (even though it disobeyed the "must be useful from compilers
rule"), and we've thought about it off and on.

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?
It would be very interesting for people to be able to try the test cases
on some different machines and see how mcuh time is spent on these.
2) for anybody:
	a) What percentage of your machine's daily work is spent doing
	str* routines?
	b) Of that, how much is getting there and getting set up, and
	how much is in the fundamental loops?
	c) For each of strcpy, strcmp, and strlen, what is the distribution
	of lengths of argument?
	d) For strcmp, what is the fraction of times it finds equality.
	e) What fraction of strings begin on non-word boundaries/
	f) For strcpy and strcmp, what fraction of calls start on word
	boundaries, what fraction don't start on words, but at least have
	similar alignment within the word, and what fraction are completely
	misaligned.
[I think that there is actually a useful MS thesis around in here if done
well.]

Finally, regarding the inclusion of hand-coded cases, i.e., of instructions
that can't be gotten to from compilers, but may still be useful, our
sense is that there aren't very many like that.  This one is one of the
few like that [the others we've generally considered have often been
compilable] that at least has seemed plausible to lots of us.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086