HDTenEightyP/NetNews huggingface dataset:
From: kearns@softrue.UUCP (Steven Kearns)
Newsgroups: comp.specification
Subject: Re: Theoretical limitations of algebraic specifications?
Date: Wed, 30 Dec 92 22:41:57 PDT
Organization: Software Truth

> I have been struggling with an algebraic spec for a couple of days and
> ...
> More specifically, I am trying to specify a tree that has the notion of
> a "current node", and operations to change the current node.  The ....
> Jeff Offutt
> Department of ISSE, George Mason University, Fairfax VA
> email: ofut@gmuvax2.gmu.edu
> phone: (703) 993-1654 (messages: 993-1640)

It has been shown that Majester's stack (sp?), which is a stack with 
a pointer to an arbitrary element (if memory serves), requires an infinite
set of algebraic axioms to specify.  

The practical point is that algebraic specs are very poor at
describing objects with state.  If you want to describe such an
object, use a model based spec language (such as Z).

-steve

********************************************************
* Steven Kearns            ....uunet!softrue!kearns    *
* Software Truth           softrue!kearns@uunet.uu.net *
********************************************************

Newsgroups: comp.parallel
From: edward@minster.york.ac.uk
Subject: SIMPLE benchmarks
Organization: Department of Computer Science, University of York, England
Date: Sat, 19 Dec 92 18:30:38

[This is certainly a FAQ. If someone would collect the answers (or if you
 have the last thread) and send it to me at fpst@hubcap.clemson.edu, I'll
 put the results in a FAQ file on parlib. Steve
]

Hi Folks!

	Can anyone tell me where can I get the SIMPLE benchmark
from?  Many thanks to any help offered.

- edward
---------------------------------------------
Edward Walker
Dept. of Computer Science
University of York
York, YO1 5DD
U.K.

Internet: edward@minster.york.ac.uk
From: lycmit@x1sun6.ccl.itri.org.tw (Yin-Chih Lin)
Newsgroups: comp.parallel
Subject: Curiosity about Grand Challenges
Date: 24 Dec 92 15:07:14 GMT
Organization: Clemson University

Greetings:

In the IEEE Spectrum September '92 issue, Richard Comerford illustrated
the Grand Challenges on page 35. I try to re-depict that figure as the
following table:

	Year	Field				Required Computing
						Performance (Billion-FLOPS)
	===========================================================
	1980	2-D plasma modeling		   0.1
		Airfoil design			   0.6
		48-hour weather			   1
		chemical dynamics		   1
	1990	3-D plasma modeling		   0.6
		estimates of Higgs boson mass	   1
		72-hour weather			   6
		ultralarge scale IC design	  10
		vehicle signature		  20
	2000	speech and natural language	   8
		pharmaceutical design		  10
		structural biology		  20
		climate modeling		1000
		fluid turbulence		1000
		pullution dispersion		1000
		human genome			1000
		ocean circulation		1000
		quantum chromodynamics		1000
		semiconductor modeling		1000
		superconductor modeling		1000
		combustion systems		1000
		vision and cognition		1000

My interesting is whether there are any favored computation models
(SIMD/MIMD/Multicomputer/Vector/Systolic etc.), interconnections
(linear-array/tree/mesh/torus/systolic/cube/hypercube etc.)
and algorithms (search/sort/merge/matrix/tree/graph/FFT etc.)
could be applied to the Grand Challenges.

It is much appreciated if any one of you could drop me a note or
show me the way to light up this question. It's also welcomed if
you know any specific filed(s) in the Grand Challenges.
 
Please send me directly, cause it is not easy for me to monitor 
this group regularly.

Thanks,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
Design Eng.                    Computer & Communication Research Labs.  (CCL)
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331         r system    14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.
From: lycmit@x1sun6.ccl.itri.org.tw (Yin-Chih Lin)
Newsgroups: comp.parallel
Subject: Asking stuff for HiPPI
Date: 28 Dec 92 21:39:40 GMT
Organization: Clemson University

Greetings:

I'm looking for the info about the HiPPI (High Performance Peripheral
Interface). Any references, papers or journals are highly appreciated.
There is one article concerned about HiPPI can be found in the
"Computer Design," June '92 issue, however without much detailed
description about the architecural layers and protocols.

Please forward your point to me directly.

Thanks,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
Design Eng.                    Computer & Communication Research Labs.  (CCL)
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.
From: herlihy@crl.dec.com (Maurice Herlihy)
Newsgroups: comp.parallel
Subject: New Tech Report: Transactional Memory
Date: 26 Dec 92 22:24:09 GMT
Organization: DEC Cambridge Research Lab

A new CRL technical report is available:

                 	CRL Technical Report 92/7
                TRANSACTIONAL MEMORY: ARCHITECTURAL SUPPORT 
                       FOR LOCK-FREE DATA STRUCTURES
                          Maurice Herlihy
                          J. Eliot B. Moss
                          December 1, 1992
                                       
A shared data structure is lock-free if its operations do not require
mutual exclusion.  If one process is interrupted in the middle of an
operation, other processes will not be prevented from operating on that
object.  In highly concurrent systems, lock-free data structures avoid common
problems associated with conventional locking techniques, including priority
inversion, convoying, and difficulty of avoiding deadlock.  This paper
introduces transactional memory, a new multiprocessor architecture that
supports lock-free implementations of complex data structures in a simple and
efficient way.  Transactional memory allows programmers to define customized
read-modify-write operations that apply to multiple, independently-chosen
words of memory.  It is implemented by straightforward extensions to any
ownership-based multiprocessor cache-coherence protocol.  Simulation results
show that transactional memory outperforms the best known locking techniques
for simple benchmarks, even in the absence of priority inversion, convoying,
and deadlock.

To retrieve the abstract for any report or note, send a message saying
(for example) "send abstract 92/9" or "send abstract 92/9 92/10", using
the number of the desired technical report to
        techreports@crl.dec.com (Internet)
        crl::techreports (DECnet)
Capitalization does not matter. 

To retrieve the PostScript for any report or note, send a message saying
(for example) "send postscript 90/3" or "send postscript 90/3 90/2", using
the number of the desired technical report to
        techreports@crl.dec.com (Internet)
        crl::techreports (DECnet)
Capitalization does not matter. 

Abstracts and PostScript versions of the CRL technical reports are
also available via anonymous FTP to crl.dec.com, in the directory
/pub/DEC/CRL/{abstracts,tech-reports}.

To be added to the mailing list for announcements of CRL technical reports,
send mail to
        techreports-interest-request@crl.dec.com (Internet)
        crl::techreports-interest-request (DECnet)


Michelle Gillespie                                        Cambridge Research Lab
michelle@crl.dec.com                                      Digital Equipment Corp.
Newsgroups: comp.parallel,comp.object
From: korfhage@weston.poly.edu (Willard Korfhage)
Subject: Load balancing in object-oriented systems
Organization: Polytechnic University, New York
Date: Fri, 18 Dec 92 19:17:20 GMT

[This is certainly a FAQ. If someone would collect the answers (or if you
 have the last thread) and send it to me at fpst@hubcap.clemson.edu, I'll
 put the results in a FAQ file on parlib. Steve
]


My references on load balancing in object-oriented distributed systems
are pretty sparse. Can anyone out there help me out with some references?

Also, I haven't been able to find any paper on measurements of object
characteristics, such as models of their communication patterns.
Has this appeared anyplace?

Thanks for any pointers. E-mailed replys are best, lest our news
program delete replys while I am away. I will summarize for the net.

   Willard
   
   korfhage@weston.poly.edu

Newsgroups: comp.parallel
From: wmitchel@fergie.dnet.ge.com (Bill Mitchell)
Subject: Re: REFERENCE NEEDED, URGENT
Reply-To: wmitchell@atl.dnet.ge.com
Organization: GE Advanced Technology Labs
Date: 21 Dec 1992 20:48:12 GMT

In article <1992Dec21.132847.24650@hubcap.clemson.edu>, chaumett@labri.greco-prog.fr (Serge CHAUMETTE) writes:

|>  TOCS 1987
|> 
|>  I cant remember what TOCS means !!!

ACM Transactions on Computer Systems

-- 
 -- Bill

William F. Mitchell           |  wmitchell@atl.ge.com
GE Advanced Technology Labs   |  na.mitchell@na-net.ornl.gov

Just the facts -- no opinion disclaimer necessary.

Newsgroups: comp.parallel
From: rmdubash@cs.uh.edu (Rumi Dubash)
Newsgroups: comp.parallel
Subject: Fortress Problem
Date: 21 Dec 92 20:25:54 GMT
Article-I.D.: hubcap.1992Dec21.205106.23716
Organization: Computer Science dept.,  Univ. of Houston (Main Campus)

Hi All,
  I was wondering if there are any results that extend the Fortress Guards
Problem such that it accounts for the guards being visible to other guards.
To make it clear, there are results O'Rourke, Wood and Aggarwal that
state that ceil(n/2) guards are necessary and sufficient for any polygon
for exterior visibility if the guards are also the vertices and ceil(n/3)
if the guards are allowed to be in the plane. I have not come across any
result that would provide bounds for the number of guards when besides the 
exterior visibility, if there is an additional condn. that a guard be 
visible by atleast two other guards (it is as though the guards could join
forces with the prisoners and hence need someone to watch them too!).
  Any pointers will be greatly appreciated.
  Thanx
Rumi Dubash
rmdubash@cs.uh.edu
rdubash@geoquest.com
Newsgroups: comp.parallel
From: tk@dcs.ed.ac.uk (Tommy Kelly)
Subject: Re: Torus vs. Hypercube
Reply-To: tk@dcs.ed.ac.uk (Tommy Kelly)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Date: Mon, 28 Dec 1992 21:02:45 GMT

In article <1992Dec27.201910.28352@ee.eng.ohio-state.edu> bai@rainier.eng.ohio-state.edu (Baback A. Izadi) writes:
>Couple of weeks ago, I think heard a speaker claiming that
>2-dimensional Torus and hypercube have basically the same
>topology. How could this be true? If it is, can someone
>point me to some references?

A 2-D torus and a binary hypercube are both k-ary n-cubes.
In the torus, n=2, in the binary hypercube, k=2.

Nonetheless, that difference in radix/dimension has such
implications that saying they are basically the same doesn't
really help a lot :-).

Check out the performance analysis by Bill Dally in IEEE TC
June 91 (I think).  "Performance Analysis of k-ary n-cubes)
(I have a subsequent, more general, analysis if you are interested).

tommy

Newsgroups: comp.parallel
From: kale@cs.uiuc.edu
Subject: Release of CHARM 3.2 parallel programming system
Apparently-To: comp-parallel@uunet.uu.net
Keywords: portable programming
Organization: Dept. of Computer Sci - University of Illinois
Date: Fri, 18 Dec 1992 22:38:38 GMT



We are happy to announce the next major release of the Charm parallel
programming system, version 3.2. The main features of Charm include:

 Efficient portability across shared and non-shared memory machines 
 Latency Tolerance via message driven execution
 Support for dynamic as well as static load balancing
 Support for specific modes information sharing
 Reuse of parallel software facilitated by a sophisticated module system

Programs are written in C with a few extensions (interface with routines
in other languages such as FORTRAN is possible).

The system currently runs on: iPSC/860 (also iPSC/2), NCUBE,
sequent symmetry, Encore Multimax, Networks of (Unix) workstations,
and uni-processors. Ports to other systems, including the CM-5, and
ALLIANT FX/2800, are planned for the near future.

The system comes with a programming manual, a tutorial introduction,
and example programs.
The software includes a translator, runtime system for each type of
machine supported, "summaryTool" a simple graphical tool to view the
performance of a program, "Projections"- a trace driven
performance feedback system, and "dagger": a notation for specifying
dependences between messages and pieces of computations that we find
quite useful while writing programs in the message-driven style.

In addition it contains libraries for different dynamic load balancing
strategies, message prioritization strategies, memory management
strategies, different forms of reductions, etc.
We expect the set of libraries to grow as applications that exploit
the modularity of the system are developed.

The system is available by anonymous ftp from a.cs.uiuc.edu, in the
directory pub/charm.  We request that if you ftp and/or install the
system, please send us (kale@cs.uiuc.edu) email informing us of that,
if possible.
Although it is available free of charge, it is not a "public-domain"
software. Please read the notice that comes with the distribution.

The system is based on work carried out over the past 6 years.
Its earlier version were called the "Chare Kernel" system.

Any comments and questions should be addressed to me at kale@cs.uiuc.edu.


	L.V. Kale (kale@cs.uiuc.edu)
	Department of Computer Science
	University of Illinois at Urbana Champaign
	1304 W. Springfield Ave., Urbana, IL-61801



Newsgroups: comp.parallel
From: nikhil@crl.dec.com (R.S. Nikhil)
Newsgroups: comp.parallel
Subject: Re: Torus vs. Hypercube
Date: 29 Dec 92 15:02:11 GMT
Organization: DEC Cambridge Research Lab

In article <1992Dec29.142815.27527@hubcap.clemson.edu>, karr@cs.cornell.EDU (David Karr) writes:
> 
> First of all, I was under the impression that the usual interpretation
> of a "torus" network was *always* 2-D.

The Tera system currently under construction by the Tera Computer Company in Seattle, WA,
uses a 3D torus; see

    "The Tera Computer System"
    Alverson, R., Callahan, D., Cummings, D., Koblenz, B., Porterfield, A. and Smith, B.
    in Proc. Intl. Conf. on Supercomputing, Amsterdam, June 1990

Rishiyur Nikhil (nikhil@crl.dec.com)
Newsgroups: comp.parallel
From: heller@Think.COM (Steve Heller)
Subject: Re: Torus vs. Hypercube
Organization: Thinking Machines Corporation, Cambridge MA, USA
	<1992Dec29.142815.27527@hubcap.clemson.edu>
Date: 29 Dec 92 12:20:20


In article <1992Dec29.142815.27527@hubcap.clemson.edu> David Karr <karr@cs.cornell.EDU> writes:

   In article <1992Dec27.201910.28352@ee.eng.ohio-state.edu> bai@rainier.eng.ohio-state.edu (Baback A. Izadi) writes:

   >Couple of weeks ago, I think heard a speaker claiming that
   >2-dimensional Torus and hypercube have basically the same
   >topology. How could this be true?

   First of all, I was under the impression that the usual interpretation
   of a "torus" network was *always* 2-D.  Perhaps the speaker meant "2-D
   hypercube," i.e. the 4-node hypercube, which would in fact match the
   4-node 2x2 torus.

To me, if unmodified, "grid" implies 2D, but I have no problem with either
3D grid or 3D torus, or higher dimensions of both.

Tommy Kelly mentioned that, both hypercubes and torii are k-ary n-cubes.  I
usually think of hypercubes and grids in this fashion, but it's a small
difference.

   Also, it turns out the 16-node (4-D) hypercube and the 16-node 4x4 torus
   have the same topology.  But that's the largest number of nodes for
   which this can occur, because in higher dimensions the hypercube nodes
   have degree 5 or greater, but the torus nodes have degree 4.

The fact that the 4^2 torus is isomorphic to the binary 4-cube led to an
interesting question here at TMC about six months ago.

Is the 4^k torus isomorphic to the binary 2k-cube?

The answer and the proof (which I found quite fun) is left as an excercise
to the reader.

-steve

Newsgroups: comp.parallel
From: kh <kh@dcs.gla.ac.uk>
Subject: Re: (comp.lang.functional) tree of frames
Apparently-To: hypercube@hubcap.clemson.edu
Keywords: tree of frames ...
Organization: Computing Sci, Glasgow Univ, Scotland
Date: Wed, 30 Dec 92 21:42:18 GMT

In article <1992Dec28.182105.9329@crl.dec.com> nikhil@crl.dec.com (R.S. Nikhil) writes:

As Nikhil's aware, in our parallel functional implementation we use a
segmented stack similar to the cactus stack model.

>- In the cactus stack model, the following actions can be expensive:
>  a) allocating a new stack (e.g., large object, load balancing issues)

For our segmented scheme, the actual allocation cost is usually no
greater than for a single small object (unless garbage collection is
invoked).  I suspect that's true for most allocators currently used in
functional/dataflow languages.  If dead stack segments can be reused,
then the cost can be reduced further.

>  b) handling the exception when (if) a stack overflows and needs to be enlarged

This can certainly be significant if it occurs, but our measurements
suggest that stack overflow is quite infrequent for the applications
we run, even with fairly small [4K] stack segments (this can depend
crucially on granularity, of course: large grained tasks are likely to
require larger stacks).  Against this, you need to count the cost of
extra GCs for allocated, but not yet used, slots in stack frames.

>  c) migrating an entire stack (for load balancing)
>  Some of these can be easier to manage at the granularity of
>  individual frames.

I've been pondering this for a while, but without coming to a definite
conclusion.  Surely, if you migrate a task then you will eventually
migrate most of the stack anyway (as each basic block returns to its
caller, so the parent frame must be migrated, unless the child task is
returned to the parent processor).  The difference is then a tradeoff
between latency and communication time (with "cactus stacks" a few
long packets transmit the entire stack, whereas many short packets may
be necessary for the distributed frame model).  Of course, if
migration is frequent, then the frame model is probably better, but
otherwise the reduction in communication cost is likely to favour the
stack model, isn't it (assuming that communication cost is cheaper
per-byte if larger packets are used)?

> So, it can only be answered by experience and, on
>that dimension, I think it is still too early to tell.

Is there any work which compares the two approaches within the same
compilation environment (for functional/dataflow languages)?  The
results could be interesting...

Regards,
Kevin
-- 
Dept. of Computing Science, Glasgow University.    E-mail: kh@dcs.glasgow.ac.uk

This Signature Intentionally segmentation fault

Newsgroups: comp.parallel
From: pestep@convex.com (Pat Estep)
Subject: Re: PVM's rcvinfo() function.
Apparently-To: hypercube@hubcap.clemson.edu
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Mon, 21 Dec 1992 20:12:28 GMT

In article <1992Dec21.132806.24272@hubcap.clemson.edu> <ruucp@samsung.com> writes:
>Hi;
>
>In the master program i a doing a >>>>putbytes(image, 262144);
>Then snd() to slave. In the slave when i do rcvinfo() it
>returns message size as 262152. (Possibly 2 ints).
>
>Can anyone explain this? I understand there will be padding/stripping
>at lower levels, but does it reflect at the user level? Do i have
>to strip off some headers etc?
>
>Thanx in advance.
>
>/ajay
>email: kalhan@usl.edu
>
  internally, the putbytes call first puts an integer which indicates
  the number of bytes, then the actual number of bytes specified.
  the integer value is not available to the user.

  the kicker is that then it sets the buffer position to a word (4 byte)
  boundary.  this makes it impossible for your application to determine
  exactly how many bytes were put.  you just have to know.

  for example, if you did the following:
    putbytes(buffer, 1)
  then rcvinfo would return a length of 8.

  similarly, if you did a
    putbytes(buffer, 4)
  then rcvinfo would again return a length of 8.

  the moral to the story is that in pvm, you can't query to see what's
  in the incoming buffer or how much is in the buffer.  the receiving
  program has to know.
-- 
Pat Estep                               System Integration and Support
Convex Computer Corporation
3000 Waterview Parkway                  Email: pestep@convex.com
Richardson, TX 75080                    Voice: (214) 497-4814

Newsgroups: comp.parallel
From: adamb+@cs.cmu.edu (Adam Beguelin)
Subject: Re: PVM's rcvinfo() function.
Organization: School of Computer Science, Carnegie Mellon
Date: Mon, 21 Dec 1992 21:55:04 GMT

rcvinfo() reports the actual number of bytes recv'd, including
the header info.  

	Regards,
	Adam


-- 
Adam Beguelin				Carnegie Mellon University 
adamb@cs.cmu.edu			School of Computer Science
Faculty, RCS				Pittsbugh Supercomputer Center
(412)268-5295				Pittsburgh, PA 15213-3890

Newsgroups: comp.parallel
From: lycmit@x1sun6.ccl.itri.org.tw (Yin-Chih Lin)
Subject: Asking any paper/textbook concerning instruction-set parallelism
Organization: Clemson University
Date: Tue, 29 Dec 92 15:39:55 CST

Greetings:

I'm looking for any papers, documents or textbooks which are concerning
about the insturction-set layer parallelism. As far as I know, there
are many parallelisms can be pursued in the computing systems:
 
        . algorithm layer
        . environment layer
        . language and compiler layer
        . OS and library layer
        . instruction-set layer
        . hardware layer
 
It's my impression that most of current parallel system implementations
are mainly focused on hardware layer. I wonder whether instruction-set
layer parallelism is worth to explore. Current CISC/RISC processors  
seem don't consider implementing any instructions which support the
concurrent execution (except floating-point operations). Although
some processors (such as Inmos's Transputer series) also include 
the inter-processor communication instructions, I doubt this is the
only way to obtain the instrcution level parallelism. 
 
The vector processors are good enough for array operations but are
criticized for most of the general-purpose programs are hard (if not
impossible) to transform into vector forms. So you can find that 
additional vector processors are attached in TMC's CM-5 nodes. 
 
MIT's dataflow machines seems be the only one computation model that can 
support instruction level parallelism. Other High-Level-Language (HLL) 
machines might be the another candidate, I'm not sure. 
 
Superpipeline and superscalar, however, are not my interesting. 
 
Please forward your direction to me. 
 
Thanks, 
 
Yin-Chih Lin    lycmit@x1sun6.ccl.itri.org.tw 
 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI) 
Design Eng.                    Computer & Communication Research Labs.  (CCL) 
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.

Newsgroups: comp.parallel
From: sridhar@cs.cornell.edu (Sridhar Sundaram)
Subject: Re: Load balancing in object-oriented systems
Organization: Clemson University
Date: Tue, 22 Dec 92 09:41:54 -0500

Article: 5347 of comp.parallel
Newsgroups: comp.parallel