Date: Sun, 5 Jul 1998 19:06:02 GMT
From: ···@stimpy.rjs.net (Robert Swindells)
Nobody was going to buy a Symbolics based on how fast it ran FFT.
For a large internal CAD application, Explorers remained competitive
with more-recent Suns because of their garbage-collection performance.
I think the two best improvements to stock hardware would be faster
traps and support for using virtual memory hardware to aid GC.
Unaligned-address traps and Sparc-like tagged adds take care of a lot of
the type checks, but the actual exceptions are too expensive. I'm not
as familiar with GC, but I think it just wants the ability to use the
hardware that is already there.
These features are not especially Lisp-specific, either, so they don't
lead us down the specialised-hardware garden path.
I would be interested to see the times for the last generation of
dedicated hardware e.g. TI Explorer-2 and XL1200.
I happen to have a couple of operational Explorers, if someone can
remind me where to find the code. The CPUs have to be about eight years
old now, and at 40 MHz aren't exactly state of the art, but I'll report
the numbers anyway.
What I'd like to see is times for the most recent Symbolics hardware
compared with Genera on Alpha.
Paul Fuqua
Texas Instruments, Dallas, Texas ··@hc.ti.com
In article <··············@elissa.hc.ti.com>,
Paul Fuqua <··@elissa.hc.ti.com> wrote:
> Date: Sun, 5 Jul 1998 19:06:02 GMT
> From: ···@stimpy.rjs.net (Robert Swindells)
>
> Nobody was going to buy a Symbolics based on how fast it ran FFT.
>
>For a large internal CAD application, Explorers remained competitive
>with more-recent Suns because of their garbage-collection performance.
>
>I think the two best improvements to stock hardware would be faster
>traps and support for using virtual memory hardware to aid GC.
>Unaligned-address traps and Sparc-like tagged adds take care of a lot of
>the type checks, but the actual exceptions are too expensive. I'm not
>as familiar with GC, but I think it just wants the ability to use the
>hardware that is already there.
We had similar experiences with an internal IC design tool. We found
that to get acceptable performance we had to have conventional
machines with at least 10x the installed RAM. In particular, we had
to have enough ram to accomidate the most frequently gc'd generation,
to get it to be a usefull tool, rather than a disk drive stress test.
This was a problem when the box ran out of slots for ram. With the
mit derived iron, we could run virtual/real ratios of 200:1. Getting
far from 10:1 on the regular iron was a big problem.
The big win seemed to be the GC being aware of the current working
set. If chasing a reference meant a page hit to check out, skip it
until you ran out of stuff that was paged in. Even the best disks can
only manage 100 operations/second. This is not special hardware
specific. You could do this on a conventional machine, either by
exposing the page tables to the user program, or by making GC just
another thing that the OS does.
Exposing the page table isn't a new idea, on Twenex, there was an
option for a "user mode" page fault handler, specifically so the
program could page "intelligently"
<dp>
Hi,
I have a couple of second hand comments to make about this. As some of
you may know, Symbolics support has recently been revived. From talking
to them, I understand there is a significant market now for XL1200s and
one of the drivers for this is the GC performance of the systems for
very large lisp applications with large databases. Apparently many users
find they can do better going back to the specialized hardware. Perhaps
the Ivory's tagged architecture still has an edge. I seem to recall
that, in the distant past, Symbolics attempted to persuade the Intels of
the world to start tagging their architectures but I suppose there has
never been enough market demand for it.
I've also been told that the most recent release of Open Genera (2.0)
(not available yet so far as I know) has been benchmarked on the Alpha
600 at about 4 times the speed of an XL1201.
Mike Harper
Jeff DelPapa wrote:
>
> In article <··············@elissa.hc.ti.com>,
> Paul Fuqua <··@elissa.hc.ti.com> wrote:
> > Date: Sun, 5 Jul 1998 19:06:02 GMT
> > From: ···@stimpy.rjs.net (Robert Swindells)
> >
> > Nobody was going to buy a Symbolics based on how fast it ran FFT.
> >
> >For a large internal CAD application, Explorers remained competitive
> >with more-recent Suns because of their garbage-collection performance.
> >
> >I think the two best improvements to stock hardware would be faster
> >traps and support for using virtual memory hardware to aid GC.
> >Unaligned-address traps and Sparc-like tagged adds take care of a lot of
> >the type checks, but the actual exceptions are too expensive. I'm not
> >as familiar with GC, but I think it just wants the ability to use the
> >hardware that is already there.
>
> We had similar experiences with an internal IC design tool. We found
> that to get acceptable performance we had to have conventional
> machines with at least 10x the installed RAM. In particular, we had
> to have enough ram to accomidate the most frequently gc'd generation,
> to get it to be a usefull tool, rather than a disk drive stress test.
> This was a problem when the box ran out of slots for ram. With the
> mit derived iron, we could run virtual/real ratios of 200:1. Getting
> far from 10:1 on the regular iron was a big problem.
>
> The big win seemed to be the GC being aware of the current working
> set. If chasing a reference meant a page hit to check out, skip it
> until you ran out of stuff that was paged in. Even the best disks can
> only manage 100 operations/second. This is not special hardware
> specific. You could do this on a conventional machine, either by
> exposing the page tables to the user program, or by making GC just
> another thing that the OS does.
>
> Exposing the page table isn't a new idea, on Twenex, there was an
> option for a "user mode" page fault handler, specifically so the
> program could page "intelligently"
>
> <dp>
Michael Harper <··············@alcoa.com> wrote:
>From talking to them, I understand there is a significant market now
>for XL1200s and one of the drivers for this is the GC performance of
>the systems for very large lisp applications with large databases.
As someone who recently bought a bunch of XL1201s and whose main
application is a very large lisp application with a very large
database, the performance of which is in part limited by GC
performance, I guarantee you that it was not to run the application
faster. The application runs a factor of ten faster in every area on
sub-US$2K PCs. (Of course, it really is saying something that
decade-old hardware is only a factor of ten slower and that it can
even run the application at all.)
Instead, I bought them for the productivity benefits of Genera. Even
on old, slow hardware, the tightly integrated environment makes
writing and, especially, debugging code several times faster. There
are a number of features (the patch system, a usable debugger, Dynamic
Windows, a bunch of Zmacs stuff, the metering interface, great
documentation, source code) that still are not in the commercial CLs,
and they really make a difference.
>Apparently many users find they can do better going back to the
>specialized hardware. Perhaps the Ivory's tagged architecture still
>has an edge.
I think the advantage of Lisp-specialized hardware is that it takes
away the temptation to write software that is down to the metal in
such a way that prevents writing great software.
>I've also been told that the most recent release of Open Genera (2.0)
>(not available yet so far as I know) has been benchmarked on the Alpha
>600 at about 4 times the speed of an XL1201.
I would be happy with a version of Open Genera that runs as fast as a
3600, as long as it ran on a PC.
--David Gadbois
In article <·····················@news.giganews.com>,
David Gadbois <·······@cyc.com> wrote:
>I would be happy with a version of Open Genera that runs as fast as a
>3600, as long as it ran on a PC.
At the time Open Genera was written, they needed to use a 64-bit machine to
get acceptable performance, so they chose the Alpha (pretty much the only
64-bit CPU that seemed real at the time). I wonder if current Pentium or
PowerPC chips are fast enough that they would be useful, even without being
fully 64-bit architectures.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Inexpensive Alpha boxes running Linux are readily available now. I
wonder if Open Genera couldn't run on them??
Barry Margolin wrote:
>
> In article <·····················@news.giganews.com>,
> David Gadbois <·······@cyc.com> wrote:
> >I would be happy with a version of Open Genera that runs as fast as a
> >3600, as long as it ran on a PC.
>
> At the time Open Genera was written, they needed to use a 64-bit machine to
> get acceptable performance, so they chose the Alpha (pretty much the only
> 64-bit CPU that seemed real at the time). I wonder if current Pentium or
> PowerPC chips are fast enough that they would be useful, even without being
> fully 64-bit architectures.
>
> --
> Barry Margolin, ······@bbnplanet.com
> GTE Internetworking, Powered by BBN, Cambridge, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
In article <·····················@news.giganews.com>, David Gadbois
<·······@cyc.com> wrote:
> As someone who recently bought a bunch of XL1201s and whose main
> application is a very large lisp application with a very large
> database, the performance of which is in part limited by GC
> performance, I guarantee you that it was not to run the application
> faster. The application runs a factor of ten faster in every area on
> sub-US$2K PCs.
My Powerbook G3 compiles CL-HTTP five times faster than an emulated Lisp
machine (which is much faster than a XL1201).
There is a threshold for usability in a development
environment. I personally find CLIM (using and developing)
on my MacIvory 3 too slow. DW is usable. On my Mac CLIM speed has
reached usability. The window debugger of Genera is sometimes too slow
(printing a lot of disassembly), same for the inspector.
Both are much faster on my Mac. The inspector of LWW is
also "unusable", because it is printing **slowly** large data.
The listener (and the rest of the UI is also affected)
of LWW is unsatisfactory, because it is not possible to move
or even update the window while the tool is executing code.
> (Of course, it really is saying something that
> decade-old hardware is only a factor of ten slower and that it can
> even run the application at all.)
It would be nice to have more than 8MW memory on those machines.
Very important is also the graphic display. A b&w console is quite
fast. Color is slow. On the MacIvory it helps to use an
accelerated graphics card and a 68040 on the Mac side.
> Instead, I bought them for the productivity benefits of Genera.
Today I browsed through a book about software project failures. One
chapter was devoted to a CAD project at MCC which developed
750 KLOC of Lisp code on Lispms. They were considering this
project to be a failure because of performance and stability
problems. The software had to be recoded in C on conventional
systems (don't know whether this solved their problems, though ;-) ).
> Even
> on old, slow hardware, the tightly integrated environment makes
> writing and, especially, debugging code several times faster. There
> are a number of features (the patch system, a usable debugger, Dynamic
> Windows, a bunch of Zmacs stuff, the metering interface, great
> documentation, source code)
I like the networking stuff. Object-oriented TCP/IP in Lisp is nice.
Should be modernized, though.
> that still are not in the commercial CLs,
> and they really make a difference.
But with commercial CLs for PCs, Macs and Unix-boxes you get:
- more users
- more memory
- faster disks
- faster networks
- faster processors
- faster graphics
- "modern UI" with multimedia capabilities, fonts, sounds, video, ...
- integration in "foreign" software via FFI, ODBC, Corba, OLE,
AppleEvents, ...
- simpler user environments (o.k, only on Macs ;-) )
- better distribution of your applications
- one Lisp (not three; ZetaLisp, SCL, CL) and one object system
(not three; Flavors, New Flavors and CLOS)
I have been using my MacIvory quite a bit lately. These machines are
really for power users. I feel that I'm only scratching the
surface. You have to deal a lot with complexity both in the
development environment and in your application. One (I) should
be creating more tools to understand the application on a
visual base. DW makes this possible, but I shy away from using
the Symbolics specific things because they are not ANSI-CL/CLOS
and they are simply not portable.
Sigh, how would the computing landscape look like, when atleast
one of Xerox, TI, LMI or Symbolics would have been sucessful
in the long run with a Lispm?
Greetings,
Rainer Joswig
In article <·······················@194.163.195.67>,
······@lavielle.com (Rainer Joswig) writes:
> In article <·····················@news.giganews.com>, David Gadbois
> <·······@cyc.com> wrote:
>> Instead, I bought them for the productivity benefits of Genera.
>
> Today I browsed through a book about software project failures. One
> chapter was devoted to a CAD project at MCC which developed
> 750 KLOC of Lisp code on Lispms. They were considering this
> project to be a failure because of performance and stability
> problems. The software had to be recoded in C on conventional
> systems (don't know whether this solved their problems, though ;-) ).
A dozen years later, that BS paper still gets my blood boiling! Lisp was NOT
MCC's problem. Incompetent management was! The director of the CAD group kept
overriding the system architect and made technical decisions about which he
knew nothing. His constant interference completely underminded any chance of
it being a success. As a result of his interference, each group leader went
and did their own thing, giving no consideration to the overall goals. As an
example of how disfunctional management became, I and another engineer
attended a meeting with the director and the system architect to discuss
design size problems, namely that TI and LMI lisp machines didn't have enough
address space to handle the size of problems that MCC wanted. (Not without
doing software "overlays".) Half way thru the meeting, the director was
sitting in one corner staring out the window and the system architect was
sitting in the opposite corner staring out that window. The director just
didn't want to hear about any problems with the TIs and LMIs. Or anything
else! It become clear to me at that moment that MCC was doomed to failure
because of the internal politics and incompetence of management.
ALthough I didn't always agree with the decisions of the system architect
(more often than not, I disagreed!), I knew that for a large system to have
any hope of success, one person had to be responsible for the global design.
Due to the director at MCC CAD, there was no ONE person responsible for the
system design. Well, that's not quite true. The system architect WAS
responsible for the design. He just had no authority to carry it out.
Now, MCC did have one problem with their Lisp Machines. They hired a bunch
of C and Fortran yahoos from TI, sat a LM in front of them with no training,
and said get busy. What a joke!
(I was lent to MCC for three months by one of the member companies to try
and help them out with their CAD database needs. After the above meeting, I
decided not to hang around any longer than those three months.)
Mike McDonald
·······@mikemac.com
Mike McDonald wrote in message ...
> Now, MCC did have one problem with their Lisp Machines. They hired a
bunch
>of C and Fortran yahoos from TI, sat a LM in front of them with no
training,
>and said get busy. What a joke!
The LMI Lambdas had severe reliability problems stemming from poor hardware
design
and bug ridden microcode. These problems were not fixed until around late
1986.
* Rainer Joswig wrote:
> Today I browsed through a book about software project failures. One
> chapter was devoted to a CAD project at MCC which developed
> 750 KLOC of Lisp code on Lispms. They were considering this
> project to be a failure because of performance and stability
> problems. The software had to be recoded in C on conventional
> systems (don't know whether this solved their problems, though ;-) ).
I've read this book too, though I don't remember the title/author.
This example was what persuaded me it was a bad book. This is a
classic example of `plan to throw one away' as described in `The
Mythical Man Month', a very long time ago. And yet, in this case,
because the one that got thrown away was in Lisp, somehow it's all
Lisp's fault.
--tim
Paul Fuqua wrote in message <··············@elissa.hc.ti.com>...
>I think the two best improvements to stock hardware would be faster
>traps and support for using virtual memory hardware to aid GC.
I definitely agree on the first. The increasing latency of traps with more
pipe stages is a real pain in the butt to RT designers also. The second is
of a more esoteric nature and probably will not come about unless a more
mainstream language (like Java :-( ) forces it.
P.S. Please no flames about Java. I know it is much less preferable than
lisp. Bur it does seem to be the current way to Trojan-horse special stuff
like this into systems. Now of they'd just get rid of the bogus
Integer/BigInteger dichotomy...
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
"Frank Adrian" <············@firstdatabank.com> writes:
>Paul Fuqua wrote in message <··············@elissa.hc.ti.com>...
>>I think the two best improvements to stock hardware would be faster
>>traps and support for using virtual memory hardware to aid GC.
> The second is of a more esoteric nature and probably will not come
> about unless a more mainstream language (like Java :-( ) forces it.
But is the access to the VMU hardware to aid GC a limitation of the
hardware itself, i.e. what "stock hardware" of today has to offer, or
is it a limitation of what aspects of the VMU are published and
accessible through the OS riding on TOP of the hardware. Would a low
level, bare metal "GC Driver" have any kind of effect?
(I don't want to go down the LispOS trail here, I'm just trying to
understand how (stock) hardware can have an effect on Lisp-esque
environments performance, in ways besides moving the rev limiter up.)
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
* Frank Adrian wrote:
>> I think the two best improvements to stock hardware would be faster
>> traps and support for using virtual memory hardware to aid GC.
> I definitely agree on the first. The increasing latency of traps with more
> pipe stages is a real pain in the butt to RT designers also. The second is
> of a more esoteric nature and probably will not come about unless a more
> mainstream language (like Java :-( ) forces it.
Isn't the long trap latency really an inevitable result of heavily
pipelined processors? Perhaps this is really belongs on comp.arch now
but it seems to me that it must be. And since heavily pipelined
processors are probably in themselves inevitable, there's not much to
be done.
--tim
Tim Bradshaw wrote:
>
> [somebody else wrote:]
> > I definitely agree on the first. The increasing latency of traps with more
> > pipe stages is a real pain in the butt to RT designers also. The second is
> > of a more esoteric nature and probably will not come about unless a more
> > mainstream language (like Java :-( ) forces it.
>
> Isn't the long trap latency really an inevitable result of heavily
> pipelined processors?
The Ivory has a five-stage pipeline. The way Symbolics seems to have
handled trap latency is to have lots of extra stack buffers and
special-purpose data paths. The most important thing is to avoid "Stack
puke" when taking an exception.
Also remember that many of the Ivory traps are in microcode. This means
that you don't have to flush the pipeline to decode the exception
handler.
> Perhaps this is really belongs on comp.arch now
Yes, probably =)
> but it seems to me that it must be. And since heavily pipelined
> processors are probably in themselves inevitable, there's not much to
> be done.
I wouldn't say that. The two biggest things in the near future are
threading and predication. Both can be used to attack this problem.
threading should be here Real Soon Now�, in a couple of years, whether
it will be 21364, PPC G4, or whatever. This will take a lot of pressure
off the first couple pipeline stages during a trap. (if I understand it
correctly)
It might be hard to cram a Symbolics-like trap model into the Merced
predication scheme, but in any case you can take these traps without
having to wait.
--
f l u i d e s i g n
www.fluidesign.com
Nate Holloway, Technical director
natedogg at fluidesign dot com
From: Howard R. Stearns
Subject: Re: common hardware soup-ups?
Date:
Message-ID: <35A11C28.3241@elwood.com>
Paul Fuqua wrote:
> ...
> I happen to have a couple of operational Explorers, if someone can
> remind me where to find the code. The CPUs have to be about eight years
> old now, and at 40 MHz aren't exactly state of the art, but I'll report
> the numbers anyway.
The Gabriel (and other) benchmarks are at
ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/bench/0.html
The machine IS there, but it's sometimes hard to reach.
(By the way, good places to check for source code, generally, are the
FAQ and the ALU website. See http://www.elwood.com/alu)