Re: time to bring back the Lisp machines?

On Sun, 30 Apr 2006 17:11:22 +0200, Mark Tarver <dr.mtarver@xxxxxxxxxxxxxx> wrote:

Interesting. A lot of your hardware seems
optimised for fast transfer/read/graphics rates.
Your clock speed is presumably pretty much
where things were in 2003.

Did you buy your new machine as a server?
It seems to be configured that way.


No Raid 0,1,5,10 and ecl in matrix are now a part of the 945 chipset
used for many desktop PC motherboards.
Raid 0 is not that great for the average user where the rsscs outweigh
the benefits. Inprovement in performance running desctop applications is
fairly minimal. Where RAID 0 shines is in creating, copying amd moving many
files at once. This is true of a file server.
What I use it for is for compilation where this also occurs.
Normally I don't notice it but when I really need the speed it's there.

A question to my mind would be to what degree
this configuration would pay off in an ordinary
Lisp application where these features might
be less at a premium.

This is mostly true for compiling large C/C++ applications.
For the Lisp model of development I can't see this particular
feature paying off. Of course the generous amount of RAM helps.
Also the possibility to run several threads at once helps.
(A reasonable setup for a Lisp mostly machine might be RAID 1.
This mirrors the data. It can still read the data striped so
this improves but write access remains the same.
Of course you drop the amount of drive space in half, but
this is not necessarily a problem with the size of todays
drives. If one drive fails you loose no data.)

I find most Lisp compilers need improvements.
Particularly moving invariants out of loops seems to be
a problem.
Also integer performance leaves something to be desired.
Clos is not very optimized in some implementations.
Gray stream implementations are slow.
(Allegro addresses all of the above.)
Lisp benefits greatly from running on a 64 bit machine I would think.
The ability to use 8 bit tags like for Ivory should be a win.
You would have to adapt the whole compiler though to use the larger words
and although some compilers now have 64 bit versions I think they
are more or less direct adaptations of the old 32 bit compilers.
Lots of work to be done there..


Do you have Qi on your machine? There is an
interesting benchmark you could try which might
answer this.


No. Haven't used that before. Looks interesting though so
maybe I'll look into it.

Would an LM have a market? Well, here is
a quote from an old Symbolics release.
http://home.hakuhale.net/rbc/symbolics/announcements/19870519-ivory.txt


I think those markets are still there. The practicality
must hinge on whether a modern LM can deliver
the performace. I think the crucial figure is an order
of magnitude. If an LM can deliver 10X the performance
of a top end PC then its a paying proposition provided
the price is right.

I think this was probably the sort of ratio that Symbolics
could boast about in 1987 when they released the Ivory
chip. As my experiments in 1990 showed, they could
not maintain their margin. Nowdays they would have a
better chance.


I am not sure that a 10 X performance increase is realistic.
But I am not the person to ask.
(Duane Retting comes to mind, His first job for Franz was to implement
Allegro on a supercomputer.)
Even so I feel for the moment more is gained by focusing on getting
current implementations more efficient.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
.

Relevant Pages

  • Re: One last chapter to review! Last chance! One-day only!
    ... > I consider non-specified evaluation order to be a TERRIBLE idea. ... > I have, over the past year, been testing the compilers on various lisp ... > implementations with a random test generator. ...
    (comp.lang.lisp)
  • Re: Making Lisp popular - can it be done?
    ... native code compilers. ... Lisp conference/meeting. ... My Clojure program took around 105 msecs and the Java code did the job ... I would like to run my tests in that JVM then. ...
    (comp.lang.lisp)
  • Re: "Sorting" assignment
    ... place depending on implementations, including implementations in which ... out on the systems and compilers you use". ... bus error doing int-sized XOR swaps on unaligned addresses. ... But computational complexity theory does. ...
    (comp.programming)
  • Re: How to change peoples minds about LISP?
    ... >>within Lisp itself, or more precisely, the type of available ... > [implementations?] that so sabotages lisp? ... than compiled, statically typed languages. ... It's still much faster than CLISP, ...
    (comp.lang.lisp)
  • Re: Whats the best language to learn...
    ... consider the merits of the typical implementations. ... on processors designed to run Lisp and Lisp OSes. ... level programming language such as Lisp. ... lisp, java, ruby, etc. ...
    (comp.programming)