Article View: comp.arch
Article #2066Re: Memory utilization & inter-process contention
From: John Mashey
Date: Thu, 31 Aug 1989 16:35
Date: Thu, 31 Aug 1989 16:35
48 lines
3108 bytes
3108 bytes
In article <1989Aug30.152155.9613@mentor.com> plogan@mentor.com (Patrick Logan) writes:
>In article <1989Aug26.232710.27174@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>Take a look at the history of Lisp on Lisp machines, whose time has come
>>*and gone* -- those awful "C-only" RISC machines run Lisp faster than the
>>custom-cooked Lisp machines do.
>Saying that C machines run Lisp faster than Lisp machines is
>simplistic. To run Lisp faster on a C machine requires more
>declarations in the code (or, as with T, more use of "type-specific"
>procedures such as fx+ instead of generic +). This goes against the
>grain of Lisp programming.
>
>Lisp machines provide a better environment (e.g. protection, ability
>to write fast, generic code) per performance unit. I'd guess the only
>reasons their time is gone are market based. They're sure to return in
>one form or another as more and more C machine programs are written in
>Lisp-like languages. Many C machine architectures (e.g. SPARC) already
>incorporate some support for Lisp.
There are many good ideas in LISP, and more of it will filter over.
The issue (and it has been discussed before in comp.arch), is that
the economics of the computer business end up with the following:
a) If something is a low-volume, special-purpose architecture,
it must be MUCH better at what it does than the high-volume,
cheap competition. If it isn't, it will end up going away,
because the competition gets to keep tracking the technology
curve at speed, rather than getting behind it. also,
if something has high-volume in VLSI, it gets to be cheap.
b) The current RISC chips are getting fast and cheap enough
that this is happening.
c) There is still some fine-tuning to be done, but most of
them are more like tweaks added to some of the existing
architectures (tagged adds, for example, by themselves, do
not necesarily solve the problem: consider the exception-
handling sequences also needed).
Useful datapoints might be, now and in future:
a) Symbolics, Inc. history, where it seems like they're
geting out of hardware-design business in favor of (fine) software.
b) TI: Ivory chip versus SPARCs
CONJECTURE/PREDICTION: fast VLSI RISCs will end up capturing the high
end of the LISP market over the next few years.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID:
<26595@winchester.mips.COM>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!ames!amdahl!pyramid!prls!mips!mashReferences:
<70663@yale-celray.yale.UUCP> <1989Aug26.232710.27174@utzoo.uucp> <1989Aug30.152155.9613@mentor.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!ames!amdahl!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch,comp.sys.mips Subject: Re: Memory utilization & inter-process contention Message-ID: <26595@winchester.mips.COM> Date: 31 Aug 89 16:35:12 GMT References: <70663@yale-celray.yale.UUCP> <1989Aug26.232710.27174@utzoo.uucp> <1989Aug30.152155.9613@mentor.com> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 48