About 16 years ago, I had a rare and not to be repeated
opportunity to be in a room which in which Symbolics,
Texas Instruments and a company called (I think) 4th
Wave were showing off their Lisp machines. The
occassion was Europal '90.
There were also software vendors - a bald guy showing off
Mu Lisp from Soft Warehouse and Harlequin showing
off their Common Lisp.
Well I tested each and every one of them on a bubble sort
algorithm. And the results were interesting. Basically
the Lisp machines were faster than the software vendors,
but only by a fairly small margin of 2 or less. And in 1990,
with PCs and workstations leapfrogging in performance,
that meant only one thing - curtains for Lisp machines.
LM vendors just could not compete with the big chip
manufacturers.
Fast forward now to 2006 and things look very different.
We've not seen much improvement in processor speed
since 2003. Intel's Prescott chip turned out to be the
world's most expensive toaster. Hence the factor that
killed off the LMs is now out of play. So is anybody out
there considering that LMs might have some future in
today's market?
Mark
> So is anybody out there considering that LMs
> might have some future in today's market?
Yes. We are. But not the way you are thinking about it. Having your own
heavy metal is sooooooo 20th century! The wave of the future is the
wave of the past: Time Sharing. (Although these days they call it
'Google'.) But old-style Time Sharing had these icky command languages!
What do you get when you cross Time Sharing with ASP with LispMs?
KnowOS! Come try out the BioBike KnowOS (a biocomputing-specific KnowOS
instance) at www.biobike.org. The demo server is free for you
amusement. (It's only running on a little dual AMD, so please try not
to abuse it too badly!) I recommend trying out the Tour of BioBike live
tutorial. Once you log into the BioBike demo server, pull down
Help>Live Tutorials from the pulldowns under the REPL.
Cheers,
'Jeff
BA (Biographical Annotation -- in honor of a certain annoying rpi
undergrad): Yes, I HAVE been programming in Lisp since before many of
you were born, and continue to do so. So to paraphrase a recent
eloquent author: "If you think I don't know what I'm talking about,
think thrice."
From: Bill Atkins
Subject: Re: KnowOS (Lisp Web-Based Time Sharing)
Date:
Message-ID: <87wtd6yapn.fsf@rpi.edu>
········@gmail.com writes:
> BA (Biographical Annotation -- in honor of a certain annoying rpi
> undergrad): Yes, I HAVE been programming in Lisp since before many of
Are you still worked up about that? And did you really go out of your
way to find out that I'm an undergraduate? That's a little
unsettling.
I don't doubt (and, in fact, never did) that you've been using Lisp
for a while. But surely you can understand where I'm coming from.
Surely you can agree that it might be irritating to see someone who
has kept a fairly low profile in the Lisp community attempt to set us
all straight simply by setting up a website - and then denounce the
Lisp community as a whole because no one was particularly keen on the
idea. Surely you can see how acting like that would bother people;
the amount of years you've used Lisp doesn't enter into it.
But come on, this was what, two weeks ago? It's in the past, I have
no hard feelings. I don't think I was particularly rude to you, in
light of your attitude. But if you disagree, oh well. There are more
important things in life than carrying on grudges and looking up
background information for USENET readers who bother you.
--
This is a song that took me ten years to live and two years to write.
- Bob Dylan
> And did you really go out of your way to find out
> that I'm an undergraduate? That's a little unsettling.
Maybe you should join a debate club: Rules #1, 2 and 3: Know your goal,
Know your topic, Know your opponent.
> I don't doubt (and, in fact, never did) that you've been using Lisp
> for a while.
Right, sorry; that must be what "An individual with no obvious
credentials" means. I guess "no obvious credentials" in Bill Atkins
speak translates to: "I've never heard of him, and I've been in this
community for, um, what, a year or so, so he must not have any
credentials and I can safely tell him to go to hell."
> But surely you can understand where I'm coming from.
Yes, surely I can; I used to be just like you. However, finally to my
great benefit someone spanked me. But don't take it personally; a lot
of people in this community could use a good spanking, some
significantly more so than you!
From: Bill Atkins
Subject: Re: KnowOS (Lisp Web-Based Time Sharing)
Date:
Message-ID: <87iroqrzxe.fsf@rpi.edu>
········@gmail.com writes:
>> And did you really go out of your way to find out
>> that I'm an undergraduate? That's a little unsettling.
>
> Maybe you should join a debate club: Rules #1, 2 and 3: Know your goal,
> Know your topic, Know your opponent.
I didn't realize we were debating. I didn't even realize you were
still offended about an offhand comment from several days ago. In any
case, I don't appreciate the intrusion into my privacy, though of
course you've got a right to look me up.
>> I don't doubt (and, in fact, never did) that you've been using Lisp
>> for a while.
>
> Right, sorry; that must be what "An individual with no obvious
> credentials" means. I guess "no obvious credentials" in Bill Atkins
> speak translates to: "I've never heard of him, and I've been in this
> community for, um, what, a year or so, so he must not have any
> credentials and I can safely tell him to go to hell."
It's interesting how bothered you are by all of this. I had never
seen your name come up in my time in the Lisp community (which, as you
mention, is about a year) and all that I'd seen of you was a
ridiculous post suggesting that because your idea hadn't caught on,
the rest of us were clearly sheep. It seems, though, that you do have
credentials - you say you've been programming Lisp for a very long
time and you run at least one large open-source Lisp project
(biobike.org, right?). So that part of my reply was mistaken and I
apologize for it. But I don't think removing this phrase from my post
makes your sudden reversal from "My whizzy web site will
single-handedly save Lisp, even though things like this have been
tried in the past!" to "People don't like my idea - you're all foolish
and misguided sheep!" any less ridiculous.
But I feel silly even arguing about this. It was, as I've mentioned,
an offhand remark from a conversation several days ago. These things
happen in the wild world of Usenet. It's not clear why you're
bringing this up in an unrelated thread.
>> But surely you can understand where I'm coming from.
>
> Yes, surely I can; I used to be just like you. However, finally to my
> great benefit someone spanked me. But don't take it personally; a lot
> of people in this community could use a good spanking, some
> significantly more so than you!
>
I can't even begin to know how to react to this paragraph.
--
This is a song that took me ten years to live and two years to write.
- Bob Dylan
> It seems, though, that you do have credentials ...
> So that part of my reply was mistaken and I
> apologize for it.
Apology accepted.
> It's not clear why you're bringing this up in an unrelated thread.
First off, you brought it up; I just added an offhand footnote to an
unrelated post that you seemed unhappy about. I didn't even use your
name. Regardless, if we keep talking about this it has the advantage of
keeping my revised subject line as the banner for the thread. :-)
> In any case, I don't appreciate the intrusion into my privacy, though of
> course you've got a right to look me up.
To quote another wag: "Aw, jeez, this is Usenet. Get over it."
Mark Tarver wrote:
> [snipped]
> Fast forward now to 2006 and things look very different.
> We've not seen much improvement in processor speed
> since 2003. Intel's Prescott chip turned out to be the
> world's most expensive toaster. Hence the factor that
> killed off the LMs is now out of play.
> [snipped]
Moore's law continues unabated, i.e. transister count doubles every 18
months. And this is despite the problems major CPU manufacturers are
having pushing higher clock speeds.
The solution is multiple core architectures, which is now a trend.
Consider Sun's T1 chip which has 8 cores allowing the chip to execute
32 simultaneous threads. The next generation Sun chip is touted to
have 32 cores, possibly allowing 128 concurrent threads.
http://www.sun.com/processors/UltraSPARC-T1/
The hardware industry is now waiting for the software industry to catch
up.
Best wishes,
Mike Thompson
Yes; this is a promising direction. What does the T1 chip
run on - assembly? Are there any high-level languages
for this chip yet?
Back in the 80s there was a lot of experiment in
parallel processing in functional programming
- ALICE and GRIP being two I recall. But they
died the death as far as I know - or else they
have such a low profile that they've become
invisible. MultiLisp was parallel too and it was
invented 1980.
So the software people introduced parallelism
and it didn't take so well. Do you think that now
it will?
Mark
The SUN T1 is simply the latest SPARC chip running Solaris. It
therefore runs all the languages that happen to run on SPARC Solaris.
This should include Allegro CL and Lispworks.
To answer your question about whether parallelism will now become
commonplace, I think it certainly will. The driving force is the
trouble CPU manufacturers are having ramping up clock speed, running
into many hard physical limits. Had clock rate managed to keep up with
the pace prior to 2003 then we would be running 10GHz pentium IVs by
now.
What I find interesting is seeing how the C++ community are thinking
about extending the language to have better concurrency control. This
might be necessary if C++ is to remain relevant as a performance
oriented language. Consider a 100 or 1000 core processor.
I don't think a Lisp company would have any success building a
dedicated Lisp CPU. Moore's law continues and I expect they will still
find Intel/AMD to be formidable competition.
A different question would be - does it make sense for Intel to extend
their instruction set to assist dynamically typed languages with
garbage collection.
Mike T wrote:
> To answer your question about whether parallelism will now become
> commonplace, I think it certainly will. The driving force is the
> trouble CPU manufacturers are having ramping up clock speed, running
> into many hard physical limits. Had clock rate managed to keep up with
> the pace prior to 2003 then we would be running 10GHz pentium IVs by
> now.
I agree. If nothing changes and today's top500 computers will be below
your desk in 10-15 years. So 16-256 CPUs. You simply cannot create
efficient and reliable software with current shared-state paradigms. So
either C/C++/Java die out quickly (unfortunately unlikely) or will get
extensions putting them closer to languages like Erlang, Oz, Alice, etc.
(likely). Then, however, I wouldn't wonder to see
Connection-Machine-style machine designs show up again in, say, 15-20
years. This again needs some pretty different style of programming and
will thus probably be done as late as possible as it'll require much of
the software to be written. (Unless new compiler technology be designed
to convert imperative-style programs into efficient data-flow-orientend
programs. Personally, I think this approach is fundamentally limited.)
> A different question would be - does it make sense for Intel to extend
> their instruction set to assist dynamically typed languages with
> garbage collection.
I see two features where better hardware support may make major differences.
Hardware support for fine-grained memory barriers. Current mechanisms
are two coarse-grained (virtual memory pages) and too expensive (trap to
kernel on access, syscall for updating rights). Having such mechanisms
would make more efficient incremental/generational GC possible. Due to
more widespread use of "managed" languages (and them being pushed by MS)
this may not be unlikely.
Hardware support for tagged data structures. One very simple change in
semantics would be making loads and stores be data size aligned. I.e.
loading a 8 byte datum would always be 8 byte aligned. Then the least
significant 3 bits would simply be ignored (ie. assumed zero, essential
part is they're throwing no alignment exception) and thus need not be
cleared out before dereferencing pointers. This would be a very simple
change with big impact on dynimcally typed languages. But it would
break backwards compatibility (on x86, not sure how PPC deals with
this). But what about one more mode bit in CRx/EFLAGS?
Any Lisp machine guru could possibly add quite a bunch of other
features, though. So no claims of completeness implied.
BTW: New AMD processors are supposed to have quite good microcoding
capabilities I hear. But the only real advantage I see is in
compressing the instruction stream.
-ts
Thomas Schilling wrote:
> Hardware support for fine-grained memory barriers. Current mechanisms
> are two coarse-grained (virtual memory pages) and too expensive (trap to
> kernel on access, syscall for updating rights). Having such mechanisms
> would make more efficient incremental/generational GC possible. Due to
> more widespread use of "managed" languages (and them being pushed by MS)
> this may not be unlikely.
I can tell you how us OSdevers will react to fine-grained memory
protection in one word: "Hallelujah!" If something like segmentation's
fine-grained protection could be used without the whole "add segment's
base address to logical address before sending to MMU"-thing and the
requirement on compilers to support segmentation it would help a LOT.
--
The science of economics is the cleverest proof of free will yet
constructed.
Thomas Schilling <······@yahoo.de> writes:
>> A different question would be - does it make sense for Intel to extend
>> their instruction set to assist dynamically typed languages with
>> garbage collection.
>
> I see two features where better hardware support may make major differences.
>
> Hardware support for fine-grained memory barriers. Current mechanisms
> are two coarse-grained (virtual memory pages) and too expensive (trap to
> kernel on access, syscall for updating rights). Having such mechanisms
> would make more efficient incremental/generational GC possible. Due to
> more widespread use of "managed" languages (and them being pushed by MS)
> this may not be unlikely.
Having the GC implemented in "hardware". Sometimes between the
introduction of L3 caches and L4 caches, perhaps they'll think of it.
Of course, this comes at the same time as:
> Hardware support for tagged data structures. [...]
Since the GC hardware needs to know the pointers.
Well, actually it doesn't need to be hardware GC really, in a
multicore CPU, you can just assign one core to the GC.
> BTW: New AMD processors are supposed to have quite good microcoding
> capabilities I hear. But the only real advantage I see is in
> compressing the instruction stream.
Which means using less memory bandwidth, which is more and more the bottleneck.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
On Sun, 30 Apr 2006 12:08:52 +0200, Mark Tarver
<··········@ukonline.co.uk> wrote:
>
> Fast forward now to 2006 and things look very different.
> We've not seen much improvement in processor speed
> since 2003. Intel's Prescott chip turned out to be the
> world's most expensive toaster. Hence the factor that
> killed off the LMs is now out of play. So is anybody out
> there considering that LMs might have some future in
> today's market?
>
> Mark
>
Maybe..
I just got a new machine here on friday.
It is has a intel Pentiom D 840 HT (dual core) chip.
You are quite wrong that the systems are not much faster.
Belive me this one is bloody fast..
Memory read in paralell (DDR2). (2 Gb in 4 512 Mb banks/533MHz DDR2 PC3200)
Chip runs two threads in paralell. Two 160 Gb disks run in paralell
(SATA RAID 0 Striped.. SATA has a max of 3 Gb/s transfer rate).
Also a seperate graphics processor (NVidia GForce 7300SL TurboCache)
on a PCI express 16x port.. (twice the transfer rate of ATA)
It's not just the chip but everything else surrounding it.
(Whatchout for RAID 0. It doubles the chance of failure and some programs
mainly scandisk and defrag can cause the whole system to fail so
a reformat is neccesary. Also Raid 0 on one motherboard will not work with
RAID 0
on another type. I back up on a extenal 360Gb drive using a firewire
800 (or IEEE 1394b) connector (manages transfer rates of 62 Mb/s).
We do have a new teckology in the 900 series from Intel.
It uses 65 nm lithography as opposed to 90 nm.
What I do see is that clock frequencies are unlikly to go
much above 3 GHz. (heat problems)
What does seem to be the trend is to put more and more spesialized
hardware on the chip.
MX SSE/2/3 Viiv etc.. So yes spesializing a chip for Lisp might perhaps be
interesting.
My main reservation is that I am not sure it is neccesary.
The Lisp community is still pretty small.
Current compilers do pretty well on current system easily competing with
Java in some areas. With Microsoft also moving to 'managed code'/.NET
I dont think speed seems to be a top priority.
Back in the 80's things looked different.
Lisp required memory diskspace and processing well in excess of the
current hardware.
Now speed or capasity is not a problem. Do enough people need/want it?
If so I am sure it can be done.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
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.
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.
Do you have Qi on your machine? There is an
interesting benchmark you could try which might
answer this.
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
"Three main groups have expressed keen interest," said Noftsker. "The
first is Department of Defense contractors who want to use Ivory as an
embedded delivery platform for applications developed on Symbolics
systems."
The second group is commercial vendors who want to
add a Symbolic co-processor to their product offering.
And the third is system integrators in various vertical
markets who want to embed their next-generation products
within an Ivory-based Symbolics product."
In addition to traditional AI research and development,
Ivory will make possible a wider range of application
products in such industries as financial, medical,
chemical and aerospace. Ivory will also allow developers
to solve larger, more complex AI problems than have
previously been possible."
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.
Mark
On Sun, 30 Apr 2006 17:11:22 +0200, Mark Tarver
<··········@ukonline.co.uk> 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/
I am curious as to what Lisp specific hardware would look like today.
Which features would actually go into modern Lisp hardware that would
give big performance wins?
I'm guessing that there aren't that many areas today where specialised
hardware is going to give you big wins.
What would you put in hardware that would make a Lisp faster?
Cheers
Brad
To answer your question authoritatively one would
(a) have to be an authority on the architecture of
the original Lisp machines (b) have kept up with
the advances since that time. That rules me out
I'm afraid.
However, here is an idea you might find interesting.
Perhaps one approach would to begin with a generic
system that could cut its own pathways adaptively
into the hardware according to the software installed
on it. In other words, you begin with a software
implementation of the Lisp evaluator and the machine
adaptively routes the processes through the hardware.
In that way the Lisp machine emerges as a by-product
of an evolutionary process - it is grown rather than built.
In case that sounds far-fetched, you using a wetware
implementation of this idea to read this post.
Mark
Mark Tarver wrote:
> To answer your question authoritatively one would
> (a) have to be an authority on the architecture of
> the original Lisp machines (b) have kept up with
> the advances since that time. That rules me out
> I'm afraid.
>
> However, here is an idea you might find interesting.
> Perhaps one approach would to begin with a generic
> system that could cut its own pathways adaptively
> into the hardware according to the software installed
> on it. In other words, you begin with a software
> implementation of the Lisp evaluator and the machine
> adaptively routes the processes through the hardware.
> In that way the Lisp machine emerges as a by-product
> of an evolutionary process - it is grown rather than built.
>
> In case that sounds far-fetched, you using a wetware
> implementation of this idea to read this post.
One could argue that regular CPUs could be designed this way, but as
far as I am aware none actually are.
If you were to base a Lisp machine off of a modern desktop CPU you
would find basically the same bottle necks, which today is often the
memory access. Looking forward, clock speed and thermal dissipation.
So you'd end up with a Lisp machine that was limited to about 2-3Ghz
per core, and would be bottle necked by the L1 cache and memory bus.
If I'm correct in my bottleneck assumptions (I very well may not be,
I'm not super up on all this), then sure you could add features to the
core, but what would they buy you? Lets assume that you add tagged
math to the core, so that fixnums don't require shifting at any stage
of the computation, you will only be saving the shift operations. With
a decent compiler you can declare the types of variables and get rid of
tagged ops anyway. Bignum math might be good to add to the core, but I
suspect that arbitary sized math would take a lot of silicon.
My point is that I can't think of any primitive operations that can be
added to a CPU that would hugely aid a Lisp system - at least compared
to what you can already do with SBCL and declares.
Good Lisp support for multi-processor machines is probably a good idea,
but that is software not hardware.
Hardware assisted GC could be good, but in a real system how much time
is spent in GC?
But I am interested in hearing about parts of Lisp that would really
benefit from a custom processor.
Cheers
Brad
bradb wrote:
> Lets assume that you add tagged
> math to the core, so that fixnums don't require shifting at any stage
> of the computation, you will only be saving the shift operations. With
> a decent compiler you can declare the types of variables and get rid of
> tagged ops anyway. Bignum math might be good to add to the core, but I
> suspect that arbitary sized math would take a lot of silicon.
You don't just save the shifts, which are easy to pipeline and cheap,
but the conditional branches, which are difficult to pipeline and
expensive. Also, I suspect that bignum math wouldn't take a lot of
silicon. Even Intel's 8086 had arbitrary length string operations.
> My point is that I can't think of any primitive operations that can be
> added to a CPU that would hugely aid a Lisp system - at least compared
> to what you can already do with SBCL and declares.
Why do we declare datatypes? So the compiler can produce code that runs
about as fast as it would on hardware with dedicated tag support. Your
argument is that dedicated hardware only saves the programmer having to
declare datatypes for speed, but transistors are getting cheaper faster
than programmers are.
> You don't just save the shifts, which are easy to pipeline and cheap,
> but the conditional branches, which are difficult to pipeline and
> expensive. Also, I suspect that bignum math wouldn't take a lot of
> silicon. Even Intel's 8086 had arbitrary length string operations.
How would specialised hardware help conditional branches? You _could_
do arbitary precision math in hardware, but it would eat up (on die?)
memory. Is there any hardware that can currently do bignum math? I
would have thought that research groups would want bignum math badly
enough that if it were easy.
> Why do we declare datatypes? So the compiler can produce code that runs
> about as fast as it would on hardware with dedicated tag support. Your
> argument is that dedicated hardware only saves the programmer having to
> declare datatypes for speed, but transistors are getting cheaper faster
> than programmers are.
It would be nice to get good fast numerical code without declaring
types, but the memory requirements would still be larger than declared
types. I'm not arguing so much as playing devil's advocate :)
And although transistors are getting cheaper faster that programmer
time, those transistors are still being designed for traditional
languages - it would cost a LOT of money to design and fab a CPU from
the ground up.
I would love to see Lisp hardware, but unless we are blue skying we
ought to be a bit realistic. The only realistic way (IMHO) that Lisp
hardware is going to get into PCs/mainstream is on a PCI expansion
card. From a pragmatic point of view we ought to look at what
performance enhancing features could go on a card like that.
Cheers
Brad
bradb wrote:
>
> I would love to see Lisp hardware, but unless we are blue skying we
> ought to be a bit realistic. The only realistic way (IMHO) that Lisp
> hardware is going to get into PCs/mainstream is on a PCI expansion
> card. From a pragmatic point of view we ought to look at what
> performance enhancing features could go on a card like that.
Unfortunately, any gain that you might get from processing on a PCI
card is
likely to be lost in transferring the data from and to the PCI card.
Joe Marshall wrote:
> bradb wrote:
> >
> > I would love to see Lisp hardware, but unless we are blue skying we
> > ought to be a bit realistic. The only realistic way (IMHO) that Lisp
> > hardware is going to get into PCs/mainstream is on a PCI expansion
> > card. From a pragmatic point of view we ought to look at what
> > performance enhancing features could go on a card like that.
>
> Unfortunately, any gain that you might get from processing on a PCI
> card is
> likely to be lost in transferring the data from and to the PCI card.
Yep, that's my guess too. PCI express might be better, but still -
you'd need the hardware to be doing something special to make it worth
the effort.
Brad
On Mon, 01 May 2006 11:33:59 -0700, bradb wrote:
> Joe Marshall wrote:
>> bradb wrote:
>> >
>> > I would love to see Lisp hardware, but unless we are blue skying we
>> > ought to be a bit realistic. The only realistic way (IMHO) that Lisp
>> > hardware is going to get into PCs/mainstream is on a PCI expansion
>> > card. From a pragmatic point of view we ought to look at what
>> > performance enhancing features could go on a card like that.
>>
>> Unfortunately, any gain that you might get from processing on a PCI
>> card is
>> likely to be lost in transferring the data from and to the PCI card.
>
> Yep, that's my guess too. PCI express might be better, but still -
> you'd need the hardware to be doing something special to make it worth
> the effort.
There is also the FPGA in an Opteron socket that was described in a thread
last week.
You might be able to use the HyperTransport protocol to snoop the caches
of the real processors and use this to implement write barriers without
the overhead of having to trap to user space.
Robert Swindells
Robert Swindells <···@fdy2.demon.co.uk> wrote:
+---------------
| There is also the FPGA in an Opteron socket that was described in
| a thread last week.
+---------------
Ex-*SPEND*-sive!! [Pardon my deliberate misspelling.]
+---------------
| You might be able to use the HyperTransport protocol to snoop
| the caches of the real processors and use this to implement
| write barriers without the overhead of having to trap to user space.
+---------------
1. I suspect the aforementioned FPGA uses plain ol' "non-coherent HT",
which is what is used for ordinary I/O (PIOs & DMA). The cc/NUMA
cache-coherency, on the other hand, uses the AMD "coherent HT"
protocol, and the latter is still quite confidential, AFAIK.
[Any given link runs in either "non-coherent" or "coherent" mode.
HT links to I/O chips such as the Am8111, Am8131/Am8132, or the
NVidia NForce run in "non-coherent" mode; links between Opteron
CPUs run in "coherent" mode.] Not even NDA partners get *all* the
details about "coherent" mode [though they do get some]. Before you
could build an FPGA that spoke the cc/NUMA protocol, you'd have to
succeed in some *serious* negotiating with AMD for NDA access.
However, some people obviously have succeeded, e.g., consider
the Horus chip from NewIsis:
http://www.hypertransport.org/docs/tech/horus_external_white_paper_final.pdf
2. Even assuming success in #1, it's not at all clear that there is
adequate information available in another socket to implement a GC
write barrier. Write barriers have to do their work *NOW*, not at
some later time when the trail has already been thoroughly muddled.
Opertons have "write-back" caches, not "write-through", and the
dirty data can be retired in random order.
3. And while you'll see the SNOOP broadcasts from other CPUs asking
about *your* dirtying of a given cache line, you won't necessarily
see what data is actually stored by *them* (which happens later
via a potentially different path through the HT fabric).
Worse, if the store is being done into an Opteron's local SDRAM,
and the local memory controller knows from recent history that
no-one else has the data cached [e.g., right after a SNOOP broadcast
gets its responses back], then *no-one* else except that local
Operton will ever *see* what data was stored -- which makes an
external write barrier impossible.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: time to bring back the Lisp machines?
Date:
Message-ID: <878xpjndq8.fsf@qrnik.zagroda>
"Mark Tarver" <··········@ukonline.co.uk> writes:
> So is anybody out there considering that LMs might have some future
> in today's market?
What would be their advantage over today PCs?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
>
>> So is anybody out there considering that LMs might have some future
>> in today's market?
>
> What would be their advantage over today PCs?
Cleaner, faster, cheaper architecture.
If Intel implemented a Lisp Machine, their processors would not get as
hot when executing Lisp code. Actually, this is the problem. They
won't introduce Lisp Machine specific instructions in their processor
until 99% of the code running on their processors Lisp.
When they'll benchmark random OS and applications, and realize that
their processors are spending half the time doing type-tagging or GC,
then they'll do what it take to do it in hardware, hence duplicating
the speed for common OS and applications.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."