🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13334

Re: String Processing Instruction -- printf, strcpy.

#13334
From: gnu
Date: Mon, 30 Mar 1987 11:47
43 lines
2960 bytes
In article <18036@ucbvax.BERKELEY.EDU>, shebanow@ji.Berkeley.EDU (Mike Shebanow) writes:
> Every time I trace a program which uses stdio to any great degree, I find
> printf to be the worst offender (with regard to time consumed).

At one point there was a new-hire at Sun who was busily going through 
the compiler replacing most of the printf's with puts's and such.  Chris
Aoki and I looked at each other for a few minutes and then did some timings.
The new-hire was right, printf was slow, but we put in the right fix:
we sped it up, and left the compiler alone!

Turns out that it was doing an amazing amount of parsing to handle the
simplest of cases.  Just adding a front-end to printf that handled %s,
%d, %c, %o, %x, and the "h" and "l" versions of these, sped the whole
thing up by a large factor (don't remember the factor).  If you used
something beyond these simple capabilities, it punted to the old
general case code.  But 99% of the printf strings ran in the trivial front
end.

When Geoff Collyer and I were speeding up "C news", we often found
that stupid algorithm design was responsible for slowness, particularly
calling string compares or string cat's in inner loops.  Don't fix
the instruction set, bunky, fix the applications!

Similarly, I have a strong suspicion that compiling strcmp(a,b) to:

	subtract *b from *a
	if nonzero, you have the result
	else call strcmp()

(say using the nice _inline_ stuff in the draft C standard) would speed
it up a lot more than all the instructions you could imagine.  It certainly
had that effect in C news when we did just that with a macro.

I too am curious about the "printf coprocessor" for the 68020.  Was this
a paper design or did it actually get built?  Considering the 68881 can
format an integer or float into decimal (BCD, but the hard part is done),
I can't see it winning much at all.  Also remember that for a coprocessor
to access main memory takes twice as long as for the 68020 to do it -- 
so you don't want the CP scanning out format strings and such.
-- 
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu
Technical Details
Message-ID: <1944@hoptoad.uucp>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!lll-crg!hoptoad!gnu
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <18036@ucbvax.BERKELEY.EDU>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!lll-crg!hoptoad!gnu
From: gnu@hoptoad.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Processing Instruction -- printf, strcpy.
Message-ID: <1944@hoptoad.uucp>
Date: Mon, 30-Mar-87 06:47:01 EST
Article-I.D.: hoptoad.1944
Posted: Mon Mar 30 06:47:01 1987
Date-Received: Tue, 31-Mar-87 06:04:14 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <18036@ucbvax.BERKELEY.EDU>
Organization: Nebula Consultants in San Francisco
Lines: 43
Keywords: instruction set architectures, Am29000, printf