[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Robert S. Boyer <boyer@CLI.COM>: Fast IO]
- To: cl-cleanup@sail.stanford.edu
- Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
- From: masinter.pa@Xerox.COM
- Date: 17 Apr 89 12:44 PDT
- Cc: wfs@CLI.COM, boyer@CLI.COM
- Reply-to: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
If two implementations need some declaration for 'simple' streams so that
READ-CHAR and friends can be fast, maybe this is a more generally felt
need? I thought I'd go ahead and forward to a wider forum....
----- Begin Forwarded Messages -----
Date: Mon, 17 Apr 89 14:31:51 CDT
From: Robert S. Boyer <boyer@CLI.COM>
To: masinter.pa
Cc: wfs@CLI.COM, jonl@lucid.com
Subject: Fast IO
Reply-To: boyer@cli.com
Sorry for not being informative about read-char, fast-read-char, and
:in-line.
In both Lucid and AKCL, it takes about 60 microseconds on a Sun-3/280
to do a read-char or read-byte in the usual case. That is a lot of
time! I am not really sure why it should take so long, but it does.
Something about doing necessary checking that the stream is not fancy,
bidirectional, etc., etc. (I am not making exact timing remarks here
-- just ballpark.)
Of course, in Unix on a Sun-3/280, the C programmer can get a
character in a couple of microseconds (again, ballpark). So both
Lucid and AKCL have non-CLTL extensions to make it possible to move
characters at microsecond speeds. Lucid does this by defining 6
functions that have a "fast-" prefix, e.g. fast-read-char. AKCL
(1.112) adds a new declaration (:in-line) whose semantics is something
like "I hereby assert that here is a really simple sort of stream and
I want the AKCL compiler to therefore lay down fast code for
read-char".
If these explanations don't suffice, I'm in over my head. I am
speaking here just as a user, not an implementor; but I am a user who
sees the necessity of a fast way to read characters in any Common
Lisp. I suspect that since both AKCL and Lucid have run into this
problem, other von Neumann machine Lisps will too. (In fact, my
recollection is that read-char stood a lot of room for speeding up on
Lispms, too, perhaps for the same reasons.)
I personally like the AKCL idea of somehow adding a declaration that a
stream is "simple". As it is, in our theorem-prover code we now do a
(proclaim '(declaration :in-file)), which, as I understand it, means
that :in-file declarations will be ignored by, say, the Lucid compiler
or any other compiler that doesn't know about :in-line. read-char
will go fast in AKCL, but the code will also work in Lucid. If we
were to use Lucid's fast-read-char, say, that would work for Lucid but
we would need dialect conditionals defining such a function to get
fast-read-char to work in other Lisps besides Lucid. We abhor dialect
conditionals.
I would much prefer a CLTL uniform nomenclature, any nomenclature,
fast-read-char, :in-line, or anything else.
Thanks,
Bob
P.S. If you have any serious questions about :in-line, I suspect that
Schelter (wfs@cli.com) will be happy to answer them.
----- End Forwarded Messages -----