home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / doc / techrepo / 132 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  13.1 KB

  1. Path: sparky!uunet!sun-barr!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!UXA.ECN.BGU.EDU!mflll
  2. From: mflll@UXA.ECN.BGU.EDU ("Dr. Laurence Leff")
  3. Newsgroups: comp.doc.techreports
  4. Subject: TRList File tech.wisjul92
  5. Message-ID: <199207271731.AA08772@uxa.ecn.bgu.edu>
  6. Date: 27 Jul 92 17:31:30 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 259
  11. Approved: trlist@smu.edu
  12.  
  13.  
  14.           Technical Report List File tech.wisjul92 
  15.  
  16.  
  17. Bibliography of Technical Reports
  18. Computer Sciences Department
  19. University of Wisconsin
  20. April 1992 - July 1992
  21.  
  22.  
  23.  
  24. University of Wisconsin Technical Reports can be obtained via anonymous
  25. ftp from ftp.cs.wisc.edu.  If you have problems or questions about
  26. ftp'ing these reports, please email "ftp@cs.wisc.edu".
  27.  
  28. For printed copies, send requests to:
  29.  
  30. Technical Report Librarian
  31. Computer Sciences Department
  32. University of Wisconsin
  33. 1210 W. Dayton Street
  34. Madison, WI 53706  USA
  35.  
  36. or email:  tech-reports@cs.wisc.edu
  37.  
  38.  
  39. ==========================================================================
  40.  
  41.  
  42. %A Sriram Vajapeyam
  43. %T Instruction Level Characterization of the Cray MP Processor
  44. %D May 1992
  45. %R TR 1086
  46. %I COMPUTER SCIENCES DEPARTMENT, UNIVERSITY OF WISCONSIN
  47. %C MADISON, WI
  48. %X Evolutionary computer architecture fundamentally relies on information
  49. obtained from empirical characterizations of the nature of programs and of 
  50. dynamic program usage of machine features.  While vector architectures have 
  51. dominated the supercomputer arena for over two decades and promise to continue 
  52. to provide superior single processor performance on a large class of scientific and engineering applications, detailed empirical characterizations of these 
  53. architectures and their workload has not been reported to date in the 
  54. literature.  This dissertation fills this void in the empirical understanding 
  55. of  machines by reporting an instruction-level study of a single processor 
  56. of the CRAY Y-MP, using as benchmarks the scientific and engineering 
  57. application programs that comprise the PERFECT Club benchmark suite.
  58.  
  59. The capability of the compiler is key to harnessing the power of a 
  60. machine today. Hence we study a version of the benchmarks that is 
  61. automatically optimized and vectorized by the Cray Research, Inc. production 
  62. FORTRAN compiler. Furthermore, several optimizations that are easily 
  63. implementable manually provide significant performance improvements over 
  64. the best efforts of the compiler today.  Therefore we also study a version 
  65. of the benchmarks, hand-optimized by a team of Cray Research, Inc. programmers, that won the 1990 Gordon Bell PERFECT award for the fastest version of 
  66. the PERFECT Club benchmarks on any machine.  In both cases, we study only 
  67. the user routines of the benchmarks.
  68.  
  69. We observe that the vectorization level of the user routines of the 
  70. programs varies widely for the compiler-optimized version of the programs, 
  71. as opposed to being uniformly high.  While hand optimizations do improve 
  72. the vectorization level, several benchmarks still have vectorization 
  73. levels below 80%.  Consequently, the performance of the non-vector 
  74. features of vector machines are important to program performance.
  75. We observe that the scalar code in the programs contain several address
  76. calculation operations and Cray-specific miscellaneous operations, in 
  77. addition to the floating-point operations.  Hence adequate attention needs 
  78. to be paid to these instruction types.  Towards exploiting the data 
  79. dependencies in the scalar code for faster execution, we characterize 
  80. the dependencies within the scalar basic blocks of the programs.
  81. We observe that the utilization of the pipeline parallelism of 
  82. the functional units by scalar code is low.  Thus, any latency 
  83. improvements that result from lower levels of functional unit 
  84. pipelining will enhance scalar performance.  For the overall programs,
  85. we observe that large basic blocks are significant in number and are 
  86. important to program performance.  Thus compiler optimization techniques 
  87. geared towards large basic blocks are desirable.  The level of vectorization
  88.  of memory operations is usually very high, thus emphasizing the need 
  89. for memory bandwidth.  We observe that for the CRAY Y-MP hardware and 
  90. for the techniques currently employed by the Cray Research compiler, the 
  91. peak instruction issue rate of the CRAY Y-MP is quite adequate, especially 
  92. because of the presence of vector instructions.  In addition to all the 
  93. issues mentioned above, several related issues are discussed and explored 
  94. in the dissertation.
  95.  
  96.  
  97. %A G. Ramalingam
  98. %A Thomas Reps
  99. %T An Incremental Algorithm for a Generalization of the Shortest-Path
  100. Problem
  101. %D May 1992
  102. %R 1087
  103. %I COMPUTER SCIENCES DEPARTMENT, UNIVERSITY OF WISCONSIN
  104. %C MADISON, WI
  105. %X The grammar problem, a generalization of  the  single-source
  106. shortest-path problem introduced by Knuth, is to compute the
  107. minimum-cost derivation of a terminal  string  from  one  or
  108. more non-terminals of a given context-free grammar, with the
  109. cost of a derivation being suitably defined.  In this  paper
  110. we  present  an  incremental  algorithm for a version of the
  111. grammar problem.  As a special case  of  this  algorithm  we
  112. obtain  an  efficient  incremental algorithm for the single-
  113. source shortest-path problem  with  positive  edge  lengths.
  114. The  aspect  of our incremental algorithm that distinguishes
  115. it from all other work on the dynamic shortest-path  problem
  116. is  its  ability to handle "multiple heterogeneous modifica-
  117. tions": between updates, the input graph is  allowed  to  be
  118. restructured  by  an  arbitrary  mixture of edge insertions,
  119. edge deletions, and edge-length changes.
  120.  
  121.  
  122. %A Men-Chow Chiang
  123. %T Memory System Design for Bus Based Multiprocessors
  124. %D May 1992
  125. %R 1088
  126. %I COMPUTER SCIENCES DEPARTMENT, UNIVERSITY OF WISCONSIN
  127. %C MADISON, WI
  128. %X This dissertation studies the design of single bus, shared memory
  129. multiprocessors.
  130. The purpose of the studies is to find optimum points in the design
  131. space for different memory system components that include private
  132. caches, shared bus and main memory.
  133.  
  134. Two different methodologies are used based on the operating environment of 
  135. a multiprocessor.  For a multiprocessor operating in the Ithroughput-oriented 
  136. environment, Customized Mean Value Analysis (CMVA) models are developed to 
  137. evaluate the performance of the multiprocessor.  The accuracy of the models 
  138. are validated by comparing their results to those generated by actual 
  139. trace-driven simulation over several thousand multiprocessor configurations.
  140. The comparison results show that the CMVA models can be as accurate as
  141. trace driven simulation in predicting the multiprocessor throughput and 
  142. bus utilization.  The validated models are then used to evaluate design 
  143. choices that include cache size, cache block size, cache set-associativity, 
  144. bus switching method, bus width, and main memory latency.
  145.  
  146. For a multiprocessor operating in the speedup-oriented
  147. environment a multiprocessor simulator is built to conduct
  148. an execution driven simulation for several parallel benchmarks.
  149. Performance statistics are collected separately for different
  150. computational phases during the execution of a parallel program,
  151. and are analyzed to characterize the behavior of the multiprocessor 
  152. in each computational phase and the overhead of parallel processing.
  153. The results show that, with loop level parallelization, performance 
  154. bottlenecks can occur in the scheduling phase (if dynamic scheduling 
  155. is used to schedule loop iterations to processors) as well as the 
  156. independent computing phase.  The cache miss ratio of shared data in 
  157. the independent computing phase is also found to increase with the 
  158. number of processors, meaning that even for this phase the speedup 
  159. will decrease instead of leveling off after the speedup has reached 
  160. its maximum.
  161.  
  162. The barrier operation in a bus based multiprocessor is found not to 
  163. be a serious concern.  With an efficient atomic decrement instruction 
  164. available, the total time for all processors to decrement the barrier 
  165. counter can be very a small portion of overall execution.  Both the 
  166. barrier and serial times can become less significant, i.e., become a smaller
  167. portion of total execution time of a parallel program, when the problem
  168. size is increased.
  169.  
  170. The impact of the synchronization method on the execution time of the
  171. scheduling phase is also considered in some detail.  The performance 
  172. of several alternatives to the base test&test&set implementation, such 
  173. as a software queue, a lock table (proposed in this thesis),
  174. and a restricted fetch&add operation with combining, are evaluated.
  175. The simulation result shows that both the lock table and restricted 
  176. combining methods can improve the scheduling rate significantly.
  177.  
  178.  
  179.  
  180. %A Michael J. Franklin
  181. %A Michael J. Carey
  182. %T Client-Server Caching Revisited
  183. %D May 1992
  184. %R TR 1089
  185. %I COMPUTER SCIENCES DEPARTMENT, UNIVERSITY OF WISCONSIN
  186. %C MADISON, WI
  187. %X Most commercial and experimental Object-Oriented Database Systems (OODBMS)
  188. are implemented using a client-server software architecture.  An effective
  189. technique for improving the performance of a client-server database system
  190. is to allow client workstations to cache data and/or locks across transaction
  191. boundaries.  This paper extends an earlier study on the performance of caching
  192. in client-server database systems [Care91a] in three ways.  The first is a
  193. re-examination of heuristics for algorithms that decide dynamically between
  194. propagating changes or invalidating remote copies of data pages in order to
  195. maintain cache consistency.  The second extension is a performance study of
  196. a class of caching algorithms known as "callback locking" algorithms.  These
  197. algorithms are of interest because they provide an alternative to the
  198. optimistic techniques used in the earlier study and because they have recently
  199. begun to find use in commercial systems.  The third way that this paper extends
  200. the previous study is to examine the performance of alternative caching
  201. algorithms in light of current trends in processor and network speeds and to
  202. more closely examine their robustness in the presence of data contention.
  203.  
  204.  
  205.  
  206. %A Manolis M. Tsangaris
  207. %A Jeffrey F. Naughton
  208. %T On the Performance of Object Clustering Techniques
  209. %D June 1992
  210. %R TR 1090
  211. %I COMPUTER SCIENCES DEPARTMENT, UNIVERSITY OF WISCONSIN
  212. %C MADISON, WI
  213. %X In this paper we investigate the performance of some of the best-known
  214. object clustering algorithms on four different workloads based upon
  215. the Tektronix benchmark.  For all four workloads, stochastic
  216. clustering gave the best performance for a variety of performance
  217. metrics.  Since stochastic clustering is computationally expensive, it
  218. is interesting that for every workload there was at least one cheaper
  219. clustering algorithm that matched or almost matched stochastic
  220. clustering.  Unfortunately, for each workload, the algorithm that
  221. approximated stochastic clustering was different.  Our experiments
  222. also demonstrated that even when the workload and object graph are fixed,
  223. the choice of the clustering algorithm depends upon the goals of the
  224. system.  For example, if the goal is to perform well on traversals of
  225. small portions of the database starting with a cold cache, the
  226. important metric is the per-traversal expansion factor, and a well-chosen
  227. placement tree will be nearly optimal; if the goal is to achieve a
  228. high steady-state performance with a reasonably large cache, the
  229. appropriate metric is the number of pages to which the clustering
  230. algorithm maps the active portion of the database.  For
  231. this metric, the PRP clustering algorithm, which only uses access
  232. probabilities achieves nearly optimal performance.
  233.  
  234.  
  235. %A Thomas Ball
  236. %A Susan Horwitz
  237. %T Constructing Control Flow From Control Dependence
  238. %D June 1992
  239. %R TR 1091
  240. %X Control dependences characterize how the predicates in a program govern 
  241. the execution of other statements and predicates.  Control dependences are 
  242. defined in terms of a program's control-flow graph; given a control-flow 
  243. graph G, a corresponding control dependence graph, CDG(G), can be constructed.
  244. This paper addresses the inverse problem: we define an algorithm that,
  245. given a control dependence graph C, finds a corresponding control-flow 
  246. graph G (i.e., a graph G such that CDG(G) is isomorphic to C),
  247. or determines that no such control-flow graph exists.
  248. We call this process CDG-reconstitution.
  249.  
  250. CDG-reconstitution is a necessary part of systems that use
  251. and transform program dependence graphs (graphs that combine
  252. data dependences and control dependences) as the basis for
  253. discovering and performing code transformations.  For example, 
  254. parallelizing or vectorizing compilers as well as program 
  255. integration tools may construct the program dependence graph(s) 
  256. of a program (or set of programs) and then manipulate them in 
  257.  various ways to form a new graph.  Reconstitution is needed as 
  258. a final step to find a corresponding program for this graph.
  259. Such a process must respect the data and control dependences of the
  260. graph - we concentrate on the reconstitution problems caused
  261. by control dependences.
  262.  
  263. Our research provides two important advances over existing
  264. CDG-reconstitution algorithms.  First, while previous algorithms 
  265. handle only acyclic CDGs, our CDG-reconstitution algorithm correctly
  266. handles both acyclic and cyclic control dependence graphs.
  267. Second, our algorithm provides an improvement in efficiency
  268. over existing algorithms.
  269.  
  270.  
  271.  
  272.