gnu@hoptoad.UUCP (03/30/87)
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
henry@utzoo.UUCP (Henry Spencer) (03/31/87)
> 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... Careful, John, this code has a bug: on a signed-char machine, the result when comparing "" to "\203" will be wrong. Correct lexical comparison requires that the terminating NUL compare low against all characters, which is not the way subtraction works on a signed-char machine. This will get more important as ISO Latin becomes more common. Admittedly, many existing implementations of strcmp botch this too! -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry