HDTenEightyP/NetNews huggingface dataset:
From: zink@phoenix.informatik.uni-stuttgart.de (Roland Zink)
Subject: Re: PVM: thoughts on data-passing routines
Apparently-To: hypercube@hubcap.clemson.edu
Organization: IPVR, University of Stuttgart, Germany
Date: Mon, 17 Aug 1992 08:39:06 GMT

In article <1992Aug11.121234.28784@hubcap.clemson.edu>, jek@cs.duke.edu (James E. Kittock) writes:
|> 
|> While working on this, I have come to the conclusion that the C
|> interface to PVM has a serious "want", namely, a routine to
|> automagically put a structure and all of its contents, *including* the
|> contents of any arrays/structures/unions pointed to by members of that
|> structure.

In my Stuttgart Parallel Processing Library (SPPL) this is possible.
The sending and receiving routines (sendd and recvd) have an
additional parameter which is a type description. Because the routine
for arbitrary graphs is not very efficient there exist two send
routines, one for data structures like trees and one for data
structures which contains cycles. DAG's can be send with the routine
for trees, but for each reference of an object there will be a copy of
the object. So you can send an arbitrary data structure with one
function call. The sendd function call is responsible for the
allocation of a message buffer, the copying of the scattered data into
this continous message buffer, the conversion of the data in a network
format and sending the message.

SPPL is a parallel processing library for distributed memory MIMD
computers and contains functions which can be used to send and receive
messages, start processes and synchronize etc. SPPL use a type
description of the message to collect the scattered data of the
message in a message-buffer and to convert the data to a network
format. The associated debugger use this information to display the
message in a readable format. This parallel debugger allows
interactive display and control of execution of SPPL programs. SPPL
uses currently TCP/IP to transfer messages.

--
Roland Zink Tel.:(0711)7816-382 email: Roland.Zink@informatik.uni-stuttgart.de
Univ. Stuttgart, IPVR, Breitwiesenstrasse 20, W-7000 Stuttgart 80, Germany


Newsgroups: comp.parallel
From: weigert@etlhit.etl.go.jp (Thomas Weigert)
Subject: Re: verification of real-time specs
Apparently-To: hypercube-request@hubcap.clemson.edu
Reply-To: weigert@mcs.anl.gov
Organization: Electrotechnical Laboratory, Tsukuba-shi, Japan
Date: Wed, 12 Aug 1992 06:49:17 GMT


In a recent post, I wrote

TW> EMC is a model checker for CTL formulae over Kripke structures. 
TW> Literature: Emerson, Halper, "Sometimes" and "Not Never" Revisited,
TW> JACM, 33, 1, 1986.

It was brought to my attention that above statement could be construed as
claiming that the mentioned paper was the seminal reference about the EMC
system or model checking. Of course, it is not, but it was the only
reference that mentioned model checking at the time of posting. Model
checking was first proposed by E.M. Clarke.

Probably the best reference for EMC is E.M. Clarke, E.A. Emerson, A.P.
Sistla, "Automatic Verification of Finite-State Concurrent Systems Using
Temporal Logic Specifications", ACM Trans. Programming Languages and
Systems, 8, 2, 1986, pp. 244-263. 

I apologize for any confusion my post might have caused.

Cheers, Thomas.

--
+--------------------------------+---------------------------------+
| Thomas Weigert                 |                                 |
| Machine Inference Section      |                                 |
| Electrotechnical Laboratory    |                                 |
| Umezono 1-1-4, Tukuba-shi      | weigert@{mcs.anl.gov,etl.go.jp} |
| Ibaraki 305, Japan             | +81-298-58-5918 (phone+fax)     |
+--------------------------------+---------------------------------+

Newsgroups: comp.parallel
From: hacksaw@cellar.org (Hacksaw)
Subject: Basic Question
Source-Info:  From (or Sender) name not authenticated.
Organization: The Cellar BBS and public access system
Date: Thu, 13 Aug 92 14:18:07 EDT

   I apologize if this message is off-topic or idiotic, but... I was talking 
to a friend who mentioned something about parallel computing. The idea that 
more than one processor could be hooked together in one system and achieve 
"super-speed". At work, he used a system(I forget the name) that had 
4-parallel 386/25Mhz processors. It handled "animation" on a CAD program 
called Jack with no trouble at all. I'm talking high-res images getting 
flipped back and forth in no time. If this is what 4 386 processors can 
achieve, then I'll be satisfied with what 2 286 processors can do.
 
   I'm currently running a 286/12 under MS-DOS. Obviously, I'm ready to 
upgrade. I can pick up another 286 motherboard for under $100. Or would I 
just need the 286 chip itself? Anyway... how would I go about hooking these 
things together to achieve parallelism? What kind of software would support 
it? MS-DOS seems to choke on even the itty-bittiest section of RAM above 
640K; I don't know what makes me think it could handle another processor.
 
   Basically... Is parallel computing something only for the highest end 
machines, or could it be achieved on a measly 286? Any comments would be 
greatly appreiated. 

Cheers!

Newsgroups: comp.parallel
From: ti6hk@ap04.rz.tu-harburg.de (Henry Koplien - 3358 )
Subject: CSP Real-Time
Originator: ti6hk@ap04.cip3a.tu-harburg.de
Organization: none
Date: 19 Aug 92 13:57:51 GMT



Hello everybody,
 
I am a new "member" of  the  comp.parallel group  and  glad to  find the right
articles.  I  make  a research  about  a  specification-language  for parallel 
processes  under  the  time  domain.  This language should be able to describe 
parallel  processes and their  communication between  them. My ideas  focus on 
using CSP  extended with  time-intervalls.  Is  anybody  working  on  the same 
problem or has anybody solved it? Is CSP a good platform?
I hope to receive a lot of answers. Thanks in advance...
 
Henry
 

------------------------------------------------------------------------------
mail-address   :  Dipl.-Inform. Henry Koplien
                  Technische Universitaet Hamburg-Harburg
                  Martin-Leuschel-Ring 16
                  2100 Hamburg 90
 
Telephone      :  040 / 7718-3358   
Fax            :  n.a.              
 
e-mail         :  koplien@rztsun.tu-harburg.dbp.de
------------------------------------------------------------------------------

Newsgroups: comp.parallel
From: edelman%math.Berkeley.EDU@ucbvax.Berkeley.EDU (Alan Edelman)
Subject: Large Dense Linear Algebra Update
Organization: U.C. Berkeley Math. Department.
Date: 20 Aug 1992 16:10:32 GMT

   Large Linear Algebra Record Update

Largest LU:     75,264 complex, double precision, Intel iPSC/860
Symmetric Eigs: 27,000 on an N-cube
Non-sym eigs:   Probably less than 10,000


  Any further updates, please let me know.

Alan Edelman

Newsgroups: comp.parallel
From: bi927@cleveland.Freenet.Edu (Yi Jin)
Subject: Is there a table lookup utility for CM5?
Apparently-To: comp-parallel@uunet.uu.net
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Thu, 20 Aug 92 05:08:13 GMT


It seems that CMSSL libraries for CM2 and CM5 are different. I used to
find that the table_lookup routine be very useful on CM2. However, when
I moved to CM5, its not there. Anyone have shcu a routine for CM5?

Thanks.

Newsgroups: comp.parallel
From: "Christian Heckler" <heckler@microdesk3.ee.uni-sb.de>
Subject: Wanted: Parallel algorithms for lattice basis reduction
Organization: Clemson University
Date: Wed, 12 Aug 92 13:43:26 +0200


I'm in research about parallel algorithms for 
basis reduction in lattices
("Given a basis B={b_1, ... , b_n} for a Lattice 
  L(B)={a_1*b_1 + a_2*b_2 + ... + a_n*b_n | with a_i integer for i=1...n},
  find another Basis
  B' which has shorter vectors.").

Therefore, I'm interested in papers about parallel algorithm
for basis reduction.

Can anybody give me some references?

Thank you very much
-- Christian

----------------------------------------------------------------------
Christian Heckler, Lehrstuhl fuer Mikroelektronik, Universitaet des
Saarlandes, W-6600 Saarbruecken, GERMANY
e-mail: heckler@ee.uni-sb.de
----------------------------------------------------------------------

Newsgroups: comp.parallel
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Is the overhead of spin lock acquisition always significant?
To: uunet!comp-parallel@uunet.UU.NET
Apparently-To: uunet!comp-parallel
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: 	Fri, 21 Aug 1992 00:38:55 -0400

In article <1992Aug19.063703.3904@leland.Stanford.EDU> bernardl@cs.Stanford.EDU (Bernard Lee) writes:
>In article <1992Aug18.111938.19628@hubcap.clemson.edu>, Ian Heavens <ian@spider.co.uk> writes:
>
>|> This issue becomes important because multiple-reader/single-writer
>|> locks are much more convenient to use, and reduce contention, at
>|> a cost of increasing the overhead (three times that of a mutex lock?).
>|> 
>|> Are their cache consistency or other reasons to inflate the overhead
>|> of testing and setting a memory location?  What have I missed?
>|> 
>|> Can someone suggest a rough equivalent for a spin lock acquisition in
>|> terms of (some arbitrary mix of) instructions execution, where both 
>|> instruction and data fetch are cache hits?
>
>Try running some industrial CFD applications with writable global data 
>(like the Barnes-Hut algorithm) on 100's of processors.  You will literally
>see the machine comes to a halt...
>

We had similar problems with SHARP APL running under MVS/XA on a 
TWO (!) processor 309x system, if memory servies(it doesn't, always).
We were using Compare and Swap to implement a race-free linked list
update on a queue. CS has the unfortunate "feechur" of dragging all
other processors to a stop, washing their dishes, clearing their
pipelines, blowing their noses, etc. So, the effect on any but the
most trivial systems was that all processing would hang on the 
CS instructions on all (both) processors. 

The dirty fix is to loop on a counter until the cell-to-be-swapped
looks "OK", then hit the CS once. If it works, fine. If not, go 
count to 1000 and then look at the cell again. This avoids the
synchronize which otherwise paralyzes the system.

Not a swell design for the naive...

Bob

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada

Newsgroups: comp.parallel
From: Jim Crammond <jimc@quintus.com>
Subject: Call For Papers: ICLP '93
Organization: Clemson University
Date: Mon, 17 Aug 92 17:22:53 PDT


			CALL FOR PAPERS - ICLP'93


	TENTH INTERNATIONAL CONFERENCE ON LOGIC PROGRAMMING

			    Budapest, Hungary
			    June 21 - 24, 1993


	Sponsored by the Association of Logic Programming


The 1993 International Conference on Logic Programming will be held on June
21-24, 1993, in historic Budapest. Logic Programming is one of the most
promising approaches to declarative programming. It forms the theoretical
basis of the programming language PROLOG and its extensions. Also, work in
logic programming has contributed to several other areas: Artificial
Intelligence where it has been used for nonmonotonic and commonsense
reasoning, Expert Systems implementation, Deductive Databases and a variety
of applications such as computer aided manufacturing. The technical program
for the conference will include workshops, tutorials, invited lectures and
presentations of refereed papers.

Papers are invited on any aspect of logic programming, including (but
not limited to): 

   o Theory and foundations                o Applications
   o Programming methodologies and tools   o Artificial intelligence
   o Meta and higher-order programming     o Constraints
   o Parallelism, concurrency              o Partial deduction
   o Deductive databases                   o Bottom-up evaluation
   o Implementations and architectures     o Compilation techniques


Papers must be written in English and should not exceed 5000 words,
excluding references. Papers should include a 200 word abstract and keywords
to define a topic. Submitted papers (or any portion thereof) should not have
been previously published or submitted to any journals, refereed conferences
or workshops. Each accepted paper must be presented at the conference.
Submit six (6) copies by December 1, 1992 to:

David S. Warren
Department of Computer Science
SUNY at Stony Brook
Stony Brook, NY 11794-4400
U.S.A.
Email: warren@cs.sunysb.edu
Fax: +1 516 632-8334

Notification will be made in early March 1993. The proceedings will be
published by MIT Press. 

      Conference Chair: Peter Szeredi, IQSOFT, Hungary
                        szeredi@iqsoft.hu
         Program Chair: David S. Warren, SUNY at Stony Brook, USA
                        warren@cs.sunysb.edu
       Publicity Chair: Jim Crammond, Quintus, USA
                        jimc@quintus.com
  Workshop Coordinator: Mats Carlsson, SICS, Sweden
                        matsc@sics.se
    Local Organization: John von Neumann Society for Computing Sciences
                        huug@neumann.hu

Newsgroups: comp.parallel
From: wong@qucis.queensu.ca (Tak Shing Wong)
Subject: GENESYS C (transputer) expert
Apparently-To: comp-parallel@watmath.uwaterloo.ca
Organization: Computing & Information Science, Queen's University at Kingston
Date: Tue, 18 Aug 1992 03:26:09 GMT

Hi,
	Is there any Genesys C expert out there?
	I've a serious problem with my transputer program. The program
will suddenly detach itself from the processor without any reason. And 
I already checked it is not due to any exit function (e.g. kexit). 
Can anyone point me out what cause the problem?

I'm currently using Transtech GENESYS II, release 2.2.

Thank you in advance.

-- 
===============================================================
Tak S, Wong			email: wong@qucis.queensu.ca
Queen's University		tel:   (613) 547 - 4740
Kingston, Ont,		

Newsgroups: comp.parallel,comp.sys.super,comp.unix.aix
From: sivap-m@sybil.cs.buffalo.edu (Muhunthan Sivapragasam)
Subject:  References rqd : automatic partitioning of parallel programs
Apparently-To: comp-parallel@cis.ohio-state.edu
Originator: sivap-m@sybil.cs.Buffalo.EDU
Organization: State University of New York at Buffalo/Comp Sci
Date: Wed, 12 Aug 1992 21:03:50 GMT


	i had posted a request about the same topic few weeks back.
thanks for those who replied.

	but i forgot to mention i am looking for info on automatic
partitioning at runtime. that is the decision to partition the program
further ( or to run sequentially ) is made at runtime. if you know
of any work, or papers about this topic please send me mail.

	thanks in advance,

-- 
						S. Muhunthan,

	"The shortest distance between two people is a smile"
################################################################################

Newsgroups: comp.parallel
From: beaudoin@ireq-robot.hydro.qc.ca (Martin Beaudoin)
Subject: pvm vs p4
Apparently-To: <comp-parallel@uunet.uu.net>
Organization: Le laboratoire de robotique de l'Institut de recherche
	d'Hydro-Quebec
Date: Tue, 18 Aug 1992 19:36:58 GMT

I would like to know the pros ans cons of using pvm rather than p4
over a network of Suns.

After browsing the documentation of both packages, I am under the
impression that they are both very similar.

Are there any noticable differences in the ease of programming or
speed of execution between the two??

I am planning to use one the package for my work on computer vision, so I
would like to receive any comments from anyone with some experience
with one or both packages.

Thank you!

--
Martin Beaudoin                         mbeaudoin@ireq-robot.hydro.qc.ca
Institut de recherche d'Hydro-Quebec    mbeaudoin@ireq-robot.uucp
Varennes, QC, Canada   J3X 1S1          +1 514 652-8136

Newsgroups: comp.parallel
From: waander@cs.umd.edu (Bill Andersen)
Subject: Need general info on MasPar product line
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Date: 20 Aug 92 20:55:37 GMT



   If anyone out there has info on MasPar computers, please
contact me by e-mail.

  ...Bill

 P.S. Thanks in advance!
-- 
   / Bill Andersen (waander@cs.umd.edu) /
  / University of Maryland             /
 / Department of Computer Science     /
/ College Park, Maryland  20742      /




Newsgroups: comp.parallel
From: bernardl@cs.Stanford.EDU (Bernard Lee)
Subject: Re: Is the overhead of spin lock acquisition always significant?
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 19 Aug 92 06:37:03 GMT

In article <1992Aug18.111938.19628@hubcap.clemson.edu>, Ian Heavens <ian@spider.co.uk> writes:

|> This issue becomes important because multiple-reader/single-writer
|> locks are much more convenient to use, and reduce contention, at
|> a cost of increasing the overhead (three times that of a mutex lock?).
|> 
|> Are their cache consistency or other reasons to inflate the overhead
|> of testing and setting a memory location?  What have I missed?
|> 
|> Can someone suggest a rough equivalent for a spin lock acquisition in
|> terms of (some arbitrary mix of) instructions execution, where both 
|> instruction and data fetch are cache hits?

Try running some industrial CFD applications with writable global data 
(like the Barnes-Hut algorithm) on 100's of processors.  You will literally
see the machine comes to a halt...

Our experience on the Stanford DASH machine is that, when simulating
iPSC/860 functions such as those global gadd or gXXX functions, the 
contention can get so bad that a single instruction on a vector machine
can turns into 20,000+ instructions, all because of lock-spinning.
We end up having to redesign the algorithm.

It all comes down to how "real" your application is.

Regards,
  Bernard Lee, Stanford CS Dept.

Newsgroups: comp.parallel
From: yufeng@cis.ksu.edu (Yufeng Li)
Subject: Distributed Scheduling
Summary: Want survey for distributed scheduling
Organization: Kansas State University
Date: 12 Aug 92 15:25:20 GMT

Does somebody have or know some papers
regarding distributed scheduling?  A survey is good enough.  
I may post a summary if needed. 
Thanks in advance.  

 Yufeng Li

Newsgroups: comp.parallel
From: martin@xenon.stanford.edu (Martin C. Rinard)
Subject: Re: PVM: thoughts on data-passing routines
Apparently-To: comp-parallel@uunet.uu.net
Organization: Computer Science Department, Stanford University.
Date: Tue, 11 Aug 1992 19:13:26 GMT

jek@cs.duke.edu (James E. Kittock) writes:

> While working on this, I have come to the conclusion that the C
> interface to PVM has a serious "want", namely, a routine to
> automagically put a structure and all of its contents, *including* the
> contents of any arrays/structures/unions pointed to by members of that
> structure.

  This is a standard problem in distributed systems. To recursively
pass a data structure between machines, you in general have
to pack recursively all the objects to which the first object points into a
message, then unpack the objects on the other side and reconstruct
the pointers. To pack an object given a pointer to that object, 
you need to know the type and size of the object. In general, 
it is impossible for a C program to get type and size information 
given only a pointer to an object. If you want to recursively pass
data structures between machines, you need to augment either the 
pointers or the data structures to which they point with type and 
size information. 

  Here at Stanford, we have developed a language called Jade that
supports the concept of an object which consists of several 
allocation units. The Jade frontend generates routines that 
recursively pack and unpack such objects, reconstructing the
pointers as necessary.  When the Jade implementation determines that
such an object needs to be passed from one machine to another, 
the sender calls the packing routines to put the data into a message,
then sends the message off to the receiver. The receiver then 
invokes the routines that unpack the object and reconstruct the
pointers. To support this functionality, the Jade memory allocators
augment allocated data with a type tag and a size tag. The packing
routines use these tags to determine how to pack and unpack the objects.

  So, such a scheme (in general) requires programming language support
beyond that which C provides. But, you can put the type and size tags
in by hand, and generate your own routines to pack and unpack the
data structures. 


  Martin

Newsgroups: comp.parallel
From: hong@cs.arizona.edu (Ke Hong)
Subject: Papers on Debugger
Organization: U of Arizona, CS Dept, Tucson
Date: 18 Aug 92 18:30:21 GMT


Hi ,

   Is there anyone know where can I get the paper on Debugger via ftp?

   Because sometimes it's hard to find the paper in lib?

Thank you in advance!

--George

hong@cs.arizona.edu
From: hattori@convex.com (Mato Hattori)
Newsgroups: comp.robotics
Subject: Re: Trouble with stepper motor
Keywords: stepper motor
Date: 17 Aug 92 21:19:35 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
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.

In <1992Aug17.202424.24162@colorado.edu> mathis@tigger.cs.Colorado.EDU (Don Mathis) writes:

>Sorry, I should have mentioned in my original post that the motor gets
>confused even at very slow speeds, like 2 pulses per second, so it's
>not just that I'm pulsing it too fast.  It happens anywhere from 2 to
>200 pulses per second.

Well, here is next suspect...  
How long is the wire connecting the motor with the drive circuit?
According to my experience, motor got mad when I use 2 feet long parallel 
ribbon-like wire to connect it with drive circuit.
I believe it has been caused by external electric noise, or drive voltage drop.

I hope this can be a help.
--
Mato Hattori
Convex Computer, U.S.A.       email: hattori@convex.com
3000 Waterview Parkway        office: 1+214-497-4304
Richardson, Texas 75083       home:   1+214-424-4655
Newsgroups: comp.robotics