Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!columbia!heathcliff.columbia.edu!metzger
From: metzger@heathcliff.columbia.edu.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Processing Instruction
Message-ID: <4504@columbia.UUCP>
Date: Fri, 27-Mar-87 14:26:33 EST
Article-I.D.: columbia.4504
Posted: Fri Mar 27 14:26:33 1987
Date-Received: Sat, 28-Mar-87 14:59:23 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <18036@ucbvax.BERKELEY.EDU>
Sender: nobody@columbia.UUCP
Reply-To: metzger@heathcliff.columbia.edu.UUCP (Perry Metzger)
Distribution: na
Organization: Columbia University CS Department, Project Synthesis
Lines: 20
Keywords: instruction set architectures, Am29000, printf
Xref: utgpu comp.arch:679 comp.lang.c:1353

In article <18036@ucbvax.BERKELEY.EDU> shebanow@ji.Berkeley.EDU.UUCP (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). In fact,
>I have seen programs which spend 30% of their time in printf (actually
>_doprnt). In the code I have optimized, I usually try to eliminate the
>use of printf (which can make the code rather opaque). This does result
>in 10-20% improvements in speed. The most obvious use of new string
>processing instructions would be to improve the performance of printf.
>Has anyone done this?

Here at Project Synthesis we found that out a while back. It is pretty
strange to think of it that way, but yes, Printf and friends are
compute bound, not I/O bound. We have experimented with a number of
solutions, including a hardware printf coprocessor for the 68020.
Predictably, it improved performance quite a bit. We also have tried
using specially coded versions of printf in assembly language that we
passed through a (very time expensive) exhaustive search optimiser and
the results were also pretty good.

Perry Metzger