self-modifying code [(Re: TOP 10 (names in comp.sci)]

Terje Mathisen Terje.Mathisen at
Sun Aug 9 01:17:49 EST 1998

Andrea Chen wrote:
>         Electronic associative memories are possible and I believe do exist in
> certain caches.  Extending the size of the data held within and allowing
> the programmer direct use of these mechanisms could allow a flexible
> highlevel (call by name) system.

Yes, but if that api is only used once, then it is (almost by
definition) not timecritical, if you use it many times, then you will
still be better off to do a one-time lookup of the actual address and
then patch that in, i.e. standard link/load behaviour for any os.

> > >
> > >> [...]
> > >Perhaps most important, it's hard to make a good marriage
> > >between on-the-fly compilation and any kind of portability
> > >even between this and next year's CPU chip, let alone across
> > >platforms.
>         Is portability the long term direction?  It seems to me an alternative
> would be increasingly specialized architectures devoted to certain
> problems.
>         For example 1 of the big money items today is servers for SQL.  The
> base of this language is simple set theory which is
> used to build the more complex relational operations.
>         Now take the programmer associative memory I proposed.  Dump in the
> members (or the first few hundred) of the first set.  With some
> extension of the logic it seems possible to then sequentially take the
> members of the second set and see if they are members (intersection) or
> not (difference) of that first step.  It seems to me that it would be
> possible to increase the speed of (some) SQL operations by orders of
> magnitude.  Such a chip might lack sophisticated floating point
> operations and many other basics of standard designs, but it could
> dominate a multibillion dollar niche.

Sorry, no again: The really fast TPC test results all come from very
well-balanced systems, speeding up just one part of it, like the
compilation of SQL statements, will not result in significant

>         Similarly for massive text processing a design which searched for
> dozens of delimiters at 1 time could parse much more rapidly.

The Word Count utility I wrote in asm about 8 years ago (486-optimized)
could handle a user-specified set of word and line separator characters,
and it still ran faster than the disk transfer speed from a RAM-disk,
i.e. more than 10MB/s on a 486-33.

The only real bottleneck on problems like these is the need for a
(small) lookup table to do text classification.

The same code today gets more than 100 MB/s on a PII, again making io
the speed limiter.


- <Terje.Mathisen at>
Using self-discipline, see
"almost all programming can be viewed as an exercise in caching"

More information about the Neur-sci mailing list