🚀 go-pugleaf

Terje Mathisen wrote:
> 
> 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.
> 


	The issue I was addressing was self modifying code.  It may be true
that associative memory would have little value in this, but I do feel
that for some programming problems direct associative addressing does
allow real time links to code and flexibility in structure.  
	I also think it possible to build a machine with literally tens of
thousands of associative members in which this high level structure can
contain much of the problem. Like McCartneys original lisp design or
Turings model and a number of other little logics, associative
structures can (theoretically) solve all computable problems with a set
of 7 or 8 basic operators (though others are needed for practical
purposes).  I find the associative logics to be more practical in
actually solving problems than others.
	During the seventies there was a lot of talk about "high level"
machines and later non Von Neumann architectures.

 
> > > >> [...]
> > > >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.

> 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
> improvements.


	People buy multiprocessors solely to run databases.  They don't do
graphics, they don't do much numerical calculation (and if so decimal is
more practical since it doesn't require 2 conversions and can be done
relatively quickly with tables.)  My belief is that computers will (in
the long run) evolve to increasingly resemble the human brain with many
specialized parts each assigned to various tasks.  There is already some
development along this line with graphic cards and for a lot of data
processing problems disk logic is more crucial than CPU.  There are many
places where a "well balanced" system isn't crucial.  In the work I've
done parallel pipelines which can do a floating point operation in a few
cycles are of little value.  We have this notion of a "general purpose"
computer, the problems for which it's optimized tend to be numeric.     
Incidently the example I gave had nothing to do with the "compilation"
of SQL statements (the last I checked it wasn't even a compiled
language.)  It had to do with the running of such statements.
It had to do with the processing.  If I could load a set (or a large
part of it) into the central processor this would be 1 memory operation
per member.  If the other set could then be compared it would take 1
memory operation to bring each member up.  Incidently because we are
dealing with order independant data there is great possibility for
parallelism.  This is a very important subset of computing (the software
alone is a 10 billion + plus industry).  If it's possible to design an
architecture which speeds up this small set of operations by an order of
magnitude or more; then it (seems to me) that it doesn't matter if it's
well balanced.  A lot of companies might be better off going for
lucrative niches rather than competing with well balanced
architectures.    
> 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.


	This is interesting.  I'm not a hardware expert, but I thought 8 years
ago the memory cycle was something like 70 nanoseconds.  Assuming (and I
believe it an incorrect assumption especially with RAM disk) that you
could get a 4 byte word up every cycle this gives me something in the
range 6  megabytes per second.  
	I haven't studied 486 architecture but unless it has something like I
described the operations to examine a dozen or so delimiters would take
something like a dozen CPU cycles.  Not to mention the costs of noting
the results and putting them someplace useful (eg. back in memory.)    

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

	Which would be an argument for at least some programmer controlled
associative memory.  
> 
> The same code today gets more than 100 MB/s on a PII, again making io
> the speed limiter.
> 
> Terje
> 
> --
> - <Terje.Mathisen@hda.hydro.com>
> Using self-discipline, see http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in caching"