HDTenEightyP/NetNews huggingface dataset:
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: More Alpha AXP Performance Numbers
Date: 13 Nov 92 20:32:28 GMT
Article-I.D.: cs.Bxo927.ECF.2
Organization: School of Computer Science, Carnegie Mellon


In article <Bxo6rI.C89.2@cs.cmu.edu> I wrote:
>Probably for the same reason one would buy an Amdahl - big IO, big
>memory, big caches

Just to rub the point in: the DEC 10000 AXP has:

- 6 processors
- 2 to 14 GB of ECC RAM
- up to 4 Futurebus+ IO busses
- up to 8 FDDI (100 Mb/s network) links
- up to 56 GB of in-cabinet disk
- up to 284 GB of directly attached disk
- up to 10,000 GB of in-cluster disk
- 800 MB/s "system interconnect"
- 400 MB/s I/O bandwidth
- support for HIPPI,CI,XMI,...
- Integrated Uninterruptible Power System

none of which I would reasonably expect on a desk, this year.

I'm not in the market for this, so I have no idea how it compares to
its competition. My point is not that this is/isn't a wonderful buy.
My point is that it is almost never reasonable to compare wildly
different *systems* by a single metric, such as $/SPECmark.  Heck,
some of the potential customers may ask DEC to price it without the
floating point units...
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Xref: sparky comp.arch:10476 comp.unix.bsd:8537 comp.os.linux:15921 comp.arch.storage:749
From: nickh@CS.CMU.EDU (Nick Haines)
Subject: Re: DEC Alpha AXP System Performance
Originator: nickh@VOILA.VENARI.CS.CMU.EDU
Organization: School of Computer Science, Carnegie Mellon University
Date: Tue, 10 Nov 1992 18:41:45 GMT

In article <1992Nov10.153629.27510@ryn.mro4.dec.com>, Dileep
Bhandarkar provides us with SPEC figures for the new DEC/Alpha
machines, which I've put into a table:

SPEC results for DEC/Alpha AXP Systems:

model		10k/610	7k/610	4k/610	3k/500	3k/400
speed		200MHz	182MHz	160MHz	150MHz	133MHz

SPECmark89	184	167	136	122	108
SPECint89	105	 95	 84	 73	 66
SPECfp89	269	244	188	170	151

SPECint92	107	 97	 84	 74	 65
SPECfp92	200	182	143	126	112

Two questions:

	- how much do these machines cost? What's the SPEC/$?
	- is the dropoff in SPEC/MHz due to smaller caches?

Nick Haines nickh@cmu.edu
Newsgroups: comp.arch,comp.benchmarks
From: cmg@ferrari.cray.com (Charles Grassl)
Subject: Re: DEC ALPHA Performance Claims
Reply-To: cmg@magnet.cray.com
Organization: Cray Research, inc.
Date: 12 Nov 92 09:18:53 CST

In article <BxKI38.DM7.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>>
>>System                100x100 dp      1000x1000 dp
>>
>Compaq Deskpro 486/33	      1.4
>DEC 5000/200 (25 MHz R3000)   3.7
>Cray-1			     11		       31
>>DEC 3000/400S AXP           26.4              70.8
>>DEC 10000/610 AXP           42.5             111.6
>Convex C3810 (1 proc)	     44		      113
>Cray C90     (1 proc)	    387		      874

      (NOTE: The performance above which is attributed to a CRAY-1 is
      actually that of a CRAY S-MP, NOT a CRAY-1.  The CRAY S-MP is
      SPARC based system with scalar and with vector processors.  There
      was also a product announcement last week from Cray Research
      Superservers, the former FPS, regarding a new vector CPU for the
      CRAY S-MP.)

We must be careful when comparing new architectures with old
architectures because of the effect of software.  The CRAY-1 has two
entries in the LINPACK benchmark report:

System                 100x100 dp    1000x1000 dp
CRAY-1S  cf77 2.1        27 Mflop/s     110 Mflop/s
CRAY-1S  CFT 1.12        12             110

That CFT 1.12 results was generated in the early 80s (1983?) with cft
1.12.  The cf77 2.1 result was generated in 1989.  With current
compilers from Cray Research, the 100x100 performance for the CRAY-1S
would be approximately 35 or 40 Mflop/s.  On this particular benchmark,
we would see a 3x speed improvement attributable to software.  (The
1000x1000 performance should not change with time because it usually
generated with "hand-optimized" libraries.)

The improvement of microprocessor speed of the past decade has been
tremendous.  How much of this improvement is attributable to software?

Charles Grassl
Cray Research, Inc.
Eagan, Minnesota  USA
Newsgroups: comp.arch
From: graeme@labtam.labtam.oz.au (Graeme Gill)
Subject: Re: RISC goes CISC?
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Wed, 11 Nov 1992 01:18:22 GMT
Summary: Intel RISC instruction sets

In article <15394@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
> Do you, or does *anybody* else, have *any* solid evidence for the claim
> that I've heard advanced on occasion that the 586^H^H^HPentium really
> has a "native RISC mode" that can really execute "native RISC mode" code
> directly?

	And it would be disappointing (although not un-expected) to find
Intel introducing yet another (different) RISC instruction set. They
already have the 860 and the 960, why invent another one ?

	Graeme Gill
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: News Release - Pentium - "INTEL UNVEILS NAME FOR ITS FIFTH GENERATION COMPATIBLE MICROPROCESSOR"
Date: 10 Nov 92 21:56:47 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <GLEW.92Nov9230655@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:

| I don't think I "iced over" the release date question - for the very
| good reason that I don't know. I didn't work on that chip. The release
| date is up to marketing.

  Unfortunately, that's true. It has no relation I can see to when Intel
will actually manufacture the chip! Intel was talking about this chip
years ago, and it was scheduled for a year ago (4Q91), then 1Q92, then
3Q92, then early 1Q93, then late 1Q93, and now the last word I heard was
FCS in 2Q93. Which really means that the chip will be in customer's
hands at stable prices by 1Q94 *if Intel doesn't slip it again*.

  What Intel marketing is doing is dangling the product just out of
reach to discourage major users from scraping DOS and Intel and going to
a reasonable workstation to get affordable performance. Just as IBM
dangles OS/2 out there to keep people from going to UNIX.

  And when it comes out and vendors are charging $2k per chip because
everyone's on allocation Intel will promise to ramp up production, just
as they did with the 486. And just like the 486 the actual price drop
will come when AMD releases a faster cheaper 486, and not a moment
before. This is my prediction. The 386 dropped when the fast 286's came
out, the 486 dropped when the fast 386's came out, and I predict that
the 586/P5/Pentium will be out in volume and at reasonable price only
when people refuse to buy them.

  I've started now. 

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: shrchin@susssys1.reading.ac.uk (Jonathan H. N. Chin)
Newsgroups: comp.arch
Subject: simple cpu-less computer
Summary: what would be a nice way to implement a cpu on a gate-array?
Date: 5 Nov 92 09:03:31 GMT
Organization: University of Reading

In our department, the 6809-based ALEX (Assembly Language EXperimenter)
is being phased out for use in practicals.  They are likely to be
replaced by 68020-based machines. Currently 386 PCs are being
used to simulate the ALEX (previously one cross-compiled on the PC and
downloaded to the ALEX over a serial line, and before that...).
The experiments are aimed at 1) demonstrating programming in machine
code, and later 2) giving practice/experience at programming in assembler.

One of the lecturers thought it would be fun to build a simple CPU
from a gate-array. First off, nobody in the dept has much experience
with them so it would be useful experience, and secondly it seemed
like a neat (bizarre) idea to run programming experiments on a machine
without a CPU.

His instruction set consists of: LOAD, STORE, ADD, SUB, AND, OR, XOR.
There are four addressing modes: IMMEDIATE, ABSOLUTE, INDIRECT, CONDITIONAL.
(IMM -> 2nd byte is data, ABS -> addr of data, IND -> addr of addr of data).
He explained COND to me, but I didn't really understand him.
There is one flag (testing for zero I seem to recall), and if it is set
the COND instruction is executed as if it were IMMED (I think).

Each instruction is 2 bytes, the first containing the op, mode and register
and the second a memory location.
There are 8 registers and it is possible to address 256 bytes of memory.
the registers occupy the bottom 8 bytes of memory. I think 0 is the PC.

Aside from the COND mode, it looks nicely orthogonal to me.

Does anyone know of any equally simple (or simpler) designs?
In particular, I was curious about a registerless design using
stacks(!) instead maybe.
Or how about one that allows 16bit addressing? (Entailing longer
instructions I presume.)

Also, I vaguely recall discussion of "the ultimate RISC", a single
instruction machine. What were the references to that?

-jonathan

-- 
Jonathan H N Chin, 8 kyu \ Dept. of Cybernetics, \ "Respondeo, etsi mutabor"
                          \ University of Reading \
shrchin@uk.ac.rdg.susssys1 \ Box 225, Whiteknights \ < Rosenstock-Huessy >
bq305@cleveland.freenet.edu \ Reading, RG6 2AY, U K \
Newsgroups: comp.arch,comp.sources.wanted,comp.unix.programmer
From: sanjay@cray.com (+Sanjay Krishnamurthy)
Subject: Re: Tools to measure Pointer Usage
Keywords: Pointers, loads, safety
Organization: Cray Research Superservers Inc., San Diego CA, USA
Date: Sat, 7 Nov 1992 00:04:05 GMT

>We are about to undertake a project to study pointer usage
>in computer programs, and were wondering if anybody has
>written a tool that will tell you what percentage of loads
>are, in fact, just getting addresses for pointer dereferences...

In "Proving safety of speculative load instructions at
compile time," ESOP'92, David Bernstein, Michael Rodeh
and Mooly Sagiv, there are some results which go way
beyond what you are asking. They have an answer to the
question-can you prove it is safe to execute a load
instruction at a certain point x in the program, at
compile time. Their method and results are relevant
to your question because one of two ways in which a load
becomes safe at point x is when an address is loaded
into the register used in the load instruction along
every execution path leading to the point x. The
second safety criterion is when the loaded register is
used along every execution path leading from x (in
the same way Ken Kennedy handled safety issues dealing
with code motion).

-Sanjay M. Krishnamurthy


Newsgroups: comp.arch
From: swm11@cl.cam.ac.uk (Simon Moore)
Subject: hardware sorting
Keywords: hardware, sorting, earliest-deadline-first scheduling
Organization: U of Cambridge Computer Lab, UK
Date: Fri, 6 Nov 1992 16:52:52 GMT


I have a requirement for a hardware sorter to sort
deadlines for high speed real-time earliest deadline
first scheduling.  New deadlines can arrive at a peak
rate of one every cycle and the earliest deadline
needs to be extracted every 8 cycles.

I would be very interested in anyone who has come
across any hardware to perform such high speed
sorting.  (N.B. Batcher sorting networks are not
practical because they require several cycles to
sort a single set of values.)

 - Simon 

[Simon Moore][University of Cambridge, Computer Laboratory][swm11@cl.cam.ac.uk]
Xref: sparky comp.arch:10538 comp.unix.bsd:8630 comp.os.linux:16096
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
Subject: Re: IDE faster than Mips SCSI disk
From: Bruce@hoult.actrix.gen.nz
Date: Mon, 09 Nov 92 20:11:45 +1300 (NZDT)
X-Mailer: rnMac Buggy, I mean Beta, Test Version


Othman Ahmad Writes:

> IOZONE performance measurements:
> 	345684 bytes/second for writing the file
> 	641985 bytes/second for reading the file

> IOZONE performance measurements:
> 	367586 bytes/second for writing the file
> 	499942 bytes/second for reading the file



Those are *both* nowhere near the limits of a cheap hard disk.


Recently I used the MPW "Search" command (equivalent to grep) to look for
a simple string in a directory of text files.  Each file was about 100KB to
200KB in size, for a total size of 45MB (about 300 files).

The search took 30 seconds, or 1.5MB/sec -- that's 2.5 to 3 times faster than
your numbers.  The disk was a cheap Quantum 240MB 3.5" SCSI-1 and the
Macintosh was a Quadra 700 (25 MHz '040).
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 8 Nov 92 23:40:19 GMT
Organization: Auspex Systems, Santa Clara

>	Intel is slowly finding that the CISC way of doing things is not
>always optimal.  Pipelining a CISC chip is painstaking brutal, and they 
>are thus focusing their efforts on the new Pentium chip, which will largely
>be a RISC chip which can execute the 486 instruction set if need be.

And, given that the *only* instructions that Pentium can execute, as far
as I know, are 3andup86 instructions, it needs to be.  (NOTE: there may
well be some additions to the instruction set, just as the 486 added a
couple of non-privileged instructions.)

Do you, or does *anybody* else, have *any* solid evidence for the claim
that I've heard advanced on occasion that the 586^H^H^HPentium really
has a "native RISC mode" that can really execute "native RISC mode" code
directly?

NOTE: the claim that if you recompile code it may execute faster is not
sufficient evidence for that claim; remember, Pentium is a superscalar
chip, and may thus run code faster if instructions are scheduled
differently.

Neither are block diagrams with a big "RISC engine" block and a small
"*86 compatibility" block evidence for that claim; the "RISC engine" may
not expose its internals outside the chip.
From: mtayler@pilot.njin.net (Mark Tayler)
Newsgroups: comp.arch
Subject: multi-computers, Definition, Questions
Keywords: multicomputer, multi-computer
Date: 7 Nov 92 18:53:16 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I am posting this for a friend
He needs to find information on "multi-computers"

What is the definition of a multi-computer
Are there any machines out there that are "multi-computers"
Is there a better news group for this topic

If you have any info I would appreciate it

****************************************************************************
*  Mark L. Tayler                               System Administrator:      *
*  mtayler@pilot.njin.net                       County College of Morris   *
*                                               (201) 328-5772    (VOICE)  *
*                                               (201) 328-5058    (DATA)   *
*                                               No Net Access Yet !!!!     *
****************************************************************************
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 13 Nov 92 01:00:10 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <15444@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>The i860 is going down the pan, but the new chip to be used by Intel
>>SSD and which will be x86-ish will have a new instruction set.
>
>"Will be x86-ish" and "will have a new instruction set"?
>
>Am I missing something here?  Which will it be - x86-ish, with an x86
>instruction set, or not x86-ish, with a new instruction set?

More the latter, to the best of my knowledge.  That is, it will somehow
resemble the x86 but won't be one.  And it'll be 64-bit.  It won't run
x86 code and it won't run i860 code.  And SSD will be the first
customers and write their own compilers, etc.  That's the best we know,
more or less.

>>This SSD chip is due in 1996.  I wonder if it's really the Pentium?
>
>I've heard claims of a 64-bit member of the x86 family; *if* the chip
>has a new instruction set, perhaps they'll have the x86 instruction set
>as the 32-bit instruction set, and some new instruction set as the
>64-bit instruction set.
>
>Doesn't sound like the Pentium, in any case.

Well, why not?  If Intel delays the Pentium until 1994 it would be due
at about the same time.  This is not to say I think the SSD chip *is*
the Pentium, just that it looks like an interesting coincidence.  This
is not to say I think the SSD chip *is not* the Pentium, either.  B^>

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Xref: sparky comp.arch:10497 comp.lang.misc:3539
From: mef@aplcenmp.apl.jhu.edu (Marty Fraeman)
Subject: Re: What's RIGHT with stack machines
Keywords: stack computers, embedded control
Organization: Johns Hopkins Continuing Professional Programs
Date: Fri, 6 Nov 1992 22:28:05 GMT

In article <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE> pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
>
...
>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).
>
The SC32 does exactly this in hardware.  John Hayes has extensively
measured lots of programs and usually sees far less than 1% overhead
for this.  Our first two Forth processors transfered half the on-chip
stack on over/underflow.  Measurements later firmly convinced us this
was not a good strategy.  So our third chip, the SC32, just transfers
one register.  Our fourth chip will do the same.  

>Are there any researches how many stack cells should be directly accessed by
><const> pick or <const> roll? Having only three is messy, I think, 4 or 5 would
>be nice; 
The SC32 has access to the top four elements of both return and data stack.
Four was choosen after inspecting our applications and finding that picks
always used a constant known at compile time and in no case was access deeper
than four needed.  This is another decision we don't regret, from a
software perspective, even on our fourth version of the machine.  This
feature does have a tendency to creep into the critcal path of the machine
if your not careful.


	Marty Fraeman

	mef@glinda.jhuapl.edu	(<--- not the machine this is posted from!)
	301-953-6000, x8360

	Room 13-s587
	Johns Hopkins University/Applied Physics Laboratory
	Johns Hopkins Road
	Laurel, Md. 20723
Newsgroups: comp.arch
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Los Alamos National Laboratory
Date: Fri, 6 Nov 1992 18:18:26 GMT

In article <2230@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
|> In article <1992Nov4.183718.5242@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
|> [...]
|> >The rationale document for ANSI C explicitly
|> >recognizes the optimization penalty inherent in pointers and suggests
|> >that remedies to this be a priority in future versions of the standard.
|> >Yes, if avoid procedure calls (at least, all those whose arguments
|> >are pointers), 
|> 
|> Automatic optimization by compilers have little to do with the above
|> mentioned *HAND* optimization.
|> 
|> You can transform the following program
|> 
|> 	f(a,b,c)
|> 	double *a,*b,*c;
|> 
|> 	for(i=0;i<4*N;i++)
|> 	{	a[i]+=b[i]*c[i];
|> 		...
|> 
|> to
|> 
|> 	for(i=0;i<N;i+=4)
|> 	{	b0=b[i]; b1=b[i+1]; b2=b[i+2]; b3=b[i+3];
|> 		c0=c[i]; c1=c[i+1]; c2=c[i+2]; c3=c[i+3];
|> 		a0=a[i]; a1=a[i+1]; a2=a[i+2]; a3=a[i+3];
|> 		a[i]=a0+b0*c0; ...
|> 
|> by hand, knowing that the area for a, b and c does not overlap.

And the code still does not parallelize.  Why?  An ANSI C implementation
must *infer* which things can be parallel and which can't because the
C language doesn't have explicit vector constructs.  There is *NO*
*HAND* optimization of the above code which will remendy this - without
using some non-standard extension for explicitly declaring whether
the variables are aliased or not.

Yes, if you have a primitive, non-pipelined, non-vector, non-parallel,
purely scalar machine, then perhaps careful hand coding can produce
as good a result with C as with assembly.  If you have such a machine,
you obviously don't think speed is worth paying for in hardware - why
do you think spending *more* money for programmer time to hand optimize
is a better investment?    

|> [...]
|> >It's easier to use assembly directly.
|> 
|> Thus, it is easier to use C.

Most assembly languages have more legible *syntax* than C, their
semantics are usually cleaner and more well-defined, and they 
provide direct control, rather than indirect reliance on the 
inference capabilities of the compiler.

-- 
J. Giles
Newsgroups: comp.arch
From: drdavis@u.cc.utah.edu (Darren R. Davis)
Subject: Registerless processor
Organization: University of Utah Computer Center Student Mail Machine
Date: Fri, 13 Nov 92 18:16:54 GMT

I have been pondering an idea for a machine architecture.  A processor
that has no registers.  I am familiar with some architectures that have
done this.  My twist on this theme is to have a very large cache on chip
for memory locations (effectivelly becoming registers).  This goes
against the RISC idea of having very large register sets with load store
instructions.  This machine would just reference memory, and the most
common addresses becoming cached internally to the processor giving very
fast access.  Does anyone know of such a machine, and what are your
thoughts on this kind of architecture.  I envision the cache being
something like 8K or greater giving a large effective register set.

This machine idea seems very Turing like in that it has a large memory
space and small control structure.  If machine instructions as well as
memory values remain on chip operations should be very quick.



The one processor I know of is the TI9900 I believe, but it does not
have all the cache stuff.
Newsgroups: comp.arch
From: John@boole.uucp (John Ahlstrom)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Boole & Babbage, Inc.
Date: Fri, 6 Nov 1992 19:10:31 GMT

In <1992Nov5.202412.7266@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:

>In article <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>:
>:I write programs for correctness and maintainability first, THEN worry
>:about little details such as performance. If you create something that's
> 
>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.

>Needless to say, there are people who have to worry about speed FIRST,
>and that other considerations are (almost) irrelevent.
               As Weinberg said:
	       If it doesn't have to be correct, I can make
	       it as fast as you want. (paraphrase)
	       
	       
John Ahlstrom
Boole & Babbage
Sunnyvale CA 94086

I can neither confirm nor deny that
anyone else holds these opinions.

)
Newsgroups: comp.arch
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Mon, 9 Nov 92 19:57:11 GMT

large accounting systems routinely carry 5 or 6 digits to the
RIGHT of the decimal.   The story I was told was that the round-off
error in the accounts of GM amount to several millions in TAX payments,
(or at least did in better times) so the IRS insists that the
computations be carried with many digits.  

Oh yes - where do you get fractional cents??? Amortization and
depreciation calculations, for starters.   Also the oil and
gas biz has similar issues, particularly with currency exchange
and the like.

	-Mike

Bellcore?? Bellcore isn't allowed opinions. Any found here are mine.
Newsgroups: comp.arch