HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.arch
Subject: Re: dinosaur horsepower
From: joelw@convex.com (Joel Williamson)
Date: Wed, 29 Jul 1992 17:18:26 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX ComputerCorp. The 
 opinions expressed are those of the user andnot necessarily those of CONVEX.

In article <7972@sirius.ucs.adelaide.edu.au> zebee@ucs.adelaide.edu.au (Zebee Johnstone) writes:
>sysmark@helios.physics.utoronto.ca (Mark Bartelt) writes:
>
>>By the way, if the history project does succeed in emulating some of the
>>older machines, will it also provide an emulator for an 026 keypunch? ;-)
>
>Who needs an emulator?  I've got the real thing!

Do you have an 010?  I have an IBJOB binary that I need to correct, and
I'm able to use bits of electrical tape as "bandaids," but it's almost
impossible to punch new holes.  (Right now I'm using a small square
drill and making two cuts. ;^} )

Joel Williamson
-- 

Newsgroups: comp.arch,comp.benchmarks,comp.sys.sun.misc,comp.unix.solaris
From: glew@pdx007.intel.com (Andy Glew)
Subject: Master Slave, SMP, etc.
Organization: Intel Corp., Hillsboro, Oregon
Date: Fri, 24 Jul 1992 06:24:02 GMT


Going further on the discussion of master/slave, floating master, etc:


A system where only one processor *at* *all* *times* can execute the
kernel or handle I/O is not necessarily a master/slave. I've found it
useful to make the following distinctions:


Master/slave(s):
    One master CPU executes the kernel.
    The master CPU determines what processes are to run on the
    	slaves, and then sends them to the slaves.
    If a process running on the slave makes a system call,
    	the slave stops, tells the master, and then
    	waits until the master reschedules it.

Self-scheduling crippled equals:
    One or several CPUs execute the kernel (masters).
    One or several CPUs executes user code only (cripples).
    All CPUs access a common run queue scheduling structure.
    If a process running on a cripple makes a system call,
    	the cripple places it on the run queue, and then
    	gets the next process that does not require a
    	run queue off. (Note that it doesn't wait)
    The "cripples" can basically be imagined as "compute servers"
    	on a shared memory network.

Floating master:
    One kernel lock

Multithreaded kernel:
    Locks around several different kernel data structures,
    permitting multiple people to be in the CPU simultaneously.



Master/slave systems slope off distinctly with number of processors,
on all but the most purely computational workloads.

There are a lot of workloads, however, where self-scheduling crippled
equals, with only one master, provide performance comparable to
floating master and a true multithreaded kernel.

I recall having to explain this to a very annoyed manager (Hi Butch!),
who had been trying to demonstrate the advantages of a multithreaded
kernel on a multiuser workload (MUSBUS).  The multithreaded kernel, in
fact, scaled less well than the self-scheduling crippled equal system.
One may conjecture that this may have been true up to the point at
which the workload saturated a single CPU, but that did not occur - we
got disk I/O bound before we got kernel bound.

Self-scheduling crippled equals often provide better performance than
the floating master, because the kernel gets localized to one
processor's caches. The cost is increased latency on system calls -
but for a thruput oriented workload, that's okay.


--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: rbw00@ccc.amdahl.com (  324  Richard Wilmot)
Newsgroups: comp.arch
Subject: MP interrupt handling  was(Re: Sun 600MP Benchmark Anomaly)
Date: 24 Jul 92 02:52:14 GMT
Reply-To: rbw00@JUTS.ccc.amdahl.com (  324  Richard Wilmot)
Organization: Amdahl Corporation, Sunnyvale CA

In article <1992Jul20.150259.16021@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>
>
>  As a general question, which machines do this now? When GE was in the
>mainframe business we never did it, the kernel was totally shared but
>all hardware interrupts came to the same processor. I think DTSS did
>that, too, but could change the processor if the master went down.
>-- 
>bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
>	It never ceases to amaze me that otherwise rational people, able to
>	understand calculus, compound interest, and the income tax form, can
>	continue to believe that poker is a game of chance.

IBM's MVS uses selective I/O interrupt enablement to vector I/O 
interrupt processing to selected processors in an MP. One would 
suppose that the operating system would then dispatch more other
work to the others or they will just become eligible for the 
next to be dispatched process. This will tend to keep the I/O
interrupt handling code as only polluting a few processor caches
instead of salting it over all. This was discussed here before.
It's not that I/O vectors are vectored to particular machines but
that they are shunted away from others and so only interrupt enabled
processors will catch interrupts.

-- 
  Dick Wilmot  | I declaim that Amdahl might disclaim any of my claims.
                 (408) 746-6108
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Newsgroups: comp.arch
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (Was: Re: What's in a name?)
Date: 22 Jul 92 16:59:06 GMT
Reply-To: vhs@darkcube.radig.de

In article <1992Jul20.183334.19342@crd.ge.com> davidsen@ariel.crd.GE.COM  
(william E Davidsen) writes:
> In article <1325@pacsoft.com>, mike@pacsoft.com (Mike Stefanik) writes:
> 
> |> : What it comes down to is that people are unsatisfied with what their
> |> : computer does for them so they keep buying bug-fixes (aka upgrades) as
> |> : well as new CPUs [...] while around me people keep upgrading their
> |> : PCs from 386/33 to 486/25 to 486/33 to 486/50 and are still unhappy.
> |> 
> |> People upgrade their machines because the marketing hype tells them that
> |> this will put them on the road to Nirvana, and hope against hope, they
> |> open their wallet one more time.  This has nothing to do with a specific
> |> machine architecture or operating system.

No, I guess it doesn't.

> |> : I'm sure the day will come when people notice that it's a matter of
> |> : (esp. OS) software more than hardware [...]
> 
>   That would improve the output speed.

No, no, no! You can improve output speed by upgrading to a faster machine.
That's what people keep doing and that's what I'm critisizing. It is for
most cases (i.e. private applications, different for number-crunching) the
wrong approach. The right approach is to improve the *quality* on the output
and input side. I.e. keep things like copyright-messages and other such crap
off my screen, use an output format so that output can be used as input to  
another command, etc.
It's no use having a fast processor if you have to keep answering lots of
redundant dialogs for every little bit of real work you want to do.
A well-designed combination of OS+GUI can improve one's productivity
by an order of magnitude, while the next chip generation usually only does x2.

But let's take this out of comp.arch - maybe to alt.pervert.microsoft? ;-}

--
Volker Herminghaus-Shirai (vhs@darkcube.radig.de)

If I had intel inside(tm), I'd throw up...
Xref: sparky comp.arch:8252 comp.benchmarks:1184
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Subject: Re: Algorithm for finding set bits in a bit-string (and MSB).
Reply-To: vhs@darkcube.radig.de
Date: Thu, 30 Jul 92 11:57:00 GMT

In many cases it is fastest to just use a lookup table for counting,
outputting, or whatever-ing bits in a byte. With proper alignment
handling and incrementation this can easily be generalized to bit-strings
of arbitrary length. So in the case you want to output a string showing
an ASCII representation of the bits in a bit string (as the original poster  
did) you define:

/* 
 * I didn't test this code. It also may need rewriting if
 * different direction is needed (backwards). In this case, you might use
 * sprintf or equivalent instead of printf and print the string backwards
 */
char *strings[]={
	"00000001",
	"00000010",
	"00000011",
	"00000100",
	...
	};

printString(char *bitString, length)
{
	/* BOS probably best handled by pre-aligning bitString such */
	/* that it always starts on a byte border */
	while((length-=8) > 0) {
		/* proper EOS-handling (e.g. by &ing *bitString and */
		/* truncating strings[*bitString] */
		printf(strings[*bitString++]);
	}
}

As I said, the code above is untested. It just went from the fingers to the
keyboard without ever touching my brain ;-). The end condition of the while
loop probably needs reworking, but I don't feel quite well with >>39  
Centigrades. Guess I shouldn't have eaten that darn fish :-(.

--
Volker Herminghaus-Shirai (vhs@darkcube.radig.de)

Cause I have fish inside(tm), I'm...
Xref: sparky comp.arch:8302 comp.sys.mips:810 comp.unix.ultrix:5884
From: yuki@watanabe.cs.unc.edu (Yuki Watanabe)
Newsgroups: comp.arch,comp.sys.mips,comp.unix.ultrix
Subject: MIPS assembler/linker/memory allocation
Date: 25 Jul 92 02:26:52 GMT
Followup-To: comp.arch

Is there any detailed documentation on MIPS/Ultrix memory allocation 
for C language (and assembly language).   I have MIPS RISC Architecture
book by Kane and Heinrich.   We are interested (eventually) in loading 
a.out file produced by C compiler in a low-level simulator.
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Newsgroups: comp.arch
Subject: Re: BUSES
Date: 31 Jul 92 02:54:51 GMT
Organization: National University of Singapore

jesup@cbmvax.commodore.com (Randell Jesup) writes:
: 	Sure they can.  A single 3.5" drive can sustain 4.2MB/s.  With
: a couple (or even maybe 1) of those, I think an AT bus would get pretty
: crowded...

HUH? are you sure? I thought the normal rate was something like 1 to
2MB/s peak and 300 to 800KB sustained.

jin meng
From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
Newsgroups: comp.arch
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 25 Jul 1992 00:51:21 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: ouroborous

I wrote:
| Second answer: Only one CPU at a time can receive interrupt
| requests from devices in the system.

In article <JIM.92Jul24155432@hunter.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
| It shouldn't be that difficult to arrange for multiple processors to
| execute multiple interrupt service routines simultaneously.

You get that when you get multithreading, ie. Solaris 2, the version
of the system that supports the SuperSPARC in MP mode.

In SunOS 4.1.2mp, we opted for maximum compatibility, which includes
the interactions between the two halves of the device drivers, and to
as large an extent as possible, not requiring source changes to
interrupt service routines.

Feel free to let me know if more detail is needed on this; I'm cutting
it short because (a) it seems obvious, and (b) it's 6pm friday evening
and I hear a beer calling.
Newsgroups: comp.arch
From: pettengill@cvg.enet.dec.com ()
Subject: Re: Request Info Re Bus Trends & Intel 486s
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Sat, 25 Jul 92 05:31:24 GMT

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

|>[Burkhard Neidecker-Lutz]
|>Can you explain which *desktop* applications need peer-to-peer communication ?
|>I.e. what is wrong with going through main memory ?
|>>
|>>[John Theus]
|>>To use today's favorite buzz word: multimedia.
|>>
|>[Andy Glew]
|>First you'll put video on your screen.
|>
|>Then you'll want special effects: things like zooming in on a
|>particular speaker (or the papers on his desk) in a video conference,
|>things like cropping speakers from different video inputs and
|>superimposing them into a virtual conference room.

I assume from the tone of his note that Andy is arguing for peer to peer...

I remember the early days of the Unibus, for which one of the selling features
was peer to peer capability.  However, I can't think of any standard or
specialized device for the Unibus or the Qbus that ever made use of it.
And, when I look at the graphics processors with special capabilities available
today, none that I'm aware of do it with peer to peer, but rather have special
ports.

As someone who has worked on comm technology that can deliver both data and
full motion video, I must say that I've never figured out a good architecture
for having some data from the fiber go directly to the video display and other
data from the fiber go to the memory and thence to the CPU.  I'm not saying
that's not possible, or that it won't happen, but since I haven't figured
out how to architect it without constraints, I'm skeptical that it can be
done given the constraints that current communication architectures imply.

(Let's see, we'll make the video display an IP node and have the fiber
interface adapter route IP packets to either the host CPU or the video
display, so it might also have an IP address....

mulp
DEC
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 24 Jul 92 20:34:49 GMT
Organization: Kithrup Enterprises, Ltd.

In article <1992Jul21.040216.13502@primerd.prime.com> danw@hobbes.prime.com (Dan Westerberg) writes:
>Backwards compatability is definitely a pain in the butt.  I've spent the last
>3 years designing a new CPU for a proprietary architecture (Prime 50 Series)
>that was originally a copy of a Honeywell machine from the early '70s.

And at least three, probably four, possibly five, different instruction
sets.

I don't mean different the way the 8086, the 80286, and the 80386 are
different; I mean different the way the VAX, the MIPS, and the 68000
instruction sets are different.

Prime's backwards compatibility is rather impressive...

-- 
Sean Eric Fagan  | "My psychiatrist says I have a messiah
sef@kithrup.COM  |  complex.  But I forgive him."
-----------------+              -- Jim Carrey
Any opinions expressed are my own, and generally unpopular with others.
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Summary: not so it matters
Date: 26 Jul 92 17:41:03 GMT
Organization: School of Computer Science, Carnegie Mellon


eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>: Since the DEC 21064 Alpha chip only supports 43-bit effective virtual
>: addresses, the cost is approximately 43-32=11 pins.
>How about the 64 pin program and 64 pin data?
>: Since the package has 431 pins, I don't think that 11 pins was some
>: sort of horrendous burden that changed everything.
>If it needs only 11 pins, why do you need 431 pins? Why not just 132+11?
>80386 uses 132 pins.

You are confusing implementation and architecture. The 386 and its
follow-ons have (so far) nearly identical ISA, but we can be sure
that the 586 and 686 will have an increased pincount. This is because
their mandate is high performance. The 21064's data bus is 128 bits
wide, and Alpha instructions are 32 bits:  clearly neither number was
driven by the choice of a 64 bit integer unit.

The original question was, what is the cost of changing the
architecture from 32 bits to 64?  The silicon answer is, today, ~~10%
more. The pin answer is, well, implementations might add another pin
or two to their physical-address bus. [In the quote above, I
incorrectly gave the number of virtual address bits, whereas physical
addresses emerge from the 21064. My apology.]

The point of undertaking this small cost _now_, instead of "someday",
is that chips have to be designed well ahead of need. As time passes,
more and more customers will find reasons to change up, and these are
precisely the customers that you don't want to lose. DEC may already
be hearing complaints from Cray about "only" allowing 34 address
lines.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 28 Jul 92 17:37:09 GMT
Organization: Purdue University Statistics Department

In article <BDS.92Jul28085651@maui.linus.mitre.org> bds@maui.linus.mitre.org (Barry D. Smith) writes:
>In article <55117@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>   If an optimization involves extensive calculation, a superfast sub-imbecile
>   can do it better than a human.

>   Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399


>This is a wonderful quote, and I think I'm going to post it over my
>desk.  I have 2 questions:

>1) Did you think of it yourself, or did you quote someone else?
>2) What exactly is a "superfast sub-imbecile?"

1.  I thought of it myself, although I have not made a thorough literature
search to see if I am the first.

2.  I see no reason to have to define superfast.  The standard three
gradations of subnormal intelligence are moron, idiot, and imbecile,
in order.  A human at the low end of imbecile is likely to have enough 
brain to maintain bodily functions through the teens.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Call for Opinion: Viking or i860
Date: Fri, 31 Jul 1992 15:08:48 GMT
Organization: The Portland Group, Portland, OR

In article <5678@nosc.NOSC.MIL> wolfgang@sunspot.nosc.mil (Lewis E. Wolfgang) writes:
>	What do you think?  Upgrade the cpu with Viking?
>Or purchase an equal number of i860 based array processors?

The sparc will certainly be substantially more versatile, as there are
no longer any i860-based workstations.  So if you buy an array
processor, you will probably have to go through some substantial effort
porting your code.

The performance difference depends on how vectorizable your code is.
If it is written in Fortran and has lots of nice vector loops you could
see pretty high mflops; on the other hand, if it is written in C and
spends tons of time chasing pointers, the i860-XR will not work as
well, since it has such a small cache and there won't be opportunity to
fill the FP pipelines.

Remember that the i860 is not superscalar, and that the only way to get
peak floating point performance is using explicit pipelined fp
operations and these really difficult dual operation instructions; the
only way to get integer + fp at the same time is in dual mode, which
results in halving instruction cache bandwidth.

If, however, you are willing to spend the time porting and tuning your
code, and if you wait for an i860-XP based processor, possibly with
external cache, then I'd expect that you would see substantially better
performance than the Viking.
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
From: adrian.cockcroft@uk.sun.com (Adrian Cockcroft - Sun UK - Cambridge SE - SPARC Specialist)
Newsgroups: comp.arch
Subject: Solaris (was: Sun 600MP Benchmark Anomaly)
Date: 24 Jul 1992 19:07:39 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: adrian.cockcroft@uk.sun.com
NNTP-Posting-Host: 129.156.129.1

In article 6464@sequent.com, dafuller@sequent.com (David Fuller) writes:
>
>In the case of Sun and their current OS, the critical discrimination between
>symmetrical and asymmetric is irrelevant since once you're out of a single
>CPU's ability to service OS requests you're out of business.  With a 2 CPU
>system that means system time is limited to 50%, which is reasonable.  With
>a 4 CPU system it's down to 25%, which may not be reasonable at high numbers
>of processes.
>
>So while the Sun offering is symmetrical it is not useful symmetry at this
>juncture.

If a system is running at more than 25% system time continuously I can
usually find plenty of scope for tuning to get it down to below 25%.
This has the desired effect in terms of getting a S600MP to work well
with 4.1.2.

>I'm sure that Solaris 2 will address this, it's just a question of
>where it degrades to a single thread and whether these places are harmful
>to system performance.

I have run a two processor S600MP with a Solaris 2 beta release with
both CPU's at over 95% system time (to show that it can be done). The
basic kernel, NFS code and the streams code at least are already multi
threaded and scale with CPU's.


The first version of Solaris 2.0 is now shipping (and is being used to
generate this posting :-) but only runs on sun4c (i.e. desktop
SPARCstation machines) since the S600MP arrived too late in the
development/test cycle. A second release at the end of this year will
support the S600MP, SuperSPARC, everything else and lots of
processors.

To oversimplify the issues and explain the essence of what Solaris 2.0 does:

There are two ways of adding MP to Unix. One is to place locks around
critical regions of code, which is the way that most small scale MP
implementations have been done in the past. The other, used in Solaris
2.0 is to place locks in data structures. This is much more scalable.

For example, if a section of the kernel messes with a table it could
have locks placed in the code so that only one CPU at a time can run
that code.  This is the way that a uniprocessor Unix kernel is written
using interrupt level masks to protect code regions. In Solaris 2 every
entry in the table would have a lock as part of its data structure and
every CPU can run the code simultaneously as long as they are modifying
different parts of the table.

One benefit is that the kernel is fully pre-emptible rather than having
preemption points and has a sub-millisecond guaranteed response time
for real time processes.

See ftp.uu.net:/systems/sun/papers/SunOS-5.0-MT for the full scoop.

Regards Adrian

---
Adrian Cockcroft -  adrian.cockcroft@uk.sun.com or adrian.cockcroft@sun.co.uk
Sun Microsystems, 306 Science Park, Milton Road, Cambridge CB4 4WG, UK
Phone +44 223 420421 - Fax +44 223 420257	Sun Mailstop: ECBG01

Newsgroups: comp.arch
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Pixie
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Wed, 29 Jul 1992 18:52:31 GMT


Does anyone know anything about a performance monitoring/profiling tool
called Pixie? I need to do some heavy duty profiling of some of the
SPECMARK routines, and gprof doesn't give enough info.

I believe Pixie comes with Ultrix, but is it public domain?

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
Xref: sparky comp.arch:8182 comp.sys.sun.misc:3263 comp.unix.solaris:99
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch,comp.sys.sun.misc,comp.unix.solaris
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 21 Jul 92 18:40:11 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>For disks with high rotation speeds (eg 5400 rpm) the arm movement time 
>is more significant than for traditional 3600 rpm disks.
>Note also that if SSTF (Shortest Seek Time First) arm scheduling is used,
>middle cylinders will on the average recieve better service, as the shorter
>arm travel will push them ahead in the queue.

	One of the many problems when trying to improve on FCFS (First Come,
First Served).

>(Note that on most disks, the angular bit density is the same throughout
>the surface, although the linear bit density is higher at the inner cylinder.)

	"Most" disks?  It seems like almost all disks today are zone-recorded.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.