HDTenEightyP/NetNews huggingface dataset:
From: grant@pentagon-gw.army.mil (Pete Grant)
Newsgroups: comp.arch,comp.lang.lisp
Subject: NXP1000, was Re: Symbolics & LISP machines
Date: 7 Nov 92 23:10:35 GMT
Organization: U.S. Army Artificial Intelligence Center, The Pentagon

In article <CGAY.92Nov5221353@ilix.cs.uoregon.edu> cgay@cs.uoregon.edu writes:
>
>   They also used to make and sell their own hardware that was
>   optimised to run LISP code as efficiently as LISP code can be run.
>
>Still do.  Have just recently come out with the NXP1000.  I don't know
>much about it except I believe it's a desktop machine and runs Lisp
>pretty fast (somewhere in the range of a Sun 4 I believe, but with a
>much better development environment).  Symbolics' number is 800-394-5522.
>

NXP1000 (they started to call it "The Brick" but seem to have dropped that
designation recently) is a Lisp processor designed to be used in conjunction
with Suns and other machines in a networked environment.  It's a complete
CPU with its own hard disk but no monitor or keyboard.  A user who has an 
X-windows terminal can logon to the NXP1000 and have a full Genera 
development system available.

Of course, like other Symbolics machines, it's a single-user box but
since it's on the net, anyone can logon to it at his/her own desk.

We've had ours for a month now.  It was rather unreliable at first but
seems to work OK now.  It appears to be quite fast; however, this
appearance may be due to the ultra-quick screen IO of the Suns.  I plan to
run our "big" system on it and find out -- when I get time.

Pete.
Newsgroups: comp.arch,comp.lang.misc
From: osycs@giac1.oscs.montana.edu (Craig Spannring)
Subject: Re: Hardware Support for Numeric Algorithms
Keywords: n
Organization: Geographic Information & Analysis Center Montana State University
Date: Fri, 6 Nov 1992 07:54:59 GMT


In article <1992Nov5.202412.7266@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
>You've probably never done any large scale computing.
>
>I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
>is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
>instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.

Large scale computing demands that you to avoid the unreadable
micro-optimizations that Herman is suggesting.  If one of your little
attempts at optimizing the code ends up producing incorrect results
then you've just wasted months of research time.  Meanwhile your
colleagues that have programs producing correct results are getting
published and getting grants.  How much research and computing time are
you wasting with buggy programs?

The second problem with these 'optimizations' is that they aren't.
Herman seems to be most concerned with saving a few clock cycles per
iteration.  The only significant performance gains will be found be
using an algorithm that uses fewer iterations.  Example-  Even a highly
optimized bubble sort will run slower than an unoptimized quick sort
for the large data sets you are refering to.

Get a clue.

-- 
=========================================================================
 Six of one, 110 (base 2) of | Craig Spannring --- (406) 994-6128
 another.                    | osycs.giac1.oscs.montana.edu
 ----------------------------+ Geographic Information & Analysis Center
Newsgroups: comp.arch
From: andy@research.canon.oz.au (Andy Newman)
Subject: Re: IDE faster than SCSI-2
Organization: Canon Information Systems Research Australia
Date: Tue, 10 Nov 1992 05:42:07 GMT

eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
[....lots of stuff about how one disk drive/controller/device driver
 combination  is faster than another one....]

Are you sure you're measuring what you think you are ;-)

-- 
Andy Newman (andy@research.canon.oz.au)
"Ignorance is curable, stupidity isn't." - Bill Campbell
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: What's become of the T9000?
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Thu, 5 Nov 1992 13:33:40 GMT

In article <duck.720958486@nuustak> duck@nuustak.csir.co.za (Paul Ducklin) writes:
>Has T9000 silicon ever appeared? Have inmos gone under? Will we ever see

They have it (rev 2, with everything on the chip), and are testing it.

No.

>the C104?

Very likely, yes.

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077  |1.30|| Cheap Sun eqpt available.
Internet:dhd@exnet.co.uk, Damon@ed.ac.uk, d@hd.org|| Mail/news feeds available.
--------------------------+ Will exchange uucped local articles free over V22b.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Newsgroups: comp.arch
From: don@mars.dgrc.doc.ca (Donald McLachlan)
Subject: Re: Hardware Support for Numeric Algorithm
Reply-To: don@mars.dgrc.doc.ca
Organization: Communication Research Centre
Date: Fri, 13 Nov 92 14:13:00 GMT

I believe Herman knows about the best algorythms for what he is doing.  Therefore
I suspect you folks who say try another algorythm are wasting bandwidth.

I believe correct results are far more important to Herman than the wrong answer
3 times as quickly.  Therefore the folks arguing over which is more important,
correctness or speed, are also wasting bandwidth.

Some of you seem to be getting the impression that Herman starts with highly
optimised code.

I suspect he writes code to verify the algorythm works.  He then optimises the
hell out of it.  Then when he posts it and asks for help for further
optimisations no one can easily understand the code.

If what you really want is nice un-optimised code to look at, I suspect Herman
would comply (as it is in his best interests) is you asked nicely.

---
Donald McLachlan			e-mail	don@mars.dgrc.doc.ca
Communications Research Centre / DRL	office	613-998-2845
3701 Carling Ave.,			lab	613-998-2423
Ottawa, Ontario				fax	613-990-7987
K2H 8S2



Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: RTX and SC32
Organization: Xenix Support, FICC
Date: Sun, 8 Nov 1992 02:31:15 GMT

In article <CLIFFC.92Nov6094232@dawn.rice.edu> cliffc@rice.edu (Cliff Click) writes:
> > are stack machines.  Do they have to throw more than 30 years of machines 
> > out to attract CS researchers? 

> How come I've never programed on one, despite 8 years of college-level
> schooling?  Obviously I picked the wrong schools ;-).

You picked the right school, just a number of years too late. Rice used
to be big into Burroughs machines, but at some point switched to IBM and
took a major performance hit. That's IBM 360 architecture, mind, the IBM
5000 series (including the IBM PC) wasn't out at that time.
-- 
% Peter da Silva % 77487-5012 % +1 713 274 5180 %
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.arch
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: Symbolics & LISP Machines
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Sat, 7 Nov 92 22:43:50 GMT

In article <Bx9L43.6r0@world.std.com> jcooley@world.std.com
(John Cooley) writes:
>A lot of what I know about them is quite old.  I don't know what they're doing 
>today but here's a quick synopsys of what they've done: 
>
>It was founded by some MIT LISP gurus and practically every piece of code
>written in that company was in LISP. (And I mean everything! mailers, editors,
>file managers, - you name it, they've probably done it in LISP.)

Is that so unusual?
I have a Greenblatt right here. (Wow what a chance to do an Annie Hall...)

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Resident Cynic, Rock of Ages Home for Retired Hackers
  {uunet,mailrus,other gateways}!ames!eugene
Second Favorite email message: Returned mail: Cannot send message for 3 days
A Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya
Newsgroups: comp.arch
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: DEC Alpha AXP System Performance
Organization: The Backbone Cabal
	<15445@auspex-gw.auspex.com> <BxL3IH.KtH.2@cs.cmu.edu>
Date: Thu, 12 Nov 1992 20:39:00 GMT

In article <BxL3IH.KtH.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> 
> What he may have meant, is that HP won't be able to use offchip
> primary cache much longer. That was difficult at 66 MHz, and is
> really impressive at 100 MHz. Even HP can't do it at 200 MHz, surely.
> 


yes, but at 66Mhz, and 100Mhz, the technique has been real effective.
By the time they get to 200Mhz, there will be enough chip real estate
to put reasonable 1st level caches on chip.  The technique should be
just as effective at making the 2nd level cache faster, so I don't
think HP is wasting effort in the long run either.


-wayne
Newsgroups: comp.arch
From: elan@tasha.cheme.cornell.edu (Elan Feingold)
Subject: Optimizing Old Code for i586
Reply-To: elan@tasha.cheme.cornell.edu (Elan Feingold)
Organization: Cornell University
Date: Fri, 6 Nov 1992 19:45:08 GMT


OK, I don't read this group, so I don't know if this has been talked about
much already, but I woke up last night at about 4AM in a cold sweat 
and with this wierd idea:

Write a program that takes a .exe file and performs the following analysis
on it:

	a) Break up the code into windows, bounded by branches.
	b) Rearrange the code within the windows following the i586
	   idea of being able to execute two instructions in a cycle if
	   there are no dependancies.  The idea is that since the 586 only
	   "looks ahead" one instruction, one helps the process by spending
           time reorganizing the code in the .exe to maximize the chance that
  	   the i586 will be able to execute two consecutive instructions 			   concurrently.

Is this a really stupid idea?
Would the performance increase be anywhere noticiable?
Will compilers for the i586 probably perform this optimization?

Thanks, 

Elan

--
---------------------------------------------------------------------------
|  Elan Feingold       |  .sig currently undergoing renovation...         |
|  CS/EE Depts.        |   					          |
|  Cornell University  |  					          |
|  Ithaca NY 14850     |             				          |
---------------------------------------------------------------------------
Newsgroups: comp.arch
From: shyamal@seas.smu.edu (Shyamal Prasad)
Subject: What's wrong with goto's
Organization: SMU School Of Engineering and Applied Science
Date: Mon, 9 Nov 1992 17:32:29 GMT

	The 'goto' thread on the newsgroup is really something else. However
it seems that the basic question is "What is wrong with the goto?",
and no one seems to answer this one. This discussion may even be in
the wrong group - but since there is so much interest, here goes.....

	Disclaimer: I am not here with all the answers,
and nothing I have to say is very original, and I am not an
authority on this. I am just trying to state a viewpoint that I
feel has not been put strongly enough in this discussion.

	In the first place there is nothing wrong with the goto
statement itself, it's the *label* that creates the problem ! (And
this is a relatively well known, but often forgotten, viewpoint)

	"Understanding" a program is, in my opinion, about
intuitively getting the hang of invariants. But when we see a goto
our intuitive understanding of an invariant condition gets thrown off
because we are really not sure where we "came from". We don't know
(formally or intuitively) what the invariants are any more when we see
a label. If we use labels and ensure that we jump to them 
carefully enough that some (useful) invariant is always satisfied 
then we are doing okay, are we not? After all if we are sure that a
certain condition holds at a label we have *not* lost any clarity over
an equivalent structured program without the goto.

	The reaction to the goto is a cultural thing. It just looks ugly,
but we never *really* question why. Try implementing a finite machine
with each state implemented with  code marked by a label. Transitions 
between states are goto statements. I always do this - it works because
each label marks an entry to a state of the machine, and the machine
states are so well defined! I don't lose any clarity because my labels
always have well defined invariant conditions on entry. This seems to be
so much clearer than the so called 'structured versions' that I tried.

	Structured programming has little to do with the lack of using
goto statements - it has to do with improving code clarity. I never read
Herman Rubin's code, only because it was *so* unclear, if you use
goto statements make sure they improve clarity. That is the final
arbiter; I have always believed that efficient programs can be
clear (with or without gotos). I am not sure if Rubin's code runs better
with all those goto's or not, but the real point is that if he uses goto
statements he should do it with discipline.

	I even ask myself : What is the use of break statements that
are more powerful than the simple single level one like we have in C?
CLU and ADA need some way to specify the level to which execution
should exit. What is the point of replacing the goto ?? If we used
a goto with a label *have we lost any clarity*? After all the label
is there only to provide an early break or continue....use it in
just that way ("keep you invariants true"). 
-- 
Shyamal Prasad, Department of Computer Science
Southern Methodist University, Dallas TX 72275
Xref: sparky comp.arch:10641 comp.lang.misc:3604
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Summary: how to satisfy the need for speed
Date: 12 Nov 92 00:52:53 GMT

: From: rh@smds.com (Richard Harter)
: Message-ID: <1992Nov11.100555.4706@smds.com>
: What Bob is telling you is that there are problems
: which are so computationally demanding that computational efficiency is
: far more important than standard programming style guides. 

Well, of *course* that's what he's saying.  But to understand that, one
first must understand that when he says "all other considerations", he
doesn't really mean all of them, just some of them.

Also, he explicitly stated that there are "times when readability,
portability, and ease of maintenance don't matter at all", and in
that I expect he really means "matter little".  Certainly I don't
agree that readability and maintainability EVER have negligable,
much less zero, worth.

I guess my point is, it isn't really straightforward to decide
just "what Bob is telling us", because he uses absolutes so freely,
when upon reflection he can't possibly mean what he says literally.
It has to be decoded somewhat.

: There is a price for programming for clean code;
: in most cases the benefits far outweigh the price; sometimes they don't.

True, but I'm more sympathetic with the Jon Bentley school of
optimization, where you transform clean, correct code into arcane,
incomprehensible code by known-safe transforms, and RECORD THE
TRANSFORMS.  For example, the chapter on code tuning in Programming
Perls, especially the case study of the binary search.  Or, if I'm
remembering rightly, Bentley's book Writing Efficient Programs.  Of
course, the shortcoming in this context is that the central focus isn't
really numerical problems, but I regard that as relatively minor. 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch,comp.lang.forth
From: mike@vlsivie.tuwien.ac.at (Michael Gschwind)
Subject: Re: What's RIGHT with stack machines
Organization: Vienna University of Technology
Date: Sun, 8 Nov 1992 23:40:26 GMT

In article <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE> pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
   Thanks to your interresting report. I have little to add.

   Code size and performance: reduced code size for equal operations means less bus
   bandwidth is requested. As busses (and DRAMs) are today the von Neumann's
   bottlenecks, stack CPUs reduces costs for main memory and second level caches and
   may increase performance, if the costs are equal.

Yes, but you pay a heavy price. Stack machines basically compute
expressions of the type 
((((...) op A) op B) op C) 
so each operation depends on the previous (if nothing else, since all 
ops operate on the stack, there is the stack pointer dependency), so
super scalar or even deep pipelining  are totally out of the question.
I used to like stack machines, they are beautiful, simple, allow easy
compilers, BUT THEY JUST DID NOT SCALE - neither in modern design
technologies nor when it comes to compilers.

   Compiler complexity: Tanenbaum had a compiler project, that did much optimizing
   on the intermediate stack machine code. I think you have little to do to convert
   this code for a stack machine, whereas you have a lot of work to allocate
   registers and schedule instructions, as you have to do on "conventional" RISC
   processors.

Yes, for simple arithmetic expressions, they allow way cool
optimizations. But what do you do when you get to things like CSE? DUP
DUP SWAP SWAP ROT? Hardly efficient! 2 memory accesses for DUP, 4 for
swap, 6 for ROT. You simply have to shuffle intermediate results too
much. Or save them in memory - definitely more expensive than a
register. Once again, with technology of 10 years ago, they were nice,
but it does pay to allocate registers and do scheduling, AND WE HAVE
THE TECHNOLOGY NOW to do it.

   Spill&Fill: did anyone thought about automatic spill&fill-buffers? (if the
   available stack cells decreases to a certain level, a number of stack items are
   load (4 or 8 would be great), and if it increases over a certain level, the same
   amount of stack items is spilled (have a hysterese of about 8 stack entries).

I figure implementation of this is just to hairy - on the same real
estate, you can put 16 extra registers ;) 

mike
--

Michael Gschwind, Dept. of VLSI-Design, Vienna University of Technology
mike@vlsivie.tuwien.ac.at	1-2-3-4 kick the lawsuits out the door 
(currently somewhere in         5-6-7-8 innovate don't litigate         
the Bay Area, back sometime     9-A-B-C interfaces should be free
at the end of this year)	D-E-F-O look and feel has got to go!
     
Newsgroups: comp.arch
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: A challenge to the anti-goto
Organization: eklektix - Boulder, Colorado
Date: Sun, 8 Nov 1992 06:55:51 GMT

firth@sei.cmu.edu (Robert Firth) writes:
>jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:
>>	If we've known about this problem for twenty years, why don't we
>>	have more powerful `break' instructions in our existing languages??
>
>We do.  Exactly the construct you require is found in Ada...
...
>My question: if we have had the *solution* to this problem for ten years,
>why don't more people know about it and use it?

The "solution" predates Ada by quite a bit, of course...

The reason we don't see it more often is that it's turned out not to be
as good an idea as people think when they first consider it.

Single-level "break" can make some pieces of code a lot easier to read.
It's simple, useful, and straightforward.

Multi-level "break" is still useful, but because it can reach further out,
it has several practical disadvantages:
	- It requires some sort of labeling, to identify how far out (how
	  many levels) you're exiting...this gives it a little of the
	  flavor of a goto.
	- In general it takes you "farther" out in the code--the transfer
	  of control will on the average be more distant, hence generally
	  harder to follow.
	- It destroys a certain sense of "nesting"--control from within
	  one or more inner structures can reach various outer points.
All of these reasons taken together still wouldn't condemn the idea of a
multi-level break if it were useful enough.  But it turns out to be one of
those 90% situations--single-level break covers 90% of the need, and the
remaining 10% doesn't justify the added complexity of another construct.

Therefore, most languages have omitted it.  It's not that it wouldn't be
useful, but only the consensus is that it isn't useful enough to justify
the added baggage in the language.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.
Newsgroups: comp.arch
From: linder@ERC.MsState.Edu (Dan Linder)
Subject: Re: asynchronous DSP project at Berkeley
Organization: /home3/linder/.organization
Distribution: na
Date: Thu, 5 Nov 1992 23:54:40 GMT

>   In article <1992Oct27.115210.14352@news.cs.indiana.edu> "Carl Bruggeman"
>   <bruggema@gable.cs.indiana.edu> writes: 

>   I vaguely recall a reference made on this news group several months ago
>   to a group at Berkeley working on a DSP using asynchronous design
>   methods.  Does anyone have a reference to the work done by this group?

You might try:

  G. M. Jacobs and R. W. Brodersen, "A Fully Asynchronous Digital Signal
    Processor Using Self-Timed Circuits," IEEE Trans. on Comp., vol. 25,
    no. 6, Dec. 1990, pp. 1526-1537.

Martin also has a processor described in:

  A. J. Martin, S. M. Burns, T. K. Lee, D. Borkovic, and P. J. Hazewindus,
    "The Design of an Asynchronous Microprocessor,"  Advanced Research in
    VLSI, Proceedings of the Decennial Caltech Conference on VLSI, March
    1989, pp. 351-373. 

>   I am particularly interested in why they chose a DSP rather than a
>   general purpose CPU.  I suspect the answer is that the complexity of the
>   global state machine controlling a typical RISC pipeline (and in
>   particular exception handling and interrupts) is overwhelming for any of
>   the current asynchronous design methodologies.  Am I wrong?

Brodersen is well known in the DSP area so this probably influenced their
decision.  It is interesting to note that the DSP processor uses
microprogramming and Martin's processor only has a few instructions.  I
suspect as well that the complexity of a modern RISC control unit is beyond
current asynchronous techniques.  Are there any asynchronous methods that
can efficiently combine the generation of a multitude of control signals
while also making the complex logical decisions associated with big state
machines?

Dan Linder                               
linder@erc.msstate.edu

Newsgroups: comp.arch
From: jonathan@geop.ubc.ca (Jonathan Thornburg)
Newsgroups: comp.arch
Subject: alpha performance for IEEE vs DEC FP (was: Re: More Alpha AXP Performance Numbers)
Date: 11 Nov 1992 00:50:02 GMT
Organization: U of BC Astronomy  +  U of Texas at Austin Physics / Relativity
NNTP-Posting-Host: rubis.astro.ubc.ca
Summary: how does alpha FP performance depend on IEEE vs DEC FP?
Keywords: alpha performance benchmark floating point SPEC FP IEEE DEC

In article <1992Nov10.204139.5148@ryn.mro4.dec.com>
bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
 [ very nice table of Alpha benchmark data ]

I presume these are for VAX format floating point?  More generally,
it would be interesting to see how these numbers vary for VAX vs IEEE
formats, single vs double precision, and what the penalties are for
turning on precise exceptions and/or full IEEE denormalized support.

- Jonathan Thornburg
  <jonathan@geop.ubc.ca> through mid-November 92, then
  <jonathan@einstein.ph.utexas.edu> or <jonathan@hermes.chpc.utexas.edu>
  [for a few more months] UBC / {Geophysics & Astronomy, Physics}
  [then through Aug/92] U of Texas at Austin / Physics / Center for Relativity
Newsgroups: comp.arch