dret@DGP.TORONTO.EDU (George Drettakis) (09/07/89)
I am interested in getting my hands on a document that will describe the Power Series parallel architecture. I am particularily interested in getting information on how the cache is organised both physically and from a software point of view, the cache consistency alg., how the hardware locks are implemented (the bus structure etc), how spin locks interact with the unix multi-programming environment, how the scheduler handles the "light-weight" threads and how they get assigned to processors and how the virtual address space is managed. A solid, public domain document (paper/tech report/memo/whatever) would be more than appreciated. Thanks, -- George Drettakis (416) 978 5473 Dynamic Graphics Project UUCP: ..!uunet!dgp.toronto.edu!dret Computer Systems Research Institute Bitnet: dret@dgp.utoronto University of Toronto Internet: dret@dgp.toronto.edu Toronto Ontario M5S 1A4 CANADA Ean: dret@dgp.toronto.cdn -- Live where it's never below 25 deg. C.
mitch@rock.sgi.com (Thomas P. Mitchell) (09/08/89)
In article <89Sep6.182533edt.4956@jarvis.csri.toronto.edu> dret@DGP.TORONTO.EDU (George Drettakis) writes: >I am interested in getting my hands on a document that will describe >the Power Series parallel architecture. Here are some pointers: 1) "UNIX Papers for UNIX Developers and Power Users" see: Article 14 Multiprocessor UNIX by Tom Jermoluk (Tom is here at SGI.) Edited by Mitchell Waite Howard W. Sams and Company ISBN 0-672-22578-6 2) Wagner, J.C., and Barton, J.M., "Threads in System V: Letting UNIX parallel Process", a work-in-progress paper presented in ;login:, USENIX Association, Vol. 12, No. 5, September/October 1987. 3) Beck, Bob, and Olien, Dave, "A Parallel Programming Process model", in USENIX Conference Procedings, Winter, 1987. 4) Barton, J.M., Wagner, J.C. "Beyond Threads: Resource Sharing in UNIX," USENIX Procedings, 1987. 5) Dijkstra, E.W. "Cooperating Sequential Processes," Technical Report EWD-123, Technological University, Eindhoven, The Netherlands, 1965. 6) Gerry Kane. "mips RISC Architecture" Prentice Hall, Englewood Cliffs, N.J. ISBN 0-13-584293-X Keys to understanding are: There is one run queue. Parallel regions in code are managed as seperate processes. All the rules of shared memory problems apply. It is the responsibility of the programmer (in 'c') to understand any data dependancies. The pfa (Power FORTRAN Accelerator) identifies regions at the do loop level which may safely be run in parallel for the FORTRAN compiler. Yea the programmer may know of other regions. Worse yet, he may think he does. The user may need to discover (profile) if the overhead of spawning the sub-processes and resyncronizing is greater than the work done in the loop. Unix needs a good spelling checker (from vi). Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.
mitch@rock.sgi.com (Thomas P. Mitchell) (09/19/89)
In article <473@odin.SGI.COM> mitch@rock.sgi.com (Thomas P. Mitchell) writes: >>I am interested in getting my hands on a document that will describe >>the Power Series parallel architecture. > >Here are some pointers: I forgot to mention that Jim Barton and Chris Wagner are two key engineers in the design and implementation of the SGI multi-processing solution. Their papers give much insight into their thoughts and the reasons behind SGI's choices. >1) "UNIX Papers for UNIX Developers and Power Users" see: >Article 14 Multiprocessor UNIX by Tom Jermoluk (Tom is here >at SGI.) Edited by Mitchell Waite Howard W. Sams and >Company ISBN 0-672-22578-6 >2) Wagner, J.C., and Barton, J.M., "Threads in System V: >Letting UNIX parallel Process", a work-in-progress paper >presented in ;login:, USENIX Association, Vol. 12, No. 5, >September/October 1987. >4) Barton, J.M., Wagner, J.C. "Beyond Threads: Resource >Sharing in UNIX," USENIX Procedings, 1987. >Eindhoven, The Netherlands, 1965. Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.