guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JACAL, scm


From: Tom Lord
Subject: Re: JACAL, scm
Date: Wed, 26 Sep 2001 02:04:11 -0700 (PDT)

      Since good performance is apparently a goal, I'm surprised to have
      not gotten any positive uptake on my suggestion of merging the I/O
      system from Systas with Guile.

   does systas have a performance-measuring framework we can adapt for
   guile?  is it accessible from scheme?


Nothing that isn't also in SCM; that's been enough to make relevant
measurements, confirming what is "easy" to predict.

Programming experience, knowledge of how the systems calls work,
knowledge of computer architecture, and knowledge of how stdio, the
ports procedures, and the VU I/O library are implemented can help you
to understand why the Systas I/O system is a winning design in terms
of performance (depending, of course, on how it is used) -- and quick
double checking with procedure timings confirm the most obvious
predictions (both good and bad) for the current release.  Familiarity
with previous work on alternative I/O libraries, such as the "Safe
Fast I/O" library from Bell Labs, can help you grok the design of the
Systas I/O substrata from just a brief look at the source; and it can
help you figure out what work remains to be done.  Writing and
profiling a lot of C code for which efficient I/O is important can
improve your visceral awareness of the issues: I recommend you master
`gprof' and practice by writing simple shell tools.  Make a habit of
reading compiled code for performance-critical sections as you write
them, experimenting with various optimization levels and other
compiler options.  Writing a lot of Lisp and Scheme code for which
efficient I/O and string handling is important can improve that
awareness further.  I recommend implementing at least two low-level
I/O libraries yourself to get a better feel for how they can get out
of control, and how best to keep them clean and well organized.
Reading some of Olin Shiver's critiques of the standard C library
gives some enhanced perspective.  Writing enough C code that the
bogosities of stdio start to hurt every time you encounter them isn't
a bad idea either.  I won't let the opportunity to recommend John
Bently's entertaining book "Writing Efficient Programs" pass by, even
if the present excuse is weak.  Have I left something out?  I'm sure
of it.

I sometimes write tersely presuming that the engineers in the audience
either share a common background in many of those areas, or are, more
likely, proactively engaged in obtaining such a background.  That
presumption isn't always true -- too many of us have day jobs that
don't encourage that, I suppose.

But more to the point: I withdraw all of my suggestions for Guile.
The maintainers don't have time to consider them, no doubt because
they are busy developing a novel theory of manners as applied to
reasoned discourse.  :-).

-t

"You don't have to get snippy about it." -- Al Gore




reply via email to

[Prev in Thread] Current Thread [Next in Thread]