From owner-pbwg-method@CS.UTK.EDU Wed Mar 24 07:15:16 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA10727; Wed, 24 Mar 93 07:15:16 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA11943; Wed, 24 Mar 93 07:15:06 -0500 X-Resent-To: pbwg-method@CS.UTK.EDU ; Wed, 24 Mar 1993 07:15:01 EST Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from sun2.nsfnet-relay.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA11895; Wed, 24 Mar 93 07:14:59 -0500 Via: uk.ac.southampton.ecs; Wed, 24 Mar 1993 12:14:16 +0000 From: R.Hockney@parallel-applications-centre.southampton.ac.uk Via: calvados.pac.soton.ac.uk (plonk); Wed, 24 Mar 93 12:05:17 GMT Date: Wed, 24 Mar 93 11:57:31 GMT Message-Id: <3358.9303241157@calvados.pac.soton.ac.uk> Apparently-To: pbwg-method@cs.utk.edu TO METHODOLOGY SUBCOMMITTEE --------------------------- The following message is my contribution to the draft report of Chapter2 - Methodology, for consideration. Please let me have your comments, so that I may modify it. Roger Hockney ~r method3.tex From owner-pbwg-method@CS.UTK.EDU Wed Mar 24 07:47:54 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA11899; Wed, 24 Mar 93 07:47:54 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA12970; Wed, 24 Mar 93 07:47:47 -0500 X-Resent-To: pbwg-method@CS.UTK.EDU ; Wed, 24 Mar 1993 07:47:46 EST Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from sun2.nsfnet-relay.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA12961; Wed, 24 Mar 93 07:47:38 -0500 Via: uk.ac.southampton.ecs; Wed, 24 Mar 1993 12:41:29 +0000 Via: brewery.ecs.soton.ac.uk; Wed, 24 Mar 93 12:34:15 GMT From: Prof Roger Hockney Received: from alithea.ecs.soton.ac.uk by brewery.ecs.soton.ac.uk; Wed, 24 Mar 93 12:42:39 GMT Date: Wed, 24 Mar 93 12:42:43 GMT Message-Id: <271.9303241242@alithea.ecs.soton.ac.uk> To: pbwg-method@cs.utk.edu Subject: Methodology Chapter 2 contribution This is my first draft of a proposed Chapter2 for your comments and amalgamation with contributions from other members of the subcommittee. Please let me have your Comments, particularly any parts that you cannot accept (I hope none, however), so that I may edit it. I particularly wish to hear from our leader, David. Best regards Roger Hockney. You should be able to print it using LATEX, and the files benrep1.tex benref1.bib sent to pbwg-comm alredy. \chapter{Methodology} The conclusions drawn from a benchmark study of computer performance depend not only on the basic timing results obtained, but also on the way these are interpreted and converted into performance figures. The choice of the performance metric, may itself influence the conclusions. For example, do we want the computer that generates the most megaflops (or has the highest Speedup), or the computer that solves the problem in the least time? It is now well known that high values of the first metrics do not necessarily imply the second property. This confusion can be avoided by choosing a more suitable metric that reflects solution time directly, for example either the Temporal or Simulation performance, defined below. This issue of the sensible choice of performance metric is becoming increasing important with the advent of massively parallel computers which have the potential of very high megaflop rates, but have much more limited potential for reducing solution time. \section{Time Measurement} The fundamental measurement made in any benchmark is the time to complete some specified task. All other performance figures are derived from this basic timing measurement. The benchmark time, $T(N;p)$, will be a function of the problem size, $N$, and the number of processors, $p$. Here, the problem size is represented by the vector variable, $N$, which stands for a set of parameters characterising the size of the problem: e.g. the number of mesh points in each dimension, and the number of particles in a particle-mesh simulation. Benchmark problems of different sizes can be created by multiplying all the size parameters by suitable powers of a single scale factor, thereby increasing the spatial and particle resolution in a sensible way, and reducing the size parameters to a single size factor (here called $\alpha$). We believe that it is most important to regard execution time and performance as a function of at least the two variables $(N,p)$, which define a parameter plane. Much confusion has arisen in the past by attempts to treat performance as a function of a single variable, by taking a particular path through this plane, and not stating what path is taken. Many different paths may be taken, and hence many different conclusions can be drawn. It is important, therefore, always to define the path through the performance plane, or better as we do here, to study the shape of the two-dimensional performance hill. In some cases there may even be an optimum path up this hill. \section{Units and Symbols} A rational set of units and symbols is essential for any numerate science including benchmarking. The following extension of the internationally agreed SI system of physical units \cite{SI75} is made to accommodate the needs of computer benchmarking. \medskip New symbols and units: \begin{enumerate} \item flop : number of floating-point operations \item mref : number of memory references (reads or writes) \item barr : number of barrier operations \item b : number of binary digits (bits) \item B : number of bytes (groups of 8 bits) \item ${\rm w}_{32}$ : number of words (number of bits per word as subscript, here 32). \end{enumerate} Note that flop and mref are both inseparable four-letter symbols. The character case is significant in all unit symbols so that e.g. Flop, Mref, $W_{64}$ are incorrect. Unit symbols should always be printed in roman type, to contrast with variables names which are printed in italic. \medskip SI provides the standard prefixes: \begin{enumerate} \item k : kilo meaning $10^3$ \item M : mega meaning $10^6$ \item G : giga meaning $10^9$ \item T : tera meaning $10^{12}$ \end{enumerate} This means that we cannot use M to mean $1024^2$ (the binary mega) as is often done in describing computer memory capacity, e.g. 256 MB. We can however introduce the new prefix: \begin{enumerate} \item K : meaning 1024, then use a subscript 2 to indicate the binary versions \item ${\rm M}_2$ : binary mega $1024^2$ \item ${\rm G}_2$ : binary giga $1024^3$ \item ${\rm T}_2$ : binary tera $1024^4$ \end{enumerate} In most cases the difference between the mega and the binary mega (4\%) is probably unimportant, but it is important to be unambiguous. In this way one can continue with existing practice if the difference doesn't matter, and have an agreed method of being more exact when necessary. For example, the above memory capacity was probably intended to mean $256 {\rm M_2 B}$. As a consequence of the above, an amount of computational work involving $4.5 \times 10^{12}$ floating-point operations is correctly written as 4.5 Tflop. Note that the unit symbol Tflop is never pluralised with an added 's', and it is therefore incorrect to write the above as 4.5 Tflops which could be confused with a rate per second. The most frequently used unit of performance, millions of floating-point operations per second is correctly written Mflop/s, in analogy to km/s. The slash is necessary and means 'per', because the 'p' is an integral part of the unit symbol 'flop' and cannot also be used for this purpose. \section{Floating-Point Operation Count} Although we discourage the use of millions of floating-point operations per second as a performance metric, it can be a useful measure if the number of floating-point operations, $F(N)$, needed to solve the benchmark problem is carefully defined. For simple problems (e.g. matrix multiply) it is sufficient to use a theoretical value for the floating-point operation count (in this case $2n^3$ flop, for nxn matrices) obtained by inspection of the code or consideration of the arithmetic in the algorithm. For more complex problems containing data-dependent conditional statements, an empirical method may have to be used. The sequential version of the benchmark code defines the problem and the algorithm to be used to solve it. Counters can be inserted into this code or a hardware monitor used to count the number of floating-point operations. The latter is the procedure followed by the {\sc PERFECT} Club \cite{Berr89}. In either case a decision has to be made regarding the number of flop that are to be credited for different types of floating-point operations, and we see no good reason to deviate from those chosen by McMahon \cite{Ma88} when the Mflop/s measure was originally defined. These are: \begin{table}[h] \centering \begin{tabular}{ll} add, subtract, multiply & 1 flop \\ divide, square-root & 4 flop \\ exponential, sine etc. & 8 flop \\ {\sc IF(X .REL. Y)} & 1 flop \\ \end{tabular} \end{table} We distinguish two types of operation count. The first is the nominal benchmark floating-point operation count, $F_B(N)$, which is found in the above way from the defining Fortran77 sequential code. The other is the actual number of floating-point operations performed by the hardware when executing the distributed multi-node version, $F_H(N)$, which may be greater than the nominal benchmark count, due to the distributed version performing redundant arithmetic operations. \section{Performance Metrics} Given the time of execution $T(N;p)$ and the flop-count $F(N)$ several different performance measures can be defined. Each metric has its own uses, and gives different information about the computer and algorithm used in the benchmark. It is important therefore to distinguish the metrics with different names, symbols and units, and to understand clearly the difference between them. Much confusion and wasted work can arise from optimising a benchmark with respect to an inappropriate metric. The principal performance metrics are: \subsection{Temporal Performance} If we are interested in comparing the performance of different algorithms for the solution of the same problem, then the correct performance metric to use is the {\it Temporal Performance}, $R_T$, which is defined as the inverse of the execution time \begin{equation} R_T(N;p)=T^{-1}(N;p) \label{Eqn(1)} \end{equation} The units of temporal performance are, in general, solutions per second (sol/s), or some more appropriate absolute unit such as timesteps per second (tstep/s). With this metric we can be sure that the algorithm with the highest performance executes in the least time, and is therefore the best algorithm. We note that the number of flop does not appear in this definition, because the objective of algorithm design is not to perform the most arithmetic per second, but rather it is to solve a given problem in the least time, regardless of the amount of arithmetic involved. For this reason the temporal performance is also the metric that a computer user should employ to select the best algorithm to solve his problem, because his objective is also to solve the problem in the least time, and he does not care how much arithmetic is done to achieve this. \subsection{Simulation Performance} A special case of temporal performance occurs for simulation programs in which the benchmark problem is defined as the simulation of a certain period of physical time, rather than a certain number of timesteps. In this case we speak of the {\em Simulation Performance} and use units such as {\em simulated days per day} (written sim-d/d or 'd'/d) in weather forecasting, where the apostrophe is used to indicate 'simulated'; or {\em simulated pico-seconds per second} (written sim-ps/s or 'ps'/s) in electronic device simulation. It is important to use simulation performance rather than timestep/s if one is comparing different simulation algorithms which may require different sizes of timestep for the same accuracy (for example an implicit scheme that can use a large timestep, compared with an explicit scheme that requires a much smaller step). In order to maintain numerical stability, explicit schemes also require the use of a smaller timestep as the spatial grid is made finer. For such schemes the simulation performance falls off dramatically as the problem size is increased by introducing more mesh points in order to refine the spatial resolution: the doubling of the number of mesh-points in each of three dimensions can reduce the simulation performance by a factor near 16 because the timestep must also be approximately halved. Even though the larger problem will generate more Megaflop per second, in forecasting, it is the simulated days per day (i.e. the simulation performance) and not the Mflop/s, that matter to the user. As we see below, benchmark performance is also measured in terms of the amount of arithmetic performed per second or Mflop/s. However it is important to realise that it is incorrect to compare the Mflop/s achieved by two algorithms and to conclude that the algorithm with the highest Mflop/s rating is the best algorithm. This is because the two algorithms may be performing quite different amounts of arithmetic during the solution of the same problem. The temporal performance metric, $R_T$, defined above, has been introduced to overcome this problem, and provide a measure that can be used to compare different algorithms for solving the same problem. However, it should be remembered that the temporal performance only has the same meaning within the confines of a fixed problem, and no meaning can be attached to a comparison of the temporal performance on one problem with the temporal performance on another. \subsection{Benchmark Performance} In order to compare the performance of a computer on one benchmark with its performance on another, account must be taken of the different amounts of work (measured in flop) that the different problems require for their solution. Using the flop-count for the benchmark, $F_B(N)$, we can define the {\em Benchmark Performance} as \begin{equation} R_B(N;p)=F_B(N)/{T(N;p)} \label{Eqn(2)} \end{equation} The units of benchmark performance are Mflop/s (benchmark name), where we include the name of the benchmark in parentheses to emphasise that the performance may depend strongly on the problem being solved, and to emphasise that the values are based on the nominal benchmark flop-count. In other contexts such performance figures would probably be quoted as examples of the so-called {\em sustained} performance of a computer. We feel that the use of this term is meaningless unless the problem being solved and the degree of code optimisation is quoted, because the performance is so varied across different benchmarks and different levels of optimisation. Hence we favour the quotation of a selection of benchmark performance figures, rather than a single sustained performance, because the latter implies that the quoted performance is maintained over all problems. Note also that the flop-count $F_B(N)$ is that for the defining sequential version of the benchmark, and that the same count is used to calculate $R_B$ for the distributed-memory (DM) version of the program, even though the DM version may actually perform a different number of operations. It is usual for DM programs to perform more arithmetic than the defining sequential version, because often numbers are recomputed on the nodes in order to save communicating their values from a master processor. However such calculations are redundant (they have already been performed on the master) and it would be incorrect to credit them to the flop-count of the distributed program. Using the sequential flop-count in the calculation of the DM programs benchmark performance has the additional advantage that it is possible to conclude that, for a given benchmark, the implementation that has the highest benchmark performance is the best because it executes in the least time. This would not necessarily be the case if a different $F_B(N)$ were used for different implementations of the benchmark. For example, the use of a better algorithm which obtains the solution with less than $F_B(N)$ operations will show up as higher benchmark performance. For this reason it should cause no surprise if the benchmark performance occasionally exceeds the maximum possible hardware performance. To this extent benchmark performance Mflop/s must be understood to be nominal values, and not necessarily exactly the number of operations executed per second by the hardware, which is the subject of the next metric. The purpose of benchmark performance is to compare different implementations and algorithms on different computers for the solution of the same problem, on the basis that the best performance means the least execution time. For this to be true $F_B(N)$ must be kept the same for all implementations and algorithms. \subsection{Hardware Performance} If we wish to compare the observed performance with the theoretical capabilities of the computer hardware, we must compute the actual number of floating-point operations performed, $F_H(N;p)$, and from it the actual {\em Hardware Performance} \begin{equation} R_H(N;p)=F_H(N)/{T(N;p)} \label{Eqn(3)} \end{equation} The hardware performance also has the units Mflop/s, and will have the same value as the benchmark performance for the sequential version of the benchmark. However, the hardware performance may be higher than the benchmark performance for the distributed version, because the hardware performance gives credit for redundant arithmetic operations, whereas the benchmark performance does not. Because the hardware performance measures the actual floating-point operations performed per second, unlike the benchmark performance, it can never exceed the theoretical peak performance of the computer. Assuming a computer with multiple-CPUs each with multiple arithmetic pipelines, delivering a maximum of one flop per clock period, the theoretical peak value of hardware performance is \begin{equation} r^*= \frac{fl.pt.pipes/CPU}{clock.period}\times number.CPUs \label{Eqn(4)} \end{equation} with units of Mflop/s if the clock period is expressed in microseconds. By comparing the measured hardware performance, $R_H(N;p)$, with the theoretical peak performance, we can assess the fraction of the available performance that is being realised by a particular implementation of the benchmark. \subsection{Speedup, Efficiency and Performance per Node} We do not favour the use of any of the popular performance metrics: speedup, efficiency or performance per node; because all these are either easily misinterpreted or obscure important effects. The speedup of a benchmark code is defined as the ratio of the $p$-processor temporal performance to the single-processor temporal performance. It is a very useful and convenient measure if we are concerned with the optimisation of a particular code in isolation, because its value can easily be compared with the maximum possible speedup, namely the number of processors being used. We can thereby assess how much of the potential hardware performance is being utilised. However benchmarking is to do with comparing the performance of different computers, and all the above three metrics are unsuitable for this purpose. Speedup compares the performance of a code with itself, and might therefore be called an introspective, or even incestuous measure. Problems can therefore arise (see below), and incorrect conclusions can be drawn, if we try to use speedup to compare different algorithms on the same computer, or the same algorithm on different computers. This is because speedup is a relative measure (it is defined as the ratio of two performances), and therefore all knowledge of the absolute performance has been lost. Benchmarking, however, is concerned with the comparison of the absolute performance of computers, and therefore the use of a relative measure like speedup is not very useful, and can be positively misleading. For example, we do not wish to conclude that a computer with a large number of slow processors and therefore high value of speedup, is faster than another with fewer processors and therefore with a lower speedup, if in fact the reverse is the case, because the processors on the second computer are so much faster. Only by adopting absolute measures of performance with physical units involving inverse time, can one avoid this type of false conclusion. Speedup is not even useful for comparing the performance of one algorithm with another on the same computer, because it is not necessarily true that the algorithm with the highest speedup executes in the least time (see, e.g. ~\cite{Cvet90}). One can only be sure that this is the case if the single-processor temporal performance of both algorithms is the same, which is most unlikely. If the single-processor performances of the two algorithms are different and we compare the speedups of the two algorithms, then we are comparing the performance of the two algorithms measured in different units. This is like comparing the speeds of two cars, one measured in m.p.h. and the other in cm/s. Such a comparison has no validity either for cars or algorithms. Computers and algorithms can only safely be compared in terms of their absolute performance in solving a problem. The most unambiguous measure is the temporal performance, which is the inverse of the time of execution, or the related simulation performance. The benchmark performance per node might seem to be an attractive metric because it is an absolute measure which can be related directly to the hardware performance of node. However it has the major defect that it hides the point at which the absolute performance begins to decrease as the number of processors increases. If we plot benchmark performance against number of processors, this point is clearly visible as a maximum, however if the same data is plotted as performance per node, all we see is a very uninteresting monotonically falling line, and the important maximum has disappeared. The efficiency, which is defined as the speedup divided by the number of processors, is doubly condemned because it is a relative measure and hides the maximum. \section{Performance Database} The database of benchmark performance results should be based on an extension of the excellent X-window display demonstrated by Jack Dongarra at the March 1993 PBWG meeting. The basic data held would be values of $T(N;p)$ for at least 4 values of problem size $N$, each for sufficient $p$-values (say 5 to 10) to determine the trend of variation of performance with number of processors for constant problem size. It is important that there be enough $p$-values to see Amdahl saturation, if present, or any peak in performance followed by degradation. A graphical interface is really essential to allow this multidimensional data to be viewed in any of the metrics defined above, as chosen interactively by the user. The user could also be offered (by suitable interpolation) a display of the results in various scaled metrics, in which the problem size is expanded with the number of processors. In order to encompass as wide a range of performance and number of processors as possible, a log-scale on both axes is unavoidable, and the format and scale range should be kept fixed as long as possible to enable easy comparison between graphs. A three-cycle by three-cycle log-log graph with range 1 to 1000 in both $p$ and Mflop/s would cover most needs in the immediate future. Examples of such graphs are to be found in \cite{Hoc92,Add93}. % ---------------------------------------------------------------------------- From owner-pbwg-method@CS.UTK.EDU Fri Mar 26 08:48:10 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA13935; Fri, 26 Mar 93 08:48:10 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA20932; Fri, 26 Mar 93 08:47:49 -0500 X-Resent-To: pbwg-method@CS.UTK.EDU ; Fri, 26 Mar 1993 08:47:46 EST Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from sun2.nsfnet-relay.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA20915; Fri, 26 Mar 93 08:47:44 -0500 Via: uk.ac.southampton.ecs; Fri, 26 Mar 1993 13:46:58 +0000 From: R.Hockney@parallel-applications-centre.southampton.ac.uk Via: calvados.pac.soton.ac.uk (plonk); Fri, 26 Mar 93 13:31:08 GMT Date: Fri, 26 Mar 93 13:37:18 GMT Message-Id: <7983.9303261337@calvados.pac.soton.ac.uk> Apparently-To: pbwg-method@cs.utk.edu Ignore this message, I'm just testing the pwg-method mail reflector Roger Hockney From owner-pbwg-method@CS.UTK.EDU Fri Apr 30 12:31:41 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA18429; Fri, 30 Apr 93 12:31:41 -0400 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA22989; Fri, 30 Apr 93 12:31:01 -0400 X-Resent-To: pbwg-method@CS.UTK.EDU ; Fri, 30 Apr 1993 12:30:59 EDT Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from sun2.nsfnet-relay.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA22968; Fri, 30 Apr 93 12:30:51 -0400 Via: uk.ac.southampton.ecs; Fri, 30 Apr 1993 16:12:44 +0100 From: R.Hockney@parallel-applications-centre.southampton.ac.uk Via: calvados.pac.soton.ac.uk (plonk); Fri, 30 Apr 93 16:04:49 BST Date: Fri, 30 Apr 93 15:11:59 GMT Message-Id: <15933.9304301511@calvados.pac.soton.ac.uk> To: pbwg-method@cs.utk.edu Subject: Contribution to Chapter-1 (Methodology) \chapter{Methodology} The conclusions drawn from a benchmark study of computer performance depend not only on the basic timing results obtained, but also on the way these are interpreted and converted into performance figures. The choice of the performance metric, may itself influence the conclusions. For example, do we want the computer that generates the most megaflops (or has the highest Speedup), or the computer that solves the problem in the least time? It is now well known that high values of the first metrics do not necessarily imply the second property. This confusion can be avoided by choosing a more suitable metric that reflects solution time directly, for example either the Temporal or Simulation performance, defined below. This issue of the sensible choice of performance metric is becoming increasing important with the advent of massively parallel computers which have the potential of very high megaflop rates, but have much more limited potential for reducing solution time. \section{Time Measurement} The fundamental measurement made in any benchmark is the time to complete some specified task. All other performance figures are derived from this basic timing measurement. The benchmark time, $T(N;p)$, will be a function of the problem size, $N$, and the number of processors, $p$. Here, the problem size is represented by the vector variable, $N$, which stands for a set of parameters characterising the size of the problem: e.g. the number of mesh points in each dimension, and the number of particles in a particle-mesh simulation. Benchmark problems of different sizes can be created by multiplying all the size parameters by suitable powers of a single scale factor, thereby increasing the spatial and particle resolution in a sensible way, and reducing the size parameters to a single size factor (here called $\alpha$). We believe that it is most important to regard execution time and performance as a function of at least the two variables $(N,p)$, which define a parameter plane. Much confusion has arisen in the past by attempts to treat performance as a function of a single variable, by taking a particular path through this plane, and not stating what path is taken. Many different paths may be taken, and hence many different conclusions can be drawn. It is important, therefore, always to define the path through the performance plane, or better as we do here, to study the shape of the two-dimensional performance hill. In some cases there may even be an optimum path up this hill. \section{Units and Symbols} A rational set of units and symbols is essential for any numerate science including benchmarking. The following extension of the internationally agreed SI system of physical units \cite{SI75} is made to accommodate the needs of computer benchmarking. \medskip New symbols and units: \begin{enumerate} \item flop : number of floating-point operations \item mref : number of memory references (reads or writes) \item barr : number of barrier operations \item b : number of binary digits (bits) \item B : number of bytes (groups of 8 bits) \item ${\rm w}_{32}$ : number of words (number of bits per word as subscript, here 32). \end{enumerate} Note that flop and mref are both inseparable four-letter symbols. The character case is significant in all unit symbols so that e.g. Flop, Mref, $W_{64}$ are incorrect. Unit symbols should always be printed in roman type, to contrast with variables names which are printed in italic. \medskip SI provides the standard prefixes: \begin{enumerate} \item k : kilo meaning $10^3$ \item M : mega meaning $10^6$ \item G : giga meaning $10^9$ \item T : tera meaning $10^{12}$ \end{enumerate} This means that we cannot use M to mean $1024^2$ (the binary mega) as is often done in describing computer memory capacity, e.g. 256 MB. We can however introduce the new prefix: \begin{enumerate} \item K : meaning 1024, then use a subscript 2 to indicate the binary versions \item ${\rm M}_2$ : binary mega $1024^2$ \item ${\rm G}_2$ : binary giga $1024^3$ \item ${\rm T}_2$ : binary tera $1024^4$ \end{enumerate} In most cases the difference between the mega and the binary mega (4\%) is probably unimportant, but it is important to be unambiguous. In this way one can continue with existing practice if the difference doesn't matter, and have an agreed method of being more exact when necessary. For example, the above memory capacity was probably intended to mean $256 {\rm M_2 B}$. As a consequence of the above, an amount of computational work involving $4.5 \times 10^{12}$ floating-point operations is correctly written as 4.5 Tflop. Note that the unit symbol Tflop is never pluralised with an added 's', and it is therefore incorrect to write the above as 4.5 Tflops which could be confused with a rate per second. The most frequently used unit of performance, millions of floating-point operations per second is correctly written Mflop/s, in analogy to km/s. The slash is necessary and means 'per', because the 'p' is an integral part of the unit symbol 'flop' and cannot also be used for this purpose. \section{Floating-Point Operation Count} Although we discourage the use of millions of floating-point operations per second as a performance metric, it can be a useful measure if the number of floating-point operations, $F(N)$, needed to solve the benchmark problem is carefully defined. For simple problems (e.g. matrix multiply) it is sufficient to use a theoretical value for the floating-point operation count (in this case $2n^3$ flop, for nxn matrices) obtained by inspection of the code or consideration of the arithmetic in the algorithm. For more complex problems containing data-dependent conditional statements, an empirical method may have to be used. The sequential version of the benchmark code defines the problem and the algorithm to be used to solve it. Counters can be inserted into this code or a hardware monitor used to count the number of floating-point operations. The latter is the procedure followed by the {\sc PERFECT} Club \cite{Berr89}. In either case a decision has to be made regarding the number of flop that are to be credited for different types of floating-point operations, and we see no good reason to deviate from those chosen by McMahon \cite{Ma88} when the Mflop/s measure was originally defined. These are: \begin{table}[h] \centering \begin{tabular}{ll} add, subtract, multiply & 1 flop \\ divide, square-root & 4 flop \\ exponential, sine etc. & 8 flop \\ {\sc IF(X .REL. Y)} & 1 flop \\ \end{tabular} \end{table} We distinguish two types of operation count. The first is the nominal benchmark floating-point operation count, $F_B(N)$, which is found in the above way from the defining Fortran77 sequential code. The other is the actual number of floating-point operations performed by the hardware when executing the distributed multi-node version, $F_H(N)$, which may be greater than the nominal benchmark count, due to the distributed version performing redundant arithmetic operations. \section{Performance Metrics} Given the time of execution $T(N;p)$ and the flop-count $F(N)$ several different performance measures can be defined. Each metric has its own uses, and gives different information about the computer and algorithm used in the benchmark. It is important therefore to distinguish the metrics with different names, symbols and units, and to understand clearly the difference between them. Much confusion and wasted work can arise from optimising a benchmark with respect to an inappropriate metric. The principal performance metrics are: \subsection{Temporal Performance} If we are interested in comparing the performance of different algorithms for the solution of the same problem, then the correct performance metric to use is the {\it Temporal Performance}, $R_T$, which is defined as the inverse of the execution time \begin{equation} R_T(N;p)=T^{-1}(N;p) \label{Eqn(1)} \end{equation} The units of temporal performance are, in general, solutions per second (sol/s), or some more appropriate absolute unit such as timesteps per second (tstep/s). With this metric we can be sure that the algorithm with the highest performance executes in the least time, and is therefore the best algorithm. We note that the number of flop does not appear in this definition, because the objective of algorithm design is not to perform the most arithmetic per second, but rather it is to solve a given problem in the least time, regardless of the amount of arithmetic involved. For this reason the temporal performance is also the metric that a computer user should employ to select the best algorithm to solve his problem, because his objective is also to solve the problem in the least time, and he does not care how much arithmetic is done to achieve this. \subsection{Simulation Performance} A special case of temporal performance occurs for simulation programs in which the benchmark problem is defined as the simulation of a certain period of physical time, rather than a certain number of timesteps. In this case we speak of the {\em Simulation Performance} and use units such as {\em simulated days per day} (written sim-d/d or 'd'/d) in weather forecasting, where the apostrophe is used to indicate 'simulated'; or {\em simulated pico-seconds per second} (written sim-ps/s or 'ps'/s) in electronic device simulation. It is important to use simulation performance rather than timestep/s if one is comparing different simulation algorithms which may require different sizes of timestep for the same accuracy (for example an implicit scheme that can use a large timestep, compared with an explicit scheme that requires a much smaller step). In order to maintain numerical stability, explicit schemes also require the use of a smaller timestep as the spatial grid is made finer. For such schemes the simulation performance falls off dramatically as the problem size is increased by introducing more mesh points in order to refine the spatial resolution: the doubling of the number of mesh-points in each of three dimensions can reduce the simulation performance by a factor near 16 because the timestep must also be approximately halved. Even though the larger problem will generate more Megaflop per second, in forecasting, it is the simulated days per day (i.e. the simulation performance) and not the Mflop/s, that matter to the user. As we see below, benchmark performance is also measured in terms of the amount of arithmetic performed per second or Mflop/s. However it is important to realise that it is incorrect to compare the Mflop/s achieved by two algorithms and to conclude that the algorithm with the highest Mflop/s rating is the best algorithm. This is because the two algorithms may be performing quite different amounts of arithmetic during the solution of the same problem. The temporal performance metric, $R_T$, defined above, has been introduced to overcome this problem, and provide a measure that can be used to compare different algorithms for solving the same problem. However, it should be remembered that the temporal performance only has the same meaning within the confines of a fixed problem, and no meaning can be attached to a comparison of the temporal performance on one problem with the temporal performance on another. \subsection{Benchmark Performance} In order to compare the performance of a computer on one benchmark with its performance on another, account must be taken of the different amounts of work (measured in flop) that the different problems require for their solution. Using the flop-count for the benchmark, $F_B(N)$, we can define the {\em Benchmark Performance} as \begin{equation} R_B(N;p)=F_B(N)/{T(N;p)} \label{Eqn(2)} \end{equation} The units of benchmark performance are Mflop/s (benchmark name), where we include the name of the benchmark in parentheses to emphasise that the performance may depend strongly on the problem being solved, and to emphasise that the values are based on the nominal benchmark flop-count. In other contexts such performance figures would probably be quoted as examples of the so-called {\em sustained} performance of a computer. We feel that the use of this term is meaningless unless the problem being solved and the degree of code optimisation is quoted, because the performance is so varied across different benchmarks and different levels of optimisation. Hence we favour the quotation of a selection of benchmark performance figures, rather than a single sustained performance, because the latter implies that the quoted performance is maintained over all problems. Note also that the flop-count $F_B(N)$ is that for the defining sequential version of the benchmark, and that the same count is used to calculate $R_B$ for the distributed-memory (DM) version of the program, even though the DM version may actually perform a different number of operations. It is usual for DM programs to perform more arithmetic than the defining sequential version, because often numbers are recomputed on the nodes in order to save communicating their values from a master processor. However such calculations are redundant (they have already been performed on the master) and it would be incorrect to credit them to the flop-count of the distributed program. Using the sequential flop-count in the calculation of the DM programs benchmark performance has the additional advantage that it is possible to conclude that, for a given benchmark, the implementation that has the highest benchmark performance is the best because it executes in the least time. This would not necessarily be the case if a different $F_B(N)$ were used for different implementations of the benchmark. For example, the use of a better algorithm which obtains the solution with less than $F_B(N)$ operations will show up as higher benchmark performance. For this reason it should cause no surprise if the benchmark performance occasionally exceeds the maximum possible hardware performance. To this extent benchmark performance Mflop/s must be understood to be nominal values, and not necessarily exactly the number of operations executed per second by the hardware, which is the subject of the next metric. The purpose of benchmark performance is to compare different implementations and algorithms on different computers for the solution of the same problem, on the basis that the best performance means the least execution time. For this to be true $F_B(N)$ must be kept the same for all implementations and algorithms. \subsection{Hardware Performance} If we wish to compare the observed performance with the theoretical capabilities of the computer hardware, we must compute the actual number of floating-point operations performed, $F_H(N;p)$, and from it the actual {\em Hardware Performance} \begin{equation} R_H(N;p)=F_H(N)/{T(N;p)} \label{Eqn(3)} \end{equation} The hardware performance also has the units Mflop/s, and will have the same value as the benchmark performance for the sequential version of the benchmark. However, the hardware performance may be higher than the benchmark performance for the distributed version, because the hardware performance gives credit for redundant arithmetic operations, whereas the benchmark performance does not. Because the hardware performance measures the actual floating-point operations performed per second, unlike the benchmark performance, it can never exceed the theoretical peak performance of the computer. Assuming a computer with multiple-CPUs each with multiple arithmetic pipelines, delivering a maximum of one flop per clock period, the theoretical peak value of hardware performance is \begin{equation} r^*= \frac{fl.pt.pipes/CPU}{clock.period}\times number.CPUs \label{Eqn(4)} \end{equation} with units of Mflop/s if the clock period is expressed in microseconds. By comparing the measured hardware performance, $R_H(N;p)$, with the theoretical peak performance, we can assess the fraction of the available performance that is being realised by a particular implementation of the benchmark. \subsection{Speedup, Efficiency and Performance per Node} We do not favour the use of any of the popular performance metrics: speedup, efficiency or performance per node; because all these are either easily misinterpreted or obscure important effects. The speedup of a benchmark code is defined as the ratio of the $p$-processor temporal performance to the single-processor temporal performance. It is a very useful and convenient measure if we are concerned with the optimisation of a particular code in isolation, because its value can easily be compared with the maximum possible speedup, namely the number of processors being used. We can thereby assess how much of the potential hardware performance is being utilised. However benchmarking is to do with comparing the performance of different computers, and all the above three metrics are unsuitable for this purpose. Speedup compares the performance of a code with itself, and might therefore be called an introspective, or even incestuous measure. Problems can therefore arise (see below), and incorrect conclusions can be drawn, if we try to use speedup to compare different algorithms on the same computer, or the same algorithm on different computers. This is because speedup is a relative measure (it is defined as the ratio of two performances), and therefore all knowledge of the absolute performance has been lost. Benchmarking, however, is concerned with the comparison of the absolute performance of computers, and therefore the use of a relative measure like speedup is not very useful, and can be positively misleading. For example, we do not wish to conclude that a computer with a large number of slow processors and therefore high value of speedup, is faster than another with fewer processors and therefore with a lower speedup, if in fact the reverse is the case, because the processors on the second computer are so much faster. Only by adopting absolute measures of performance with physical units involving inverse time, can one avoid this type of false conclusion. Speedup is not even useful for comparing the performance of one algorithm with another on the same computer, because it is not necessarily true that the algorithm with the highest speedup executes in the least time (see, e.g. ~\cite{Cvet90}). One can only be sure that this is the case if the single-processor temporal performance of both algorithms is the same, which is most unlikely. If the single-processor performances of the two algorithms are different and we compare the speedups of the two algorithms, then we are comparing the performance of the two algorithms measured in different units. This is like comparing the speeds of two cars, one measured in m.p.h. and the other in cm/s. Such a comparison has no validity either for cars or algorithms. Computers and algorithms can only safely be compared in terms of their absolute performance in solving a problem. The most unambiguous measure is the temporal performance, which is the inverse of the time of execution, or the related simulation performance. The benchmark performance per node might seem to be an attractive metric because it is an absolute measure which can be related directly to the hardware performance of node. However it has the major defect that it hides the point at which the absolute performance begins to decrease as the number of processors increases. If we plot benchmark performance against number of processors, this point is clearly visible as a maximum, however if the same data is plotted as performance per node, all we see is a very uninteresting monotonically falling line, and the important maximum has disappeared. The efficiency, which is defined as the speedup divided by the number of processors, is doubly condemned because it is a relative measure and hides the maximum. \section{Performance Database} The database of benchmark performance results should be based on an extension of the excellent X-window display demonstrated by Jack Dongarra at the March 1993 PBWG meeting. The basic data held would be values of $T(N;p)$ for at least 4 values of problem size $N$, each for sufficient $p$-values (say 5 to 10) to determine the trend of variation of performance with number of processors for constant problem size. It is important that there be enough $p$-values to see Amdahl saturation, if present, or any peak in performance followed by degradation. A graphical interface is really essential to allow this multidimensional data to be viewed in any of the metrics defined above, as chosen interactively by the user. The user could also be offered (by suitable interpolation) a display of the results in various scaled metrics, in which the problem size is expanded with the number of processors. In order to encompass as wide a range of performance and number of processors as possible, a log-scale on both axes is unavoidable, and the format and scale range should be kept fixed as long as possible to enable easy comparison between graphs. A three-cycle by three-cycle log-log graph with range 1 to 1000 in both $p$ and Mflop/s would cover most needs in the immediate future. Examples of such graphs are to be found in \cite{Hoc92,Add93}. % ---------------------------------------------------------------------------- From owner-pbwg-method@CS.UTK.EDU Tue May 18 09:41:04 1993 Received: from CS.UTK.EDU by netlib2.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.8t-UTK) id AA23468; Tue, 18 May 93 09:41:04 -0400 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07846; Tue, 18 May 93 09:41:43 -0400 X-Resent-To: pbwg-method@CS.UTK.EDU ; Tue, 18 May 1993 09:41:41 EDT Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from ben.uknet.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07829; Tue, 18 May 93 09:41:36 -0400 Message-Id: <9305181341.AA07829@CS.UTK.EDU> Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Tue, 18 May 1993 14:41:31 +0100 Received: from newton.npl.co.uk by eros.uknet.ac.uk via PSS with NIFTP (PP) id <6811-0@eros.uknet.ac.uk>; Tue, 18 May 1993 14:41:22 +0100 Date: Tue, 18 May 93 14:41 GMT From: Trevor Chambers To: PBWG-METHOD COMMITTEE: methodology TOPIC: definition of popular metrics CONTENT: They are here to stay. Should we attempt to strengthen the definitions? ACTUAL MESSAGE: Can PBWG realistically dispense with commonly used measures such as speed-up and performance per node? There is the danger that PBWG could isolate itself from the main stream of computer users, or that others will use the PBWG benchmarks and report the popular metrics anyway. One possibility is to acknowledge these metrics and to attempt to strengthen the definitions. Relevant to this matter is the degree to which the suggested PBWG metrics are used and understood by potential users and people involved in procurement. What information do we have on this matter? I propose that the committee takes a considered view on the use of popular metrics. Trevor Chambers pp Ed Brocklehurst From owner-pbwg-method@CS.UTK.EDU Fri May 21 07:17:47 1993 Received: from CS.UTK.EDU by netlib2.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.8t-UTK) id AA03541; Fri, 21 May 93 07:17:47 -0400 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA11317; Fri, 21 May 93 07:17:43 -0400 X-Resent-To: pbwg-method@CS.UTK.EDU ; Fri, 21 May 1993 07:17:42 EDT Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from ben.uknet.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA11309; Fri, 21 May 93 07:17:37 -0400 Message-Id: <9305211117.AA11309@CS.UTK.EDU> Received: from newton.npl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Fri, 21 May 1993 12:17:09 +0100 Date: Fri, 21 May 93 12:17 GMT From: CBF@newton.npl.co.uk To: PBWG-METHOD To the Methodology Committee. I'm afraid I'm a little confused at the intent of 2.4.3 the Benchmark Performance section as stated. If we are comparing the same benchmark on different machines do we need Fb(N) in the equations? For instance R1b(N;p) > R2b(N;p) where R1b is the rate of machine 1 and R2b is the rate of machine 2. This implies Fb(N)/T1(N;p) > Fb(N)/T(N;p) as Fb(N) does not depend on the machine but only on the defining serial code. This implies 1/T1(N;p) > 1/T(N;p) (or T(N;p) > T1(N;p) ). In other words we get a straight timing result anyway. If we are not comparing the same benchmark is the flop a suitable representation of the work that a benchmark does. Is it not possible that memory accessing and I/O usage could outstrip floating point operations in terms of importance? From owner-pbwg-method@CS.UTK.EDU Fri May 21 13:12:51 1993 Received: from CS.UTK.EDU by netlib2.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.8t-UTK) id AA06602; Fri, 21 May 93 13:12:51 -0400 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA29733; Fri, 21 May 93 12:05:30 -0400 X-Resent-To: pbwg-method@CS.UTK.EDU ; Fri, 21 May 1993 12:05:25 EDT Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from sun2.nsfnet-relay.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA29698; Fri, 21 May 93 12:05:18 -0400 Via: uk.ac.southampton.ecs; Fri, 21 May 1993 16:42:15 +0100 From: R.Hockney@parallel-applications-centre.southampton.ac.uk Via: calvados.pac.soton.ac.uk (plonk); Fri, 21 May 93 16:34:34 BST Date: Fri, 21 May 93 15:41:53 GMT Message-Id: <3128.9305211541@calvados.pac.soton.ac.uk> To: pbwg-method@cs.utk.edu Subject: Speedup and R_B Mflop/s May I respond to some comments on my submission on metrics: (1) To Trevor Chambers - Speedup and Performance per Node I think you may have talked yourself into a job! Although I personally do not think that Speedup is a useful metric, I acknowledge its widespread use, and agree that the best policy is to try to tighten up the definitions. Please put your suggestions to the 24th May meeting. My problem with the use of Speedup is that I don't think that it is possible to produce a usefull definition, because all the knowledge of absolute performance has been thrown away by taking the ratio to some (what) one-processor time. Its much more rational to keep the knowledge of absolute performance by using e.g. Temporal or Benchmark performance. How can you compare different computers if you don't use absolute measures, which involve seconds^-1 in their units? Lets discuss this on Monday. (2) To CBF at NPL - Do we need F_B(N) The answer is NO we don't, in which case the only metric to use is the Temporal Performance, which is the same as comparing executions times, but the result is expressed more naturally as a performance. The definition of Benchmark performance was made inorder to keep the units of Mflop/s which people widely use but ensure that the highest R_B implies the least execution time. This can only be done if F_B(N) is kept the same for all implementations and treated as a nominal figure. If you want real Mflop/s you use R_H the hardware performance. Of course F_B is only appropriate for problems dominated by floating-point arithmetic, for other problems the Benchmark writyer would be expected to define an appropriate measure of work (I/O references e.g.) or else simply fall back on Temporal performance and time alone. The other reason for R_B is to allow some (albeit approximate) comparison of all arithmetic benchmarks in the same units (i.e.Mflop/s). Temporal Performances cannot be compared across benchmarks. All Good points for disussion on Monday, preferable as suggested editting to my draft submission, with your agreement of course David. Are you there Roger Hockney From owner-pbwg-method@CS.UTK.EDU Mon May 24 03:26:04 1993 Received: from CS.UTK.EDU by netlib2.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.8t-UTK) id AA19684; Mon, 24 May 93 03:26:04 -0400 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA13266; Mon, 24 May 93 03:26:34 -0400 X-Resent-To: pbwg-method@CS.UTK.EDU ; Mon, 24 May 1993 03:26:33 EDT Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from sun2.nsfnet-relay.ac.uk by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA13258; Mon, 24 May 93 03:26:28 -0400 Via: uk.ac.southampton.ecs; Mon, 24 May 1993 08:25:54 +0100 Via: brewery.ecs.soton.ac.uk; Mon, 24 May 93 08:18:26 BST From: Vladimir Getov Received: from beluga.ecs.soton.ac.uk by brewery.ecs.soton.ac.uk; Mon, 24 May 93 08:27:00 BST Date: Mon, 24 May 93 08:26:59 BST Message-Id: <25360.9305240726@beluga.ecs.soton.ac.uk> To: pbwg-method@cs.utk.edu Subject: a note on metrics Here follows my rough note on metrics, which you may like to consider in today's meeting. I wish you fruitful and successful discussions. Best regards, Vladimir Getov A Few Notes on Metrics ---------------------- 1. The elapsed time is the only prime metric. 1.1. It must be the wall-clock time, otherwise there will be some hidden delays and the interpretation of results may not be correct. 1.2. Do we need to know the components of the wall-clock time? The computer user will probably answer: - `No, I am only interested in the total elapsed time to complete my task.' However, if one would like to improve the application performance as much as possible, the knowledge of all components of the wall-clock time is necessary. This information is essential for computer architects, but is also very useful for computer users. As usual, these components include the calculation time, the communication time, the memory-access time, the I/O time, the system time, the wait time, etc. 2. In order to define the secondary (derivative) metrics I would suggest answering the question: -`What is our goal? Why we need benchmark measurements?' There is a few answers to this question and I believe every answer defines its appropriate derivative (secondary) performance metrics. My current `goals' list includes: - Comparative benchmarking analysis of different parallel machines; - Analysis and comparison of different algorithms, methods and program implementations for a given application; - Benchmarking analysis and identification of bottlenecks for particular parallel architecture (shell we include the compiler benchmarks, etc. here?). In my opinion the most useful derivative benchmarking metrics are the benchmark performance, the speed-up and the efficiency. Concerning the speed-up and the efficiency I would think about different definitions. For example, it seems very useful to calculate the speed-up as the ratio of the elapsed time of two different algorithms on the same computer. This defines straight-away which one is faster for given problem size and number of processors. The efficiency could be defined as the ratio of the benchmark performance to the peak performance. This gives a clear picture of how far the measurement results are from the theoretical peak. In fact the list of derivative metrics may be quite long and it would be difficult to decide which are the important and useful metrics to be included in the PBWG documents. vsg@ecs.soton.ac.uk Dr Vladimir Getov Tel: +44 703 593368 Dept of Electronics and Computer Science Fax: +44 703 593045 University of Southampton Southampton SO9 5NH, U.K. From owner-pbwg-method@CS.UTK.EDU Wed Sep 1 22:04:37 1993 Received: from CS.UTK.EDU by netlib2.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.8t-netlib) id AA12004; Wed, 1 Sep 93 22:04:37 -0400 Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25195; Wed, 1 Sep 93 22:03:06 -0400 X-Resent-To: pbwg-method@CS.UTK.EDU ; Wed, 1 Sep 1993 22:03:04 EDT Errors-To: owner-pbwg-method@CS.UTK.EDU Received: from BERRY.CS.UTK.EDU by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25189; Wed, 1 Sep 93 22:03:03 -0400 Received: from LOCALHOST.cs.utk.edu by berry.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA08100; Wed, 1 Sep 93 22:03:01 -0400 Message-Id: <9309020203.AA08100@berry.cs.utk.edu> To: pbwg-method@cs.utk.edu Subject: method5.tex Date: Wed, 01 Sep 1993 22:03:01 -0400 From: "Michael W. Berry" This is a revision of the methodology chapter of the PARKBENCH report submitted by David Bailey. Regards, Mike ------- Forwarded Message Return-Path: Received: from wk49.nas.nasa.gov by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA19544; Wed, 1 Sep 93 20:24:25 -0400 Received: by wk49.nas.nasa.gov (5.67-NAS.4/5.67-NAS-1.1(SGI)) id AA02573; Wed, 1 Sep 93 17:24:22 -0700 Date: Wed, 1 Sep 93 17:24:22 -0700 From: dbailey@nas.nasa.gov (David H. Bailey) Message-Id: <9309020024.AA02573@wk49.nas.nasa.gov> To: berry@cs.utk.edu Subject: Revised Methodology section. Please distribute to method group %file method5.tex % Compiled by David Bailey for methodology subcommittee. % Text below submitted by Roger Hockney to methodology subcommittee. % This text includes revision by Bailey on 01 Sep 1993. \chapter{Methodology} \section{Philosophy} One might ask why anyone should care about developing a standardized, rigorous and scientifically tenable methodology for studying the performance of high-performance computer systems. There are several reasons why this is an important undertaking: \begin{enumerate} \item To establish and maintain high standards of honesty and integrity in our profession. \item To improve the status of supercomputer performance analysis as a rigorous scientific discipline. \item To reduce confusion in the high-performance computing literature. \item To increase understanding of these systems, both at a low-level hardware or software level and at a high-level, total system performance level. \item To assist the purchasers of high-performance computing equipment in selecting systems best suited to their needs. \item To reduce the amount of time and resources vendors must expend in implementing multiple, redundant benchmarks. \item To provide valuable feedback to vendors on bottlenecks that can be alleviated in future products. \end{enumerate} It is important to note that researchers in many scientific disciplines have found it necessary to establish and refine standards for performing experiments and reporting the results. Many scientists have learned the importance of standard terminology and notation. Chemists, physicists and biologists long ago discovered the importance of ``controls'' in their experiments. The issue of repeatability proved crucial in the recent ``cold fusion'' episode. Medical researchers have found it necessary to perform ``double-blind'' experiments in their field. Psychologists and sociologists have developed highly refined experimental methodologies and advanced data analysis techniques. Political scientists have found that subtle differences in the phrasing of a question can affect the results of a poll. Researchers in many fields have found that environmental factors in their experiments can significantly influence the measured results; thus they must carefully report all such factors in their papers. If supercomputer performance analysis and benchmarking is ever to be taken seriously as a scientific discipline, certainly its practitioners should be expected to adhere to standards that prevail in other disciplines. This document is dedicated to promoting these standards in our field. \section{Fundamental Metrics} The conclusions drawn from a benchmark study of computer performance depend not only on the basic timing results obtained, but also on the way these are interpreted and converted into performance figures. The choice of the performance metric, may itself influence the conclusions. For example, do we want the computer that generates the most megaflop per second (or has the highest Speedup), or the computer that solves the problem in the least time? It is now well known that high values of the first metrics do not necessarily imply the second property. This confusion can be avoided by choosing a more suitable metric that reflects solution time directly, for example either the Temporal, Simulation or Benchmark performance, defined below. This issue of the sensible choice of performance metric is becoming increasing important with the advent of massively parallel computers which have the potential of very high megaflop rates, but have much more limited potential for reducing solution time. \section{Time Measurement} Before other issues can be considered, we must discuss the measurement of run time. In recent years a consensus has been reached among many scientists in the field that the most relevant measure of run time is actual wall-clock elapsed time. This measure of time will be required for all ParkBench results that are posted to the database. Elapsed wall-clock time means the time that would be measured on an external clock that records the time-of-day or even Greenwich mean time (GMT), between the start and finish of the benchmark. We are not concerned with the origin of the time measurement, since we are taking a difference, but it is important that the time measured would be the same as that given by a difference between two measurements of GMT, if it were possible to make them. It is important to be clear about this, because many computer clocks (e.g. Sun Unix function ETIME) measure elapsed CPU time, which is the total time that the process or job which calls it has been executing in the CPU. Such a clock does not record time (i.e. it stops ticking) when the job is swapped out of the CPU. It does not record, therefore, any wait time which must be included if we are to assess correctly the performance of a parallel program. On some systems, scientists have found that even for programs that perform no explicit I/O, considerable ``system'' time is nonetheless involved, for example in fetching certain library routines or other data. Only timings actually measured may be cited for ParkBench benchmarks (and we strongly recommend this practice for other benchmarks as well). Extrapolations and projections, for instance to a larger number of nodes, may not be employed for any reason. Also, in the interests of repeatability it is highly recommended that timing runs be repeated, several times if possible. Two low-level benchmarks are provided in the ParkBench~ suite to test the precision and accuracy of the clock that is to be used in the benchmarking. These should be run first, before any benchmark measurements are made. They are: \begin{enumerate} \item TICK1 - measures the precision of the clock by measuring the time interval between ticks of the clock. A clock is said to tick when it changes its value. \item TICK2 - measures the accuracy of the clock by comparing a given time interval measured by an external wall-clock (the benchmarker's wrist watch is adequate) with the same interval measured by the computer clock. This tests the scale factor used to convert computer clock ticks to seconds, and immediately detects if a CPU-clock is incorrectly being used. \end{enumerate} The fundamental measurement made in any benchmark is the elapsed wall-clock time to complete some specified task. All other performance figures are derived from this basic timing measurement. The benchmark time, $T(N;p)$, will be a function of the problem size, $N$, and the number of processors, $p$. Here, the problem size is represented by the vector variable, $N$, which stands for a set of parameters characterising the size of the problem: e.g. the number of mesh points in each dimension, and the number of particles in a particle-mesh simulation. Benchmark problems of different sizes can be created by multiplying all the size parameters by suitable powers of a single scale factor, thereby increasing the spatial and particle resolution in a sensible way, and reducing the size parameters to a single size factor (usually called $\alpha$). We believe that it is most important to regard execution time and performance as a function of at least the two variables $(N,p)$, which define a parameter plane. Much confusion has arisen in the past by attempts to treat performance as a function of a single variable, by taking a particular path through this plane, and not stating what path is taken. Many different paths may be taken, and hence many different conclusions can be drawn. It is important, therefore, always to define the path through the performance plane, or better as we do here, to study the shape of the two-dimensional performance hill. In some cases there may even be an optimum path up this hill. \section{Units and Symbols} A rational set of units and symbols is essential for any numerate science including benchmarking. The following extension of the internationally agreed SI system of physical units \cite{SI75} is made to accommodate the needs of computer benchmarking. The value of a variable comprises a pure number stating the number of units which equal the value of the variable, followed by a unit symbol specifying the unit in which the variable is being measured. A new unit is required whenever a quantity of a new nature arises, such as e.g. the first appearance of vector operations, or message sends. Generally speaking a unit symbol should be as short as possible, consistent with being easily recognised and not already used. The following have been found necessary in the characterisation of computer and benchmark performance in science and engineering. No doubt more will have to be defined as benchmarking enters new areas. \medskip New unit symbols and their meaning: \begin{enumerate} \item \flop : floating-point operation [latex \verb1\1flop] \item \inst : instruction of any kind [latex \verb1\1inst] \item \inop : integer operation [latex \verb1\1inop] \item \vecop: vector operation [latex \verb1\1vecop] \item \send: message send operation [latex \verb1\1send] \item \iter : iteration of loop [latex \verb1\1iter] \item \mref : memory reference (read or write) [latex \verb1\1mref] \item \barr : barrier operation [latex \verb1\1barr] \item \bit : binary digit (bit) [latex \verb1\1bit] \item \B : byte (groups of 8 bits) [latex \verb1\1B] \item \sol : solution or single execution of benchmark [latex \verb1\1sol] \item \w : computer word. Symbol is lower case (W means watt) [latex \verb1\1w] \end{enumerate} When required a subscript may be used to show the number of bits involved in the unit. For example: a 32-bit floating-point operation ${\flop}_{32}$, a 64-bit word ${\w}_{64}$, also we have ${\bit}={\w}_1$, ${\B}={\w}_8$, ${\w}_{64}= 8 {\B}$. Note that flop, mref and other multi-letter symbols are inseparable four or five-letter symbols. The character case is significant in all unit symbols so that e.g. Flop, Mref, $W_{64}$ are incorrect. Unit symbols should always be printed in roman type, to contrast with variables names which are printed in italic. To aid in the use of roman type, especially within Latex maths mode, Latex commands have been defined for each unit, these commands being a backslash followed by the unit symbol (except for '\inop' and '\bit' whose names are changed in the command to avoid a clash with already defined system commands). Such commands will print in roman type wherever they occur. Because 's' is the SI unit for seconds, unit symbols like 'sheep' do not take 's' in the plural. Thus one counts: one flop, two flop, ..., one hundred flop etc. This is especially important when the unit symbol is used in ordinary text as a useful abbreviation, as often, quite sensibly, it is. \medskip SI provides the standard prefixes: \begin{enumerate} \item k : kilo meaning $10^3$ \item M : mega meaning $10^6$ \item G : giga meaning $10^9$ \item T : tera meaning $10^{12}$ \end{enumerate} This means that we cannot use M to mean $1024^2$ (the binary mega) as is often done in describing computer memory capacity, e.g. 256 MB. We can however introduce the new prefix: \begin{enumerate} \item K : meaning 1024, then use a subscript 2 to indicate the binary versions \item $\mbox{\rm M}_2$ : binary mega $1024^2$ \item $\mbox{\rm G}_2$ : binary giga $1024^3$ \item $\mbox{\rm T}_2$ : binary tera $1024^4$ \end{enumerate} In most cases the difference between the mega and the binary mega (4\%) is probably unimportant, but it is important to be unambiguous. In this way one can continue with existing practice if the difference doesn't matter, and have an agreed method of being more exact when necessary. For example, the above memory capacity was probably intended to mean $256 \mbox{\rm M}_2 \B$. As a consequence of the above, an amount of computational work involving $4.5 \times 10^{12}$ floating-point operations is correctly written as 4.5 Tflop. Note that the unit symbol Tflop is never pluralised with an added 's', and it is therefore incorrect to write the above as 4.5 Tflops which could be confused with a rate per second. The most frequently used unit of performance, millions of floating-point operations per second is correctly written Mflop/s, in analogy to km/s. The slash is necessary and means 'per', because the 'p' is an integral part of the unit symbol 'flop' and cannot also be used to mean 'per'. \section{Floating-Point Operation Count} Although we discourage the use of millions of floating-point operations per second as a performance metric, it can be a useful measure if the number of floating-point operations, $F(N)$, needed to solve the benchmark problem is carefully defined. For simple problems (e.g. matrix multiply) it is sufficient to use a theoretical value for the floating-point operation count (in this case $2n^3$ flop, for nxn matrices) obtained by inspection of the code or consideration of the arithmetic in the algorithm. For more complex problems containing data-dependent conditional statements, an empirical method may have to be used. The sequential version of the benchmark code defines the problem and the algorithm to be used to solve it. Counters can be inserted into this code or a hardware monitor used to count the number of floating-point operations. The latter is the procedure followed by the {\sc PERFECT} Club \cite{Berr89}. In either case a decision has to be made regarding the number of flop that are to be credited for different types of floating-point operations, and we see no good reason to deviate from those chosen by McMahon \cite{Ma88} when the Mflop/s measure was originally defined. These are: \begin{table}[h] \centering \begin{tabular}{ll} add, subtract, multiply & 1 flop \\ divide, square-root & 4 flop \\ exponential, sine etc. & 8 flop (this figure will be adjusted) \\ {\sc IF(X .REL. Y)} & 1 flop \\ \end{tabular} \end{table} Some members of the committee felt that these numbers, derived in the 1970s, no longer correctly reflected the situation on current computers. However, since these numbers are only used to calculate a nominal benchmark flop-count, it is not so important that they be accurate. The important thing is that they do not change, otherwise all previous flop-counts would have to be renormalised. In any case, it is not possible for a single set of ratios to be valid for all computers and library software. I (rwh) suggest the committee stays with the above ratios until such time as they become wildly wrong and extensive research provides us with a more realistic set. We distinguish two types of operation count. The first is the nominal benchmark floating-point operation count, $F_B(N)$, which is found in the above way from the defining Fortran77 sequential code. The other is the actual number of floating-point operations performed by the hardware when executing the distributed multi-node version, $F_H(N,p)$, which may be greater than the nominal benchmark count, due to the distributed version performing redundant arithmetic operations. Because of this, the hardware flop count may also depend on the number of processors on which the benchmark is run, as shown in its argument list. \section{Performance Metrics} Given the time of execution $T(N;p)$ and the flop-count $F(N)$ several different performance measures can be defined. Each metric has its own uses, and gives different information about the computer and algorithm used in the benchmark. It is important therefore to distinguish the metrics with different names, symbols and units, and to understand clearly the difference between them. Much confusion and wasted work can arise from optimising a benchmark with respect to an inappropriate metric. The principal performance metrics are: \subsection{Temporal Performance} If we are interested in comparing the performance of different algorithms for the solution of the same problem, then the correct performance metric to use is the {\it Temporal Performance}, $R_T$, which is defined as the inverse of the execution time \begin{equation} R_T(N;p)=T^{-1}(N;p) \label{Eqn(1)} \end{equation} The units of temporal performance are, in general, solutions per second (sol/s), or some more appropriate absolute unit such as timesteps per second (tstep/s). With this metric we can be sure that the algorithm with the highest performance executes in the least time, and is therefore the best algorithm. We note that the number of flop does not appear in this definition, because the objective of algorithm design is not to perform the most arithmetic per second, but rather it is to solve a given problem in the least time, regardless of the amount of arithmetic involved. For this reason the temporal performance is also the metric that a computer user should employ to select the best algorithm to solve his problem, because his objective is also to solve the problem in the least time, and he does not care how much arithmetic is done to achieve this. \subsection{Simulation Performance} A special case of temporal performance occurs for simulation programs in which the benchmark problem is defined as the simulation of a certain period of physical time, rather than a certain number of timesteps. In this case we speak of the {\em Simulation Performance} and use units such as {\em simulated days per day} (written sim-d/d or 'd'/d) in weather forecasting, where the apostrophe is used to indicate 'simulated'; or {\em simulated pico-seconds per second} (written sim-ps/s or 'ps'/s) in electronic device simulation. It is important to use simulation performance rather than timestep/s if one is comparing different simulation algorithms which may require different sizes of timestep for the same accuracy (for example an implicit scheme that can use a large timestep, compared with an explicit scheme that requires a much smaller step). In order to maintain numerical stability, explicit schemes also require the use of a smaller timestep as the spatial grid is made finer. For such schemes the simulation performance falls off dramatically as the problem size is increased by introducing more mesh points in order to refine the spatial resolution: the doubling of the number of mesh-points in each of three dimensions can reduce the simulation performance by a factor near 16 because the timestep must also be approximately halved. Even though the larger problem will generate more Megaflop per second, in forecasting, it is the simulated days per day (i.e. the simulation performance) and not the Mflop/s, that matter to the user. As we see below, benchmark performance is also measured in terms of the amount of arithmetic performed per second or Mflop/s. However it is important to realise that it is incorrect to compare the Mflop/s achieved by two algorithms and to conclude that the algorithm with the highest Mflop/s rating is the best algorithm. This is because the two algorithms may be performing quite different amounts of arithmetic during the solution of the same problem. The temporal performance metric, $R_T$, defined above, has been introduced to overcome this problem, and provide a measure that can be used to compare different algorithms for solving the same problem. However, it should be remembered that the temporal performance only has the same meaning within the confines of a fixed problem, and no meaning can be attached to a comparison of the temporal performance on one problem with the temporal performance on another. \subsection{Benchmark Performance} In order to compare the performance of a computer on one benchmark with its performance on another, account must be taken of the different amounts of work (measured in flop) that the different problems require for their solution. Using the flop-count for the benchmark, $F_B(N)$, we can define the {\em Benchmark Performance} as \begin{equation} R_B(N;p)=F_B(N)/{T(N;p)} \label{Eqn(2)} \end{equation} The units of benchmark performance are Mflop/s (benchmark name), where we include the name of the benchmark in parentheses to emphasise that the performance may depend strongly on the problem being solved, and to emphasise that the values are based on the nominal benchmark flop-count. In other contexts such performance figures would probably be quoted as examples of the so-called {\em sustained} performance of a computer. We feel that the use of this term is meaningless unless the problem being solved and the degree of code optimisation is quoted, because the performance is so varied across different benchmarks and different levels of optimisation. Hence we favour the quotation of a selection of benchmark performance figures, rather than a single sustained performance, because the latter implies that the quoted performance is maintained over all problems. Note also that the flop-count $F_B(N)$ is that for the defining sequential version of the benchmark, and that the same count is used to calculate $R_B$ for the distributed-memory (DM) version of the program, even though the DM version may actually perform a different number of operations. It is usual for DM programs to perform more arithmetic than the defining sequential version, because often numbers are recomputed on the nodes in order to save communicating their values from a master processor. However such calculations are redundant (they have already been performed on the master) and it would be incorrect to credit them to the flop-count of the distributed program. Using the sequential flop-count in the calculation of the DM programs benchmark performance has the additional advantage that it is possible to conclude that, for a given benchmark, the implementation that has the highest benchmark performance is the best because it executes in the least time. This would not necessarily be the case if a different $F_B(N)$ were used for different implementations of the benchmark. For example, the use of a better algorithm which obtains the solution with less than $F_B(N)$ operations will show up as higher benchmark performance. For this reason it should cause no surprise if the benchmark performance occasionally exceeds the maximum possible hardware performance. To this extent benchmark performance Mflop/s must be understood to be nominal values, and not necessarily exactly the number of operations executed per second by the hardware, which is the subject of the next metric. The purpose of benchmark performance is to compare different implementations and algorithms on different computers for the solution of the same problem, on the basis that the best performance means the least execution time. For this to be true $F_B(N)$ must be kept the same for all implementations and algorithms. \subsection{Hardware Performance} If we wish to compare the observed performance with the theoretical capabilities of the computer hardware, we must compute the actual number of floating-point operations performed, $F_H(N;p)$, and from it the actual {\em Hardware Performance} \begin{equation} R_H(N;p)=F_H(N,p)/{T(N;p)} \label{Eqn(3)} \end{equation} The hardware performance also has the units Mflop/s, and will have the same value as the benchmark performance for the sequential version of the benchmark. However, the hardware performance may be higher than the benchmark performance for the distributed version, because the hardware performance gives credit for redundant arithmetic operations, whereas the benchmark performance does not. Because the hardware performance measures the actual floating-point operations performed per second, unlike the benchmark performance, it can never exceed the theoretical peak performance of the computer. Assuming a computer with multiple-CPUs each with multiple arithmetic pipelines, delivering a maximum of one flop per clock period, the theoretical peak value of hardware performance is \begin{equation} r^*= \frac{fl.pt.pipes/CPU}{clock.period}\times number.CPUs \label{Eqn(4)} \end{equation} with units of Mflop/s if the clock period is expressed in microseconds. By comparing the measured hardware performance, $R_H(N;p)$, with the theoretical peak performance, we can assess the fraction of the available performance that is being realised by a particular implementation of the benchmark. \subsection{Speedup, Efficiency and Performance per Node} ``Parallel speedup'' is a popular metric that has been used for many years in the study of parallel computer performance. However, its definition is open to ambiguity and misuse because it always begs the question ``speedup over what?'' Speedup is usually defined as \begin{equation} \frac{T_1}{T_p} \end{equation} \noindent where $T_p$ is the $p$-processor time to perform some benchmark, and $T_1$ is the one-processor time. There is no doubt about the meaning of $T_p$ --- this is the measured time $T(N;p)$ to perform the benchmark. There is often considerable dispute over the meaning of $T_1$: should it be the time for the parallel code running on one processor, which probably contains unnecessary parallel overhead, or should it be the best serial code (possibly using a different algorithm) running on one processor? Many scientists feel the latter is a more responsible choice, but this requires research to determine the best practical serial algorithm for the given application. If at a later time a better algorithm is found, current speedup figures might be considered obsolete. An additional difficulty with this definition is that even if a meaning for $T_1$ is agreed to, there may be insufficient memory on a single node to store an entire large problem. Thus in many cases it may be impossible to measure $T_1$ using this definition. One principal objective in the field of performance analysis is benchmarking: to compare the performance of different computers. It is generally agreed that the best performance corresponds to the least wall-clock execution time. In order to adapt the speedup statistic for benchmarking, it is thus necessary to define a single reference value of $T_1$ to be used for all calculations. It does not matter how $T_1$ is defined, or what its value is, only that the same value of $T_1$ is used to calculate all speedup values used in the comparison. However, defining $T_1$ as a reference time unrelated to the parallel computer being benchmarked unfortunately has the consequence that many properties that many people regard as essential to the concept of parallel speedup are lost: \begin{enumerate} \item It is no longer necessarily true that the speedup of the parallel code on one processor is unity. It may be, but only by chance. \item It is no longer true that the maximum speedup using $p$-processors is $p$. \item Because of the last item, efficiency figures computed as speedup divided by $p$ are no longer a meaningful measure of processor utilization. \end{enumerate} There are other difficulties with this formulation of speedup. If we use $T_1$ as the run time on a very fast single processor (currently, say, a Cray C90 or a NEC SX-3), then manufacturers of highly parallel systems will be reluctant to quote the speedup of their system in the above way. For example, if the speedup of a 100 processor parallel system over a single node of the same system is a respectable factor of 80, it is likely that the speedup computed from the ``standard'' $T_1$ would be reduced to 10 or less. This is because a fast vector processor is typically at least ten times faster than the RISC processors used in many highly parallel systems of a comparable generation. Thus it appears that if one sharpens the definition of speedup to make it an acceptable metric for comparing the performance of different computers, one has to throw away the main properties that have made the concept of speedup useful in the past. Accordingly, the ParkBench committee has decided the following [DHB's suggestion]: \begin{enumerate} \item No speedup statistic will be kept in the ParkBench database. \item Speedup statistics based on ParkBench benchmarks must never be used as figures of merit when comparing the performance of different systems. We further recommend that speedup figures based on other benchmarks not be used as figures of merit in such comparisons. \item Speedup statistics may be used in a study of the performance characteristics of an individual parallel system. But the basis for the determination of $T_1$ must be clearly and explicitly stated. \item The value of $T_1$ should be based on an efficient uniprocessor implementation. Code for message passing, synchronization, etc. should not be present. The author should also make a reasonable effort to insure that the algorithm used in the uniprocessor implementation is the best practical serial algorithm for this purpose. \item Given that a large problem frequently does not fit on a single node, it is permissible to cite speedup statistics based on the timing of a smaller number of nodes. In other words, it is permissible to compute speedup as $T_p / T_m$, for some $m, \; 1 < m < p$. If this is done, however, this usage must be clearly stated, and full details of the basis of this calculation must be presented. As above, care must be taken to insure that the unit timing $T_m$ is based on an efficient implementation of appropriate algorithms. \end{enumerate} \section{Performance Database} \begin{verbatim} It was agreed that this subsection be redrafted by Jack Dongarra. - -------------------------- START OLD TEXT --------------------------------- \end{verbatim} \input{pds.tex} \begin{verbatim} - --------------------------- END OLD TEXT --------------------------------- - ---------------------- SOME PROPOSED NEW TEXT ---------------------------- \end{verbatim} At present each benchmark measurement for a particular problem size $N$ and processor number $p$, is represented by one line in the database with variable length fields chosen by the benchmark writer as suitable and comprehensive to describe the conditions of the benchmark run. The fields separated by a marker include, benchmarkers name and e-mail, computer location and date, hardware specification, compiler date and optimisation level, $N$, $p$, $T(N,p)$, $R_B(N,P)$ and other metrics as deemed appropriate by the benchmark writer. Ideally, the line for the database would be produced automatically as output by the benchmark program itself. \begin{verbatim} - ---------------------- END PROPOSED NEW TEXT ---------------------------- \end{verbatim} \section{Interactive Graphical Interface} The Southampton Group has agreed to provide an interactive graphical front end to the ParkBench~ database of performance results. To achieve this, the basic data held in the Performance Data Base should be values of $T(N;p)$ for at least 4 values of problem size $N$, each for sufficient $p$-values (say 5 to 10) to determine the trend of variation of performance with number of processors for constant problem size. It is important that there be enough $p$-values to see Amdahl saturation, if present, or any peak in performance followed by degradation. A graphical interface is really essential to allow this multidimensional data to be viewed in any of the metrics defined above, as chosen interactively by the user. The user could also be offered (by suitable interpolation) a display of the results in various scaled metrics, in which the problem size is expanded with the number of processors. In order to encompass as wide a range of performance and number of processors as possible, a log-scale on both axes is unavoidable, and the format and scale range should be kept fixed as long as possible to enable easy comparison between graphs. A three-cycle by three-cycle log-log graph with range 1 to 1000 in both $p$ and Mflop/s would cover most needs in the immediate future. Examples of such graphs are to be found in \cite{Hoc92,Add93}. A log/log graph is also desirable because the size and shape of the Amdahl saturation curve is the same wherever it is plotted on such a graph. That is to say there is a universal Amdahl curve that is invariant to its position on any log/log graph. Amdahl saturation is a two-parameter description of any of the performance metrics, $R$, as a function of $p$ for fixed $N$, which can be expressed by \begin{equation} R = \frac{R_\infty}{(1 + \phalf/p)} \end{equation} where $R_\infty$ is the saturation performance approached as $p \rightarrow \infty$ and \phalf is the number of processors required to reach half the saturation performance. The graphical interface should allow this universal Amdahl curve to be moved around the graphical display, and be matched against the performance curves. The changing values of the two parameters \Rphalf should be displayed as the Amdahl curve is moved. As more experience is gained with performance analysis, that is to say the fitting of performance data to parametrised formulae, it is to be expected that the graphical interface will allow more complicated formulae to be compared with the experimental data, perhaps allowing 3 to 5 parameters in the theoretical formula. But, as yet, we do not know what these for parametrised formula should be. \section{Benchmarking Procedure and Code Optimisation} Manufacturers will always feel that any benchmark not tuned specifically by themselves, is an unfair test of their hardware and software. This is inevitable and from their viewpoint it is true. NASA have overcome this problem by only specifying the problems (the NAS paper-and-pencil benchmarks \cite{naspar2}) and leaving the manufacturers to write the code, but in many circumstances this would require unjustifiable effort and take too long. It is also a perfectly valid question to ask how a particular parallel computer will perform on existing parallel code, and that is the viewpoint of ParkBench. The benchmarking procedure is to run the distributed ParkBench~ suite on an 'as-is' basis, making only such non-substantive changes that are required to make the code run (e.g. changing the names of header files to a local variant). The as-is run may use the highest level of automatic compiler optimisation that works, but the level used and compiler date should be noted in the appropriate section of the performance database entry. After completing the as-is run, which gives a base-line result, any form of optimisation may be applied to show the particular computer to its best advantage, up to completely rethinking the algorithm, and rewriting the code. The only requirement on the benchmarker is to state what has been done. However, remember that, even if the algorithm is changed, the official flop-count, $F_B(N)$ that is used in the calculation of nominal benchmark Mflop/s, $R_B(N,p)$, does not. In this way a better algorithm will show up with a higher $R_B$, as we would want it to, even though the hardware Mflop/s is likely to be little changed. Typical steps in optimisation might be: \begin{enumerate} \item explore the effect of different compiler optimisations on a single processor, and choose the best for the as-is run. \item perform the as-is run on multiple processors, using enough values of $p$ to determine any peak in performance or saturation. \item return to single processor and optimise code for vectorisation, if a vector processor is being used. This means restructuring loops to permit vectorisation. \item continue by replacement of selected loops with optimal assembly coded library routines (e.g. BLAS where appropriate). \item replacement of whole benchmark by a tuned library routine with the same functionality. \item replace whole benchmark with locally written version with the same functionality but using possibly an entirely different algorithm that is more suited to the architecture. \end{enumerate} % ---------------------------------------------------------------------------- ------- End of Forwarded Message From owner-parkbench-method@CS.UTK.EDU Fri Sep 8 16:37:32 1995 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA14461; Fri, 8 Sep 1995 16:37:32 -0400 Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA04711; Fri, 8 Sep 1995 16:37:50 -0400 X-Resent-To: parkbench-method@CS.UTK.EDU ; Fri, 8 Sep 1995 16:37:48 EDT Errors-to: owner-parkbench-method@CS.UTK.EDU Received: from franklin.seas.gwu.edu by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA04695; Fri, 8 Sep 1995 16:37:47 -0400 Received: from felix.seas.gwu.edu (abdullah@felix.seas.gwu.edu [128.164.9.3]) by franklin.seas.gwu.edu (v8) with ESMTP id QAA10248 for ; Fri, 8 Sep 1995 16:37:45 -0400 Received: (from abdullah@localhost) by felix.seas.gwu.edu (8.6.12/8.6.12) id QAA07221 for parkbench-method@cs.utk.edu; Fri, 8 Sep 1995 16:37:41 -0400 Date: Fri, 8 Sep 1995 16:37:41 -0400 From: Abdullah Meajil Message-Id: <199509082037.QAA07221@felix.seas.gwu.edu> To: parkbench-method@CS.UTK.EDU Subject: subscribe subscribe From owner-parkbench-method@CS.UTK.EDU Fri Sep 8 16:38:32 1995 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA14473; Fri, 8 Sep 1995 16:38:32 -0400 Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA04768; Fri, 8 Sep 1995 16:38:51 -0400 X-Resent-To: parkbench-method@CS.UTK.EDU ; Fri, 8 Sep 1995 16:38:50 EDT Errors-to: owner-parkbench-method@CS.UTK.EDU Received: from franklin.seas.gwu.edu by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA04759; Fri, 8 Sep 1995 16:38:48 -0400 Received: from felix.seas.gwu.edu (abdullah@felix.seas.gwu.edu [128.164.9.3]) by franklin.seas.gwu.edu (v8) with ESMTP id QAA10342 for ; Fri, 8 Sep 1995 16:38:43 -0400 Received: (from abdullah@localhost) by felix.seas.gwu.edu (8.6.12/8.6.12) id QAA07361 for parkbench-method@cs.utk.edu; Fri, 8 Sep 1995 16:38:40 -0400 Date: Fri, 8 Sep 1995 16:38:40 -0400 From: Abdullah Meajil Message-Id: <199509082038.QAA07361@felix.seas.gwu.edu> To: parkbench-method@CS.UTK.EDU Subject: subscribe subscribe From sgreen@cs.utk.edu Mon Sep 11 13:37:57 1995 Return-Path: Received: from dancer.cs.utk.edu by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id NAA27033; Mon, 11 Sep 1995 13:37:56 -0400 From: Received: by dancer.cs.utk.edu (cf v2.11c-UTK) id NAA04860; Mon, 11 Sep 1995 13:38:27 -0400 Date: Mon, 11 Sep 1995 13:38:27 -0400 Message-Id: <199509111738.NAA04860@dancer.cs.utk.edu> To: parkbench-method-archive@netlib2.cs.utk.edu Mon Sep 11 13:38:26 EDT 1995 From owner-parkbench-comm@CS.UTK.EDU Fri May 2 15:53:02 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id PAA00358; Fri, 2 May 1997 15:53:02 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA13341; Fri, 2 May 1997 15:44:43 -0400 Received: from blueberry.cs.utk.edu (BLUEBERRY.CS.UTK.EDU [128.169.92.34]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA13327; Fri, 2 May 1997 15:44:36 -0400 Received: by blueberry.cs.utk.edu (cf v2.11c-UTK) id TAA08348; Fri, 2 May 1997 19:44:04 GMT From: "Erich Strohmaier" Message-Id: <9705021544.ZM8346@blueberry.cs.utk.edu> Date: Fri, 2 May 1997 15:44:03 -0400 X-Face: ,v?vp%=2zU8m.23T00H*9+qjCVLwK{V3T{?1^Bua(Ud:|%?@D!~^v^hoA@Z5/*TU[RFq_n'n"}z{qhQ^Q3'Mexsxg0XW>+CbEOca91voac=P/w]>n_nS]V_ZL>XRSYWi:{MzalK9Hb^=B}Y*[x*MOX7R=*V}PI.HG~2 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: parkbench-comm@CS.UTK.EDU Subject: ParkBench Committee Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Dear Colleague, Here is the revised agenda. Please send me ASAP a short email if you come so that we can arrange for a meeting room. ------------------- The ParkBench (Parallel Benchmark Working Group) will meet in Knoxville, Tennessee on May 9th, 1997. The meeting site will be the Knoxville Downtown Hilton Hotel. We have made arrangements with the Hilton Hotel in Knoxville. Hilton Hotel 501 W. Church Street Knoxville, TN Phone: 423-523-2300 When making arrangements tell the hotel you are associated with the 'ParkBench'. The rate about $79.00/night. You can download a postscript map of the area by looking at http://www.netlib.org/utk/people/JackDongarra.html. ---------------- The tentative agenda for the meeting is: 1. Minutes of last meeting (MBe) Changes to Current release: 2. Low Level (ES, VG, RS) comms1, comms2, comms3, poly2 3. Linear Algebra (ES) 4. Compact Applications - NPBs (SS, ES) New benchmarks: 5. HPF Low Level benchmarks (MBa) 6. Java Low-Level Benchmarks (VG) 7. New I/O benchmark benchmarks (MBa) 8. New performance database design and new benchmark output format Update of GBIS with new Web front-end (MBa,TH) Report from other benchmark activities 9. ASCI Benchmark Codes (AH) 10. SPEC-HPG (RE, JD) ParkBench: 11. ParkBench Bibliography 12. ParkBench Report 2 Other Activities: 13. Discussion of the ParkBench Workshop 11/12 September, UK (TH, MBa) 14. PEMCS - "Electronic Benchmarking Journal" - status report - (TH, MBa) 15. Status of Funding proposals (JD, TH) 15. Miscellaneous - 16. Date and venue for next meeting - (MBa) Mark Baker Univ. of Portsmouth (MBe) Michael Berry Univ. of Tennessee (JD) Jack Dongarra Univ. of Tenn./ORNL (RE) Rudi Eigenmann SPEC (VG) Vladimir Getov Univ. of Westminister (TH) Tony Hey Univ. of Southampton (AH) Adolfy Hoisie LLNL (SS) Subhash Saini NASA Ames (RS) Ron Sercely HP/CXTC (ES) Erich Strohmaier Univ. of Tennessee Jack Dongarra Erich Strohmaier From owner-parkbench-comm@CS.UTK.EDU Tue May 6 14:46:45 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id OAA04480; Tue, 6 May 1997 14:46:45 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA25737; Tue, 6 May 1997 14:34:05 -0400 Received: from punt-2.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA25715; Tue, 6 May 1997 14:33:58 -0400 Received: from minnow.demon.co.uk ([158.152.73.63]) by punt-2.mail.demon.net id aa1000641; 6 May 97 19:07 BST Message-ID: Date: Tue, 6 May 1997 19:06:15 +0100 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: Parkbench Meeting Documents In-Reply-To: <9705021544.ZM8346@blueberry.cs.utk.edu> MIME-Version: 1.0 X-Mailer: Turnpike Version 3.01 AGENDA ITEM: > Changes to Current release: > 2. Low Level (VG) > comms1, comms2, Two documents will be submitted to the committee on this item by Roger Hockney and Vladimir Getov (Westminster University, UK). They can be downloaded as postscript files from: "New COMMS1 Benchmark: Results and Recommendations" http://www.minow.demon.co.uk/Pbench/comms1/PBPAPER2.PS "New COMMS1 Benchmark: The Details" http://www.minow.demon.co.uk/Pbench/comms1/PBPAPER3.PS The papers will be presented by Vladimir who will bring some paper copies with him. Best wishes Roger and Vladimir -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Tue May 6 17:54:47 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id RAA07526; Tue, 6 May 1997 17:54:46 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA17012; Tue, 6 May 1997 17:48:50 -0400 Received: from punt-1.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA17003; Tue, 6 May 1997 17:48:47 -0400 Received: from minnow.demon.co.uk ([158.152.73.63]) by punt-1.mail.demon.net id aa0623986; 6 May 97 21:37 BST Message-ID: Date: Tue, 6 May 1997 21:26:50 +0100 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: Parkbench Meeting Documents (Correction) MIME-Version: 1.0 X-Mailer: Turnpike Version 3.01 I am resending this because there was a typo in the URLs: There are two MM in "minnow". Also if you took PBPAPER2.PS before receiving this repeat message, please take it again as I have corrected two errors in the graphs. SORRY Roger ************************ AGENDA ITEM: > Changes to Current release: > 2. Low Level (VG) > comms1, comms2, Two documents will be submitted to the committee on this item by Roger Hockney and Vladimir Getov (Westminster University, UK). They can be downloaded as postscript files from: CORRECTED URLs: "New COMMS1 Benchmark: Results and Recommendations" http://www.minnow.demon.co.uk/Pbench/comms1/PBPAPER2.PS "New COMMS1 Benchmark: The Details" http://www.minnow.demon.co.uk/Pbench/comms1/PBPAPER3.PS The papers will be presented by Vladimir who will bring some paper copies with him. Best wishes Roger and Vladimir -- -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Mon May 12 05:36:41 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id FAA24086; Mon, 12 May 1997 05:36:41 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA10068; Mon, 12 May 1997 05:18:21 -0400 Received: from haven.EPM.ORNL.GOV (haven.epm.ornl.gov [134.167.12.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id FAA10051; Mon, 12 May 1997 05:18:18 -0400 Received: (from worley@localhost) by haven.EPM.ORNL.GOV (8.8.3/8.8.3) id FAA29262; Mon, 12 May 1997 05:18:16 -0400 (EDT) Date: Mon, 12 May 1997 05:18:16 -0400 (EDT) From: Pat Worley Message-Id: <199705120918.FAA29262@haven.EPM.ORNL.GOV> To: parkbench-comm@CS.UTK.EDU Subject: Gordon Conference on HPC and NII Forwarding: Mail from 'Tony Skjellum ' dated: Sat, 10 May 1997 16:32:12 -0500 (CDT) Cc: worley@haven.EPM.ORNL.GOV Just in case you haven't received information on this already, here is a blurb on the 1997 Gordon conference in high performance computing. Unlike previous years, there is not an explicit emphasis on performance evaluation in this year's stated themes, but you can't (shouldn't) discuss future architectures and their impacts without discussing how to evaluate performance, and I am hoping that some benchmarking-minded people will show up and keep the discussion honest. ---------- Begin Forwarded Message ---------- The deadline for applying to attend the 1997 Gordon conference in high performance computing is June 1. If you are interested in attending, please apply as soon as possible. The simplest way to apply is to download the application form from the web site indicated below, or to use the online registration option. If you have any problems with either of these, please contact the organizers at tony@cs.msstate.edu and worleyph@ornl.gov. ------------------------------------------------------------------------------- The 1997 Gordon Conference on High Performance Computing and Information Infrastructure: "Practical Revolutions in HPC and NII" Chair, Anthony Skjellum, Mississippi State University, tony@cs.msstate.edu, 601-325-8435 Co-Chair, Pat Worley, Oak Ridge National Laboratory, worleyph@ornl.gov, 615-574-3128 Conference web page: http://www.erc.msstate.edu/conferences/gordon97 July 13-17, 1997 Plymouth State College Plymouth NH The now bi-annual Gordon conference series in HPC and NII commenced in 1992 and has had its second meeting in 1995. The Gordon conferences are an elite series of conferences designed to advance the state-of-the-art in covered disciplines. Speakers are assured of anonymity and referencing presentations done at Gordon conferences is prohibited by conference rules in order to promote science, rather than publication lists. Previous meetings have had good international participation, and this is always encouraged. Experts, novices, and technically interested parties from other fields interested in HPC and NII are encouraged to apply to attend. All attendees, including speakers, poster presenters, and session chairs must apply to attend. We *strongly* encourage all poster presenters to have their poster proposals in by May 13, 1997, though we will consider poster presentations up to six weeks prior to the conference. Application to attend the conference is also six weeks in advance. More information on the conference can be found at the web page listed above, including the list of speakers and poster presenters and information on applying for attendance. ----------- End Forwarded Message ----------- From owner-parkbench-comm@CS.UTK.EDU Tue May 13 13:58:00 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id NAA20879; Tue, 13 May 1997 13:57:59 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA11997; Tue, 13 May 1997 13:33:14 -0400 Received: from timbuk.cray.com (timbuk-fddi.cray.com [128.162.8.102]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id NAA11983; Tue, 13 May 1997 13:33:10 -0400 Received: from ironwood.cray.com (root@ironwood-fddi.cray.com [128.162.21.36]) by timbuk.cray.com (8.8.5/CRI-gate-news-1.3) with ESMTP id MAA20939 for ; Tue, 13 May 1997 12:33:07 -0500 (CDT) Received: from magnet.cray.com (magnet [128.162.173.162]) by ironwood.cray.com (8.8.4/CRI-ironwood-news-1.0) with ESMTP id MAA16428 for ; Tue, 13 May 1997 12:33:06 -0500 (CDT) From: Charles Grassl Received: by magnet.cray.com (8.8.0/btd-b3) id RAA20181; Tue, 13 May 1997 17:33:04 GMT Message-Id: <199705131733.RAA20181@magnet.cray.com> Subject: Parkbench directions To: parkbench-comm@CS.UTK.EDU Date: Tue, 13 May 1997 12:33:04 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24-CRI-d] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: ParkBench Group From: Charles Grassl Date: May 13, 1997 (Long) I appreciated the meeting this past week and wish to thank Eric and Jack for hosting it. I am aware of the great effort of many individuals have contributed to developing and implementing the ParkBench suite. In spite of this, I feel that we need to evaluate and correct our course. ParkBench should not merge with or use benchmarks from the SPEC/HPG (High Performance Group) group. SGI/Cray and IBM have already withdrawn from the SPEC/HPG group and Fujitsu and NEC are no longer participating. The reasons for these companies and other institutions no longer participating should indicate to us (ParkBench) that something is amiss with the SPEC/HPG benchmarks and paradigm. Several of the reasons for the supercomputer manufacturers not supporting the SPEC/HPG effort are listed below. I list these reasons so that the ParkBench group can learn from them and avoid the same problems. - Relevance. The particular benchmark programs being used by SPEC/HPG are not relevant or appropriate for supercomputing. The programs in the current SPEC/HPG suite do not represent any leading edge software which is more typical of usage for high performance systems. - Redundancy. The programs being developed by SPEC/HPG are not qualitatively or quantitatively different from the SPEC/OSG programs and as such, it is viewed as redundant and expensive. - Methodology. The methodology being used by SPEC/HPG to procure, develop and run benchmarks lacks scientific and technical basis and hence results have a vague and arbitrary interpretation. - Programming model. Designing benchmarks for portability across systems is a convenient idea but does not reflect actual constraints or usage. More often than not, compatibility with a PREVIOUS model of computer is more important than compatibility ACROSS computers. - Expense. Some of the large data cases for the SPEC/HPG programs will requires hours or days to run with little new data or information gained by the exercise. These exercises are extremely expensive both in time and capital equipment and in logistics. - Ergonomics. The cumbersome design of SPEC/HPG Makefiles and build procedures make the programs difficult and expensive to test, maintain and analyze. We in the ParkBench group must acknowledge the above items if we are to maintain interest and participation from computer vendors. I believe that reorganizing and refocusing the group could revitalize high performance computer benchmarking and and re-invigorate the ParkBench group. As the ParkBench suite now stands, there are too many programs and they are difficult to build, test and maintain. This situation impedes usage and participation. Here are a few suggestions for our future practices and directions: - Design and write benchmarks programs. Don't borrow or solicit old code. The borrowed or solicited code is never quite appropriate and usually obsolete. Our greatest asset is that we have scientist who are capable of designing experiments (benchmarks). (Build value.) - Monitor and evaluate accuracy. Though we mention accuracy in ParkBench Report 1, we haven't applied it to the current programs (Scientifically validate, or invalidate, our experiments.) - Make it simple. Write and develop simple programs which do not need elaborate build procedures and which easier to test and to maintain. (Keep It Simple, Stupid.) - Build a better user interface. The belabored "run rules" and the interface with layers of Makefiles, includes and embedded relative file paths is unacceptable. An acceptable interface might require binary distribution and hence a desirable emphasis on designing and running rather than building and porting the benchmarks. (Make the product more attractive to more users.) - Make the suite truly modular. The current structure makes the simplest one CPU program as difficult to build and run as the most complicated program with Makefile includes, special compilers, source file includes, special libraries, suite libraries, etc. (Make it manageable.) - Drop the connection with SPEC/HPG and with NPB. This "grand unifying" scheme make redundant code. It has had the opposite effect of focusing benchmarking attention on ParkBench because it is yet another collection of benchmarks used by other organizations. (Be distinguishable and identifiable.) - Emphasis what ParkBench is associated with: benchmarking distributed memory parallel computers. We should write and develop benchmark programs which measure and instrument the parallel processing aspect of MPP systems. (Keep our focus.) I volunteer to develop and write a suite of message passing test programs which measure the performance and variance of message passing communication schemes. I have much experience with writing such a programs and believe that such suite would be useful for others and for the computer industry in general. I hesitate to contribute such programs to the present structure for several reasons: - The network test suite does not logically fit into the current "hierarchy" and hence might further clutter the ParkBench suite and make it further unfocused. - The current ParkBench structure is not manageable. Testing and maintenance would be extremely expensive in the current structure. - My company's effort may be interpreted as an endorsement of the current structure and model. The suite is not popular with vendors for reasons outlined above. Participation is currently discouraged. Discussion? Regards, Charles Grassl SGI/Cray Eagan, Minnesota USA From owner-parkbench-comm@CS.UTK.EDU Wed May 21 17:25:15 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id RAA27513; Wed, 21 May 1997 17:25:15 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA07579; Wed, 21 May 1997 17:18:07 -0400 Received: from rastaman.rmt.utk.edu (root@TCHM11A6.RMT.UTK.EDU [128.169.27.188]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA07571; Wed, 21 May 1997 17:18:02 -0400 Received: from rastaman.rmt.utk.edu (localhost [127.0.0.1]) by rastaman.rmt.utk.edu (8.7.6/8.7.3) with SMTP id RAA01108; Wed, 21 May 1997 17:24:43 -0400 Sender: mucci@CS.UTK.EDU Message-ID: <3383681A.D98C5FB@cs.utk.edu> Date: Wed, 21 May 1997 17:24:42 -0400 From: "Philip J. Mucci" Organization: University of Tennessee, Knoxville X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: parkbench-comm@CS.UTK.EDU CC: "PVM Developer's Mailing List" Subject: Mesg Passing Benchmarks References: <199705131733.RAA20181@magnet.cray.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, Charles Grassl in his last message to this committee volunteered to write a suite of message passing benchmarks to replace the Low Levels...Before any action on his or this committee's part, I would recommend that you all have a look at version 3 of my pvmbench package. It now does MPI as well and can easily support other message passing primitives with a few #defines. Version 3 along with some sample results can be found at http://www.cs.utk.edu/~mucci/pvmbench. Note that this has not been tested on any MPP's with UTK PVM. This benchmark will generate and graph the following: bandwidth gap time (to buffer an outgoing message) roundtrip (latency /2) barrier/sec broadcast summation reduction Other tests can easily be added...I would highly recommend before any action done that this code be examined. It is less than a year old, version 3 available on that page is in beta, i.e. it has not been released to the general public. Let me know what you think... -Phil -- /%*\ Philip J. Mucci | GRA in CS under Dr. JJ Dongarra /*%\ \*%/ http://www.cs.utk.edu/~mucci PVM/Active Messages \%*/ From owner-parkbench-comm@CS.UTK.EDU Fri May 23 12:03:04 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA06549; Fri, 23 May 1997 12:03:03 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA15901; Fri, 23 May 1997 11:05:32 -0400 Received: from berry.cs.utk.edu (BERRY.CS.UTK.EDU [128.169.94.70]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id LAA15895; Fri, 23 May 1997 11:05:30 -0400 Received: from cs.utk.edu by berry.cs.utk.edu with ESMTP (cf v2.11c-UTK) id LAA01370; Fri, 23 May 1997 11:05:31 -0400 Message-Id: <199705231505.LAA01370@berry.cs.utk.edu> to: parkbench-comm@CS.UTK.EDU Subject: Minutes of May ParkBench Meeting Date: Fri, 23 May 1997 11:05:31 -0400 From: "Michael W. Berry" Here are the minutes from the recent ParkBench meeting in Knoxville. Best regards, Mike ----------------------------------------------------------------- Minutes of ParkBench Meeting - Knoxville Hilton, May 9, 1997 ----------------------------------------------------------------- ParkBench Attendee List: (MBa) Mark Baker Univ. of Portsmouth mab@sis.port.ac.uk (MBe) Michael Berry Univ. of Tennessee berry@cs.utk.edu Shirley Browne Univ. of Tennessee browne@cs.utk.edu (JD) Jack Dongarra Univ. of Tenn./ORNL dongarra@cs.utk.edu Jeff Durachta Army Res. Lab MSRC durachta@arl.mil (VG) Vladimir Getov Univ. of Westminister getovv@wmin.ac.uk (CG) Charles Grassl SGI/Cray cmg@cray.com (TH) Tony Hey Univ. of Southampton ajgh@ecs.soton.ac.uk (AH) Adolfy Hoisie Los Alamos Nat'l Lab hoisie@lanl.gov (CK) Charles Koelbel Rice University chk@cs.rice.edu (PM) Phil Mucci Univ. of Tennessee mucci@cs.utk.edu Erik Riedel GENIAS Software GmbH erik@genias.de (SS) Subhash Saini NASA Ames saini@nas.nasa.gov (RS) Ron Sercely HP-Convex sercely@convex.hp.com Alan Stagg CEWES stagga@wes.army.mil (ES) Erich Strohmaier Univ. of Tennessee erich@cs.utk.edu (PW) Pat Worley Oak Ridge Nat'l Lab worleyph@ornl.gov SPEC-HPG Visitors: Don Dossa DEC dossa@eng.pko.dec.com (RE) Rudi Eigenmann Purdue University eigenman@ecn.purdue.edu Greg Gaertner DEC ggg@zko.dec.com Jean Suplick HP suplick@rsn.hp.com Joe Throp Kuck & Associates throp@kai.com At 9:05am EST, TH opened the meeting and ask that all the attendees introduce themselves. After a brief overview of the proposed agenda, MBe reviewed the minutes from the last ParkBench meeting in October of '96. The minutes were unanimously accepted and TH asked VG to present the proposed changes to the low-level benchmarks (9:20am). VG reviewed the original COMMS1 (ping-pong or simplex communication) and the COMMS2 (duplex communication) low-level benchmarks. He discussed some of the problems with the previous versions. These included the omission of calculated bandwidth, large message length problems, and large errors in the asymptotic fit. In collaboration with RS and CG, a number of improvements have been made to these benchmarks: 1. Measured bandwidth is provided in output. 2. Time for shortest message is provided. 3. Maximum measured bandwidth and the corresponding message length is now provided. 4. The accuracy of the least-squares 2-parameter fit has been improved (sum of squares of the "relative" and not absolute error is now used). 5. New 3-parameter variable-power fit for certain cases added. 6. Can report parametric fits if the error is less than some user-specified tolerance. 7. Introduce KDIAG parameter to invoke diagnostic outputs. 8. Modifications fo ESTCOM.f (as suggested by RS). CG pointed out that it may not always be possible to interpret zero-length messages for these codes. On the Cray machines, such messages force an immediate return (i.e., no synchronization). He proposed that allowing zero- length messages be removed for the COMMS benchmarks. RS showed an actual COMMS1 performance graph demonstrating the difficulty of data extrapolation (if used to get latency for zero-length message-passing). RS pointed out, however, that zero-length message are defined w/in MPI, and suggested that a simple return (as in the case of Cray machines) is not standard. VG displayed some of the observed COMMS1/2 performance obtained on the Cray T3E. The 3-parameter fit yielded a 7% relative error for messages ranging from 8 to 1.E+7 bytes. CG questioned how the breakpoints were determined? He indicated the input parameters to the program required previous knowledge of where breakpoints occur (although implementations could change constantly). TH suggested that the parametric fitting should not be the default for these benchmarks, i.e., separate the analysis from the actual benchmarking (this concept was seconded by CG). RS suggested that the fitting routines could be placed on the WWW/Internet and the COMMS1/2 codes simply produce data. CK, however, stressed that the codes should maintain some minimal parametric fitting for clarity and consistency of output interpretations. The minimal message length shown for the T3E results shown by VG was 8 and the corresponding minimal message length for a Convex CXD set of COMMS benchmarks was 1. The lack of similar ranges of messages could pose problems for comparisons. JD strongly felt that users will return to the notion of "latency" and want zero-length message overheads. Users may be primarily interested in start-up time for message-passing. RS pointed out that MPI does process zero-length messages. JD suggested that the minimal message length for the COMMS benchmarks be 8 bytes and RS proposed that the minimal message-passing time and corresp. message length be an output. After more discussion, the following COMMS changes/outputs were unanimously agreed upon: 1. Maximum bandwidth with corresp. message size. 2. Minimum message-passing time with corresp. message size. 3. Time for minimum message length (could be 0, 1, 8, or 32 bytes but must be specified). 4. The software will be split into two program: one to report the spot measurements and the other for the analysis. At 10:00 am, SPEC-HPG members joined the ParkBench meeting for a joint session. CK reviewed the DoD Modernization Program. He indicated that the program is based on 3 primary components: 1. CHSSI (Commonly Highly Scalable Software Initiative) 2. DREN (Defense Research & Engineering Network) 3. Shared Resource Centers (4 Major Shared Resource Centers or MSRC's and 20 Distributed Centers or DC's) Benchmarking is part of the mission of the MSRC's, especially for system integration and the Programming Environment & Training (PET) team. CK mentioned that the resources available at the MSRC's include: 256-proc. Cray T3E, SGI Power Challenge (CEWES), 256 proc. IBM SP/2 and SGI Origin 2000 at ASC, SGI 790 at NAVO, and a collection of {SGI Origin, Cray Titan, J90} at the Army Research Lab. The benchmarking needs of the DoD program can be categorized as either contractual or training. The contractual needs are specified as PL1 (evaluation of initial machines), PL2 (upgrade to gain 3 times the performance of PL1), and PL3 (upgrade to gain 10 times the performance of PL1). CK mentioned that the MSRC's are planning for the PL2 phase later this year with PL3 scheduled in approx. 3 years. The training needs include: the evaluation of programming paradigms, the evaluation of performance trade-offs, templates for designing new codes, and benchmarks for training examples. The contractual benchmarks comprise 30 benchmarks (22 programs) some of which are export-controlled or proprietary (data may not be used in the public domain in some cases). The run rules specify the number of iterations for each benchmark in the suite. Each MSRC uses a different number of iterations per benchmark. Code modifications are allowed (parallel directives and message-passing can be used but no assembler) and algorithm substitutions are permitted provided the problem does not become specialized. The only performance metric reported for these benchmarks is the elapsed time for the entire suite. Benchmarks can be upgraded to reflect current workloads of the MSRCs but they must be compared head-to-head with previous systems. Example codes included in the DoD benchmark suite include: CTH (finite volume shock simulation), X3D (explicit finite element code), OCEAN-O2 (an ocean modeling code), NIKE3D (implicit nonlinear 3D FEM), and Aggregate I/O benchmark. Planned benchmarking activites for the DoD Modernization Program include: 1. benchmarks for evaluating programming techniques (determine what works; develop decision trees) 2. benchmarks for teaching (classes on "worked" examples; template modification) This effort currently has 1 FTE and over 50 University personnel (in PET program) involved (although they are not primarily responsible for benchmarking work). At 10:35am, TH asked AH from Los Alamos Nat'l Lab to overview their ASCI benchmark suite. He began by pointing out that these codes formulate the "Los Alamos set of" ASCI Benchmarks. Before presenting the list of codes, AH noted that the philosophy of this activity was to achieve "experiment ahead" capability especially with immature computing platforms. Los Alamos is also interested in developing performance modes as well as kernels. The list of active/research codes and compact applications comprising this suite are: Code Language(s) Parallelism Description *HEAT(RAGE) f77, f90 MPI(f90) Eulerian adaptive mesh MPIfSM(f77) refinement based on Riemann solvers; coupled physics-CFD; particle & radiative transport EULER f90 MPI Admissable fluid (for SIMD); SIMD(SP unstructured mesh, explicit vector) solution; high-speed fluids; SP=single processor NEUT f77 MPI,SM, Monte-Carlo, particle SHMEM SWEEP3D f90 MPI, SHMEM Inner/outer iteration (kernel) (compact application) HYDRO(T) f77 Serial (compact application) TBON f77 MPI Material science; quantum mechanics; polymer age simulation *TECOLOTE C++ MPI Mixed call hydro. with regular structured grid *TELURIDE f90 MPI Casting simulation; irregular structured grid; Krylov solution methods *DANTE HPF MPI * = export controlled The codes and compact apps above vary in size from 2,000 to 35,000 lines. AK noted that LANL could provide support for future ASCI-based ParkBench codes. The ASCI benchmark suite presented might include in the future tri-lab (Livermore, Sandia, Los Alamos) contributions. The ASCI application suite can be set up with data sets leading to varying run-times. AH mentioned that Los Alamos' ASCI benchmarking efforts are focused on high performance computing, leading edge architectures, algorithms, and applications. They are particularly concentrating in developing expertise in distributed shared-memory performance evaluation and modeling. AH expressed the hope that the efforts of ParkBench will follow similar directions. At 11:05am, SS reviewed some of the most recent NAS Parallel Benchmarks results. He began with vendor-optimized CG Class B results using row and column distribution blocking. Results for different numbers of processors of the T3D were reported along with results for the NEC SX-4, SGI Origin 2K, Convex SPP2K, Fujitsu VPP700, and IBM P2SC. He also showed results for FT Class B and BT Class B (all machines reported performed well on this benchmark). For BT, it was pointed out that 4 of the machines (Cray T3E, DEC Alpha, IBM P2SC, and NEC SX-4) essentially are based on the same processor but achieve widely-varying results. SS also reported HPF Class A MG results on 16 processors of the IBM SP2. The HPF version (APR-HPF/Portland Group compiled) was only 3 times slower than the MPI-based (f77) implementation. This is indeed a significant result given that two years ago the HPF version was as much as 10 times slower than the comparable MPI version. An HPF version of the Class A FT benchmark on 64 processors was shown to be faster than the MPI version (1.6 times faster) when optimized libraries are used in both versions. For the Class A SP benchmark (on 64 processors of the SP/2), the APR- and PGI-compiled HPF versions were within a factor of 2 of the MPI versions. Finally, the HPF Class A BT code on 64 processors of the Cray T3D was within a factor of 0.5 of the MPI version. At 11:35am, TH invited RE to overview current SPEC-HPG activities. The SPEC-HPG benchmarks define a suite of real-world high-performance computing applications designed for comparisons across different platforms (serial and message- passing). RE pointed out the history of the SPEC-HPG effort as a merger between the PERFECT and SPEC benchmarking activities. The current SPEC-HPG suite is comprised of 2 codes: SPECchem96 and SPECseis96. The SPECchem96 code evolved from the GAMES code used in pharmaceutical and chemical industries. It comprises 109,389 lines of f77 (21% comments), 865 subroutines and functions. The wave functions are written to disk. The SPECseis96 code is derived from the ARCO benchmark suite which consists of four phases: data generation, stack data, time migration, and depth migration. This code decomposes the domain into n equal parts (for n processors) with each part processed independently. It is have over 15K lines of code made up of 230 Fortran subroutines and 199 C functions for I/O and systems utilities. SPECseis96 uses 32-bit precision, FFT's, Kirchoff integrals, and finite differences. The very first set of SPEC-HPG benchmark results were approved on May 8, 1997 (preceding day). New benchmarks being considered are PMD (Parallel Molecular Dynamics) and MM5 (NCAR Weather Processing C code). The decision on whether or not to accept these two potential SPEC-HPG codes will be made in about 5 months. The SPEC-HPG run rules permit the use of compiler switches, source code changes, optimized libraries (which have been disclosed to customers). Only approved algorithmic changes will be disclosed. RE gave the URL for the SPEC-HPG effort: http://www.specbench.org/hpg. He also referred to a recent article by himself and S. Hassanzadeh in "IEEE Computational Science & Engineering" and two email reflectors for SPEC-HPG communication: comments@specbench.org and info@specbench.org. JD then gave a brief history of ParkBench and SPEC-HPG interactions and suggested that the two efforts might consider sharing results and software. The biggest difference in the two efforts is in the availability of software as ParkBench code is freely available and SPEC-HPG software has some restrictions. A forum to publish both sets of results was discussed and it was agreed that both efforts should at least share links on their respective webpages. RE pointed out that anyone can get the SPEC-HPG CD of benchmarks without actually being a SPEC member. JD stressed that the process of running codes (for any suite) needs to be simplified so that building executables for different platforms is not problematic. Modifications for porting should be restricted to driver programs. RS indicated that he has Perl scripts that runs all low_level, including COMMS3 for 2 to N procs, and produces a summary of the results. *** ACTION ITEM *** JD, RE, AH, and CK will discuss a potential joint effort to simplify the running of benchmark codes (contact RS also about his Perl scripts). MBa noted that the SPEC-HPG members should be added to the ParkBench email list (parkbench-comm@cs.utk.edu). He also indicated that European benchmarking workshop scheduled next Fall might coordinate with the European SPEC group (scheduled for Sept. 11-12). At 12:10pm, the attendees went to the lunch (Soup Kitchen). After lunch (1:30pm), TH asked ES and VG to coordinate changes to the COMMS benchmarks discussed above (*** ACTION ITEM ***). ES then discussed modifications to poly2 for the ParkBench V2.2 suite. The proposed changes include 1. enlarged arrays A(1000000), B(1000000) 2. removal of arrays C and D 3. avoid cache flush (use a sliding vector), i.e., DO I=1,N DO I=NMIN,NMAX becomes ... NMIN=NMIN+N+INC where INC=17 by default (avoids reuse of the old cache line). PM then discussed a program for determining parameters for memory subsystems. Characteristics of this software include the use of tight loops, independent memory references, maximized register use. He showed graphs of memory hierarchy bandwidth (reads and writes) depicting memory size (ranging from 4Kb to 4Mb) versus Mb/sec transfer rates. Some curves illustrated the effective cache size quite well. PM pointed out that dynamically-scheduled processors pose a significant problem for this type of modeling. The program can be run with or without a calibration loop exploiting known memory transfer data. CG suggested that it would be nice to have such a program to measure latency at all levels of the hierarchy. PM's webpages for this program are: http://www.cs.utk.edu/~mucci/cachebench and http://www.cs.utk.edu/~mucci/parkbench. CK suggested that an uncalibrated version of PM's benchmark would be more useful to users (more reflective of real codes). JD pointed out that the output of the program could be tabulated bandwidths, latencies, etc. CG felt this program would be a very useful tool. PM noted that the calibration will not be used by default. TH suggested that the ParkBench effort might want to develop a future "ParkBench Tool Set" which contains progams like this one developed by PM. With regard to the Linalg Kernels, ES noted that although many of the routines have calls to Scalapack routines, Scalapack will not be included in future software releases. Users will have to ge their own copies of the source (or binaries) for Scalapack. The size of these particular kernel benchmarks drops by a factor of one-third by removing Scalapack. *** ACTION ITEM *** ES will report the most recent Linalg benchmark performance results at the next ParkBench meeting. TH then asked for discussions on new benchmarks with MBa leading the discussion on HPF benchmarks. MBa indicated that a new mail reflector (parkbench-hpf@cs.utk.edu) had been set up for this cause with himself as moderator for low-level codes (CK will moderate kernels and SS will moderate discussions on HPF compact applications). MBa noted that there is limited manpower for the HPF benchmarking activities. CK noted that he had discussed this effort at recent the HPFF meeting (and other users meetings). A draft document on the ParkBench HPF benchmarks is available at http://www.sis.port.ac.uk/~mab/ParkBench. MBa felt strongly that without manpower support this particular activity will die and that a lead site is needed. *** ACTION ITEM *** CK and SS will investigate interest in HPF compact application development. JD indicated that wrappers are being used to create HPF versions of the Linalg kernels. The procedure involves writing wrappers for the current Scalapack driver programs. Eventually, these programs may be completely rewritten in HPF (this will start in the summer). TH suggested that HPF kernel benchmark performance be reported at the ParkBench meeting in September (at Southampton Performance Workshop). MBa went on to report on the status of I/O benchmarks. Basically, not much progress has been made on the ParkBench I/O initiative. A new I/O project between ECMWF, FECIT, and the Univ. of Southampton was launched this past February. They are looking at the I/O in the IFS code from the ECMWF (European Weather Forecasting). David Snelling is the FECIT leader who has also participated in ParkBench activities. This I/O project has 1 FTE at Southampton and 1.5 FTE at FECIT along with several personnel at ECMWF. One workshop, two technical meetings for the 1-year project is planned. The goals are: to develop instrumented I/O benchmarks and build on top of MPI-IO (test, characterize parallel systems). Their methodology is very similar to that of ParkBench. Codes in f90 and ANSI C are being considered (stubs for VAMPIR and PABLO). Regular reports to Fujitsu (sponsor of activity) are planned and a full I/O test suite is planned by February 1998. MBa also reported on the status of the ParkBench graphical database. Currently, the performance data is kept in a relational DBMS. A frontend Java applet has been written to query the DBMS on-the-fly. A backend is also in development which will automate the extraction of new performance data and insertion into the DBMS (via an http server). By September, a more complete prototype which will allow MS access and JDBC between 2 different machines should be ready. VG then discussed the development of Java-based low-level benchmarks. He presented a Java-to-C Interface Generator which would allow Java benchmarks to call existing C libraries on remote machines. He presented sample Java+C NAS PB results on a 16-processor IBM SP/2 (Class A IS Benchmark): Version 1 Proc 2Procs 4 Procs 8 Procs 16 Procs NASA (C) 29.1 17.4 9.4 5.2 2.8 C 40.5 24.9 13.1 9.3 15.6 Java ---- 132.5 64.7 37.9 33.5 At 2:50pm, TH reported other ParkBench activities including the new PEMCS (Performance Evaluation and Modeling for Computer Systems) electronic journal. Suggested articles/authors include: *1. ParkBench Report No. 2 (ES, MBe) *2. NAS PB 3. SPEC-HPG *4. Top 500 5. AutoBench (M. Ginsburg) *6. Euroben (van der Steen) 7. RAPS 8. Europort *9. Cache benchmarks 10. ASCI benchmarks (DoD) *11. PERFORM 12. R. Hockney *13. PEPS 14. C3I/Rome Labs Those articles possible for Summer '97 are marked via *. JD suggested that articles be available in Encapsulated Postscript, PDF (Adobe), and HTML. TH noted that EU funding will provide a host computer and some administration. Possible publishers are Oxford Univ. Press and Elsevier. At 3:10pm, ES requested more items for the ParkBench bibliography which will be available on the WWW. PW suggested that authors should be able to submit links to ParkBench-related applications. JD then briefly discussed WebBench which is a website focused on benchmarking and performance evaluation. Data is presented on platform,s applications, organizations, vendors, conferences, papers, newsgroups, FAQ's, and repositories (PDS, Top500, Linpack, etc.). The WebBench URL is http://www.netlib.org/benchweb. MBa reminded attendees of the Fall Performance Workshop/ParkBench meeting on (Thursday and Friday) Sept. 11 and 12. This meeting will be held at Venue, County Hotel, Southampton, UK. Invited and contributed talks will be presented. With regard to ParkBench funding, JD indicated that the UT/ORNL/NASA Ames proposal was not selected for funding but that it could be re- submitted next year. Expected funding from Rome lab was not received. TH and VG did not succeed this past year either although some funding from Fujitsu is possible. TH adjourned the meeting at 3:25pm EST. From owner-parkbench-comm@CS.UTK.EDU Tue May 27 10:32:45 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA25239; Tue, 27 May 1997 10:32:45 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA05022; Tue, 27 May 1997 10:12:02 -0400 Received: from exu.inf.puc-rio.br (exu.inf.puc-rio.br [139.82.16.3]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA05013; Tue, 27 May 1997 10:11:53 -0400 Received: from obaluae (obaluae.inf.puc-rio.br) by exu.inf.puc-rio.br (4.1/SMI-4.1) id AA20170; Tue, 27 May 97 11:11:00 EST From: maira@inf.puc-rio.br (Maira Tres Medina) Received: by obaluae (SMI-8.6/client-1.3) id LAA16226; Tue, 27 May 1997 11:10:58 -0300 Date: Tue, 27 May 1997 11:10:58 -0300 Message-Id: <199705271410.LAA16226@obaluae> To: parkbench-comments@CS.UTK.EDU Subject: Benchmarks Cc: parkbench-comm@CS.UTK.EDU, maira@CS.UTK.EDU, victal@CS.UTK.EDU X-Sun-Charset: US-ASCII Hello I'm a graduate student at the Computer Science Department of PUC-Rio (Catholic University of Rio de Janeiro). I'm currently studing Low_Level benchmarks for measuring basic computer characteristics. I have had same problems trying to run some of the benchmarks. For example, the benchmark comms1 for PVM, prints the following errors messages and stops. n05.sp1.lncc.br:/u/renata/maira/ParkBench/bin/RS6K>comms1_pvm Number of nodes = 2 Front End System (1=yes, 0=no) = 0 Spawning done by process (1=yes, 0=no) = 1 Spawned 0 processes OK... libpvm [t4000c]: pvm_mcast(): Bad parameter TIDs sent...benchmark progressing... n05.sp1.lncc.br:/u/renata/maira/ParkBench> bin/RS6K/comms1_pvm 1525-006 The OPEN request cannot be processed because STATUS=OLD was coded in the OPEN statement but the file comms1.dat does not exist. The program will continue if ERR= or IOSTAT= has been coded in the OPEN statement. 1525-099 Program is stopping because errors have occurred in an I/O request and ERR= or IOSTAT= was not coded in the I/O statement. I would like to know how I can execute the benchmarks only for PVM. Can you help me? I have not had problems with benchmarks sequentials (tick1, tick2 ...). Thank you very much for your attention. Maira Tres Medina Phd. Student Pontificial Catholic University Rio de Janeiro, Brazil From owner-parkbench-comm@CS.UTK.EDU Wed May 28 16:36:07 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA15377; Wed, 28 May 1997 16:36:06 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA16158; Wed, 28 May 1997 16:26:41 -0400 Received: from rastaman.rmt.utk.edu (root@TCHM03A16.RMT.UTK.EDU [128.169.27.60]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA16150; Wed, 28 May 1997 16:26:37 -0400 Received: from rastaman.rmt.utk.edu (localhost [127.0.0.1]) by rastaman.rmt.utk.edu (8.7.6/8.7.3) with SMTP id QAA00226; Wed, 28 May 1997 16:33:33 -0400 Sender: mucci@CS.UTK.EDU Message-ID: <338C968B.124F15AA@cs.utk.edu> Date: Wed, 28 May 1997 16:33:33 -0400 From: "Philip J. Mucci" Organization: University of Tennessee, Knoxville X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: Maira Tres Medina CC: parkbench-comments@CS.UTK.EDU, parkbench-comm@CS.UTK.EDU Subject: Re: Benchmarks References: <199705271410.LAA16226@obaluae> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You need to make sure the dat files are in the executable directory. They should be installed in $PVM_ROOT/bin/$PVM_ARCH. -Phil -- /%*\ Philip J. Mucci | GRA in CS under Dr. JJ Dongarra /*%\ \*%/ http://www.cs.utk.edu/~mucci PVM/Active Messages \%*/ From owner-parkbench-comm@CS.UTK.EDU Thu Jun 5 11:30:41 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id LAA11302; Thu, 5 Jun 1997 11:30:41 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA14227; Thu, 5 Jun 1997 10:53:09 -0400 Received: from haven.EPM.ORNL.GOV (haven.epm.ornl.gov [134.167.12.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id KAA14220; Thu, 5 Jun 1997 10:53:07 -0400 Received: (from worley@localhost) by haven.EPM.ORNL.GOV (8.8.3/8.8.3) id KAA06499; Thu, 5 Jun 1997 10:53:06 -0400 (EDT) Date: Thu, 5 Jun 1997 10:53:06 -0400 (EDT) From: Pat Worley Message-Id: <199706051453.KAA06499@haven.EPM.ORNL.GOV> To: parkbench-comm@CS.UTK.EDU Subject: Gordon conference deadline extended Forwarding: Mail from 'Pat Worley ' dated: Thu, 5 Jun 1997 10:48:07 -0400 (EDT) Cc: worley@haven.EPM.ORNL.GOV, tony@cs.msstate.edu (Our apologies if you receive this multiple times.) There is still room for additional attendees at the Gordon Conference on High Performance Computing, and the Gordon Research Conference administration has agreed to extend the application deadline. As a practical matter, applications need to be submitted no later than JULY 1. We will also stop accepting applications before that date if the maximum meeting size is reached, so please apply as soon as possible if you are interested in attending. The simplest way to apply is to download the application form from the web site http://www.erc.msstate.edu/conferences/gordon97 or to use the online registration option available at the same site. If you have any problems with either of these, please contact the organizers at tony@cs.msstate.edu and worleyph@ornl.gov. Complete information on the meeting is available from the Web site or its links, but a short summary of the meeting follows: -------------------------------------------------------------------------- The 1997 Gordon Conference on High Performance Computing and Information Infrastructure: "Practical Revolutions in HPC and NII" Chair, Anthony Skjellum, Mississippi State University, tony@cs.msstate.edu, 601-325-8435 Co-Chair, Pat Worley, Oak Ridge National Laboratory, worleyph@ornl.gov, 615-574-3128 Conference web page: http://www.erc.msstate.edu/conferences/gordon97 July 13-17, 1997 Plymouth State College Plymouth NH The now bi-annual Gordon conference series in HPC and NII commenced in 1992 and has had its second meeting in 1995. The Gordon conferences are an elite series of conferences designed to advance the state-of-the-art in covered disciplines. Speakers are assured of anonymity and referencing presentations done at Gordon conferences is prohibited by conference rules in order to promote science, rather than publication lists. Previous meetings have had good international participation, and this is always encouraged. Experts, novices, and technically interested parties from other fields interested in HPC and NII are encouraged to apply to attend. The conference consists of technical sessions in the morning and evening, with afternoons free for discussion and recreation. Each session consists of 2 or 3 one hour talks, with ample time for questions and discussion. All speakers are invited and there are no parallel sessions. All attendees are both encouraged and expected to actively participate, via discussions during the technical sessions or via poster presentations. All attendees, including speakers, poster presenters, and session chairs, must apply to attend. Poster presenters should indicate their poster proposals on their applications. While all posters must be approved, successful applicants should assume that their posters have been accpeted unless they hear otherwise. Meeting Themes: Networks: Emerging capabilities and the practical implications : New types of networking Real-Time Issues Multilevel Multicomputers Processors-in-Memory and Other Fine Grain Computational Architectures Impact of Evolving Hardware on Applications Impact of Software Abstractions on Performance Confirmed Speakers: Ashok K. Agrawala University of Maryland Kirstie Bellman DARPA/SISTO James C. Browne University of Texas at Austin Andrew Chien University of Illiniois, Urbana-Champaign Thomas H. Cormen Dartmouth College Jean-Dominique Decotignie CSEM David Greenberg Sandia National Laboratories William Gropp Argonne National Laboratory Don Heller Ames Laboratory Jeff Koller Information Sciences Institute Peter Kogge University of Notre Dame Chris Landauer The Aerospace Corporation Olaf M. Lubeck Los Alamos National Laboratory Andrew Lumsdaine University of Notre Dame Lenore Mullins SUNY, Albany Paul Plassmann Argonne National Laboratory Lui Sha Carnegie Mellon Univeristy Paul Woodward University of Minnesota From owner-parkbench-comm@CS.UTK.EDU Tue Jul 1 17:06:52 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id RAA20550; Tue, 1 Jul 1997 17:06:51 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA21503; Tue, 1 Jul 1997 17:03:35 -0400 Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA21438; Tue, 1 Jul 1997 17:02:42 -0400 Received: from baker (baker.npac.syr.edu) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA10168; Tue, 1 Jul 97 22:00:22 BST Date: Tue, 1 Jul 97 20:55:49 From: Mark Baker Subject: Fall 97 Parkbench Workshop - Southampton, UK To: ejz@ecs.soton.ac.uk, parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU, William Gropp , Antoine Hyaric , gent@genias.de, gcf@npac.syr.edu, geerd.hoffman@ecmwf.co.uk, reed@cs.uiuc.edu, david@cs.cf.ac.uk, clemens-august.thole@gmd.de, klaus.stueben@gmd.de, "J.C.T. Pool" , Paul Messina , foster@mcs.anl.gov, idh@soton.ac.uk, rjc@soton.ac.uk, plg@pac.soton.ac.uk, Graham.Nudd@dcs.warwick.ac.uk Cc: lec@ecs.soton.ac.uk, rjr@ecs.soton.ac.uk, "MATRAVERS Prof. D R STAF" , wilsona@sis.port.ac.uk, grant , hwyau@epcc.ed.ac.uk X-Priority: 3 (Normal) X-Mailer: Chameleon 5.0.1, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, This is to let you know that the Department of Electronics and Computer Science at the University of Southampton is organising a Fall 97 Parkbench Workshop on the 11th and 12th of September 1997. See http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/ for futher details. The workshop will include a number of talks from researchers working in th field of performance evaluation and modelling of computer systems, a panel discussion session and a Parkbench committee meeting. The Workshop is free to attend - workshop delegates need only cover their own travel and accommodation expenses. Attendance is limited and so the availability of places at the Workshop will be allocated on a first come basis. It is planned to turn the talks given at the Workshop into a series of short papers which will be put together and published as a Special Issue of the electronic journal Performance Evaluation and Modelling of Computer Systems (PEMCS). For further information or registration details refer to the Web pages - (http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/registration.html). I would appreciate it if you would kindly pass this email onto colleges who may be interested in the event. Regards Mark ------------------------------------- Dr Mark Baker CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 7/1/97 - Time: 8:55:49 PM URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Wed Jul 23 17:19:23 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id RAA04434; Wed, 23 Jul 1997 17:19:23 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA28191; Wed, 23 Jul 1997 17:10:39 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA28171; Wed, 23 Jul 1997 17:10:24 -0400 (EDT) Received: from baker (baker.npac.syr.edu) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA14190; Wed, 23 Jul 97 22:10:30 BST Date: Wed, 23 Jul 97 22:01:41 +0000 From: Mark Baker Subject: PEMCS Web Site To: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Face: "3@c]&iv:nfs&\mp6nN90ioxbQ-Eu:]}^MyviIL7YjwT,Cl)|TYpTQ})PP'&O=V`~)JQRWjM?H;'`q\"3mv "j@5vs)}!WC3pG9q:;rpe0\LoLQfY"1?1A.\(f=E*&QAW8WK+)*)T0[Bv=[{.-f7<6Ddv!2XaWhH X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, The Web site that will host the Journal of "Performance Evaluation and Modelling of Computer Systems (PEMCS)" can be found at: http://hpc-journals.ecs.soton.ac.uk/PEMCS/ The pages I have put up are at the present still in a "draft/under-construction" state. I would appreciate any comments or feedback about the pages. Regards Mark ------------------------------------- Dr Mark Baker DIS, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 07/23/97 - Time: 22:01:41 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Thu Jul 24 08:26:42 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA12708; Thu, 24 Jul 1997 08:26:42 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA04617; Thu, 24 Jul 1997 08:21:55 -0400 (EDT) Received: from berry.cs.utk.edu (BERRY.CS.UTK.EDU [128.169.94.70]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA04599; Thu, 24 Jul 1997 08:21:23 -0400 (EDT) Received: from cs.utk.edu by berry.cs.utk.edu with ESMTP (cf v2.11c-UTK) id IAA13817; Thu, 24 Jul 1997 08:21:24 -0400 Message-Id: <199707241221.IAA13817@berry.cs.utk.edu> To: Mark Baker cc: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU Subject: Re: PEMCS Web Site In-reply-to: Your message of Wed, 23 Jul 1997 22:01:41 -0000. Date: Thu, 24 Jul 1997 08:21:24 -0400 From: "Michael W. Berry" > Dear All, > > The Web site that will host the Journal of "Performance > Evaluation and Modelling of Computer Systems (PEMCS)" can > be found at: > > http://hpc-journals.ecs.soton.ac.uk/PEMCS/ > > The pages I have put up are at the present still in a > "draft/under-construction" state. > > I would appreciate any comments or feedback about the > pages. > > Regards > > Mark > > > > ------------------------------------- > Dr Mark Baker > DIS, University of Portsmouth, Hants, UK > Tel: +44 1705 844285 Fax: +44 1705 844006 > E-mail: mab@sis.port.ac.uk > Date: 07/23/97 - Time: 22:01:41 > URL http://www.sis.port.ac.uk/~mab/ > ------------------------------------- > Mark, the webpages are well organized. You might reconsider the red text on the green background of the menu frame. It was difficult to read on my machine at home. Nice work! Mike ------------------------------------------------------------------- Michael W. Berry Ayres Hall 114 berry@cs.utk.edu Department of Computer Science OFF:(423) 974-3838 University of Tennessee FAX:(423) 974-4404 Knoxville, TN 37996-1301 URL:http://www.cs.utk.edu/~berry/ ------------------------------------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Fri Aug 1 12:59:29 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA05831; Fri, 1 Aug 1997 12:59:27 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA01387; Fri, 1 Aug 1997 12:38:00 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA01337; Fri, 1 Aug 1997 12:37:24 -0400 (EDT) Received: from baker (baker.npac.syr.edu) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA15842; Fri, 1 Aug 97 17:36:11 BST Date: Fri, 1 Aug 97 17:17:51 +0000 From: Mark Baker Subject: Reminder - Fall Parkbench Workshop To: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Face: ,<'y31|nlb,jCP5?km9\KD+>p9/e?:|$RRhY]e;#`awGHh=mrY.T??#]-*rt}l0*u`k2A7n KlqNG"u'-%cS@3|G[%=m%bSB[lfSn5n"gD4CU(j?1y?#SOkm!qw_=p%c#"6g&(+\Oy6T{4CEShal?z M)&Gd'Pb6Qc~>SPx{m[F55=]yY>cN>|/m5)T?q`OTjdQL=7-n%NT({;;$P*2[#7ZWL8baLoI_/F89, x'u`*$'<|ctKNYTSJuLV=!$QT3bN*>91V,a0Cc"_UsxwMKg\;#W2LZ$!`j?ZWp;byz~;y}2Dz6i7y% E&;gfnmI_~}+oifmWXJMHfWeezBL1("ZnFe!rnX[Q|,:IJ?iq+PePa/[3R4 X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, This email is a reminder about the: ---------------------------------------------------------------------------------------------------- Fall ParkBench Workshop Thursday 11th/Friday 12th September 1997 at the University of Southampton, UK See http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/ ---------------------------------------------------------------------------------------------------- If you are interested in attending the Workshop you should register now and reserve accommodation as hotel rooms in Southampton during the workshop period will be in short supply due to the "International Southampton Boat Show" which will also be taking place. At present we have a preliminary reservation on rooms at the County Hotel where the Workshop is being held. Without concrete delegate reservations we can only hold onto there rooms for approximately another week. Thereafter, accommodation at the Hotel, or around the city, may be more problematic in getting and reserving. So, I encourage potential Workshop delegates to register ASAP. Mark ------------------------------------- Dr Mark Baker University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 08/01/97 - Time: 17:17:52 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Mon Aug 11 13:13:12 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id NAA20171; Mon, 11 Aug 1997 13:13:11 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA06842; Mon, 11 Aug 1997 13:02:59 -0400 (EDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA06808; Mon, 11 Aug 1997 13:02:42 -0400 (EDT) Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA27349; Mon, 11 Aug 97 13:02:14 EDT Received: from HOCKEY.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA01161; Mon, 11 Aug 97 13:02:12 EDT Message-Id: <9708111702.AA01161@MIT.MIT.EDU> X-Sender: mmccarth@po9.mit.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Aug 1997 13:02:12 -0400 To: alison.wall@rl.ac.uk, weber@scripps.edu, schauser@cs.ucsb.edu, dewombl@sandia.gov, edgorha@sandia.gov, rdskocy@sandia.gov, sales@pgroup.com, utpds@CS.UTK.EDU, parkbench-comm@CS.UTK.EDU, pancake@cs.orst.edu, johnreed@ghost.CS.ORST.EDU, levesque@apri.com, davida@cit.gu.edu.au, gddt@gup.uni-linz.ac.at, atempt@gup.uni-linz.ac.at, rileyba@ornl.gov, bac@ccs.ornl.gov From: "Michael F. McCarthy" Subject: For Sale: CM-5 PLEASE FORWARD THIS NOTE TO ANYONE THAT YOU BELIEVE MAY HAVE AN INTEREST IN PURCHASING THIS SYSTEM! __________________________________________________________________________ Case #3971 -- FOR SALE - CM5 with 128 nodes and SDA -- __________________________________________________________________________ The MIT Lab for Computer Science offers for bid sale a Thinking Machines CM-5 Connection Machine (described below). Bids to purchase this system are requested from all interested parties, (with a minimum expected Bid of $25,000). All bids must be received at the MIT property office by 5:00 PM (EDT) on Monday, 8/Sept/97. The machine must be moved from MIT within 10 business days of acceptance of the bid. All expenses and arrangements for moving will be made by purchaser. The system consists of: 1) 128 PN CM-5 w/ Vector Units, 256 Network addresses-Part No.CM5-128V-32F 2) Scalable Disk Array with Twenty-four(24) 1.2 GB Drives-Part No.CM5-SA25F 3) Control Processor Interface-Part No. CM5-CPI 4) S-Bus to Diagnostics Network Interface-Part No. CM5-SDN 5) S-Bus Network Interface Board(5)-Part No. CM5-SNI [N.B. On July 16 1997 power was turned off.The machine can be turned back on in its present location only until Friday, 22/AUG/97 when wiring changes are planned in that machine room.] "The Institute reserves the right to reject any or all offers.MIT makes no warranty of any kind, express or implied, with respect to this equipment. This includes fitness for a particular purpose. It is the responsibility of those making an offer to determine, before making an offer, that the equipment meets any conditions required by those making that offer.Thank you." __________________________________________________________________________ Submit bids for Case #3971 before Monday, 8/Sept/97, 5:00 PM (EDT) to: ***************************************************************** * Michael F. McCarthy * Phone: (617)253-2779 * * MIT Property Office * FAX: (617)253-2444 * * E19-429 * E-Mail: mmccarth@MIT.EDU * * 77 Massachusetts Ave. * * * Cambridge, MA 02139 * * ***************************************************************** __________________________________________________________________________ SYSTEM HISTORY The Project SCOUT CM-5 is housed in M.I.T's Laboratory for Computer Science (L.C.S). The machine was acquired in 1993 as part of the the ARPA sponsored project SCOUT, and used to accomplish the stated aim of the project of "fermenting collaborations between users, builders and networkers of massively parallel computers". The CM-5 computer, developed and manufactured by Thinking Machines Corporation, evolved from earlier T.M.C. computers (the CM-2 and the CM-200)with an architecture targeted toward teraflops performance for large, complex data intensive applications. The MIT hardware consists of a total of 128 32MHz SPARC microprocessors, each with 4 proprietary floating point arithmetic units and 32Mb of local memory attached to it. The system also includes a subsidiary 25Gb parallel file system for handling high volume parallel application I/O. The system was operated under full maintenance contract from May of 1993 until March 20 1997. On July 16 1997 power was turned off. The machine can be turned back on in its present location only until Friday, 22/AUG/97 when wiring changes are planned in that machine room. The system was used primarily for research but a description of an instructional use made of the machine can be found at http://www-erl.mit.edu/eaps/seminar/iap95/cnh/CM5Intro.html Web sites about other CM5 sites and general information include: http://www.math.uic.edu/~hanson/cmg.html http://www.acl.lanl.gov/UserInfo/cm5admin.html http://ec.msc.edu/CM5/ __________________________________________________________________________ FUTURE MAINTENANCE People submitting bids may wish to discuss future maintenance issues with a company that is a present maintainer of CM5 Equipment, Connection Machine Services. ***************************************************************** * Larry Stewart * Phone: (505) 820-1470 * * * Cell: (505) 690-7799 * * Account Executive * FAX: (505) 820-0810 * * Connection Machines Services * Home: (505) 983-9670 * * 1373 Camino Sin Salida * Pager (888) 712-4143 * * Santa Fe, NM 87501 * E-Mail: stewart@ix.netcom.com * ***************************************************************** __________________________________________________________________________ Michael F. McCarthy MIT Property Office E19-429 77 Massachusetts Ave. Cambridge, MA 02139 Ph (617)253-2779 Fax (617)253-2444 From owner-parkbench-comm@CS.UTK.EDU Mon Sep 1 05:44:50 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id FAA11838; Mon, 1 Sep 1997 05:44:50 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA07176; Mon, 1 Sep 1997 05:35:14 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA07160; Mon, 1 Sep 1997 05:34:44 -0400 (EDT) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA14311; Mon, 1 Sep 97 10:33:06 BST Date: Mon, 1 Sep 97 10:19:23 +0000 From: Mark Baker Subject: Final Announcement: Fall ParkBench Workshop To: "Daniel A. Reed" , "J.C.T. Pool" , a.j.grant@mcc.ac.uk, Antoine Hyaric , Ed Zaluska , Fritz Ferstl , Hon W Yau , idh@soton.ac.uk, parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU, Paul Messina , R.Rankin@Queens-Belfast.AC.UK, rjc@soton.ac.uk, topic@mcc.ac.uk, Wolfgang Genzsch Cc: lec@ecs.soton.ac.uk X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Face: ,<'y31|nlb,jCP5?km9\KD+>p9/e?:|$RRhY]e;#`awGHh=mrY.T??#]-*rt}l0*u`k2A7n KlqNG"u'-%cS@3|G[%=m%bSB[lfSn5n"gD4CU(j?1y?#SOkm!qw_=p%c#"6g&(+\Oy6T{4CEShal?z M)&Gd'Pb6Qc~>SPx{m[F55=]yY>cN>|/m5)T?q`OTjdQL=7-n%NT({;;$P*2[#7ZWL8baLoI_/F89, x'u`*$'<|ctKNYTSJuLV=!$QT3bN*>91V,a0Cc"_UsxwMKg\;#W2LZ$!`j?ZWp;byz~;y}2Dz6i7y% E&;gfnmI_~}+oifmWXJMHfWeezBL1("ZnFe!rnX[Q|,:IJ?iq+PePa/[3R4 X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all, This is the FINAL ANNOUNCEMENT: If you would like to attend this workshop please let Lesley Courtney (lec@ecs.soton.ac.uk) know by Friday 5th September 1997 at the latest as we need to confirm numbers. Workshop details can be found at http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/ Regards Mark ------------------------------------- Dr Mark Baker University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 09/01/97 - Time: 10:19:23 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Wed Sep 3 15:37:55 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id PAA20262; Wed, 3 Sep 1997 15:37:55 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA08273; Wed, 3 Sep 1997 15:19:14 -0400 (EDT) Received: from punt-2.mail.demon.net (punt-2b.mail.demon.net [194.217.242.6]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA08262; Wed, 3 Sep 1997 15:19:10 -0400 (EDT) Received: from minnow.demon.co.uk ([158.152.73.63]) by punt-2.mail.demon.net id aa0626941; 3 Sep 97 17:35 BST Message-ID: Date: Wed, 3 Sep 1997 16:31:07 +0100 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: Prototype PICT release 1.0 MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a At their last meeting the Parkbench Committee recommended that an interactive curve fitting tool be produced for the postprocessing and parametrisation of Parkbench results using the latest Internet Web technology. I have produced a prototype of such a tool as a Java applet running on a Web page on the user's machine and called it PICT (Parkbench Interactive Curve-fitting Tool). This is now ready for evaluation and testing by the committee. The tool provides the following features: (1) Automatic plotting of Low-Level Parkbench output files from a URL anywhere on the Web (At present limited to New COMMS1 and Raw data, but easily extended to original COMMS1 and RINF1). This is useful for a quick comparison of raw data. (2) Automatic plotting of both 2 and 3-parameter curve-fits which are produce by the benchmarks. Good for checking the quality of the fits. (3) Allows manual rescaling of the graph range to suit the data, either by typing in the required range values or by dragging out a range box with the mouse. (4) Allows the 2-parameter and 3-parameter performance curves to be manually moved about the graph in order to fine tune the fits. The curve follows the mouse and the RMS and MAX percentage errors are shown as the curve moves. Alternatively parameter values can be typed in and the Manual button pressed when the curve for these values will be plotted. (5) The data file being plotted can be VIEWed and a HELP button provides a description of the action of each button in a separate windows. The PICT applet has been built on top of Leigh Brookshaw's 2D plotting package the URL for which is given at the bottom of the HELP window. The features under the RESTART button are in his original code, I have just added the 2-PARA and 3-PARA features. The applet was developed using JDK1.0 beta on a PC with a 1600x1200 display and works on the PC both locally and from my Web page with appletview, MSIE 3.02 and Netscape 3.01. It has also been successfully run on a Solaris Sun with NS3.01, but another Sun user has reported no graphs and errors due to "wrong applet version". So please report your experiences (both success and failure please) to me with all the details. To play with PICT turn your browser to: http://www.minnow.demon.co.uk/pict/source/pict1.html or pict1a.html pict1.html asks for 1000x732 pixels and suits PCs best (it's about the minimum useful size). pict1a.html asks for 1020x900 pixels and was necessary for the whole applet to visible on the Sun. For those wishing to look closer all the source is provided and should be downloadable. Suggestions for improvement, corrections or constructive criticism are solicited. I have asked for an agenda item to be included for the Parkbench meeting on 11 Sept in Southampton so that PICT can be discussed. I look forward to seeing some of you there. -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-lowlevel@CS.UTK.EDU Wed Sep 10 06:29:15 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA21129; Wed, 10 Sep 1997 06:29:14 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA20815; Wed, 10 Sep 1997 06:31:30 -0400 (EDT) Received: from sun3.nsfnet-relay.ac.uk (sun3.nsfnet-relay.ac.uk [128.86.8.50]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id GAA20791; Wed, 10 Sep 1997 06:30:47 -0400 (EDT) Received: from bright.ecs.soton.ac.uk by sun3.nsfnet-relay.ac.uk with JANET SMTP (PP); Wed, 10 Sep 1997 11:30:44 +0100 Received: from landlord.ecs.soton.ac.uk by bright.ecs.soton.ac.uk; Wed, 10 Sep 97 11:32:57 BST From: Vladimir Getov Received: from bill.ecs.soton.ac.uk by landlord.ecs.soton.ac.uk; Wed, 10 Sep 97 11:33:16 BST Date: Wed, 10 Sep 97 11:33:13 BST Message-Id: <2458.9709101033@bill.ecs.soton.ac.uk> To: parkbench-lowlevel@CS.UTK.EDU, parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU Subject: ParkBench Committee Meeting - tentative Agenda Dear Colleague, The ParkBench (Parallel Benchmark Working Group) will meet in Southampton, U.K. on September 11th, 1997 as part of the ParkBench Workshop. The Workshop site will be the County Hotel in Southampton. County Hotel Highfield Lane Southampton, U.K. Phone: +44-(0)1703-359955 Please send us your comments about the tentative agenda: 14:30 Finalize meeting agenda Minutes of last meeting (Erich Strohmaier) 14:45 Changes to Current release: - Low Level COMMS benchmarks (Vladimir Getov) - NAS Parallel Benchmarks (Subhash Saini) 15:15 New benchmarks: - HPF Low Level benchmarks (Mark Baker) 15:30 ParkBench Performance Analysis Tools: - ParkBench Result Templates (Vladimir Getov and Mark Papiani) - Visualization of Parallel Benchmark Results - new GBIS (Mark Papiani and Flavio Bergamaschi) - Interactive Web-page Curve-fitting of Parallel Performance Measurements (Roger Hockney) 16:15 Demonstrations: - Java Low-Level Benchmarks (Vladimir Getov) - BenchView: Java Tool for Visualization of Parallel Benchmark Results (Mark Papiani and Flavio Bergamaschi) - PICT: An Interactive Web-page Curve-fitting Tool (Roger Hockney) 16:45 Other activities: - "Electronic Benchmarking Journal" - status report (Mark Baker) Miscellaneous Date and venue for next meeting 17:00 Adjourn Tony Hey Vladimir Getov Erich Strohmaier From owner-parkbench-comm@CS.UTK.EDU Wed Sep 10 06:40:25 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA21186; Wed, 10 Sep 1997 06:40:25 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA20806; Wed, 10 Sep 1997 06:31:06 -0400 (EDT) Received: from sun3.nsfnet-relay.ac.uk (sun3.nsfnet-relay.ac.uk [128.86.8.50]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id GAA20791; Wed, 10 Sep 1997 06:30:47 -0400 (EDT) Received: from bright.ecs.soton.ac.uk by sun3.nsfnet-relay.ac.uk with JANET SMTP (PP); Wed, 10 Sep 1997 11:30:44 +0100 Received: from landlord.ecs.soton.ac.uk by bright.ecs.soton.ac.uk; Wed, 10 Sep 97 11:32:57 BST From: Vladimir Getov Received: from bill.ecs.soton.ac.uk by landlord.ecs.soton.ac.uk; Wed, 10 Sep 97 11:33:16 BST Date: Wed, 10 Sep 97 11:33:13 BST Message-Id: <2458.9709101033@bill.ecs.soton.ac.uk> To: parkbench-lowlevel@CS.UTK.EDU, parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU Subject: ParkBench Committee Meeting - tentative Agenda Dear Colleague, The ParkBench (Parallel Benchmark Working Group) will meet in Southampton, U.K. on September 11th, 1997 as part of the ParkBench Workshop. The Workshop site will be the County Hotel in Southampton. County Hotel Highfield Lane Southampton, U.K. Phone: +44-(0)1703-359955 Please send us your comments about the tentative agenda: 14:30 Finalize meeting agenda Minutes of last meeting (Erich Strohmaier) 14:45 Changes to Current release: - Low Level COMMS benchmarks (Vladimir Getov) - NAS Parallel Benchmarks (Subhash Saini) 15:15 New benchmarks: - HPF Low Level benchmarks (Mark Baker) 15:30 ParkBench Performance Analysis Tools: - ParkBench Result Templates (Vladimir Getov and Mark Papiani) - Visualization of Parallel Benchmark Results - new GBIS (Mark Papiani and Flavio Bergamaschi) - Interactive Web-page Curve-fitting of Parallel Performance Measurements (Roger Hockney) 16:15 Demonstrations: - Java Low-Level Benchmarks (Vladimir Getov) - BenchView: Java Tool for Visualization of Parallel Benchmark Results (Mark Papiani and Flavio Bergamaschi) - PICT: An Interactive Web-page Curve-fitting Tool (Roger Hockney) 16:45 Other activities: - "Electronic Benchmarking Journal" - status report (Mark Baker) Miscellaneous Date and venue for next meeting 17:00 Adjourn Tony Hey Vladimir Getov Erich Strohmaier From owner-parkbench-lowlevel@CS.UTK.EDU Thu Sep 18 18:27:19 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id SAA12991; Thu, 18 Sep 1997 18:27:18 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA29359; Thu, 18 Sep 1997 18:26:21 -0400 (EDT) Received: from k2.llnl.gov (zosel@k2.llnl.gov [134.9.1.1]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id SAA29352; Thu, 18 Sep 1997 18:26:19 -0400 (EDT) Received: (from zosel@localhost) by k2.llnl.gov (8.8.5/8.8.5/LLNL-Jun96) id PAA07246 for parkbench-lowlevel@cs.utk.edu; Thu, 18 Sep 1997 15:26:16 -0700 (PDT) Date: Thu, 18 Sep 1997 15:26:16 -0700 (PDT) From: Mary E Zosel Message-Id: <199709182226.PAA07246@k2.llnl.gov> To: parkbench-lowlevel@CS.UTK.EDU Subject: any pthreads tests??? Does anyone know of any low-level performance tests for pthreads libraries??? I'm interested in both single processor performance of pthreads calls - and also multiprocessor (shared memory) calls ... to measure the overhead of the calls. -mary zosel- zosel@llnl.gov From owner-parkbench-lowlevel@CS.UTK.EDU Sun Sep 21 09:13:20 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id JAA08699; Sun, 21 Sep 1997 09:13:20 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA15884; Sun, 21 Sep 1997 09:15:32 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA15877; Sun, 21 Sep 1997 09:15:30 -0400 (EDT) Received: from mordillo (p41.ascend3.is2.bb.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA10322; Sun, 21 Sep 97 14:15:58 BST Date: Sun, 21 Sep 97 13:32:56 +0000 From: Mark Baker Subject: Re: any pthreads tests??? To: Mary E Zosel , parkbench-lowlevel@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199709182226.PAA07246@k2.llnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mary, This has been talked about as one of the activities that Parkbench would be interested in persuing. But, so far we have not had the time or man-power to follow up our interests. Ron Sercely at HP/CTCX was particularly interested in this area. Also, I know the people at Manchester University wrote a bunch of Pthreads codes - some were benchmarks - for their KSR machine. Hope this helps. Regards Mark --- On Thu, 18 Sep 1997 15:26:16 -0700 (PDT) Mary E Zosel wrote: > Does anyone know of any low-level performance tests for pthreads libraries??? > I'm interested in both single processor performance of pthreads calls - > and also multiprocessor (shared memory) calls ... to measure the overhead > of the calls. > -mary zosel- zosel@llnl.gov > ---------------End of Original Message----------------- ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 09/21/97 - Time: 13:32:57 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Wed Sep 24 06:04:19 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA23913; Wed, 24 Sep 1997 06:04:18 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA23163; Wed, 24 Sep 1997 05:46:35 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA23156; Wed, 24 Sep 1997 05:46:26 -0400 (EDT) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA29780; Wed, 24 Sep 97 10:47:01 BST Date: Wed, 24 Sep 97 10:38:39 +0000 From: Mark Baker Subject: PC timers To: parkbench-comm@CS.UTK.EDU, parkbench-low-level@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Can someone suggest the appropriate PC-based timer function (MS Visual C++ or Digital Visual Fortran) to replace the usual gettimeofday call !? Cheers Mark ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 09/24/97 - Time: 10:38:39 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Thu Sep 25 10:11:01 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA20147; Thu, 25 Sep 1997 10:11:01 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA18087; Thu, 25 Sep 1997 09:24:56 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA18080; Thu, 25 Sep 1997 09:24:53 -0400 (EDT) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA12457; Thu, 25 Sep 97 14:25:35 BST Date: Thu, 25 Sep 97 14:11:59 +0000 From: Mark Baker Subject: PC Time function To: parkbench-comm@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks to all for timer info. I used the C function _ftime() in the end because it had millisec resolution. Just had to get a my head around using INTERFACE in F90 to include the external C function. I've inserted my version of the _ftime() timer below - I don't think there are any obvious error in it :-) I also implemented the dflib F90 function CALL GETTIM(hour, min, sec, hund) - this function passed tick2 testing but only has 1/100 sec resolution. ------------------------------------------------------- double dwalltime00() { struct _timeb timebuf; _ftime( &timebuf ); return (double) timebuf.time + (double) timebuf.millitm / 1000.0; } double dwalltime00_() { return dwalltime00(); } double DWALLTIME00() { return dwalltime00(); } ------------------------------------------------------- Cheers Mark ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 09/25/97 - Time: 14:11:59 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Tue Oct 7 06:35:04 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA26560; Tue, 7 Oct 1997 06:35:04 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA25697; Tue, 7 Oct 1997 06:10:11 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA25668; Tue, 7 Oct 1997 06:09:40 -0400 (EDT) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA05125; Tue, 7 Oct 97 11:09:53 BST Date: Tue, 7 Oct 97 10:43:49 +0000 From: Mark Baker Subject: Workshop Papers To: "Aad J. van der Steen" , Charles Grassl , Clemens Thole , David Snelling , Erich Strohmaier , Grapham Nudd , Klaus Stueben , parkbench-comm@CS.UTK.EDU, Roger Hockney , Saini Subhash , Vladimir Getov , William Gropp X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, I am now back in the office and have a small amount of time to follow up the Parkbench Workshop that took place a few weeks ago. I would firstly like to thanks everyone who attended - especially all the speakers. Even though we did not attract hundreds of delegates to the workshop, I think the event was very successful - but I may be bias... So, the plans are that in the first instance I will collect the slides from all the speaker and package them up and put them on the PEMCS Web site. We also decided that we would encourage all the speaker to produce short papers on their talks and put all the workshop paper together to create a special issue the the PEMCES journal. Can the speakers therefore send me their slides (I would prefer powerpoint or word version if possible). I will harrass you further about a short papers in the near future. Thanks in advance for your help. Regards Mark ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 10/07/97 - Time: 10:43:49 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Sun Oct 12 09:55:57 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id JAA28908; Sun, 12 Oct 1997 09:55:57 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA08800; Sun, 12 Oct 1997 09:44:23 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA08793; Sun, 12 Oct 1997 09:44:20 -0400 (EDT) Received: from mordillo (p26.nas4.is2.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA11347; Sun, 12 Oct 97 14:45:07 BST Date: Sun, 12 Oct 97 14:35:10 +0000 From: Mark Baker Subject: Equivalent to comms1 To: parkbench-comm@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Can someone point me at the equivalant of comms1 written in C - either MPI or sockets (or even PVM if its out there). Cheers Mark ------------------------------------- Dr Mark Baker CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 10/12/97 - Time: 14:35:10 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Mon Oct 13 16:30:04 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA17020; Mon, 13 Oct 1997 16:29:59 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA24297; Mon, 13 Oct 1997 16:02:05 -0400 (EDT) Received: from dancer.cs.utk.edu (DANCER.CS.UTK.EDU [128.169.92.77]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA24288; Mon, 13 Oct 1997 16:02:03 -0400 (EDT) From: Philip Mucci Received: by dancer.cs.utk.edu (cf v2.11c-UTK) id QAA02925; Mon, 13 Oct 1997 16:02:00 -0400 Date: Mon, 13 Oct 1997 16:02:00 -0400 Message-Id: <199710132002.QAA02925@dancer.cs.utk.edu> To: mab@sis.port.ac.uk, parkbench-comm@CS.UTK.EDU Subject: Re: Equivalent to comms1 In-Reply-To: X-Mailer: [XMailTool v3.1.2b] I would check out my mpbench on my web page.... It does PVM and MPI for now... > Can someone point me at the equivalant of comms1 written in > C - either MPI or sockets (or even PVM if its out there). > > Cheers > > Mark > > > ------------------------------------- > Dr Mark Baker > CSM, University of Portsmouth, Hants, UK > Tel: +44 1705 844285 Fax: +44 1705 844006 > E-mail: mab@sis.port.ac.uk > Date: 10/12/97 - Time: 14:35:10 > URL http://www.sis.port.ac.uk/~mab/ > ------------------------------------- > /%*\ Philip J. Mucci | GRA in CS under Dr. JJ Dongarra /*%\ \*%/ http://www.cs.utk.edu/~mucci PVM/Active Messages \%*/ From owner-parkbench-comm@CS.UTK.EDU Mon Oct 20 10:37:14 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA15359; Mon, 20 Oct 1997 10:37:14 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA07990; Mon, 20 Oct 1997 10:19:41 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA07691; Mon, 20 Oct 1997 10:17:09 -0400 (EDT) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA16636; Mon, 20 Oct 97 15:17:33 BST Date: Mon, 20 Oct 97 15:02:39 +0000 From: Mark Baker Subject: PEMCS Short Article To: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, I've just put up (at last!!) the first PEMCES short article at http://hpc-journals.ecs.soton.ac.uk/PEMCS/Articles/ At the moment there is not much of a "house style" for the format of the papers and articles - this will hopefully be developed over the coming months. I expect to put the first full paper up on the Web in the next week or so. Comments, ideas and help with the journal and its Web site are most welcome. Regards Mark ------------------------------------------------------------------------------------------ COMPARING COMMUNICATION PERFORMANCE OF MPI ON THE CRAY RESEARCH T3E-600 AND IBM SP-2 1 by Glenn R. Luecke and James J. Coyle Iowa State University Ames, Iowa 50011-2251, USA Waqar ul Haque University of Northern British Columbia Prince George, British Columbia, Canada V2N 4Z9 Abstract This paper reports the performance of the Cray Research T3E and IBM SP-2 on a collection of communication tests that use MPI for the message passing. These tests have been designed to evaluate the performance of communication patterns that we feel are likely to occur in scientific programs. Communication tests were performed for messages of sizes 8 Bytes (B), 1 KB, 100 KB, and 10 MB with 2, 4, 8, 16, 32 and 64 processors. Both machines provided a high level of concurrency for the nearest neighbor communication tests and moderate concurrency on the broadcast operations. On the tests used, the T3E significantly outperformed the SP-2 with most performance tests being at least three times faster than the SP-2. ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 10/20/97 - Time: 15:02:42 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Sat Oct 25 08:52:33 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA12875; Sat, 25 Oct 1997 08:52:33 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA05256; Sat, 25 Oct 1997 08:41:15 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA05244; Sat, 25 Oct 1997 08:41:05 -0400 (EDT) Received: from mordillo (p16.nas2.is2.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA01764; Sat, 25 Oct 97 13:41:26 BST Date: Sat, 25 Oct 97 13:27:24 +0000 From: Mark Baker Subject: Parkbench Workshop Talks - On line To: Chuck Koelbel , Clemens Thole , Grapham Nudd , Guy Robinson , Klaus Stueben , parkbench-comm@CS.UTK.EDU, William Gropp X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 2 (High) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, I have put the talks received so far up at... http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/abstracts.html Please can the speakers who have not passed their talks onto me to do so. Thanks in advance. Regards Mark ------------------------------------- Dr Mark Baker CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 10/25/97 - Time: 13:27:25 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Fri Oct 31 08:22:47 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA19412; Fri, 31 Oct 1997 08:22:46 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA15140; Fri, 31 Oct 1997 07:44:09 -0500 (EST) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA15133; Fri, 31 Oct 1997 07:44:05 -0500 (EST) Received: from minnow.demon.co.uk ([158.152.73.63]) by post.mail.demon.net id aa2017784; 31 Oct 97 12:25 GMT Message-ID: Date: Fri, 31 Oct 1997 12:22:33 +0000 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: Announcing PICT2 MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a ANNOUNCING PICT2 ++++++++++++++++ The prototype Parkbench Interactive Curve Fitting Tool (PICT1) that was demonstrated at the Southampton meeting of Parkbench in September was difficult to use on small screens because the image was too large and could not be reduced in size to suit the users' screen size. Sorry, I had developed it on my own 1600x1200 display without realising that most users considered 800x600 as large! Well the new version PICT2 that is now on my web page allows for the full range of screen sizes: 640x480, 800x600, 1024x768, >=1600x1200, and also allows the user to customise his own display by selecting a font size and screen width and height. So the new version should be usable by all -- I hope! Another problem at Southampton was that the display workstation was very old and too slow in MHz to do the job. I use a P133 Pentium and the graphs lines move around instantly, but if you only have a 20MHz machine for example the response wil probably be too slow to be useful for real curve interactive fitting. There is nothing I can do about this except to suggest that you use the need to use PICT as an excuse (I mean justification) to upgrade your equipment. PICT2 still relies on the use of New COMMS1 to compute the least square 2-para fit and the 3-point fit fot the 3-para. The next step will be to put these features in PICT but that is a fair amount of code to get right and I thought it best to solve the screen-size problem first. But remember the key point about PICT is that it allows Interactive manual fitting and display that is not otherwise available. To try out PICT2 turn your browser to: http://www.minnow.demon.co.uk/pict/source/pict2a.html and follow the instructions. When you have a good PICT Frame displayed, press the HELP button for a description of the button actions. Please report problems, experiences (good and bad), suggestions to me at: roger@minnow.demon.co.uk I need feedback in order to improve the tool. Best wishes to you all Roger -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Tue Nov 11 06:21:05 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA18373; Tue, 11 Nov 1997 06:21:05 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA27963; Tue, 11 Nov 1997 06:06:45 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA27930; Tue, 11 Nov 1997 06:06:15 -0500 (EST) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA23083; Tue, 11 Nov 97 11:07:22 GMT Date: Tue, 11 Nov 97 11:00:36 GMT From: Mark Baker Subject: Couple of Announcements To: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A couple of announcements... Firstly, the majority of the papers presented at Fall ParkBench Workshop on Thursday 11th /Friday 12th September 1997 at the University of Southampton, are now on-line and can be found at... http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/abstracts.html or >From http://hpc-journals.ecs.soton.ac.uk/PEMCS/ and click on News in the left frame... Secondly, the first full paper for the electronic journal Performance Evaluation and Modelling of Computer Systems (PEMCS) "PERFORM - A Fast Simulator For Estimating Program Execution Time" By Alistair Dunlop and Tony Hey, Department Electronics and Computer Science University of Southampton Southampton, SO17 1BJ, U.K. Can be found at... http://hpc-journals.ecs.soton.ac.uk/PEMCS/Papers/vol1.html See you'll at the Parkbench BOF at SC'97... Mark ------------------------------------- Dr Mark Baker CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 11/11/97 - Time: 11:00:36 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-lowlevel@CS.UTK.EDU Wed Nov 12 21:30:42 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id VAA13985; Wed, 12 Nov 1997 21:30:42 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA06841; Wed, 12 Nov 1997 21:31:46 -0500 (EST) Received: from rudolph.cs.utk.edu (RUDOLPH.CS.UTK.EDU [128.169.92.87]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA06806; Wed, 12 Nov 1997 21:31:01 -0500 (EST) Received: from localhost by rudolph.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA24812; Wed, 12 Nov 1997 21:31:01 -0500 Date: Wed, 12 Nov 1997 21:31:00 -0500 (EST) From: Erich Strohmaier To: parkbench-hpf@CS.UTK.EDU, parkbench-lowlevel@CS.UTK.EDU, parkbench-comm@CS.UTK.EDU Subject: ParkBench BOF session at the SC'97 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Colleague, The ParkBench (PARallel Kernels and BENCHmarks) committee has organized a BOF session at the SC'97 in San Jose. Room: Convention Center Room C1 Time: Wednesday 5:30pm We will talk about the latest release, new results available and future plans. Tentative Agenda of the BOF - Introduction, background, WWW-Server - Current Release of ParkBench - Low Level Performance Evaluation Tools - LinAlg Kernel Benchmarks - NAS Parallel Benchmarks, including latest results - Plans for the next Release - Electronic Journal of Performance Evaluation and Modeling for Computer Systems - Questions from the floor / discussion Please mark your calendar and plan to attend. Jack Dongarra Tony Hey Erich Strohmaier From owner-parkbench-comm@CS.UTK.EDU Wed Nov 12 21:46:18 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id VAA14031; Wed, 12 Nov 1997 21:46:17 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA06813; Wed, 12 Nov 1997 21:31:03 -0500 (EST) Received: from rudolph.cs.utk.edu (RUDOLPH.CS.UTK.EDU [128.169.92.87]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA06806; Wed, 12 Nov 1997 21:31:01 -0500 (EST) Received: from localhost by rudolph.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA24812; Wed, 12 Nov 1997 21:31:01 -0500 Date: Wed, 12 Nov 1997 21:31:00 -0500 (EST) From: Erich Strohmaier To: parkbench-hpf@CS.UTK.EDU, parkbench-lowlevel@CS.UTK.EDU, parkbench-comm@CS.UTK.EDU Subject: ParkBench BOF session at the SC'97 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Colleague, The ParkBench (PARallel Kernels and BENCHmarks) committee has organized a BOF session at the SC'97 in San Jose. Room: Convention Center Room C1 Time: Wednesday 5:30pm We will talk about the latest release, new results available and future plans. Tentative Agenda of the BOF - Introduction, background, WWW-Server - Current Release of ParkBench - Low Level Performance Evaluation Tools - LinAlg Kernel Benchmarks - NAS Parallel Benchmarks, including latest results - Plans for the next Release - Electronic Journal of Performance Evaluation and Modeling for Computer Systems - Questions from the floor / discussion Please mark your calendar and plan to attend. Jack Dongarra Tony Hey Erich Strohmaier From owner-parkbench-lowlevel@CS.UTK.EDU Thu Nov 13 06:30:40 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA07097; Thu, 13 Nov 1997 06:30:40 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA01844; Thu, 13 Nov 1997 05:55:24 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA01835; Thu, 13 Nov 1997 05:55:18 -0500 (EST) Received: from mordillo (p19.nas2.is2.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA18430; Thu, 13 Nov 97 10:56:11 GMT Date: Thu, 13 Nov 97 10:48:53 GMT From: Mark Baker Subject: Fall 97 Parkbench Committee Meeting Minutes To: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU, parkbench-lowlevel@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="mordillo:879418490:877:126:21579" --mordillo:879418490:877:126:21579 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, Here are the minutes of the Parkbench committee meeting held The County Hotel in Southampton during the Fall 97 Parkbench Workshop. For those of you with a MIME-compliant mail-reader I've attached a formatted word 7 doc. Regards Mark ----------------------------------------------------------------------------- Parkbench Committee Meeting Held during the Fall Parkbench Workshop The County Hotel Southampton, UK 1515, 11th September 1997 Meeting Participation List: Mark Baker - Univ. of Portsmouth (mab@sis.port.ac.uk) Flavio Bergamaschi - Univ of Southampton (fab@ecs.soton.ac.uk) Jack Dongarra - Univ. of Tenn./ORNL (dongarra@cs.utk.edu) Vladimir Getov - Univ. of Westminister (getovv@wmin.ac.uk) Charles Grassl - SGI/Cray (cmg@cray.com) William Gropp - ANL (gropp@mcs.anl.gov) Tony Hey - Univ. of Southampton (ajgh@ecs.soton.ac.uk) Roger Hockney - Univ. of Westminister (roger@minnow.demon.co.uk) Mark Papiani - Univ of Southampton (mp@ecs.soton.ac.uk) Subhash Saini - NASA Ames (saini@nas.nasa.gov) Dave Snelling - FECIT (snelling@fecit.co.uk) Aad J. van der Steen - RUU (steen@fys.ruu.nl) Erich Strohmaier - Univ. of Tennessee (erich@cs.utk.edu) Klaus Stueben - GMD (klaus.stueben@gmd.de) Meeting Activities and Actions Tony Hey chaired the meeting. Minutes from last meeting were seven pages long and it was decided that only the actions from the last meeting would be reviewed. The actions from last meeting were reviewed - a short discussion about each took place. A discussion about interaction with SPEC-HPG was initiated. Comms Low-Level Benchmarks Vladimir Getov gave a short presentation on the current status of the Parkbench Comms benchmarks. Charles Grassl was asked to explained how his new Comms programs worked and the rationale behind it. A long discussion ensued. Action - Create a formal proposal of alternative or additions to the comms low-level benchmarks for SC'97 - Charles Grassl. Action - Members should look at the PALLAS version of the low-level benchmarks (based on Genesis/RAPS). Action - Erich Strohmaier and Vladimir Getov will discuss the efforts needed to split up Parkbench and add in the new Comms1 benchmark (with new curve fitting routine). NPB - Subhash Siani reported on the status of the NAS Parallel Benchmarks HPF - Mark Baker read Chuck Koebel's email about CEWES HPCM HPF efforts. Action - Subhash Siani will let RICE know that Gina should start of from the single NAS codes Electronic Journal - Mark Baker and Tony Hey reported on the electronic journal PEMCS and its Web site. It was agreed that this would be discussed further informally. Parkbench Report -Erich Strohmaier reported on the efforts of creating a new Parkbench report. A short discussion about this ensued. Action - Jack Dongarra /Tony Hey will talk to other members about the potential efforts that could be put into a Parkbench report II by SC'97. Funding Efforts Jack Dongarra's recent benchmarking proposal was turned down. Tony Hey mentioned the possibly of entering a proposal to the EU. Possibility of a joint EU / NSF bid. Mark Baker asked if SIO would be interested in being more closely involved. William Gropp reported that SIO was actually winding down and so formal association was not really an option. AOB The participants were then invited by Tony to move to the University of Southampton (bldg. 16) for the Parkbench demonstrations which included: -- Java Low-Level Benchmarks (Vladimir Getov) -- BenchView: Java Tool for Visualization of Parallel Benchmark Results (Mark Papiani and Flavio Bergamaschi) -- PICT: An Interactive Web-page Curve-fitting Tool (Roger Hockney) Jack Dongarra informed the committee of Parkbench BOF at SC'97 (Wednesday at 3.30PM). The meeting was wound up by Tony Hey at 1630. ----------------------------------------------------------------------------- ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 11/13/97 - Time: 10:48:53 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- --mordillo:879418490:877:126:21579 Content-Type: APPLICATION/msword; name="minutes-fall-97.doc" Content-Transfer-Encoding: BASE64 Content-Description: minutes-fall-97.doc 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAEQAAAAAAAAAAEAAAEgAAAAEAAAD+////AAAAABAAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////cpWgAY+AJBAAAAABlAAAAAAAAAAAAAAAAAwAA hxAAABAeAAAAAAAAAAAAAAAAAAAAAAAAhw0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABgAAGoAAAAAGAAAagAAAGoYAAAAAAAAahgAAAAA AABqGAAAAAAAAGoYAAAAAAAAahgAABQAAACkGAAAAAAAAKQYAAAAAAAApBgA AAAAAACkGAAAAAAAAKQYAAAAAAAApBgAAAoAAACuGAAAEAAAAKQYAAAAAAAA Eh0AAHwAAAC+GAAAAAAAAL4YAAAAAAAAvhgAAAAAAAC+GAAAAAAAAL4YAAAA AAAAvhgAAAAAAAC+GAAAAAAAAL4YAAAAAAAABxoAAAIAAAAJGgAAAAAAAAka AAAAAAAACRoAAEsAAABUGgAAUAEAAKQbAABQAQAA9BwAAB4AAACOHQAAWAAA AOYdAAAqAAAAEh0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAahgAAAAAAAC+GAAA AAAAAAAACQAKAAEAAgC+GAAAAAAAAL4YAAAAAAAAAAAAAAAAAAAAAAAAAAAA AL4YAAAAAAAAvhgAAAAAAAASHQAAAAAAANQYAAAAAAAAahgAAAAAAABqGAAA AAAAAL4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL4YAAAAAAAA1BgAAAAAAADU GAAAAAAAANQYAAAAAAAAvhgAABYAAABqGAAAAAAAAL4YAAAAAAAAahgAAAAA AAC+GAAAAAAAAAcaAAAAAAAAAAAAAAAAAAAQq9KCIvC8AX4YAAAOAAAAjBgA ABgAAABqGAAAAAAAAGoYAAAAAAAAahgAAAAAAABqGAAAAAAAAL4YAAAAAAAA BxoAAAAAAADUGAAAMwEAANQYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABQYXJrYmVuY2ggQ29tbWl0dGVlIE1lZXRp bmcNDUhlbGQgZHVyaW5nIHRoZSBGYWxsIFBhcmtiZW5jaCBXb3Jrc2hvcA0N VGhlIENvdW50eSBIb3RlbA0NU291dGhhbXB0b24sIFVLDQ0xNTE1LCAgMTF0 aCBTZXB0ZW1iZXIgMTk5Nw0NDU1lZXRpbmcgUGFydGljaXBhdGlvbiBMaXN0 Og0NTWFyayBCYWtlciAtIFVuaXYuIG9mIFBvcnRzbW91dGggKG1hYkBzaXMu cG9ydC5hYy51aykNRmxhdmlvIEJlcmdhbWFzY2hpICAtIFVuaXYgb2YgU291 dGhhbXB0b24gKGZhYkBlY3Muc290b24uYWMudWspDUphY2sgRG9uZ2FycmEg LSBVbml2LiBvZiBUZW5uLi9PUk5MIChkb25nYXJyYUBjcy51dGsuZWR1KQ1W bGFkaW1pciBHZXRvdiAgLSBVbml2LiBvZiBXZXN0bWluaXN0ZXIgKGdldG92 dkB3bWluLmFjLnVrKQ1DaGFybGVzIEdyYXNzbCAtIFNHSS9DcmF5IChjbWdA Y3JheS5jb20pDVdpbGxpYW0gR3JvcHAgLSBBTkwgKGdyb3BwQG1jcy5hbmwu Z292KQ1Ub255IEhleSAtIFVuaXYuIG9mIFNvdXRoYW1wdG9uIChhamdoQGVj cy5zb3Rvbi5hYy51aykNUm9nZXIgSG9ja25leSAtIFVuaXYuIG9mIFdlc3Rt aW5pc3RlciAocm9nZXJAbWlubm93LmRlbW9uLmNvLnVrKQ1NYXJrIFBhcGlh bmkgLSBVbml2IG9mIFNvdXRoYW1wdG9uIChtcEBlY3Muc290b24uYWMudWsp DVN1Ymhhc2ggU2FpbmkgLSBOQVNBIEFtZXMgKHNhaW5pQG5hcy5uYXNhLmdv dikNRGF2ZSBTbmVsbGluZyAtIEZFQ0lUIChzbmVsbGluZ0BmZWNpdC5jby51 aykNQWFkIEouIHZhbiBkZXIgU3RlZW4gIC0gUlVVIChzdGVlbkBmeXMucnV1 Lm5sKQ1FcmljaCBTdHJvaG1haWVyIC0gVW5pdi4gb2YgVGVubmVzc2VlIChl cmljaEBjcy51dGsuZWR1KQ1LbGF1cyBTdHVlYmVuIC0gR01EICAoa2xhdXMu c3R1ZWJlbkBnbWQuZGUpDQ1NZWV0aW5nIEFjdGl2aXRpZXMgYW5kIEFjdGlv bnMNDVRvbnkgSGV5IGNoYWlyZWQgdGhlIG1lZXRpbmcuDQ1NaW51dGVzIGZy b20gbGFzdCBtZWV0aW5nIHdlcmUgc2V2ZW4gcGFnZXMgbG9uZyBhbmQgaXQg d2FzIGRlY2lkZWQgdGhhdCBvbmx5IHRoZSBhY3Rpb25zIGZyb20gdGhlIGxh c3QgbWVldGluZyB3b3VsZCBiZSByZXZpZXdlZC4gVGhlIGFjdGlvbnMgZnJv bSBsYXN0IG1lZXRpbmcgd2VyZSByZXZpZXdlZCAtIGEgc2hvcnQgZGlzY3Vz c2lvbiBhYm91dCBlYWNoIHRvb2sgcGxhY2UuIEEgZGlzY3Vzc2lvbiBhYm91 dCBpbnRlcmFjdGlvbiB3aXRoIFNQRUMtSFBHIHdhcyBpbml0aWF0ZWQuDQ1D b21tcyBMb3ctTGV2ZWwgQmVuY2htYXJrcyANDVZsYWRpbWlyIEdldG92IGdh dmUgYSBzaG9ydCBwcmVzZW50YXRpb24gb24gdGhlIGN1cnJlbnQgc3RhdHVz IG9mIHRoZSBQYXJrYmVuY2ggQ29tbXMgYmVuY2htYXJrcy4gIENoYXJsZXMg R3Jhc3NsIHdhcyBhc2tlZCB0byBleHBsYWluZWQgaG93IGhpcyBuZXcgQ29t bXMgcHJvZ3JhbXMgd29ya2VkIGFuZCB0aGUgcmF0aW9uYWxlIGJlaGluZCBp dC4gDUEgbG9uZyBkaXNjdXNzaW9uIGVuc3VlZC4NDUFjdGlvbiAtIENyZWF0 ZSBhIGZvcm1hbCBwcm9wb3NhbCAgb2YgYWx0ZXJuYXRpdmUgb3IgYWRkaXRp b25zIHRvIHRoZSBjb21tcyBsb3ctbGV2ZWwgYmVuY2htYXJrcyBmb3IgU0OS OTcgLSBDaGFybGVzIEdyYXNzbC4NDUFjdGlvbiAtIE1lbWJlcnMgc2hvdWxk IGxvb2sgYXQgdGhlIFBBTExBUyB2ZXJzaW9uIG9mIHRoZSBsb3ctbGV2ZWwg YmVuY2htYXJrcyAoYmFzZWQgb24gR2VuZXNpcy9SQVBTKS4NDUFjdGlvbiAg LSBFcmljaCAgU3Ryb2htYWllciBhbmQgVmxhZGltaXIgR2V0b3Ygd2lsbCBk aXNjdXNzIHRoZSBlZmZvcnRzIG5lZWRlZCB0byBzcGxpdCB1cCBQYXJrYmVu Y2ggYW5kIGFkZCBpbiB0aGUgbmV3IENvbW1zMSBiZW5jaG1hcmsgKHdpdGgg bmV3IGN1cnZlIGZpdHRpbmcgcm91dGluZSkuDQ1OUEIgLSBTdWJoYXNoIFNp YW5pIHJlcG9ydGVkIG9uIHRoZSBzdGF0dXMgb2YgdGhlIE5BUyBQYXJhbGxl bCBCZW5jaG1hcmtzDQ1IUEYgLSBNYXJrIEJha2VyIHJlYWQgQ2h1Y2sgS29l YmVsknMgZW1haWwgYWJvdXQgQ0VXRVMgSFBDTSBIUEYgZWZmb3J0cy4NDUFj dGlvbiAtIFN1Ymhhc2ggU2lhbmkgd2lsbCBsZXQgUklDRSBrbm93IHRoYXQg R2luYSBzaG91bGQgc3RhcnQgb2YgZnJvbSB0aGUgc2luZ2xlIE5BUyBjb2Rl cw0NRWxlY3Ryb25pYyBKb3VybmFsIC0gTWFyayBCYWtlciBhbmQgVG9ueSBI ZXkgcmVwb3J0ZWQgb24gdGhlIGVsZWN0cm9uaWMgam91cm5hbCBQRU1DUyBh bmQgaXRzIFdlYiBzaXRlLiBJdCB3YXMgYWdyZWVkIHRoYXQgdGhpcyB3b3Vs ZCBiZSBkaXNjdXNzZWQgIGZ1cnRoZXIgaW5mb3JtYWxseS4NDVBhcmtiZW5j aCBSZXBvcnQgLUVyaWNoIFN0cm9obWFpZXIgcmVwb3J0ZWQgb24gdGhlIGVm Zm9ydHMgb2YgY3JlYXRpbmcgYSBuZXcgUGFya2JlbmNoIHJlcG9ydC4gQSBz aG9ydCBkaXNjdXNzaW9uIGFib3V0IHRoaXMgZW5zdWVkLg0NQWN0aW9uIC0g SmFjayBEb25nYXJyYSAvVG9ueSBIZXkgd2lsbCB0YWxrIHRvIG90aGVyIG1l bWJlcnMgYWJvdXQgdGhlIHBvdGVudGlhbCBlZmZvcnRzIHRoYXQgY291bGQg YmUgcHV0IGludG8gYSBQYXJrYmVuY2ggcmVwb3J0IElJIGJ5IFNDkjk3Lg0N RnVuZGluZyBFZmZvcnRzDQ1KYWNrIERvbmdhcnJhknMgcmVjZW50IGJlbmNo bWFya2luZyAgcHJvcG9zYWwgd2FzIHR1cm5lZCBkb3duLiBUb255IEhleSBt ZW50aW9uZWQgdGhlIHBvc3NpYmx5IG9mIGVudGVyaW5nIGEgcHJvcG9zYWwg dG8gdGhlIEVVLg1Qb3NzaWJpbGl0eSBvZiBhIGpvaW50IEVVIC8gTlNGIGJp ZC4NDU1hcmsgQmFrZXIgYXNrZWQgaWYgU0lPIHdvdWxkIGJlIGludGVyZXN0 ZWQgaW4gYmVpbmcgbW9yZSBjbG9zZWx5IGludm9sdmVkLiAgV2lsbGlhbSBH cm9wcCByZXBvcnRlZCB0aGF0IFNJTyB3YXMgYWN0dWFsbHkgd2luZGluZyBk b3duIGFuZCBzbyBmb3JtYWwgYXNzb2NpYXRpb24gd2FzIG5vdCByZWFsbHkg YW4gb3B0aW9uLg0NQU9CDQ1UaGUgcGFydGljaXBhbnRzIHdlcmUgdGhlbiBp bnZpdGVkIGJ5IFRvbnkgdG8gbW92ZSB0byB0aGUgVW5pdmVyc2l0eSBvZiBT b3V0aGFtcHRvbiAoYmxkZy4gMTYpIGZvciB0aGUgUGFya2JlbmNoIGRlbW9u c3RyYXRpb25zIHdoaWNoIGluY2x1ZGVkOg0NSmF2YSBMb3ctTGV2ZWwgQmVu Y2htYXJrcyAoVmxhZGltaXIgR2V0b3YpDUJlbmNoVmlldzogSmF2YSBUb29s IGZvciBWaXN1YWxpemF0aW9uIG9mIFBhcmFsbGVsIEJlbmNobWFyayBSZXN1 bHRzIChNYXJrIFBhcGlhbmkgYW5kIEZsYXZpbyBCZXJnYW1hc2NoaSkNUElD VDogQW4gSW50ZXJhY3RpdmUgV2ViLXBhZ2UgQ3VydmUtZml0dGluZyBUb29s IChSb2dlciBIb2NrbmV5KQ0NSmFjayBEb25nYXJyYSAgaW5mb3JtZWQgdGhl IGNvbW1pdHRlZSBvZiAgUGFya2JlbmNoIEJPRiBhdCBTQ5I5NyAoV2VkbmVz ZGF5IGF0IDMuMzBQTSkuDQ1UaGUgbWVldGluZyB3YXMgd291bmQgdXAgYnkg VG9ueSBIZXkgYXQgMTYzMC4NFQCk0C+l4D2mCAenCAeooAWpoAWqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAHQMAAGgD AAByAwAAdAMAAIYDAAChAwAAogMAAMUDAADXAwAABAQAABcEAAA+BAAAUQQA AHwEAACNBAAAqgQAALYEAADNBAAA3gQAAAEFAAAVBQAAPgUAAFYFAABvBQAA jgUAAKsFAAC9BQAA1gUAAOoFAAAJBgAAGQYAAEIGAABSBgAAagYAAH4GAACB BgAAoAYAANcHAADzBwAARAgAAEkIAACJCAAAjggAANgIAADeCAAAVgkAAFwJ AABeCQAAvwkAAMUJAAA3CgAAPQoAAGsKAABuCgAAtgoAALkKAAAACwAABgsA AF8LAABxCwAACAwAABgMAACODAAAlAwAAB4NAAAtDQAALg0AAJIOAACVDgAA hxAAAJ4QAAD79gD0APHvAO0A7QDtAO0A7QDrAO0A7QDtAO0A7QDtAO0A7QDm APEA7QDtAOMA4+EA4wDtAPEA8QDjAPEA8QDjAPHvAPEA3wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQACVoEABFWBVoEA CFWBXQMAYxgAAANdBQADXQQAA10DAAVVgV0DAAJoAQAIVYFdAwBjHAAACFWB XQMAYyQARwADAAAcAwAAHQMAAEUDAABGAwAAVwMAAFgDAABoAwAAaQMAAIQD AACFAwAAhgMAAKIDAACjAwAA2QMAABkEAABTBAAAjwQAALgEAADgBAAAFwUA AFgFAACQBQAAvwUAAOwFAAAbBgAAVAYAAIAGAACBBgAAoAYAAKEGAAC/BgAA wAYAANYHAADXBwAA8wcAAPQHAAC9CAAA1wgAANgIAAD9AAHAIaIB+gABwCGi Af0AAcAhRgH9AAHAIUYB/QABwCFGAf0AAcAhRgH9AAHAIUYB/QABwCHrAP0A AcAh6wD6AAHAIesA+gABwCHrAPoAAcAh6QD6AAHAIesA+gABwCHyAPoAAcAh 8gD6AAHAIfIA+gABwCHyAPoAAcAh8gD6AAHAIfIA+gABwCHyAPoAAcAh8gD6 AAHAIfIA+gABwCHyAPoAAcAh8gD6AAHAIfIA+gABwCHyANwAAcAh8gD6AAHA IesA+gABwCEWAfoAAcAh6wD6AAHAIesA+gABwCHrAPoAA8Ah6wD6AAHAIesA +gABwCHpAPoAAcAh6wD6AALAIfIA+gABwCHrAPoAAcAh6wAAAAAAAAAAHQAA BQMMNP8BAAgAAAEAAAABAGgBAAAAAAAAtwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgAABQMAAgAABQEn2AgAAFUJAABWCQAAvgkAAL8JAABq CgAAawoAALUKAAC2CgAA/woAAAALAABeCwAAXwsAAAcMAAAIDAAAjQwAAI4M AAAdDQAAHg0AAC4NAAAvDQAAsA0AANUNAADWDQAAkQ4AAJIOAACWDgAAlw4A ACcPAAAoDwAAUw8AAL4PAAD/DwAAABAAAFgQAABZEAAAhxAAAP0E/8Ah2QH9 AAHAIesA/QT/wCHZAf0AAcAh6wD9BP/AIeAB/QABwCHrAP0AAcAh7gD9AAHA IesA/QABwCHuAP0AAcAh6wD9AAHAIe4A/QABwCHrAP0E/8Ah2QH9AAHAIesA /QT/wCHZAf0AAcAh6wD9BP/AIdkB/QABwCHrAP0AAcAh6QD9AAHAIesA/QAC wCHrAP0AAcAh6wD9AAHAIesA/QACwCHrAP0AAcAh6wD9AAHAIekA/QABwCHr AP0AAsAh6wD9AAHAIesA2wABwCH6ANsE/8Ah5QHbAAHAIfoA/QABwCHrAP0A AcAh6wD9AAHAIesA/QABwCHrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIQAABQMNCxFoAROY/gw0/wEACAAAAQAAAAEAaAEAAAAA AAC3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAFAyQOAA8A CAABAEsADwAAAAAAGgAAQPH/AgAaAAZOb3JtYWwAAgAAAAMAYQkEAAAAAAAA AAAAAAAAAAAAAAAAACIAQUDy/6EAIgAWRGVmYXVsdCBQYXJhZ3JhcGggRm9u dAAAAAAAAAAAAAAAAAAAAIcNAAAEAIcQAAAAAP////8CAAQh//8BAAAg//8C AAAAAABqBwAAhw0AAAAAAQAAAAEAAAAAAAADAACeEAAACQAAAwAA2AgAAIcQ AAAKAAsAAAAAAAECAAAVAgAAiQ0AAAcAHAAHADMBC01hcmsgIEJha2VyJEM6 XHRleFxQYXJrQmVuY2hcbWludXRlcy1mYWxsLTk3LmRvYwtNYXJrICBCYWtl cjNDOlx0ZXhcUGFya0JlbmNoXEFkbWluaXN0cmF0aW9uXG1pbnV0ZXMtZmFs bC05Ny5kb2MLTWFyayAgQmFrZXIzQzpcdGV4XFBhcmtCZW5jaFxBZG1pbmlz dHJhdGlvblxtaW51dGVzLWZhbGwtOTcuZG9jC01hcmsgIEJha2VyM0M6XHRl eFxQYXJrQmVuY2hcQWRtaW5pc3RyYXRpb25cbWludXRlcy1mYWxsLTk3LmRv YwtNYXJrICBCYWtlcjNDOlx0ZXhcUGFya0JlbmNoXEFkbWluaXN0cmF0aW9u XG1pbnV0ZXMtZmFsbC05Ny5kb2P/QFRla3Ryb25peCBQaGFzZXIgNTUwIDEy MDAgZHBpAExQVDE6AHdpbnNwb29sAFRla3Ryb25peCBQaGFzZXIgNTUwIDEy MDAgZHBpAFRla3Ryb25peCBQaGFzZXIgNTUwIDEyMDAgZHBpAAAAAQQABJwA tAATzwEAAQABAOoKbwhkAAEADwBYAgIAAQAAAAMAAABMZXR0ZXIAABQAZWVl ZWVlZWVlZWVlZWVlZWVlZWVlZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBSSVbgEAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAQJxAnECcAABAnAAAA AAAAAABjdQgA/wMAAQEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRla3Ryb25peCBQaGFzZXIg NTUwIDEyMDAgZHBpAAAAAQQABJwAtAATzwEAAQABAOoKbwhkAAEADwBYAgIA AQAAAAMAAABMZXR0ZXIAAAAADwAGAAAACgAwARQAMAEUAHIAcABjAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAFBSSVbgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAABjdQgA/wMAAQEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAOAAQDHAAAAxwAAAAgAzwDPAMcAAAAAAAAAxwAAAHwAFRaQAQAAVGlt ZXMgTmV3IFJvbWFuAAwSkAECAFN5bWJvbAAWIpABAAZBcmlhbABIZWx2ZXRp Y2EAABsmvAIAAEFyaWFsIFJvdW5kZWQgTVQgQm9sZAARNZABAABDb3VyaWVy IE5ldwARNZABAgBNUyBMaW5lRHJhdwAiAAQAcQiJGAAA0AIAAGgBAAAAANBb GYa2ahuGAAAAAAcAXAAAAPQBAAAnCwAAAgAFAAAABACDEBcAAAAAAAAAAAAA AAIAAQAAAAEAAAAAAAAAIQMAAAAAKgAAAAAAAAALTWFyayAgQmFrZXILTWFy ayAgQmFrZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcA AAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAAP7////9////FAAA AP7///8cAAAA/v/////////////////////////////////////////+//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////UgBvAG8AdAAg AEUAbgB0AHIAeQAAAGspDUphY2sgRG9uZ2FycmEgLSBVbml2LiBvZiBUZW5u Li9PUk5MIChkbxYABQH//////////wEAAAAACQIAAAAAAMAAAAAAAABGAAAA AKD5PUK9vrwBEKvSgiLwvAETAAAAQAMAAGdldG9XAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAHNzbCAtIFNHSS9DcmF5IChjbWdAY3JheS5jb20pDVdpbGxp YW0gGgACAQIAAAADAAAA/////3BwQG1jcy5hbmwuZ292KQ1Ub255IEhleSAt IFVuaXYuIG9mIAAAAAAQHgAAdG9uIAEAQwBvAG0AcABPAGIAagAAAC51aykN Um9nZXIgSG9ja25leSAtIFVuaXYuIG9mIFdlc3RtaW5pc3RlciAocm8SAAIB ////////////////LmNvLnVrKQ1NYXJrIFBhcGlhbmkAAAAAAAAAAAAAAAAA AAAAAAAAAGoAAABtcEBlBQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAHMgKHNhaW5pQG5hcy5uYXNhLmdvdikNRCgAAgH/////BAAA AP////9FQ0lUIChzbmVsbGluZ0BmZWNpdAAAAAAAAAAAAAAAAAAAAAACAAAA vAEAAHRlZW4BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAP7///8K AAAACwAAAAwAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////wEA/v8DCgAA/////wAJAgAAAAAA wAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29y ZERvYwAQAAAAV29yZC5Eb2N1bWVudC42APQ5snEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAjAEAABIAAAABAAAAmAAAAAIAAACgAAAA AwAAAKwAAAAEAAAAuAAAAAUAAADMAAAABgAAANgAAAAHAAAA5AAAAAgAAAD0 AAAACQAAAAgBAAASAAAAFAEAAAoAAAA8AQAACwAAAEgBAAAMAAAAVAEAAA0A AABgAQAADgAAAGwBAAAPAAAAdAEAABAAAAB8AQAAEwAAAIQBAAACAAAA5AQA AB4AAAABAAAAAAAGAB4AAAABAAAAAFdSTR4AAAAMAAAATWFyayAgQmFrZXIA HgAAAAEAAAAAOmkQHgAAAAEAAAAAAAAAHgAAAAcAAABOb3JtYWwAYR4AAAAM AAAATWFyayAgQmFrZXIAHgAAAAIAAAA3AAQAHgAAAB4AAABNaWNyb3NvZnQg V29yZCBmb3IgV2luZG93cyA5NQAAAEAAAAAAKC3aDAAAAEAAAAAAAAAABQBE AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAADgAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAA6AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN 1ZwuGxCTlwgAKyz5rjAAAAC4AAAACAAAAAEAAABIAAAADwAAAFAAAAAEAAAA dAAAAAUAAAB8AAAABgAAAIQAAAALAAAAjAAAABAAAACUAAAADAAAAJwAAAAC AAAA5AQAAB4AAAAZAAAAVW5pdmVyc2l0eSBvZiBQb3J0c21vdXRoAAAAAAMA AAAAOgAAAwAAABcAAAADAAAABQAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAA AB4AAAABAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABAAAAAADhSnMW+vAFAAAAAANR+ciLwvAEDAAAAAgAAAAMAAAD0AQAAAwAA ACcLAAADAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA AtXN1ZwuGxCTlwgAKyz5rjAAAAC4AAAACAAAAAEAAABIAAAADwAAAFAAAAAE AAAAdAAAAAUAAAB8AAAABgAAAIQAAAALAAAAjAAAABAAAACUAAAADAAAAJwA AAACAAAA5AQAAB4AAAAZAAAAVW5pdmVyc2l0eSBvZiBQb3J0c21vdXRoAAAA AAMAAAAAOgAAAwAAABcAAAADAAAABQAAAAsAAAAAAAAACwAAAAAAAAAMEAAA AgAAAB4AAAABAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --mordillo:879418490:877:126:21579-- From owner-parkbench-comm@CS.UTK.EDU Thu Nov 13 06:31:53 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA07105; Thu, 13 Nov 1997 06:31:52 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA01880; Thu, 13 Nov 1997 05:56:05 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA01835; Thu, 13 Nov 1997 05:55:18 -0500 (EST) Received: from mordillo (p19.nas2.is2.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA18430; Thu, 13 Nov 97 10:56:11 GMT Date: Thu, 13 Nov 97 10:48:53 GMT From: Mark Baker Subject: Fall 97 Parkbench Committee Meeting Minutes To: parkbench-comm@CS.UTK.EDU, parkbench-hpf@CS.UTK.EDU, parkbench-lowlevel@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="mordillo:879418490:877:126:21579" --mordillo:879418490:877:126:21579 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, Here are the minutes of the Parkbench committee meeting held The County Hotel in Southampton during the Fall 97 Parkbench Workshop. For those of you with a MIME-compliant mail-reader I've attached a formatted word 7 doc. Regards Mark ----------------------------------------------------------------------------- Parkbench Committee Meeting Held during the Fall Parkbench Workshop The County Hotel Southampton, UK 1515, 11th September 1997 Meeting Participation List: Mark Baker - Univ. of Portsmouth (mab@sis.port.ac.uk) Flavio Bergamaschi - Univ of Southampton (fab@ecs.soton.ac.uk) Jack Dongarra - Univ. of Tenn./ORNL (dongarra@cs.utk.edu) Vladimir Getov - Univ. of Westminister (getovv@wmin.ac.uk) Charles Grassl - SGI/Cray (cmg@cray.com) William Gropp - ANL (gropp@mcs.anl.gov) Tony Hey - Univ. of Southampton (ajgh@ecs.soton.ac.uk) Roger Hockney - Univ. of Westminister (roger@minnow.demon.co.uk) Mark Papiani - Univ of Southampton (mp@ecs.soton.ac.uk) Subhash Saini - NASA Ames (saini@nas.nasa.gov) Dave Snelling - FECIT (snelling@fecit.co.uk) Aad J. van der Steen - RUU (steen@fys.ruu.nl) Erich Strohmaier - Univ. of Tennessee (erich@cs.utk.edu) Klaus Stueben - GMD (klaus.stueben@gmd.de) Meeting Activities and Actions Tony Hey chaired the meeting. Minutes from last meeting were seven pages long and it was decided that only the actions from the last meeting would be reviewed. The actions from last meeting were reviewed - a short discussion about each took place. A discussion about interaction with SPEC-HPG was initiated. Comms Low-Level Benchmarks Vladimir Getov gave a short presentation on the current status of the Parkbench Comms benchmarks. Charles Grassl was asked to explained how his new Comms programs worked and the rationale behind it. A long discussion ensued. Action - Create a formal proposal of alternative or additions to the comms low-level benchmarks for SC'97 - Charles Grassl. Action - Members should look at the PALLAS version of the low-level benchmarks (based on Genesis/RAPS). Action - Erich Strohmaier and Vladimir Getov will discuss the efforts needed to split up Parkbench and add in the new Comms1 benchmark (with new curve fitting routine). NPB - Subhash Siani reported on the status of the NAS Parallel Benchmarks HPF - Mark Baker read Chuck Koebel's email about CEWES HPCM HPF efforts. Action - Subhash Siani will let RICE know that Gina should start of from the single NAS codes Electronic Journal - Mark Baker and Tony Hey reported on the electronic journal PEMCS and its Web site. It was agreed that this would be discussed further informally. Parkbench Report -Erich Strohmaier reported on the efforts of creating a new Parkbench report. A short discussion about this ensued. Action - Jack Dongarra /Tony Hey will talk to other members about the potential efforts that could be put into a Parkbench report II by SC'97. Funding Efforts Jack Dongarra's recent benchmarking proposal was turned down. Tony Hey mentioned the possibly of entering a proposal to the EU. Possibility of a joint EU / NSF bid. Mark Baker asked if SIO would be interested in being more closely involved. William Gropp reported that SIO was actually winding down and so formal association was not really an option. AOB The participants were then invited by Tony to move to the University of Southampton (bldg. 16) for the Parkbench demonstrations which included: -- Java Low-Level Benchmarks (Vladimir Getov) -- BenchView: Java Tool for Visualization of Parallel Benchmark Results (Mark Papiani and Flavio Bergamaschi) -- PICT: An Interactive Web-page Curve-fitting Tool (Roger Hockney) Jack Dongarra informed the committee of Parkbench BOF at SC'97 (Wednesday at 3.30PM). The meeting was wound up by Tony Hey at 1630. ----------------------------------------------------------------------------- ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 11/13/97 - Time: 10:48:53 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- --mordillo:879418490:877:126:21579 Content-Type: APPLICATION/msword; name="minutes-fall-97.doc" Content-Transfer-Encoding: BASE64 Content-Description: minutes-fall-97.doc 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAEQAAAAAAAAAAEAAAEgAAAAEAAAD+////AAAAABAAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////cpWgAY+AJBAAAAABlAAAAAAAAAAAAAAAAAwAA hxAAABAeAAAAAAAAAAAAAAAAAAAAAAAAhw0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABgAAGoAAAAAGAAAagAAAGoYAAAAAAAAahgAAAAA AABqGAAAAAAAAGoYAAAAAAAAahgAABQAAACkGAAAAAAAAKQYAAAAAAAApBgA AAAAAACkGAAAAAAAAKQYAAAAAAAApBgAAAoAAACuGAAAEAAAAKQYAAAAAAAA Eh0AAHwAAAC+GAAAAAAAAL4YAAAAAAAAvhgAAAAAAAC+GAAAAAAAAL4YAAAA AAAAvhgAAAAAAAC+GAAAAAAAAL4YAAAAAAAABxoAAAIAAAAJGgAAAAAAAAka AAAAAAAACRoAAEsAAABUGgAAUAEAAKQbAABQAQAA9BwAAB4AAACOHQAAWAAA AOYdAAAqAAAAEh0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAahgAAAAAAAC+GAAA AAAAAAAACQAKAAEAAgC+GAAAAAAAAL4YAAAAAAAAAAAAAAAAAAAAAAAAAAAA AL4YAAAAAAAAvhgAAAAAAAASHQAAAAAAANQYAAAAAAAAahgAAAAAAABqGAAA AAAAAL4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL4YAAAAAAAA1BgAAAAAAADU GAAAAAAAANQYAAAAAAAAvhgAABYAAABqGAAAAAAAAL4YAAAAAAAAahgAAAAA AAC+GAAAAAAAAAcaAAAAAAAAAAAAAAAAAAAQq9KCIvC8AX4YAAAOAAAAjBgA ABgAAABqGAAAAAAAAGoYAAAAAAAAahgAAAAAAABqGAAAAAAAAL4YAAAAAAAA BxoAAAAAAADUGAAAMwEAANQYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABQYXJrYmVuY2ggQ29tbWl0dGVlIE1lZXRp bmcNDUhlbGQgZHVyaW5nIHRoZSBGYWxsIFBhcmtiZW5jaCBXb3Jrc2hvcA0N VGhlIENvdW50eSBIb3RlbA0NU291dGhhbXB0b24sIFVLDQ0xNTE1LCAgMTF0 aCBTZXB0ZW1iZXIgMTk5Nw0NDU1lZXRpbmcgUGFydGljaXBhdGlvbiBMaXN0 Og0NTWFyayBCYWtlciAtIFVuaXYuIG9mIFBvcnRzbW91dGggKG1hYkBzaXMu cG9ydC5hYy51aykNRmxhdmlvIEJlcmdhbWFzY2hpICAtIFVuaXYgb2YgU291 dGhhbXB0b24gKGZhYkBlY3Muc290b24uYWMudWspDUphY2sgRG9uZ2FycmEg LSBVbml2LiBvZiBUZW5uLi9PUk5MIChkb25nYXJyYUBjcy51dGsuZWR1KQ1W bGFkaW1pciBHZXRvdiAgLSBVbml2LiBvZiBXZXN0bWluaXN0ZXIgKGdldG92 dkB3bWluLmFjLnVrKQ1DaGFybGVzIEdyYXNzbCAtIFNHSS9DcmF5IChjbWdA Y3JheS5jb20pDVdpbGxpYW0gR3JvcHAgLSBBTkwgKGdyb3BwQG1jcy5hbmwu Z292KQ1Ub255IEhleSAtIFVuaXYuIG9mIFNvdXRoYW1wdG9uIChhamdoQGVj cy5zb3Rvbi5hYy51aykNUm9nZXIgSG9ja25leSAtIFVuaXYuIG9mIFdlc3Rt aW5pc3RlciAocm9nZXJAbWlubm93LmRlbW9uLmNvLnVrKQ1NYXJrIFBhcGlh bmkgLSBVbml2IG9mIFNvdXRoYW1wdG9uIChtcEBlY3Muc290b24uYWMudWsp DVN1Ymhhc2ggU2FpbmkgLSBOQVNBIEFtZXMgKHNhaW5pQG5hcy5uYXNhLmdv dikNRGF2ZSBTbmVsbGluZyAtIEZFQ0lUIChzbmVsbGluZ0BmZWNpdC5jby51 aykNQWFkIEouIHZhbiBkZXIgU3RlZW4gIC0gUlVVIChzdGVlbkBmeXMucnV1 Lm5sKQ1FcmljaCBTdHJvaG1haWVyIC0gVW5pdi4gb2YgVGVubmVzc2VlIChl cmljaEBjcy51dGsuZWR1KQ1LbGF1cyBTdHVlYmVuIC0gR01EICAoa2xhdXMu c3R1ZWJlbkBnbWQuZGUpDQ1NZWV0aW5nIEFjdGl2aXRpZXMgYW5kIEFjdGlv bnMNDVRvbnkgSGV5IGNoYWlyZWQgdGhlIG1lZXRpbmcuDQ1NaW51dGVzIGZy b20gbGFzdCBtZWV0aW5nIHdlcmUgc2V2ZW4gcGFnZXMgbG9uZyBhbmQgaXQg d2FzIGRlY2lkZWQgdGhhdCBvbmx5IHRoZSBhY3Rpb25zIGZyb20gdGhlIGxh c3QgbWVldGluZyB3b3VsZCBiZSByZXZpZXdlZC4gVGhlIGFjdGlvbnMgZnJv bSBsYXN0IG1lZXRpbmcgd2VyZSByZXZpZXdlZCAtIGEgc2hvcnQgZGlzY3Vz c2lvbiBhYm91dCBlYWNoIHRvb2sgcGxhY2UuIEEgZGlzY3Vzc2lvbiBhYm91 dCBpbnRlcmFjdGlvbiB3aXRoIFNQRUMtSFBHIHdhcyBpbml0aWF0ZWQuDQ1D b21tcyBMb3ctTGV2ZWwgQmVuY2htYXJrcyANDVZsYWRpbWlyIEdldG92IGdh dmUgYSBzaG9ydCBwcmVzZW50YXRpb24gb24gdGhlIGN1cnJlbnQgc3RhdHVz IG9mIHRoZSBQYXJrYmVuY2ggQ29tbXMgYmVuY2htYXJrcy4gIENoYXJsZXMg R3Jhc3NsIHdhcyBhc2tlZCB0byBleHBsYWluZWQgaG93IGhpcyBuZXcgQ29t bXMgcHJvZ3JhbXMgd29ya2VkIGFuZCB0aGUgcmF0aW9uYWxlIGJlaGluZCBp dC4gDUEgbG9uZyBkaXNjdXNzaW9uIGVuc3VlZC4NDUFjdGlvbiAtIENyZWF0 ZSBhIGZvcm1hbCBwcm9wb3NhbCAgb2YgYWx0ZXJuYXRpdmUgb3IgYWRkaXRp b25zIHRvIHRoZSBjb21tcyBsb3ctbGV2ZWwgYmVuY2htYXJrcyBmb3IgU0OS OTcgLSBDaGFybGVzIEdyYXNzbC4NDUFjdGlvbiAtIE1lbWJlcnMgc2hvdWxk IGxvb2sgYXQgdGhlIFBBTExBUyB2ZXJzaW9uIG9mIHRoZSBsb3ctbGV2ZWwg YmVuY2htYXJrcyAoYmFzZWQgb24gR2VuZXNpcy9SQVBTKS4NDUFjdGlvbiAg LSBFcmljaCAgU3Ryb2htYWllciBhbmQgVmxhZGltaXIgR2V0b3Ygd2lsbCBk aXNjdXNzIHRoZSBlZmZvcnRzIG5lZWRlZCB0byBzcGxpdCB1cCBQYXJrYmVu Y2ggYW5kIGFkZCBpbiB0aGUgbmV3IENvbW1zMSBiZW5jaG1hcmsgKHdpdGgg bmV3IGN1cnZlIGZpdHRpbmcgcm91dGluZSkuDQ1OUEIgLSBTdWJoYXNoIFNp YW5pIHJlcG9ydGVkIG9uIHRoZSBzdGF0dXMgb2YgdGhlIE5BUyBQYXJhbGxl bCBCZW5jaG1hcmtzDQ1IUEYgLSBNYXJrIEJha2VyIHJlYWQgQ2h1Y2sgS29l YmVsknMgZW1haWwgYWJvdXQgQ0VXRVMgSFBDTSBIUEYgZWZmb3J0cy4NDUFj dGlvbiAtIFN1Ymhhc2ggU2lhbmkgd2lsbCBsZXQgUklDRSBrbm93IHRoYXQg R2luYSBzaG91bGQgc3RhcnQgb2YgZnJvbSB0aGUgc2luZ2xlIE5BUyBjb2Rl cw0NRWxlY3Ryb25pYyBKb3VybmFsIC0gTWFyayBCYWtlciBhbmQgVG9ueSBI ZXkgcmVwb3J0ZWQgb24gdGhlIGVsZWN0cm9uaWMgam91cm5hbCBQRU1DUyBh bmQgaXRzIFdlYiBzaXRlLiBJdCB3YXMgYWdyZWVkIHRoYXQgdGhpcyB3b3Vs ZCBiZSBkaXNjdXNzZWQgIGZ1cnRoZXIgaW5mb3JtYWxseS4NDVBhcmtiZW5j aCBSZXBvcnQgLUVyaWNoIFN0cm9obWFpZXIgcmVwb3J0ZWQgb24gdGhlIGVm Zm9ydHMgb2YgY3JlYXRpbmcgYSBuZXcgUGFya2JlbmNoIHJlcG9ydC4gQSBz aG9ydCBkaXNjdXNzaW9uIGFib3V0IHRoaXMgZW5zdWVkLg0NQWN0aW9uIC0g SmFjayBEb25nYXJyYSAvVG9ueSBIZXkgd2lsbCB0YWxrIHRvIG90aGVyIG1l bWJlcnMgYWJvdXQgdGhlIHBvdGVudGlhbCBlZmZvcnRzIHRoYXQgY291bGQg YmUgcHV0IGludG8gYSBQYXJrYmVuY2ggcmVwb3J0IElJIGJ5IFNDkjk3Lg0N RnVuZGluZyBFZmZvcnRzDQ1KYWNrIERvbmdhcnJhknMgcmVjZW50IGJlbmNo bWFya2luZyAgcHJvcG9zYWwgd2FzIHR1cm5lZCBkb3duLiBUb255IEhleSBt ZW50aW9uZWQgdGhlIHBvc3NpYmx5IG9mIGVudGVyaW5nIGEgcHJvcG9zYWwg dG8gdGhlIEVVLg1Qb3NzaWJpbGl0eSBvZiBhIGpvaW50IEVVIC8gTlNGIGJp ZC4NDU1hcmsgQmFrZXIgYXNrZWQgaWYgU0lPIHdvdWxkIGJlIGludGVyZXN0 ZWQgaW4gYmVpbmcgbW9yZSBjbG9zZWx5IGludm9sdmVkLiAgV2lsbGlhbSBH cm9wcCByZXBvcnRlZCB0aGF0IFNJTyB3YXMgYWN0dWFsbHkgd2luZGluZyBk b3duIGFuZCBzbyBmb3JtYWwgYXNzb2NpYXRpb24gd2FzIG5vdCByZWFsbHkg YW4gb3B0aW9uLg0NQU9CDQ1UaGUgcGFydGljaXBhbnRzIHdlcmUgdGhlbiBp bnZpdGVkIGJ5IFRvbnkgdG8gbW92ZSB0byB0aGUgVW5pdmVyc2l0eSBvZiBT b3V0aGFtcHRvbiAoYmxkZy4gMTYpIGZvciB0aGUgUGFya2JlbmNoIGRlbW9u c3RyYXRpb25zIHdoaWNoIGluY2x1ZGVkOg0NSmF2YSBMb3ctTGV2ZWwgQmVu Y2htYXJrcyAoVmxhZGltaXIgR2V0b3YpDUJlbmNoVmlldzogSmF2YSBUb29s IGZvciBWaXN1YWxpemF0aW9uIG9mIFBhcmFsbGVsIEJlbmNobWFyayBSZXN1 bHRzIChNYXJrIFBhcGlhbmkgYW5kIEZsYXZpbyBCZXJnYW1hc2NoaSkNUElD VDogQW4gSW50ZXJhY3RpdmUgV2ViLXBhZ2UgQ3VydmUtZml0dGluZyBUb29s IChSb2dlciBIb2NrbmV5KQ0NSmFjayBEb25nYXJyYSAgaW5mb3JtZWQgdGhl IGNvbW1pdHRlZSBvZiAgUGFya2JlbmNoIEJPRiBhdCBTQ5I5NyAoV2VkbmVz ZGF5IGF0IDMuMzBQTSkuDQ1UaGUgbWVldGluZyB3YXMgd291bmQgdXAgYnkg VG9ueSBIZXkgYXQgMTYzMC4NFQCk0C+l4D2mCAenCAeooAWpoAWqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAHQMAAGgD AAByAwAAdAMAAIYDAAChAwAAogMAAMUDAADXAwAABAQAABcEAAA+BAAAUQQA AHwEAACNBAAAqgQAALYEAADNBAAA3gQAAAEFAAAVBQAAPgUAAFYFAABvBQAA jgUAAKsFAAC9BQAA1gUAAOoFAAAJBgAAGQYAAEIGAABSBgAAagYAAH4GAACB BgAAoAYAANcHAADzBwAARAgAAEkIAACJCAAAjggAANgIAADeCAAAVgkAAFwJ AABeCQAAvwkAAMUJAAA3CgAAPQoAAGsKAABuCgAAtgoAALkKAAAACwAABgsA AF8LAABxCwAACAwAABgMAACODAAAlAwAAB4NAAAtDQAALg0AAJIOAACVDgAA hxAAAJ4QAAD79gD0APHvAO0A7QDtAO0A7QDrAO0A7QDtAO0A7QDtAO0A7QDm APEA7QDtAOMA4+EA4wDtAPEA8QDjAPEA8QDjAPHvAPEA3wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQACVoEABFWBVoEA CFWBXQMAYxgAAANdBQADXQQAA10DAAVVgV0DAAJoAQAIVYFdAwBjHAAACFWB XQMAYyQARwADAAAcAwAAHQMAAEUDAABGAwAAVwMAAFgDAABoAwAAaQMAAIQD AACFAwAAhgMAAKIDAACjAwAA2QMAABkEAABTBAAAjwQAALgEAADgBAAAFwUA AFgFAACQBQAAvwUAAOwFAAAbBgAAVAYAAIAGAACBBgAAoAYAAKEGAAC/BgAA wAYAANYHAADXBwAA8wcAAPQHAAC9CAAA1wgAANgIAAD9AAHAIaIB+gABwCGi Af0AAcAhRgH9AAHAIUYB/QABwCFGAf0AAcAhRgH9AAHAIUYB/QABwCHrAP0A AcAh6wD6AAHAIesA+gABwCHrAPoAAcAh6QD6AAHAIesA+gABwCHyAPoAAcAh 8gD6AAHAIfIA+gABwCHyAPoAAcAh8gD6AAHAIfIA+gABwCHyAPoAAcAh8gD6 AAHAIfIA+gABwCHyAPoAAcAh8gD6AAHAIfIA+gABwCHyANwAAcAh8gD6AAHA IesA+gABwCEWAfoAAcAh6wD6AAHAIesA+gABwCHrAPoAA8Ah6wD6AAHAIesA +gABwCHpAPoAAcAh6wD6AALAIfIA+gABwCHrAPoAAcAh6wAAAAAAAAAAHQAA BQMMNP8BAAgAAAEAAAABAGgBAAAAAAAAtwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgAABQMAAgAABQEn2AgAAFUJAABWCQAAvgkAAL8JAABq CgAAawoAALUKAAC2CgAA/woAAAALAABeCwAAXwsAAAcMAAAIDAAAjQwAAI4M AAAdDQAAHg0AAC4NAAAvDQAAsA0AANUNAADWDQAAkQ4AAJIOAACWDgAAlw4A ACcPAAAoDwAAUw8AAL4PAAD/DwAAABAAAFgQAABZEAAAhxAAAP0E/8Ah2QH9 AAHAIesA/QT/wCHZAf0AAcAh6wD9BP/AIeAB/QABwCHrAP0AAcAh7gD9AAHA IesA/QABwCHuAP0AAcAh6wD9AAHAIe4A/QABwCHrAP0E/8Ah2QH9AAHAIesA /QT/wCHZAf0AAcAh6wD9BP/AIdkB/QABwCHrAP0AAcAh6QD9AAHAIesA/QAC wCHrAP0AAcAh6wD9AAHAIesA/QACwCHrAP0AAcAh6wD9AAHAIekA/QABwCHr AP0AAsAh6wD9AAHAIesA2wABwCH6ANsE/8Ah5QHbAAHAIfoA/QABwCHrAP0A AcAh6wD9AAHAIesA/QABwCHrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIQAABQMNCxFoAROY/gw0/wEACAAAAQAAAAEAaAEAAAAA AAC3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAFAyQOAA8A CAABAEsADwAAAAAAGgAAQPH/AgAaAAZOb3JtYWwAAgAAAAMAYQkEAAAAAAAA AAAAAAAAAAAAAAAAACIAQUDy/6EAIgAWRGVmYXVsdCBQYXJhZ3JhcGggRm9u dAAAAAAAAAAAAAAAAAAAAIcNAAAEAIcQAAAAAP////8CAAQh//8BAAAg//8C AAAAAABqBwAAhw0AAAAAAQAAAAEAAAAAAAADAACeEAAACQAAAwAA2AgAAIcQ AAAKAAsAAAAAAAECAAAVAgAAiQ0AAAcAHAAHADMBC01hcmsgIEJha2VyJEM6 XHRleFxQYXJrQmVuY2hcbWludXRlcy1mYWxsLTk3LmRvYwtNYXJrICBCYWtl cjNDOlx0ZXhcUGFya0JlbmNoXEFkbWluaXN0cmF0aW9uXG1pbnV0ZXMtZmFs bC05Ny5kb2MLTWFyayAgQmFrZXIzQzpcdGV4XFBhcmtCZW5jaFxBZG1pbmlz dHJhdGlvblxtaW51dGVzLWZhbGwtOTcuZG9jC01hcmsgIEJha2VyM0M6XHRl eFxQYXJrQmVuY2hcQWRtaW5pc3RyYXRpb25cbWludXRlcy1mYWxsLTk3LmRv YwtNYXJrICBCYWtlcjNDOlx0ZXhcUGFya0JlbmNoXEFkbWluaXN0cmF0aW9u XG1pbnV0ZXMtZmFsbC05Ny5kb2P/QFRla3Ryb25peCBQaGFzZXIgNTUwIDEy MDAgZHBpAExQVDE6AHdpbnNwb29sAFRla3Ryb25peCBQaGFzZXIgNTUwIDEy MDAgZHBpAFRla3Ryb25peCBQaGFzZXIgNTUwIDEyMDAgZHBpAAAAAQQABJwA tAATzwEAAQABAOoKbwhkAAEADwBYAgIAAQAAAAMAAABMZXR0ZXIAABQAZWVl ZWVlZWVlZWVlZWVlZWVlZWVlZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBSSVbgEAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAQJxAnECcAABAnAAAA AAAAAABjdQgA/wMAAQEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRla3Ryb25peCBQaGFzZXIg NTUwIDEyMDAgZHBpAAAAAQQABJwAtAATzwEAAQABAOoKbwhkAAEADwBYAgIA AQAAAAMAAABMZXR0ZXIAAAAADwAGAAAACgAwARQAMAEUAHIAcABjAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAFBSSVbgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAABjdQgA/wMAAQEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAOAAQDHAAAAxwAAAAgAzwDPAMcAAAAAAAAAxwAAAHwAFRaQAQAAVGlt ZXMgTmV3IFJvbWFuAAwSkAECAFN5bWJvbAAWIpABAAZBcmlhbABIZWx2ZXRp Y2EAABsmvAIAAEFyaWFsIFJvdW5kZWQgTVQgQm9sZAARNZABAABDb3VyaWVy IE5ldwARNZABAgBNUyBMaW5lRHJhdwAiAAQAcQiJGAAA0AIAAGgBAAAAANBb GYa2ahuGAAAAAAcAXAAAAPQBAAAnCwAAAgAFAAAABACDEBcAAAAAAAAAAAAA AAIAAQAAAAEAAAAAAAAAIQMAAAAAKgAAAAAAAAALTWFyayAgQmFrZXILTWFy ayAgQmFrZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcA AAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAAP7////9////FAAA AP7///8cAAAA/v/////////////////////////////////////////+//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////UgBvAG8AdAAg AEUAbgB0AHIAeQAAAGspDUphY2sgRG9uZ2FycmEgLSBVbml2LiBvZiBUZW5u Li9PUk5MIChkbxYABQH//////////wEAAAAACQIAAAAAAMAAAAAAAABGAAAA AKD5PUK9vrwBEKvSgiLwvAETAAAAQAMAAGdldG9XAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAHNzbCAtIFNHSS9DcmF5IChjbWdAY3JheS5jb20pDVdpbGxp YW0gGgACAQIAAAADAAAA/////3BwQG1jcy5hbmwuZ292KQ1Ub255IEhleSAt IFVuaXYuIG9mIAAAAAAQHgAAdG9uIAEAQwBvAG0AcABPAGIAagAAAC51aykN Um9nZXIgSG9ja25leSAtIFVuaXYuIG9mIFdlc3RtaW5pc3RlciAocm8SAAIB ////////////////LmNvLnVrKQ1NYXJrIFBhcGlhbmkAAAAAAAAAAAAAAAAA AAAAAAAAAGoAAABtcEBlBQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAHMgKHNhaW5pQG5hcy5uYXNhLmdvdikNRCgAAgH/////BAAA AP////9FQ0lUIChzbmVsbGluZ0BmZWNpdAAAAAAAAAAAAAAAAAAAAAACAAAA vAEAAHRlZW4BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAP7///8K AAAACwAAAAwAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////////////////////////////wEA/v8DCgAA/////wAJAgAAAAAA wAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29y ZERvYwAQAAAAV29yZC5Eb2N1bWVudC42APQ5snEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAjAEAABIAAAABAAAAmAAAAAIAAACgAAAA AwAAAKwAAAAEAAAAuAAAAAUAAADMAAAABgAAANgAAAAHAAAA5AAAAAgAAAD0 AAAACQAAAAgBAAASAAAAFAEAAAoAAAA8AQAACwAAAEgBAAAMAAAAVAEAAA0A AABgAQAADgAAAGwBAAAPAAAAdAEAABAAAAB8AQAAEwAAAIQBAAACAAAA5AQA AB4AAAABAAAAAAAGAB4AAAABAAAAAFdSTR4AAAAMAAAATWFyayAgQmFrZXIA HgAAAAEAAAAAOmkQHgAAAAEAAAAAAAAAHgAAAAcAAABOb3JtYWwAYR4AAAAM AAAATWFyayAgQmFrZXIAHgAAAAIAAAA3AAQAHgAAAB4AAABNaWNyb3NvZnQg V29yZCBmb3IgV2luZG93cyA5NQAAAEAAAAAAKC3aDAAAAEAAAAAAAAAABQBE AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAADgAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAA6AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN 1ZwuGxCTlwgAKyz5rjAAAAC4AAAACAAAAAEAAABIAAAADwAAAFAAAAAEAAAA dAAAAAUAAAB8AAAABgAAAIQAAAALAAAAjAAAABAAAACUAAAADAAAAJwAAAAC AAAA5AQAAB4AAAAZAAAAVW5pdmVyc2l0eSBvZiBQb3J0c21vdXRoAAAAAAMA AAAAOgAAAwAAABcAAAADAAAABQAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAA AB4AAAABAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABAAAAAADhSnMW+vAFAAAAAANR+ciLwvAEDAAAAAgAAAAMAAAD0AQAAAwAA ACcLAAADAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA AtXN1ZwuGxCTlwgAKyz5rjAAAAC4AAAACAAAAAEAAABIAAAADwAAAFAAAAAE AAAAdAAAAAUAAAB8AAAABgAAAIQAAAALAAAAjAAAABAAAACUAAAADAAAAJwA AAACAAAA5AQAAB4AAAAZAAAAVW5pdmVyc2l0eSBvZiBQb3J0c21vdXRoAAAA AAMAAAAAOgAAAwAAABcAAAADAAAABQAAAAsAAAAAAAAACwAAAAAAAAAMEAAA AgAAAB4AAAABAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --mordillo:879418490:877:126:21579-- From owner-parkbench-comm@CS.UTK.EDU Mon Nov 17 08:32:09 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA28026; Mon, 17 Nov 1997 08:32:09 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA07698; Mon, 17 Nov 1997 07:58:13 -0500 (EST) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA07665; Mon, 17 Nov 1997 07:57:54 -0500 (EST) Received: from minnow.demon.co.uk ([158.152.73.63]) by post.mail.demon.net id aa2024828; 17 Nov 97 12:43 GMT Message-ID: <06u4dCAfsDc0Ew8p@minnow.demon.co.uk> Date: Mon, 17 Nov 1997 12:39:59 +0000 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: To the PARKBENCH97 BOF MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a GREETINGS TO THE PARKBENCH 1997 BOF ----------------------------------- I am not able to attend the Parkbench BOF this year but would like to make the following input: Chairman: Please express my apologies for absence to the meeting. Agenda Item: Low-Level Performance Evaluation tools. -------------------------------------- The latest version of the Parkbench Interactive Curve Fitting Tool (PICT2) is on my Web page at: http://www.minnow.demon.co.uk/pict/source/pict2a.html I believe that this solves the problem of displaying on different sized screens. Please try it and give me feedback (I have had little so far, so I don't know how worthwhile it is!). This plots and allows manual interactive curve fitting of data anywhere on the Web in raw-data, Original COMMS1, and New COMMS1 format. However, it still relies on COMMS1 calculating the least squares 2-Para and 3-Point 3-Para fits. Agenda Item : Plans for the next Release. -------------------------- Just a reminder that New COMMS1 as announced in my email to the committee of 16 Feb 1997, was designed as the minimum necessary changes to the existing release to solve the problems raised at the beginning of the year. It involves new versions of 5 routines and 2 new routines. In addition, the Make files need the 2 new routines added where appropriate. We have incorporated these changes at Westminster in the existing release without trouble. I believe that these should be incorported in the next release. In summary: New COMMS1 In directory: http://www.minnow.demon.co.uk/Pbench/comms1/ The 5 Changed Routines: (1) File COMMS1_1.F replaces ParkBench/Low_Level/comms1/src_mpi/COMMS1.f (2) File COMMS1_1.INC replaces ParkBench/Low_Level/comms1/src_mpi/comms1.inc (3) File ESTCOM_1.F replaces ParkBench/Low_Level/comms1/src_mpi/ESTCOM.f (4) File LSTSQ_1.F replaces ParkBench/lib/Low_Level/LSTSQ.f (5) File CHECK_1.F replaces Parkbench/lib/Low_Level/CHECK.f The 2 New Routines: (6) File LINERR_1.F add as ParkBench/lib/Low_Level/LINERR.f (7) File VPOWER_1.F add as ParkBench/lib/Low_Level/VPOWER.f HAVE A NICE MEETING, and best wishes to you all, Roger Hockney -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Mon Dec 1 08:38:55 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA05062; Mon, 1 Dec 1997 08:38:55 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA20432; Mon, 1 Dec 1997 08:03:34 -0500 (EST) Received: from hermes.lsi.usp.br (hermes.lsi.usp.br [143.107.161.220]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id IAA20425; Mon, 1 Dec 1997 08:03:30 -0500 (EST) Received: from cali.lsi.usp.br (cali.lsi.usp.br [10.0.161.7]) by hermes.lsi.usp.br (8.8.5/8.7.3) with SMTP id LAA05866; Mon, 1 Dec 1997 11:03:20 -0200 (BDB) Message-ID: <34830ABD.487C@lsi.usp.br> Date: Mon, 01 Dec 1997 11:06:37 -0800 From: Martha Torres Organization: LSI X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: parkbench-comm@CS.UTK.EDU CC: mxtd@lsi.usp.br Subject: compiling ParkBench for MPICH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sirs ParkBench Committee Dear Sirs, I am Ph.D student and I am working with collective communication operations. Particulary, I am interested in to quantify the influence of collective communication operations on the total execution time of several MPI-programs. My platform is a cluster of 8 Dual Pentium Pro processors interconnected by 100Mb/s Fastethernet. I use MPICH version 1.1, fort77 and cc compilers I have downloaded ParkBench.tar from netlib. I followed all instructions but there are some programs that did not work: 1. Low_Level/poly1 poly2 rinf1 tick1 tick2 They did not compile. It appears the following: ParkBench/lib/LINUX/ParkBench_misc.a: No such file or directory. How do I create this library?? 2. Kernels/LU_solver QR TRD They also did not compile. It appears the following: ParkBench/lib/LINUX/pblas_subset.a: In function 'pberror_' undefined reference to 'blacs_gridinfo_' undefined reference to 'blacs_abort_' 3. Comp_Apps/PSTSWM and Kernels/MATMUL They compiled but they did not run Thanks in advance, Best Regards Martha Torres Laboratorio de Sistema Integraveis University of Sao Paulo Sao Paulo - S.P. Brazil From owner-parkbench-lowlevel@CS.UTK.EDU Wed Dec 3 02:22:07 1997 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id CAA13224; Wed, 3 Dec 1997 02:22:07 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA11602; Wed, 3 Dec 1997 02:22:29 -0500 (EST) Received: from soran.pacific.net.sg (soran.pacific.net.sg [203.120.90.76]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id CAA11594; Wed, 3 Dec 1997 02:22:26 -0500 (EST) From: Received: from pop1.pacific.net.sg (pop1.pacific.net.sg [203.120.90.85]) by soran.pacific.net.sg with ESMTP id PAA08723 for ; Wed, 3 Dec 1997 15:22:07 +0800 (SGT) Received: from pacific.net.sg ([203.116.15.109]) by pop1.pacific.net.sg with SMTP id PAA19445 for ; Wed, 3 Dec 1997 15:22:19 +0800 (SGT) Message-Id: <199712030722.PAA19445@pop1.pacific.net.sg> To: pbwg-compactapp@CS.UTK.EDU Date: Wed, 3 Dec 97 15:25:30 +0800 Subject: Seeking Importer for Blank CD-R and Computer Parts X-Mailer: Crescent Internet ToolPak OLE Mail Control v.1.0 Dear Sir, I understand that you are a computer reseller/trader. (If you not, or not interested in this message, DO NOTHING, as we might have made a mistake) We respect your privacy. As such, we only followup if you are interested and responded to our mail. We are seeking importer for the following products:- Able to supply the following in bulk / small quantity. 1.CD-R (Jewel Case) 2.CD-R (Spindle) 3.CD-R replicator (4pcs/hour, 50pcs tower) 4.Yamaha CDR400 (4x write, 6x read) recorder. 5.CD-RW as well as its recorder 6.PC Mother Board 7.PC RAMs 8.PC CPUs. All products FOB Singapore. Clients to specify freight forwarder. Thank you very much. Have a nice day. Best regards, Manager, Insas Networks. From owner-parkbench-comm@CS.UTK.EDU Wed Jan 7 16:49:19 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA19963; Wed, 7 Jan 1998 16:49:19 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA17461; Wed, 7 Jan 1998 16:30:05 -0500 (EST) Received: from timbuk.cray.com (timbuk-fddi.cray.com [128.162.8.102]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA17452; Wed, 7 Jan 1998 16:30:02 -0500 (EST) Received: from ironwood.cray.com (root@ironwood-fddi.cray.com [128.162.21.36]) by timbuk.cray.com (8.8.7/CRI-gate-news-1.3) with ESMTP id PAA16817 for ; Wed, 7 Jan 1998 15:30:03 -0600 (CST) Received: from magnet.cray.com (magnet [128.162.173.162]) by ironwood.cray.com (8.8.4/CRI-ironwood-news-1.0) with ESMTP id PAA27253; Wed, 7 Jan 1998 15:30:00 -0600 (CST) From: Charles Grassl Received: by magnet.cray.com (8.8.0/btd-b3) id VAA26077; Wed, 7 Jan 1998 21:29:59 GMT Message-Id: <199801072129.VAA26077@magnet.cray.com> Subject: Low Level benchmarks To: parkbench-comm@CS.UTK.EDU Date: Wed, 7 Jan 1998 15:29:59 -0600 (CST) X-Mailer: ELM [version 2.4 PL24-CRI-d] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit -- Charles Grassl From owner-parkbench-comm@CS.UTK.EDU Wed Jan 7 16:56:40 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA19981; Wed, 7 Jan 1998 16:56:40 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA17784; Wed, 7 Jan 1998 16:36:27 -0500 (EST) Received: from timbuk.cray.com (timbuk-fddi.cray.com [128.162.8.102]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA17776; Wed, 7 Jan 1998 16:36:24 -0500 (EST) Received: from ironwood.cray.com (root@ironwood-fddi.cray.com [128.162.21.36]) by timbuk.cray.com (8.8.7/CRI-gate-news-1.3) with ESMTP id PAA17087 for ; Wed, 7 Jan 1998 15:36:24 -0600 (CST) Received: from magnet.cray.com (magnet [128.162.173.162]) by ironwood.cray.com (8.8.4/CRI-ironwood-news-1.0) with ESMTP id PAA28449 for ; Wed, 7 Jan 1998 15:36:22 -0600 (CST) Received: from magnet by magnet.cray.com (8.8.0/btd-b3) via SMTP id VAA26107; Wed, 7 Jan 1998 21:36:21 GMT Sender: cmg@cray.com Message-ID: <34B3F553.167E@cray.com> Date: Wed, 07 Jan 1998 15:36:19 -0600 From: Charles Grassl Organization: Cray Research X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: parkbench-comm@CS.UTK.EDU Subject: Low Level benchmark errors and differences Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Parkbench Low Level interests From: Charles Grassl Subject: Low Level benchmark errors and differences Date: 7 January, 1998 We should not produce or publish Parkbench Low level benchmark results with the current suite of programs because the programs are inaccurate and unreliable. I ran the Low Level programs and compared the results with the same metrics as recorded from other benchmark programs. The differences range from less than 5% (acceptable) to a factor of 6 times difference, which is unacceptable. The differences, or "errors", are summarized in the table below. The recorded differences in results from the Low Level program were arrived at by comparing the Parkbench program reported metrics with the same metrics as measured by alternative programs. Table. Differences in Low Level benchmark results for two systems. System A is an Origin 2000. System B is a CRAY T3E. System A System B Rinf Startup Rinf Startup ----------------------------------------- COMMS1 <10% 6x <5% 6x COMMS2 2x 3x <5% <5% COMMS3 <5% <5% POLY1 <5% 60% 2x <5% POLY2 <5% 60% 2x <5% POLY3 - - 2x 80x The Parkbench Low Level programs are occasionally requested for benchmarking computer systems, but the results are usually rejected because of their inaccuracy and unreliability. If not rejected, they cause confusion and consternation because the results do not agree with other measurements of the same variables. I emphasize that this is not a case of obtaining optimization and favorable results for a computer system. The problem is with the inaccuracy and unreliability of the results. The Low Level programs measure and report low level parameters. Therefore their value is in accuracy and utility. The programs do not constitute definitions of the reported metrics and hence the results should correlate with other measurements of the the same variables. The Low Level programs are obsolete and need to be replaced. I have written seven simple programs, with MPI and PVM versions, and offer them as a replacement for the Low Level suite. I strongly suggest that we delete or withdraw from distribution the current Low Level suite. From owner-parkbench-comm@CS.UTK.EDU Thu Jan 8 05:40:28 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id FAA01529; Thu, 8 Jan 1998 05:40:28 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA00442; Thu, 8 Jan 1998 05:20:21 -0500 (EST) Received: from sun1.ccrl-nece.technopark.gmd.de (sun1.ccrl-nece.technopark.gmd.de [193.175.160.67]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id FAA00380; Thu, 8 Jan 1998 05:20:13 -0500 (EST) Received: from sgi7.ccrl-nece.technopark.gmd.de (sgi7.ccrl-nece.technopark.gmd.de [193.175.160.89]) by sun1.ccrl-nece.technopark.gmd.de (8.7/3.4W296021412) with SMTP id LAA28869; Thu, 8 Jan 1998 11:20:05 +0100 (MET) Received: (from hempel@localhost) by sgi7.ccrl-nece.technopark.gmd.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA24864; Thu, 8 Jan 1998 11:18:48 +0100 Date: Thu, 8 Jan 1998 11:18:48 +0100 From: hempel@ccrl-nece.technopark.gmd.de (Rolf Hempel) Message-Id: <199801081018.LAA24864@sgi7.ccrl-nece.technopark.gmd.de> To: parkbench-comm@CS.UTK.EDU Subject: Low Level benchmark errors and differences Cc: ritzdorf@ccrl-nece.technopark.gmd.de, zimmermann@ccrl-nece.technopark.gmd.de, clantwin@ess.nec.de, eckhard@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, tbeckers@ess.nec.de Reply-To: hempel@ccrl-nece.technopark.gmd.de To: Parkbench Low Level interests From: Rolf Hempel Subject: Low Level benchmark errors and differences, Note from Charles Grassl of January 7th Date: 8 January, 1998 Thank you, Charles, for your note on the Low Level benchmarks. It could not have come at a better time, because at NEC we just recently ran into problems with COMMS1. This code had been specified by a customer as a test case in a current procurement. When we ran COMMS1 with our current MPI library, the results for rinfinity and latency were completely wrong. In particular, the latency values were off by more than a factor of two, when compared with other ping-pong test programs. The following turned out to be the main reasons for the errors: 1. The performance model is completely inadequate. A linear dependency between time and message length, fitted to the measurements by least squares, is bound to fail in the presence of discontinuities caused by protocol changes. Most MPI implementations change protocols for different message lengths for an overall performance optimization. 2. To make things worse, the least square fit overweighs the data points for very long messages, because the differences "model minus measurement" are largest there in absolute terms. The fitted line, therefore, more or less ignores the short message measurements. As a result, the latencies are completely up to chance. 3. The correction for internal measurement overhead (e.g., for subroutine calls) is programmed in a sloppy way, to say the least. We discovered several subroutine calls which were not taken into account, and the overhead is measured with low precision. For our implementation, this alone introduced a latency error of about 25%. The result in our case was that, instead of the 13.5 usec latency measured by the MPICH MPPTEST routine, COMMS1 initially reported some 28 usec. My colleague Hubert Ritzdorf then made an interesting experiment: he removed some optimization from our MPI library for long messages, thus INCREASING the communication times for messages longer than 128000 bytes, and not changing anything for shorter messages. The resulting DROP in latency from 28 to under 22 usec clearly shows how ridiculous the COMMS1 benchmark is. Thus, I strongly agree with Charles in that the COMMS* benchmarks must be removed from PARKBENCH. They don't help anybody, and they only cause confusion on the side of customers and frustration on the side of benchmarkers. Let's get rid of this long-standing nuisance as quickly as possible. Best regards, Rolf Hempel ------------------------------------------------------------------------ Rolf Hempel (email: hempel@ccrl-nece.technopark.gmd.de) Senior Research Staff Member C&C Research Laboratories, NEC Europe Ltd., Rathausallee 10, 53757 Sankt Augustin, Germany Tel.: +49 (0) 2241 - 92 52 - 95 Fax: +49 (0) 2241 - 92 52 - 99 From owner-parkbench-comm@CS.UTK.EDU Thu Jan 8 08:07:54 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA02383; Thu, 8 Jan 1998 08:07:53 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA05392; Thu, 8 Jan 1998 07:50:13 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA05383; Thu, 8 Jan 1998 07:50:03 -0500 (EST) Received: from mordillo (p108.nas1.is4.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA03072; Thu, 8 Jan 98 12:48:32 GMT Date: Thu, 8 Jan 98 12:10:55 GMT From: Mark Baker Subject: Re: Low Level benchmark errors and differences To: Charles Grassl , parkbench-comm@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <34B3F553.167E@cray.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am in agreement with Charles and Rolf about the low-level codes. We've known for some time that they (the codes) are less than perfect, if not in some cases flawed. At the SC'97 Parkbench meeting it was mooted that Parkbench should concentrate on producing, supporting, analysing and recording Low-Level codes and results. If this is the case then we should certainly ensure that what we support codes that are soundly written and produce consistent and reliable results. I certainly believe that a set of codes, akin to the low-level ones, should be part of the Parkbench suite. Maybe this is a good time to replace the current codes with those that Charles has produced !? As a side issue, I think we should produce C versions of whatever low-level codes we produce. Charles, I'd be interested in your thoughts on the codes that Pallas produce - ftp://ftp.pallas.de/pub/PALLAS/PMB/PMB10.tar.gz. These are C benchmark codes that run: PingPong - like comms1 PingPing - like comms2 Xover Cshift Exchange Allreduce Bcast Barrier - like synch1 Obviously, I would'nt like to comment on how well written they are or how reliable the results that they produce are. I'm relatively impressed with them. I also like the fact they try and produce results for commonly used MPI functions - cshift/exchange/etc. I've run the codes on NT boxes and they appear to produce results close to what I would expect. Regards Mark --- On Wed, 07 Jan 1998 15:36:19 -0600 Charles Grassl wrote: > To: Parkbench Low Level interests > From: Charles Grassl > > Subject: Low Level benchmark errors and differences > > Date: 7 January, 1998 > > > We should not produce or publish Parkbench Low level benchmark results > with the current suite of programs because the programs are inaccurate > and unreliable. I ran the Low Level programs and compared the results > with the same metrics as recorded from other benchmark programs. > The differences range from less than 5% (acceptable) to a factor of 6 > times difference, which is unacceptable. > > The differences, or "errors", are summarized in the table below. > The recorded differences in results from the Low Level program were > arrived at by comparing the Parkbench program reported metrics with the > same metrics as measured by alternative programs. > > > Table. Differences in Low Level benchmark results > for two systems. System A is an Origin 2000. > System B is a CRAY T3E. > > System A System B > Rinf Startup Rinf Startup > ----------------------------------------- > COMMS1 <10% 6x <5% 6x > COMMS2 2x 3x <5% <5% > COMMS3 <5% <5% > POLY1 <5% 60% 2x <5% > POLY2 <5% 60% 2x <5% > POLY3 - - 2x 80x > > > The Parkbench Low Level programs are occasionally requested for > benchmarking computer systems, but the results are usually rejected > because of their inaccuracy and unreliability. If not rejected, they > cause confusion and consternation because the results do not agree > with other measurements of the same variables. I emphasize that this > is not a case of obtaining optimization and favorable results for a > computer system. The problem is with the inaccuracy and unreliability > of the results. > > The Low Level programs measure and report low level parameters. > Therefore their value is in accuracy and utility. The programs do not > constitute definitions of the reported metrics and hence the results > should correlate with other measurements of the the same variables. > > The Low Level programs are obsolete and need to be replaced. I have > written seven simple programs, with MPI and PVM versions, and offer them > as a replacement for the Low Level suite. > > I strongly suggest that we delete or withdraw from distribution the > current Low Level suite. > ---------------End of Original Message----------------- ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 01/08/98 - Time: 12:10:55 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Mon Jan 12 16:02:28 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA26216; Mon, 12 Jan 1998 16:02:28 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA16631; Mon, 12 Jan 1998 15:38:05 -0500 (EST) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA16588; Mon, 12 Jan 1998 15:37:38 -0500 (EST) Received: from minnow.demon.co.uk ([158.152.73.63]) by post.mail.demon.net id aa2012292; 12 Jan 98 17:34 GMT Message-ID: Date: Mon, 12 Jan 1998 17:33:01 +0000 To: hempel@ccrl-nece.technopark.gmd.de Cc: parkbench-comm@CS.UTK.EDU, ritzdorf@ccrl-nece.technopark.gmd.de, zimmermann@ccrl-nece.technopark.gmd.de, clantwin@ess.nec.de, eckhard@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, tbeckers@ess.nec.de From: Roger Hockney Subject: Re: Low Level benchmark errors and differences In-Reply-To: <199801081018.LAA24864@sgi7.ccrl-nece.technopark.gmd.de> MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a To: Rolf, Charles, Mark and others, From: Roger I too am distressed to see the original COMMS1 code (written and tested for message lengths only up to 10^4) is still being issued by Parkbench and being used well outside its range of proven validity (message lengths now typically up to 10^7 or even 10^8). These problems were pointed out about one year ago by Charles and Ron, and as a result I worked on the code and issued to the committee a minmum set of changes to the current release that would solve many of the problems. These involve replacing five existing routines and adding two to the existing release. The routines involved have been downloadable from my Web site since about 12 March 1997 and have been used successfully at Westminster University in our work. The New COMMS1, as I called it, was the subject of two printed reports to the May 1997 meeting of Parkbench and further results were shown at the Sept 1997 meeting. There were also extensive discussions in this email group during 1997. Unfortunately my simple fixes were not inserted into the Parkbench release and as a result we are still getting a bad press from benchmarkers. After all the effort I put into solving this problem a year ago, I feel rather let down that my work was never used. If my changes had been encorporated into the Parkbenchmarks when they were offered at least as an interim measure, I believe we could have avoided much of the current bad publicity. I emphasise that the New COMMS1 was written as a minimum patch to the existing release to solve an urgent problem in the simplest way. I am not against a complete rethink of the low level benchmarks and now that MPI has become a recognised standard, benchmarks timing the principal software primitives of MPI would seem to be the most useful. Quite possibly Charles's or Mucci's codes could be used. However, I am still firmly convinced of the value of approximate parametric representation of all the benchmark measurements based on a simple performance model. Most of the existing low-level benchmarks were written primarily to determine such parameters and hence include both raw measurements and least squares curve fitting to obtain the parameters. I have yet to see data that cannot be satisfactorily fitted by 2 or 3 parameters, or two sets of 2-paras. And remember that I am talking here about fitting ALL the measured data by some simple formulae. After the decision of the May 1997 meeting to separate the raw measurements from the parametric curve fitting, the curve fitting will eventually become part of the "Parkbench Interactive Curve Fitting Tool" (PICT). At present this applet can be used to produce a manual curve fit, but eventually I will put up on my Web site a version in which the least squares and 3-point buttons are active. But PICT as it is can now be used manually to see how good or bad the 2-para and 3-para fits are. Turn your browser to: http://www.minnow.demon.co.uk/pict/source/pict2a.html and insert your raw data. I would be very interested to see what the NEC data looks like. To answer some of Rolf's points: Rolf Hempel writes > >1. The performance model is completely inadequate. A linear dependency > between time and message length, fitted to the measurements by > least squares, is bound to fail in the presence of discontinuities > caused by protocol changes. Most MPI implementations change > protocols for different message lengths for an overall performance > optimization. > Note that the original COMMS1 that you are using allows you to insert one break point to take account of one major discontinuity. Have you tried this? In any case, to make t_0 a good measure of startup it is sensible ALWAYS to make a breakpoint at say 100 or 1000 Byte, then the short message t_0 should be a good measure of startup. The long message t_0 is then not of interest and should be ignored. In this way one is using the straight- line fit over a short range of lengths, and the resulting t_0 should be a better estimate of latency because it is derived from several measurements rather than just selecting a single measurement (e.g. the time for the shortest message) -- surely a better experimental procedure. I emphasise that this procedure can be used now with the original COMMS1 to get sensible results. If there are many small discontinuities or changes of protocol then I expect you data is rather like that shown by Charles this time last year and used as an example in PICT. In this case the 3-para fit may give good results for your data as it did for Charles's. >2. To make things worse, the least square fit overweighs the data points > for very long messages, because the differences "model minus > measurement" are largest there in absolute terms. The fitted line, > therefore, more or less ignores the short message measurements. > As a result, the latencies are completely up to chance. > This is absolutely true and was discovered to be the problem one year ago. My solution, used in the New COMMS1, was and is to minimise the sum of the squares of the relative (rather than absolute) error. If this is done the values for short messages are not ignored in the way described, and t_0 is held much closer to the time for the smallest message length. Note also that the 3-parameter fit provided by New COMMS1 can be fitted exactly to the time for the shortest message, to the bandwidth for the longest message, and to the bandwidth near the mid point. This is the so-called 3-point fit, but it does require a third parameter. Can you please email me the output file for the NEC from the original COMMS1. I can then put this data through the New COMMS1 and see what two and three parameter fits are produced. Otherwise you could update your version of Parkbenchmarks with the 7 subroutines and rerun using New COMMS1. See the instructions at the end of this email. >28 usec. My colleague Hubert Ritzdorf then made an interesting >experiment: he removed some optimization from our MPI library for >long messages, thus INCREASING the communication times for messages >longer than 128000 bytes, and not changing anything for shorter >messages. The resulting DROP in latency from 28 to under 22 usec >clearly shows how ridiculous the COMMS1 benchmark is. > Hubert's results are just what one would expect from minimising the absolute error. I suspect you would not see this effect with New COMMS1 which does not over-emphasise the long message measurements. Please remember that the t_0 reported by COMMS1 is not a measurement of the time for any particular message length. It is the constant term in the fitted curve: t = t_0 + n/rinf which is an approximation to ALL the measured data. If you want to know the time, say for the smallest message length, then that is listed in the table of lengths and times reported in the benchmark output. If you mean by latency the time for the shortest message (hopefully zero or 1 Byte) then the COMMS1 measurements of this are in this table not in t_0. For those who missed my two earlier emailings on using the New COMMS1, I copy my earlier email below: Agenda Item : Plans for the next Release. -------------------------- Just a reminder that New COMMS1 as announced in my email to the committee of 16 Feb 1997, was designed as the minimum necessary changes to the existing release to solve the problems raised at the beginning of the year. It involves new versions of 5 routines and 2 new routines. In addition, the Make files need the 2 new routines added where appropriate. We have incorporated these changes at Westminster in the existing release without trouble. I believe that these should be incorported in the next release. In summary: New COMMS1 In directory: http://www.minnow.demon.co.uk/Pbench/comms1/ The 5 Changed Routines: (1) File COMMS1_1.F replaces the following file in the current release: ParkBench/Low_Level/comms1/src_mpi/COMMS1.f (2) File COMMS1_1.INC replaces ParkBench/Low_Level/comms1/src_mpi/comms1.inc (3) File ESTCOM_1.F replaces ParkBench/Low_Level/comms1/src_mpi/ESTCOM.f (4) File LSTSQ_1.F replaces ParkBench/lib/Low_Level/LSTSQ.f (5) File CHECK_1.F replaces Parkbench/lib/Low_Level/CHECK.f The 2 New Routines: (6) File LINERR_1.F add as ParkBench/lib/Low_Level/LINERR.f (7) File VPOWER_1.F add as ParkBench/lib/Low_Level/VPOWER.f Best wishes to you all Roger -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Tue Jan 13 08:38:07 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA17513; Tue, 13 Jan 1998 08:38:07 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA03191; Tue, 13 Jan 1998 08:20:10 -0500 (EST) Received: from sun1.ccrl-nece.technopark.gmd.de (sun1.ccrl-nece.technopark.gmd.de [193.175.160.67]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id IAA03184; Tue, 13 Jan 1998 08:20:07 -0500 (EST) Received: from sgi7.ccrl-nece.technopark.gmd.de (sgi7.ccrl-nece.technopark.gmd.de [193.175.160.89]) by sun1.ccrl-nece.technopark.gmd.de (8.7/3.4W296021412) with SMTP id OAA04953; Tue, 13 Jan 1998 14:19:47 +0100 (MET) Received: (from hempel@localhost) by sgi7.ccrl-nece.technopark.gmd.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA02202; Tue, 13 Jan 1998 14:18:30 +0100 Date: Tue, 13 Jan 1998 14:18:30 +0100 From: hempel@ccrl-nece.technopark.gmd.de (Rolf Hempel) Message-Id: <199801131318.OAA02202@sgi7.ccrl-nece.technopark.gmd.de> To: roger@minnow.demon.co.uk Subject: COMMS1 Benchmark Cc: tbeckers@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, eckhard@ess.nec.de, clantwin@ess.nec.de, parkbench-comm@CS.UTK.EDU Reply-To: hempel@ccrl-nece.technopark.gmd.de Dear Roger, thank you for your note on the COMMS1 benchmark. We didn't try the NEW COMMS1 code yet with our MPI library, so I cannot comment on its accuracy. I just would like to answer some of the issues you raised in your mail. Of course we have seen that in COMMS1 you can select a transition point between a short and a long model. For this choice, however, you have to be able to change the input data. In our case (a benchmark suite used in a procurement) our customer had provided the input dataset, and we were not allowed to change it. So, the only way for us to correct the results was to tune our MPI library to make it fit to the benchmark program. I don't think that this is what you had in mind when you wrote COMMS1. You didn't comment on the inaccuracies we found in the raw measurements. We ran several ping-pong benchmarks before, as, for example, the MPPTEST routine of MPICH, and they consistently give better latencies for short messages (difference approx. 25%). As I explained in my previous mail, we found the reason to be an improper correction for measurement overheads in COMMS1. Thus, the raw data are flawed, and this cannot be resolved by any parameter fitting. This is also the reason that I hesitate to send you the raw data reported by COMMS1 on our machine. I agree with you that it would be nice to have a few parameters to characterize the performance of any given system. The values for "n1/2" and "rinfinity" have been quite successful for vector arithmetic operations. The situation is, however, much more complicated for communication operations. As an example, let's take the famous ping-pong benchmark. We already discussed the problem of discontinuities caused by protocol changes. If you want to do a parameter fitting, the only reasonable solution seems to me that your test program automatically detects such points and handles the different protocols separately. If you leave the selection to an input parameter, you will inevitably run into the problem I discussed above. Even if you solve this problem, there remain many others. In modern (i.e. highly optimized) MPI implementations, the performance of a ping-pong operation crucially depends on the status of the two processes involved. Is the receiving process already waiting for the message? In a ping-pong, it usually is. This can make a huge difference! Also, the performance can also depend on the global number of processes active in the application. Not only do search lists in communication progress engines become shorter if there are fewer processes, but some implementers even went as far as writing special code for the case where you just have two processes. Ping-pong codes such as COMMS1 almost always just use two communicating processes, so they measure the best case. Another effect which is too often ignored is that messages can interfere with each other (both at the hardware and software level) if they are sent at the same time between different process pairs. All those effects combined cause a substantial difference between ping-pong results and measurements in real applications. In this situation the apparent precision of performance parameters can be quite misleading. If I want to judge the quality of an MPI implementation, I don't trust in best fit parameters so much. For the ping-pong code, I just look at a graphic representation of time versus message length for short messages, and another one of bandwidth versus message length for long messages. This way I can study discontinuities and other minor effects in detail. And then, take real applications and measure the communication times there. Then you will often find surprising results which you have never seen in a ping-pong benchmark. Best wishes, Rolf ------------------------------------------------------------------------ Rolf Hempel (email: hempel@ccrl-nece.technopark.gmd.de) Senior Research Staff Member C&C Research Laboratories, NEC Europe Ltd., Rathausallee 10, 53757 Sankt Augustin, Germany Tel.: +49 (0) 2241 - 92 52 - 95 Fax: +49 (0) 2241 - 92 52 - 99 From owner-parkbench-comm@CS.UTK.EDU Thu Jan 15 14:17:57 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id OAA00690; Thu, 15 Jan 1998 14:17:56 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA23858; Thu, 15 Jan 1998 13:55:08 -0500 (EST) Received: from timbuk.cray.com (timbuk-fddi.cray.com [128.162.8.102]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id NAA23830; Thu, 15 Jan 1998 13:54:57 -0500 (EST) Received: from ironwood.cray.com (root@ironwood-fddi.cray.com [128.162.21.36]) by timbuk.cray.com (8.8.7/CRI-gate-news-1.3) with ESMTP id LAA11159 for ; Thu, 15 Jan 1998 11:11:42 -0600 (CST) Received: from magnet.cray.com (magnet [128.162.173.162]) by ironwood.cray.com (8.8.4/CRI-ironwood-news-1.0) with ESMTP id LAA08650 for ; Thu, 15 Jan 1998 11:11:41 -0600 (CST) From: Charles Grassl Received: by magnet.cray.com (8.8.0/btd-b3) id RAA07227; Thu, 15 Jan 1998 17:11:40 GMT Message-Id: <199801151711.RAA07227@magnet.cray.com> Subject: Low Level Benchmarks To: parkbench-comm@CS.UTK.EDU Date: Thu, 15 Jan 1998 11:11:39 -0600 (CST) X-Mailer: ELM [version 2.4 PL24-CRI-d] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: Parkbench interests From: Charles Grassl Subject: Low Level benchmarks Date: 15 January, 1998 Mark, thank you for pointing us to the PMB benchmark. It is well written and coded, but has some discrepancies and shortcomings. My comments lead to suggestions and recommendation regarding low level communication benchmarks. First, in program PMB the PingPong tests are twice as fast (in time) as the corresponding message length tests in the PingPing tests (as run on a CRAY T3E). The calculation of the time and bandwidth is incorrect by a factor of 100% in one of the programs. This error can be fixed by recording, using and reporting the actual time, amount of data sent and their ratio. That is, the time should not be divided by two in order to correct for a round trip. This recorded time is for a round trip message, and is not precisely the time for two messages. Half the round trip message passing time, as reported in the PMB tests, is not the time for a single message and should not be reported and such. This same erroneous technique is used in the COMMS1 and COMMS2 two benchmarks. (Is Parkbench is responsible for propagating this incorrect methodology.) In program PMB, the testing procedure performs a "warm up". This procedure is a poor testing methodology because is discards important data. Testing programs such as this should record all times and calculate the variance and other statistics in order to perform error analysis. Program PMB does not measure contention or allow extraction of network contention data. Tests "Allreduce" and "Bcast" and several others stress the inter-PE communication network with multiple messages, but it is not possible to extract information about the contention from these tests. The MPI routines for Allreduce and Bcast have algorithms which change with respect to number of PEs and message lengths, Hence, without detailed information about the specific algorithms used, we cannot extract information about network performance or further characterize the inter-PE network. Basic measurements must be separated from algorithms. Tests PingPong, PingPing, Barrier, Xover, Cshift and Exchange are low level. Tests Allreduce and Bcast are algorithms. The algorithms Allreduce and Bcast need additional (algorithmic) information in order to be described in terms of the basic level benchmarks. With respect to low level testing, the round trip exchange of messages, as per PingPing and PingPong in PMB or COMMS1 and COMMS2, is not characteristic of the lowest level of communication. This pattern is actually rather rare in programming practice. It is more common for tasks to send single messages and/or to receive single messages. In this scheme, messages do not make a round trip and there is not necessarily caching or other coherency effects. The single message passing is a distinctly different case from that of round trip tests. We should be worried that the round trip testing might introduce artifacts not characteristic of actual (low level) usage. We need a better test of basic bandwidth and latency in order to measure and characterize message passing performance. Here are suggestions and requirements, in an outline form, for a low level benchmark design: I. Single and double (bidirectional) messages. A. Test single messages, not round trips. 1. The round trip test is an algorithm and a pattern. As such it should not be used as the basic low level test of bandwidth. 2. Use direct measurements where possible (which is nearly always). For experimental design, the simplest method is the most desirable and best. 3. Do not perform least squares fits A PIORI. We know that the various message passing mechanisms are not linear or analytic because different mechanisms are used for different message sizes. It is not necessarily known before hand where this transition occurs. Some computer systems have more than two regimes and their boundaries are dynamic. 4. Our discussion of least squares fitting is loosing tract of experimental design versus modeling. For example, the least squares parameter for t_0 from COMMS1 is not a better estimate of latency than actual measurements (assuming that the timer resolution is adequate). A "better" way to measure latency is to perform addition DIRECT measurements, repetitions or otherwise, and hence decrease the statistical error. The fitting as used in the COMMS programs SPREADS error. It does not reduce error and hence it is not a good technique for measuring such an important parameter as latency. B. Do not test zero length messages. Though valid, zero length messages are likely to take special paths through library routines. This special case is not particularly interesting or important. 1. In practice, the most common and important message size is 64 bits (one word). The time for this message is the starting point for bandwidth characterization. D. Record all times and use statistics to characterize the message passing time. That is, do not prime or warm up caches or buffers. Timings for unprimed caches and buffers give interesting and important bounds. These timings are also the nearest to typical usage. 1. Characterize message rates by a minimum, maximum, average and standard deviation. E. Test inhomogeneity of the communication network. The basic message test should be performed for all pairs of PEs. II. Contention. A. Measure network contention relative to all PEs sending and/or receiving messages. B. Do not use high level routines where the algorithm is not known. 1. With high level algorithms, we cannot deduce which component of the timing is attributable to the "operation count" and which is attributable to the actual system (hardware) performance. III. Barrier. A. Simple test of barrier time for all numbers of processors. Additionally, the suite should be easy to use. C and Fortran programs for direct measurements of message passing times are short and simple. These simple tests are of order 100 lines of code and, at least in Fortran 90, can be written in a portable and reliable manner. The current Parkbench low level suite does not satisfy the above requirements. It is inaccurate, as pointed out by previous letters, and uses questionable techniques and methodologies. It is also difficult to use, witness the proliferation of files, patches, directories, libraries and the complexity and size of the Makefiles. This Low Level suite is a burden for those who are expecting a tool to evaluate and investigate computer performance. The suite is becoming a liability for our group. As such, it should be withdrawn from distribution. I offer to write, test and submit a new set of programs which satisfy most of the above requirements. Charles Grassl SGI/Cray Research Eagan, Minnesota USA From owner-parkbench-comm@CS.UTK.EDU Fri Jan 16 09:12:18 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id JAA11774; Fri, 16 Jan 1998 09:12:18 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA16130; Fri, 16 Jan 1998 08:53:07 -0500 (EST) Received: from haven.EPM.ORNL.GOV (haven.epm.ornl.gov [134.167.12.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id IAA16123; Fri, 16 Jan 1998 08:53:06 -0500 (EST) Received: (from worley@localhost) by haven.EPM.ORNL.GOV (8.8.3/8.8.3) id IAA01963; Fri, 16 Jan 1998 08:52:17 -0500 (EST) Date: Fri, 16 Jan 1998 08:52:17 -0500 (EST) From: Pat Worley Message-Id: <199801161352.IAA01963@haven.EPM.ORNL.GOV> To: parkbench-comm@CS.UTK.EDU Subject: Re: Low Level Benchmarks In-Reply-To: Mail from 'Charles Grassl ' dated: Thu, 15 Jan 1998 11:11:39 -0600 (CST) Cc: worley@haven.EPM.ORNL.GOV, ritzdorf@ccrl-nece.technopark.gmd.de, zimmermann@ccrl-nece.technopark.gmd.de, clantwin@ess.nec.de, eckhard@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, tbeckers@ess.nec.de I have not been paying close attention to the current Low Level communication suite discussions, having confidence in capabilities and resolve of the current participants, but have decided to muddy the waters with a few personal observations. 1) I do not use the Low Level suite in my own performnace-related work. I find that the interpretation of results is much easier if the experiments are designed to answer (my) specific performance questions. Producing numbers that are accurate enough and whose experiments are well-enough understood to be used to answer arbitrary performance questions is much more difficult. 2) It may be time to revisit the goals of the Low Level suite. There are two obvious extremes. a) Determine some (hopefully representative) metrics of point-to-point communication performance, concentrating on making the measurements fair when comparing across platforms, but not requiring that the underlying architecture parameters be derivable from these numbers, or that they agree exactly with any other group's measurements. In this situation, a two (or more) parameter model fit to the data can be useful, if only as a shorthand for the raw data, but the model should not be expected to explain the data. b) Characterize the low level communication performance for each platform. Charles Grassl's latest recommendation is a first step in that direction. As a personal aside, I attempted such an exercise a few years ago (on the T3D, looking at the effect of common usage patterns on performance, not just ping-pong between nearest neighbors). I quickly became swamped by the amount of data and by the number of ways of presenting it (and the work was never written up). I realize now that my problem was trying to address too many evaluation questions simultaneously. In addition to the large amount of data required, an accurate characterization is likely to require more platform-specific elements, and will continue to evolve as new machines are added, in order to be as fair to the new machines as it is to the old ones. (The two parameter models are very acurrate for some of the previous generation of homogeneous message-passing platforms.) In case my sympathies are not clear, I prefer to revisit and fix the current suite, "dumbing it down", if only in presentation, making it clear what it does and does not measure. In my own work, the point-to-point measurements are only for establishing a general performance baseline. The important measures are the performance observed in the kernel and full application codes. The baseline measurements are simply to assess the "peak achieveable" communication performance. While a full characterization is an important thing to do, I do not believe that this group has the manpower, resources, or staying power to do it right. At one time in the past, we proposed to simply be a clearinghouse for the best of the performance measurement codes. If Charles wants to write and submit such an extensive low level suite, we can consider it, but in the meantime we should address the problems in the current suite, and not claim more than is appropriate. In particular, make sure that the customer does not become concerned that the vendor-stated latency and bandwidth does not match the PARKBENCH reported values. A discrepancy does not necessarily mean that someone is lying, simply that different aspects are being measured. But we should also be sure that intermachine comparisons using PARKBENCH measurements are valid, otherwise, they serve no purpose. Pat Worley PS. - I may be in the fringe, but all my codes are written using variants of SWAP and SENDRECV, and most of the codes I see can be written in such a fashion (and could gain something from it). So, ping-pong and ping-ping are not irrelevant to me. PPS. - Of course the real reason for using ping-pong is the difficulty in measuring the time for one-way messaging. I was not aware that this was a solved problem, at least at the MPI or PVM level. Perhaps system instrumentation can answer it, but I didn't know that portable measurement codes could be guaranteed to do so across the different platforms. From owner-parkbench-comm@CS.UTK.EDU Fri Jan 16 10:57:55 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA13381; Fri, 16 Jan 1998 10:57:55 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA20483; Fri, 16 Jan 1998 10:38:52 -0500 (EST) Received: from sun1.ccrl-nece.technopark.gmd.de (sun1.ccrl-nece.technopark.gmd.de [193.175.160.67]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id KAA20468; Fri, 16 Jan 1998 10:38:45 -0500 (EST) Received: from sgi7.ccrl-nece.technopark.gmd.de (sgi7.ccrl-nece.technopark.gmd.de [193.175.160.89]) by sun1.ccrl-nece.technopark.gmd.de (8.7/3.4W296021412) with SMTP id QAA09438; Fri, 16 Jan 1998 16:38:41 +0100 (MET) Received: (from hempel@localhost) by sgi7.ccrl-nece.technopark.gmd.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA04930; Fri, 16 Jan 1998 16:37:14 +0100 Date: Fri, 16 Jan 1998 16:37:14 +0100 From: hempel@ccrl-nece.technopark.gmd.de (Rolf Hempel) Message-Id: <199801161537.QAA04930@sgi7.ccrl-nece.technopark.gmd.de> To: parkbench-comm@CS.UTK.EDU Subject: Re: Low Level Benchmarks Cc: tbeckers@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, eckhard@ess.nec.de, clantwin@ess.nec.de, zimmermann@ccrl-nece.technopark.gmd.de, ritzdorf@ccrl-nece.technopark.gmd.de, hempel@ccrl-nece.technopark.gmd.de Reply-To: hempel@ccrl-nece.technopark.gmd.de I would like to send some remarks to the notes by Charles Grassl and Pat Worley on the problem of low-level communication benchmarks. As Pat pointed out, the ping-pong benchmark has been invented because generally there is no global clock by which you could measure the time for a single message. Everybody knows that this is no perfect solution, and in my previous mail I already explained some aspects of why ping-pong results can differ substantially from times found in real applications. So, I think we will have to use ping-pong tests in the future, with the caveat that they only measure a very special case of message-passing. If Charles knows a way to measure single messages, I would like to learn about it. In most other points I agree with Charles. I'm strongly convinced that the COMMS* routines are obsolete and should be replaced with something reasonable. In particular, the current routines are far too complicated to use, and give completely meaningless results. Therefore, I think one should not even try to correct the COMMS* routines, especially as there are already better alternatives available. One example is the PMB suite of PALLAS. It is relatively easy to use, but the documentation should provide more information than the internal calling tree given in the README file. What is missing is a precise definition of the underlying measuring methodology. I strongly prefer the output of timing tables (perhaps translated in good graphical representations) over crude parametrizations like the ones in the COMMS* benchmarks. Those can only frustrate the experts and confuse all other people. As to the definition of latency, Charles is right in saying that zero byte messages are dangerous because they often use special algorithms. The straightforward solution to use 1 byte messages instead is bad because usually messages are sent as multiples of 4 or 8 bytes, and for other message lengths some overhead by additional copying or even subroutine calls may be introduced. Since the lengths of most real messages are multiples of 4 or 8 bytes, I support Charles' proposal to measure the time for an 8 byte message and call it the latency. I think the warm-up phase before the actual benchmarking is important in order not to smear out initialization overheads over some number of messages. The time for the first ping-pong (or other operation), however, should be measured and compared with the time found for the following operations. I very much welcome Charles Grassl's kind offer to write a new benchmark suite. Perhaps there are even other suites available which could also be candidates for getting adopted by PARKBENCH. This forum meanwhile is quite well-known, which gives them considerable responsibility. PARKBENCH's choice of benchmark programs influences procurements of new machines world-wide, and the availability of a good set of low level benchmarks could give PARKBENCH a good reputation. I'm afraid that the current set of routines has the opposite effect. - Rolf Hempel ------------------------------------------------------------------------ Rolf Hempel (email: hempel@ccrl-nece.technopark.gmd.de) Senior Research Staff Member C&C Research Laboratories, NEC Europe Ltd., Rathausallee 10, 53757 Sankt Augustin, Germany Tel.: +49 (0) 2241 - 92 52 - 95 Fax: +49 (0) 2241 - 92 52 - 99 From owner-parkbench-comm@CS.UTK.EDU Fri Jan 16 12:46:04 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA14801; Fri, 16 Jan 1998 12:46:04 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA27007; Fri, 16 Jan 1998 12:29:03 -0500 (EST) Received: from haven.EPM.ORNL.GOV (haven.epm.ornl.gov [134.167.12.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA27000; Fri, 16 Jan 1998 12:29:01 -0500 (EST) Received: (from worley@localhost) by haven.EPM.ORNL.GOV (8.8.3/8.8.3) id MAA02149; Fri, 16 Jan 1998 12:29:01 -0500 (EST) Date: Fri, 16 Jan 1998 12:29:01 -0500 (EST) From: Pat Worley Message-Id: <199801161729.MAA02149@haven.EPM.ORNL.GOV> To: parkbench-comm@CS.UTK.EDU Subject: Re: Low Level Benchmarks In-Reply-To: Mail from 'hempel@ccrl-nece.technopark.gmd.de (Rolf Hempel)' dated: Fri, 16 Jan 1998 16:37:14 +0100 Cc: worley@haven.EPM.ORNL.GOV In most other points I agree with Charles. I'm strongly convinced that the COMMS* routines are obsolete and should be replaced with something reasonable. I have no problem with this. As I indicated, I have no experience with these. What is missing is a precise definition of the underlying measuring methodology. Perhaps this is the point that I was trying to make. Not only must the codes be easy to use, but the results should be easy to interpret. Every code should have a simple description of what it is measuring, what the data can be used for (and what it shouldn't be used for), and how to use the data. PARKBENCH needs to provide guidance in what data to collect, not just carefully crafted benchmark codes. And we need to describe clearly what low level communication tests are good for. For example, I have problems with low level contention tests. Understanding hotspots is an interesting exercise, but the connection to "real" codes is more subtle. Do we stress test, look at contention for given algorithms/global operators (and which algorithms), use some standard workload characterization as the background job, ...? For any given performance question, what should be used may be clear, but it is difficult to do this a priori. A simultaneous send/receive stress test may very well be something interesting to present, but we also need to be able to explain why (because it is typical in synchronous global communication operations?). In summary, I would like to see a prioritized list of what low level information is worth collecting, and why. We can then use this to choose or generate codes to do the testing. I apologize for being lazy. This may have already been laid out in the original ParkBench document, but I never worried about the low level tests before and don't have a copy of the document in front of me. Pat Worley From owner-parkbench-comm@CS.UTK.EDU Fri Jan 16 13:45:53 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id NAA15447; Fri, 16 Jan 1998 13:45:52 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA29375; Fri, 16 Jan 1998 13:15:58 -0500 (EST) Received: from c3serve.c3.lanl.gov (root@c3serve-f0.c3.lanl.gov [128.165.20.100]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id NAA29368; Fri, 16 Jan 1998 13:15:55 -0500 (EST) Received: from risc.c3.lanl.gov (risc.c3.lanl.gov [128.165.21.76]) by c3serve.c3.lanl.gov (8.8.5/1995112301) with ESMTP id LAA04436 for ; Fri, 16 Jan 1998 11:16:08 -0700 (MST) Received: from localhost (hoisie@localhost) by risc.c3.lanl.gov (950413.SGI.8.6.12/c93112801) with SMTP id LAA13115 for ; Fri, 16 Jan 1998 11:14:30 -0700 Date: Fri, 16 Jan 1998 11:14:30 -0700 (MST) From: Adolfy Hoisie To: parkbench-comm@CS.UTK.EDU Subject: Low Level Benchmarks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just to amplify some of the numerous excellent points made by Pat and Charles and Rolf, the emphasis of the Parkbench group, as I see it, should be on defining the methodology for benchmarking at this level. A string of numbers says very little about machine performance in absence of a solid, scientifcally defined underlying base for the programs utilized for benchmarking. COMMS is obsolete in methodology, coding and generation and analysis of results. As such, I have used it quite some time ago only to reach the conclusions above. Instead, I always chose to write my own benchmarking programs in order to extract meaningful data for the applications I was working on. I would like to see the debate heading towards what is it that we need to measure in a suite of general use that is applicable to machines of interest. For example, very little or no attention is being paid to benchmarking DSM architectures, where quite a few architectural parameters become harder to define and subtler to interpret. Including, but not limited to, message passing characterization on these architectures. Adolfy ====================================================================== Adolfy Hoisie \ Los Alamos National Laboratory \Scientific Computing, CIC-19, MS B256 hoisie@lanl.gov \ Los Alamos, NM 87545 USA \ Phone: 505-667-5216 http://www.c3.lanl.gov/~hoisie/hoisie.html FAX: 505-667-1126 From owner-parkbench-comm@CS.UTK.EDU Sun Jan 18 07:38:42 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id HAA20627; Sun, 18 Jan 1998 07:38:42 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA21662; Sun, 18 Jan 1998 07:28:22 -0500 (EST) Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.154]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA21655; Sun, 18 Jan 1998 07:28:20 -0500 (EST) Received: from minnow.demon.co.uk ([158.152.73.63]) by post.mail.demon.net id aa1002926; 18 Jan 98 12:25 GMT Message-ID: Date: Sun, 18 Jan 1998 12:24:20 +0000 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: Low Level Benchmarks MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a To: the low-level discussion group From: Roger I comment below on recent emailings on this topic which arrived on the 16 Jan 1998. Pat Worley writes: >2) It may be time to revisit the goals of the Low Level suite. There ar > are two obvious extremes. > > a) Determine some (hopefully representative) metrics of point-to-po > point communication performance, concentrating on making the > measurements > SNIP > In this situation, a two (or more) parameter model fit to the > data can be useful, if only as a shorthand for the raw data, > but the model should not be expected to explain the data. This is of course what COMMS1 sets out to do. But please when judging this point, use the New COMMS1 revised code that DOES give much more sensible answers in difficult cases. Please do not base your opinions on results from the Original COMMS1 code that is still unfortunately being issued by Parkbench. Instructions for getting the new code was given in my email to this group on 12 Jan 1998. > (The two parameter models are very accurate for some of the > previous generation of homogeneous message-passing platforms.) It is nice to have confirmation of this from an independent source. In addition, the 3-parameter mode is available in New COMMS1 for cases where the 2-para fails. > In case my sympathies are not clear, I prefer to revisit and fix > the current suite, "dumbing it down", if only in presentation, > making it clear what it does and does not measure. Again this was my objective in writting the New COMMS1 as a minimum fix to the existing Original COMMS1. However I don't think I would call this "Dumbing Down". In fact New COMMS1 is a "Smartening UP" of the benchmark because it provides a 3-parameter fit for those cases for which the 2-para fit fails. It also reports the Key spot values of "time for shortest message (which Charles and Rolfe want to call the Latency)" and bandwidth for longest message (this could equally well be the maximum measured bandwidth). It also compares the fitted values with measured values at these key points. The fit formulae are also given in the output for completeness. Pleas note that COMMS1 has always reported ALL the measured lengths and times in the output file as the basic data, and ALL spot bandwidths were printed to the screen as measured, and could be captured in a file if required. In New COMMS1 the spot bandwidths are more conveniently included in the standard output file as they should have been in the first place. Unfortunately the above additions make the new output file more complex (which I am not happy about). An example of New COMMS1 output is attached at the end of this email. >PPS. - Of course the real reason for using ping-pong is the difficulty > in measuring the time for one-way messaging. I was not aware > that this was a solved problem, at least at the MPI or PVM > level. Perhaps system instrumentation can answer it, but I > didn't know that portable measurement codes could be guaranteed > to do so across the different platforms. Exactly so. ******************************* Rolf Hempel writes: >of message-passing. If Charles knows a way to measure single messages, >I would like to learn about it. Me too. >In most other points I agree with Charles. I'm strongly convinced that >the COMMS* routines are obsolete and should be replaced with something >reasonable. In particular, the current routines are far too complicated >to use, and give completely meaningless results. Therefore, I think one Please base your judgement on the results from New COMMS1 which has a much more satisfactory fitting procedure (see the examples in the PICT tool mentioned below). I believe that the revised program New COMMS1 gives reasonable results and is not obselete. >README file. What is missing is a precise definition of the underlying >measuring methodology. In contrast, the methodology of the COMMS1 curve fitting is given in the Parkbench Report and in detail in my book "The Science of Computer Benchmarking", see: http://www.siam.org/catalog/mcc07/hockney.htm >I strongly prefer the output of timing tables (perhaps translated in >good graphical representations) over crude parametrizations like the >ones in the COMMS* benchmarks. Those can only frustrate the experts >and confuse all other people. You seem to have failed to notice that both the Original COMMS1 and the New COMMS1 report the timing table as the FIRST part of their output files. Further a good graphical representation is available using the database tool from Southampton and my own PICT tool (see below) The COMMS1 fitting procedure is not crude. On the contrary it uses least-squares fitting of a performance model that is quite satisfactory for a lot of data. In minimising relative rather than absolute error, New COMMS1 spreads the error in a much more satisfactory way and allows the fitting to be used over a much longer range of message lengths. Furthermore where the 2-parameter model is unsuitable, New COMMS1 provides a 3-parameter model which fits the Cray T3E (Charles's data 17 Dec 96) very well. I don't think one can call all this crude. To see how good the 2 and 3 parameter fits produced by New COMMS1 are to recent data, check out the examples on my Parkbench Interactive Curve Fitting Tool (PICT) at: http://www.minnow.demon.co.uk/pict/source/pict2a.html For the most part these show that 2-parameters fit the data surprisingly well. The parameters are not meaningless and useless, but often a rather good summary of the measurements. The 3-parameter fit is described quite fully in my talk to the 11 Sep 1997. I have finally written this up with pretty pictures for the PEMCS Web Journal. Look at: http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/ talks/Roger-Hockney/perfprof1.html In truth we need to see a lot more data before judging the usefulness of parametric fitting. That is why I would like to look at your NEC results. These need not be the timings from COMMS1, but any pingpong measurements that you regard as "good". Please do not base your opinion on the results produced by the Original COMMS1 which is presently in the Parkbench suit. This will only work satisfactorily results for message lengths up to about 4*10^4. When used outside this range it may produce useless numbers. >messages are multiples of 4 or 8 bytes, I support Charles' proposal to >measure the time for an 8 byte message and call it the latency. I am STRONGLY opposed to this. Latency is an ambiguous term that has different meanings to different people. If we wish to report the time for an 8-byte message we should call it what it is, no more no less, eg: t(n=8B) = 45.6 us To call this latency only leads to confusion and senseless misunderstanding and argument. **************************************************************** EXAMPLE NEW COMMS1 OUTPUT FILE: T3E Results from Grassl's 17 Dec 1996 email to Parkbench committee **************************************************************** ================================================= === === === GENESIS / ParkBench Parallel Benchmarks === === === === comms1_mpi === === === ================================================= Pingpong Benchmark: ------------------- Measures time to send a message between two nodes on a multi-processor computer (MPP or network) as a function of the message length. It also characterises the time and corresponding bandwidth by both two and three performance parameters. Original code by Roger Hockney (1986/7), modified by Ian Glendinning and Ade Miller (1993/4), and by Roger Hockney and Ron Sercely (1997). ----------------------------------------------------------------------- You are running the VERSION dated: RWH-12-Mar-1997 ----------------------------------------------------------------------- The measurement time requested for each test case was 1.00E+00 seconds. No distinction was made between long and short messages. Zero length messages were not used in least squares fitting. ----------------------------------------------- (1) PRIMARY MEASUREMENTS (BW=Bandwidth, B=Byte) ----------------------------------------------------------------------- SPOT MEASURED VALUES | EVOLVING TWO-PARAMETER FIT --------------------------------------|-------------------------------- POINT LENGTH(n) TIME(t) BW(r=n/t) | rinf nhalf RMS rel B s B/s | B/s B error % *SPOT1*-------------------------------|-------------------------------- 1 8.000E+00 1.260E-05 6.349E+05 | 0.000E+00 0.000E+00 0.000E+00 2 1.000E+01 1.348E-05 7.418E+05 | 2.273E+06 2.064E+01 -1.255E-06 3 2.000E+01 1.380E-05 1.449E+06 | 1.237E+07 1.516E+02 2.277E+00 4 3.000E+01 1.590E-05 1.887E+06 | 7.798E+06 9.157E+01 2.762E+00 5 4.000E+01 1.561E-05 2.562E+06 | 1.020E+07 1.237E+02 3.267E+00 6 5.000E+01 1.648E-05 3.034E+06 | 1.115E+07 1.366E+02 3.126E+00 7 6.000E+01 1.618E-05 3.708E+06 | 1.364E+07 1.711E+02 3.796E+00 8 7.000E+01 1.773E-05 3.948E+06 | 1.356E+07 1.699E+02 3.552E+00 9 8.000E+01 1.694E-05 4.723E+06 | 1.562E+07 1.992E+02 4.072E+00 10 9.000E+01 1.793E-05 5.020E+06 | 1.634E+07 2.095E+02 3.954E+00 11 1.000E+02 1.802E-05 5.549E+06 | 1.741E+07 2.249E+02 3.983E+00 12 1.100E+02 1.889E-05 5.823E+06 | 1.776E+07 2.300E+02 3.841E+00 13 1.200E+02 1.780E-05 6.742E+06 | 1.983E+07 2.607E+02 4.483E+00 14 1.300E+02 1.917E-05 6.781E+06 | 2.034E+07 2.682E+02 4.368E+00 15 1.400E+02 1.902E-05 7.361E+06 | 2.131E+07 2.828E+02 4.405E+00 16 1.500E+02 1.941E-05 7.728E+06 | 2.209E+07 2.946E+02 4.389E+00 17 1.600E+02 1.896E-05 8.439E+06 | 2.353E+07 3.167E+02 4.644E+00 18 1.700E+02 2.057E-05 8.264E+06 | 2.362E+07 3.179E+02 4.514E+00 19 1.800E+02 1.911E-05 9.419E+06 | 2.526E+07 3.434E+02 4.887E+00 20 1.900E+02 2.125E-05 8.941E+06 | 2.517E+07 3.420E+02 4.765E+00 21 2.000E+02 1.894E-05 1.056E+07 | 2.730E+07 3.754E+02 5.382E+00 22 2.100E+02 2.091E-05 1.004E+07 | 2.767E+07 3.812E+02 5.282E+00 23 2.200E+02 2.011E-05 1.094E+07 | 2.885E+07 3.998E+02 5.393E+00 24 2.300E+02 2.136E-05 1.077E+07 | 2.915E+07 4.047E+02 5.296E+00 25 2.400E+02 2.015E-05 1.191E+07 | 3.053E+07 4.268E+02 5.496E+00 26 2.500E+02 2.228E-05 1.122E+07 | 3.047E+07 4.258E+02 5.390E+00 27 2.600E+02 2.144E-05 1.213E+07 | 3.110E+07 4.360E+02 5.365E+00 28 2.700E+02 2.212E-05 1.221E+07 | 3.142E+07 4.412E+02 5.290E+00 29 2.800E+02 2.111E-05 1.326E+07 | 3.249E+07 4.588E+02 5.417E+00 30 2.900E+02 2.259E-05 1.284E+07 | 3.272E+07 4.626E+02 5.337E+00 31 3.000E+02 2.284E-05 1.313E+07 | 3.294E+07 4.663E+02 5.262E+00 32 4.000E+02 2.256E-05 1.773E+07 | 3.550E+07 5.098E+02 5.818E+00 33 6.000E+02 2.549E-05 2.354E+07 | 4.022E+07 5.921E+02 6.632E+00 34 8.000E+02 2.817E-05 2.840E+07 | 4.567E+07 6.883E+02 7.296E+00 35 1.000E+03 3.253E-05 3.074E+07 | 4.887E+07 7.452E+02 7.451E+00 36 2.000E+03 4.496E-05 4.448E+07 | 5.553E+07 8.657E+02 8.013E+00 37 5.000E+03 6.135E-05 8.150E+07 | 7.983E+07 1.312E+03 1.090E+01 38 1.000E+04 8.579E-05 1.166E+08 | 1.070E+08 1.814E+03 1.284E+01 39 2.000E+04 1.294E-04 1.546E+08 | 1.339E+08 2.315E+03 1.426E+01 40 3.000E+04 1.722E-04 1.742E+08 | 1.523E+08 2.659E+03 1.493E+01 41 4.000E+04 2.161E-04 1.851E+08 | 1.647E+08 2.890E+03 1.524E+01 42 5.000E+04 2.594E-04 1.928E+08 | 1.735E+08 3.056E+03 1.539E+01 43 1.000E+05 4.534E-04 2.206E+08 | 1.847E+08 3.266E+03 1.575E+01 44 2.000E+05 7.784E-04 2.569E+08 | 1.996E+08 3.548E+03 1.648E+01 45 3.000E+05 1.110E-03 2.703E+08 | 2.123E+08 3.787E+03 1.701E+01 46 5.000E+05 1.697E-03 2.946E+08 | 2.256E+08 4.039E+03 1.762E+01 47 1.000E+06 3.276E-03 3.053E+08 | 2.370E+08 4.255E+03 1.806E+01 48 2.000E+06 6.373E-03 3.138E+08 | 2.468E+08 4.440E+03 1.839E+01 49 3.000E+06 9.489E-03 3.162E+08 | 2.547E+08 4.590E+03 1.858E+01 50 5.000E+06 1.569E-02 3.187E+08 | 2.612E+08 4.714E+03 1.870E+01 51 1.000E+07 3.134E-02 3.191E+08 | 2.666E+08 4.816E+03 1.874E+01 *SPOT2*---------------------------------------------------------------- ------------------------ COMMS1: Message Pingpong ------------------------ Result Summary -------------- ------------------- (2) KEY SPOT VALUES ------------------- ----------------------- *KEY1* Shortest n = 8.000E+00 B, | t = 1.260E-05 s | ****** | | ****** *KEY2* Longest n = 1.000E+07 B, | r = 3.191E+08 B/s | ****** ----------------------- ----------------------------------------------------------------------- -- ------------------------------------------ (3) BEST TWO-PARAMETER LINEAR-(t vs n) FIT ------------------------------------------ (Minimises sum of squares of relative error at all points being fitted) Root Mean Square (RMS) Relative Error in time = 18.74 % Maximum Relative Error in time = 43.61 % at POINT = 1 This is a fit to ALL points. Even though different expressions are given for short and long messages, they are algebraically identical and either may be used for any message length in the full range. -------------- Short Messages -------------- Best expressions to use if nhalf > 0 and n <= nhalf = 4.816E+03 B Bandwidth fitted to: r = pi0*n/(1+n/nhalf) Time fitted to: t = t0*(1+n/nhalf) -------------------------------------------- *LIN1* | pi0 = 5.536E+04 Hz, nhalf= 4.816E+03 B | ****** | | ****** *LIN2* | t0 = 1/pi0 = 1.807E-05 s | ****** -------------------------------------------- Spot comparison at POINT = 1, n = 8.000E+00 B t(fit) = 1.810E-05 s, t(measured) = 1.260E-05 s, relative error in time = 43.6 % ------------- Long Messages ------------- Best expressions to use if n > nhalf = 4.816E+03 B, or nhalf=0 Bandwidth fitted to: r = rinf/(1+nhalf/n) Time fitted to: t = (n+nhalf)/rinf ----------------------------------------------- *LIN3* | rinf = 2.666E+08 B/s, nhalf = 4.816E+03 B | ****** ----------------------------------------------- Spot comparison at POINT = 51, n = 1.000E+07 B r(fit) = 2.665E+08 B/s, r(measured) = 3.191E+08 B/s, relative error in B/W = -16.5 % ----------------------------------------------------------------------- -- --------------------------------------- (4) BEST 3-PARAMETER VARIABLE-POWER FIT --------------------------------------- Root Mean Square (RMS) Relative Error in B/W = 6.89 % Maximum Relative Error in B/W = -13.41 % at POINT = 39 This fit is to ALL data points Bandwidth is fitted to: rvp = rivp/(1+(navp/n)^gamvp)^(1/gamvp) Time is fitted to: tvp = t0vp*(1+(n/navp)^gamvp)^(1/gamvp) where t0vp = navp/rivp and navp = t0vp*rivp When gamvp = 1.0, this form reduces to the linear-time form (3) above, navp becomes nhalf, and rivp becomes rinf. The three independent parameters are (t0vp is derived): ------------------------------------------------------------- *VPWR1* | rivp = 3.475E+08 B/s, navp = 3.670E+03 B, gamvp = 4.190E-01 | | | *VPWR2* | t0vp = navp/rivp = 1.056E-05 s | ------------------------------------------------------------- This function is guaranteed to fit the first and last measured values of time and bandwidth. It also fits the (interpolated) time and bandwidth at n = navp. -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Mon Jan 19 13:10:51 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id NAA16306; Mon, 19 Jan 1998 13:10:50 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA21116; Mon, 19 Jan 1998 12:53:17 -0500 (EST) Received: from haze.vcpc.univie.ac.at (haze.vcpc.univie.ac.at [131.130.186.138]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA21105; Mon, 19 Jan 1998 12:53:14 -0500 (EST) Received: (from smap@localhost) by haze.vcpc.univie.ac.at (8.8.6/8.8.6) id SAA21164 for ; Mon, 19 Jan 1998 18:53:11 +0100 (MET) From: Ian Glendinning Received: from fidelio(131.130.186.155) by haze via smap (V2.0beta) id xma021162; Mon, 19 Jan 98 18:52:48 +0100 Received: (from ian@localhost) by fidelio.vcpc.univie.ac.at (8.7.5/8.7.3) id SAA03411 for parkbench-comm@CS.UTK.EDU; Mon, 19 Jan 1998 18:52:48 +0100 (MET) Date: Mon, 19 Jan 1998 18:52:48 +0100 (MET) Message-Id: <199801191752.SAA03411@fidelio.vcpc.univie.ac.at> To: parkbench-comm@CS.UTK.EDU Subject: Re: Low Level benchmark errors and differences X-Sun-Charset: US-ASCII Dear parkbench-comm subscriber, I have been following the discussions regarding the low-level ParkBench benchmarks over the last couple of weeks with intertest, but so far I have been content to keep my head below the parapet, as most of the things I would have said have been said by others anyway. However, there is one thing that I would like to point out. On Wed Jan 7 22:56:04 1998, Charles Grassl wrote: > The Low Level programs are obsolete and need to be replaced. I agree that the existing code could use some improvement, though most of the discussion seems to have revolved around the version in the "current release", which as Roger has pointed out several times is very old, and he has written an improved version. Have people tried that version out? > I have > written seven simple programs, with MPI and PVM versions, and offer them > as a replacement for the Low Level suite. I have tried a version of Charles's "comms1" code that he sent me, on our CS-2 system, and found that it reported approximately half the expected asymptotic bandwidth, so this code is not without its problems either! By "expected", I mean the bandwidth reported by various versions of (the ParkBench version of) COMMS1 over the years, coded using first PARMACS, then PVM, and more recently MPI, as a message-passing library. This value corresponds closely to what one would expect for the peak performance, given the performance figures for the underlying hardware. For an explanation of what I think is happening, please read on... On Thu Jan 15 20:20:36 1998, Charles Grassl wrote: > This recorded > time is for a round trip message, and is not precisely the time for > two messages. Half the round trip message passing time, as reported in > the PMB tests, is not the time for a single message and should not be > reported and such. This same erroneous technique is used in the COMMS1 > and COMMS2 two benchmarks. (Is Parkbench is responsible for propagating > this incorrect methodology.) As Pat Worley and Rolf Hempel pointed out, the ping-pong is used because of the difficulty in measuring the time for one-way messages, and I believe that this is illustrated in this instance, as it seems that Charles's attempt to time one-way messages has caused the unexpectedly low asymptotic bandwidth measurement... Charles's code executes a send, and then as fast as possible executes another one, without any concern as to whether the data has left the sending processor, or has arrived at the receiving processor, and what I think is happening is that his code is queuing requests to send, before the previous messages have left the sending processor, forcing the MPI implementation to buffer them, at the cost of an extra copy operation, which would not otherwise have been necessary, thus reducing the effective bandwidth! > With respect to low level testing, the round trip exchange of messages, > as per PingPing and PingPong in PMB or COMMS1 and COMMS2, is not > characteristic of the lowest level of communication. This pattern > is actually rather rare in programming practice. It is more common > for tasks to send single messages and/or to receive single messages. It seems to me that it is not very common programming practice to send a sequence of messages to the same destination in rapid fire, without having either done some intermediate processing, or waiting to get some response back. If you were trying to code efficiently, you would doubtless merge the messages into one, and send the data all together in one message, if it was all available already, which it must have been if you were able to execute the sends so rapidly one after another! > The single message passing is a distinctly different case from that > of round trip tests. We should be worried that the round trip testing > might introduce artifacts not characteristic of actual (low level) usage. > We need a better test of basic bandwidth and latency in order to measure > and characterize message passing performance. Well, it seems that in this case, the attempt to measure the single message passing case has introduced an artifact. To an extent it depends what you are trying to measure of course, but it has always been my understanding that the COMMS1 benchmark was trying to measure the peak performance that you could reasonably expect to obtain using a portable message-passing library interface, which, for a good implementation of MPI, ought to come close to the theoretical hardware limit, which is precisely what the existing COMMS1 ping-pong code does on our system. I would therefore argue in favour of retaining the ping-pong technique for obtaining timings. Ian -- Ian Glendinning European Centre for Parallel Computing at Vienna (VCPC) ian@vcpc.univie.ac.at Liechtensteinstr. 22, A-1090 Vienna, Austria Tel: +43 1 310 939612 WWW: http://www.vcpc.univie.ac.at/~ian/ From owner-parkbench-comm@CS.UTK.EDU Tue Jan 20 08:50:06 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA06977; Tue, 20 Jan 1998 08:50:06 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA01200; Tue, 20 Jan 1998 08:28:44 -0500 (EST) Received: from sun1.ccrl-nece.technopark.gmd.de (sun1.ccrl-nece.technopark.gmd.de [193.175.160.67]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id IAA01193; Tue, 20 Jan 1998 08:28:39 -0500 (EST) Received: from sgi7.ccrl-nece.technopark.gmd.de (sgi7.ccrl-nece.technopark.gmd.de [193.175.160.89]) by sun1.ccrl-nece.technopark.gmd.de (8.7/3.4W296021412) with SMTP id OAA12945; Tue, 20 Jan 1998 14:19:53 +0100 (MET) Received: (from hempel@localhost) by sgi7.ccrl-nece.technopark.gmd.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA09828; Tue, 20 Jan 1998 14:19:52 +0100 Date: Tue, 20 Jan 1998 14:19:52 +0100 From: hempel@ccrl-nece.technopark.gmd.de (Rolf Hempel) Message-Id: <199801201319.OAA09828@sgi7.ccrl-nece.technopark.gmd.de> To: cmg@cray.com Subject: Re: Low Level Benchmarks Cc: hempel@ccrl-nece.technopark.gmd.de, parkbench-comm@CS.UTK.EDU Reply-To: hempel@ccrl-nece.technopark.gmd.de Dear Charles, thank you for your note, and for sending me your simple test program. One thing I like about the program is that it's easy to install and run; no complicated makefiles, include files and sophisticated driver software. We had the code running in five minutes. In many points I agree with Ian Glendinning who already reported about his tests with your code on the Meiko system. When we ran the test on our SX-4, however, the results were very similar to ping-pong figures. With the particular MPI version I used for my measurements, the classical ping-pong test as implemented in MPPTEST of the MPICH distribution gives about 4 usec less time in latency and about 4% higher throughput than your test program. The reason for the increase in latency as reported by your code is fully explained by the fact that you forgot to correct for the time spent in the timer routine (see below). So, we would have no problem with adopting a corrected version of your code as the basic communication test. However, I think that this is not the point. The question we have to answer is what communication pattern we want to measure with our benchmark code. In my view the ping-pong technique, with all its problems, is much closer to a typical application than your program. Of course, the situation "receiver already waiting" implemented by the ping-pong, is a special case which will not be found for all messages in an application. In this situation, the MPI implementation can use a more efficient protocol, which will lead to a best case measurement of latency and throughput. I agree with Ian that the rapid succession of messages in one direction is very untypical. Only a stupid programmer would do it this way in an application, and not aggregate the messages to a larger one. What you really measure with this benchmark is how well the MPI library can deal with this kind of congestion. As you see, our library is not affected at all by this, but, as Ian reported, the Meiko shows a much different behaviour. In a sense, you measure a kind of worst case scenario, as opposed to the best case one in the ping-pong. One technical detail of your program: You time every send operation separately, and then sum up the individual times. This requires a quite accurate clock. I would expect that some machines could run into trouble with this approach. Also, you don't correct for the time needed for calling the timer twice for every send/receive. On machines with highly optimized MPI libraries this is not at all negligible. On our machine two timer calls require as much time as 25% of a complete send-receive sequence! As a summary, your basic communication program does not convince me as a better alternative to ping-pong programs such as MPPTEST. The only thing I really like about it is its simplicity. Best regards, Rolf ------------------------------------------------------------------------ Rolf Hempel (email: hempel@ccrl-nece.technopark.gmd.de) Senior Research Staff Member C&C Research Laboratories, NEC Europe Ltd., Rathausallee 10, 53757 Sankt Augustin, Germany Tel.: +49 (0) 2241 - 92 52 - 95 Fax: +49 (0) 2241 - 92 52 - 99 From owner-parkbench-comm@CS.UTK.EDU Wed Jan 21 11:22:06 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id LAA27346; Wed, 21 Jan 1998 11:22:06 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA20207; Wed, 21 Jan 1998 10:55:58 -0500 (EST) Received: from sun1.ccrl-nece.technopark.gmd.de (sun1.ccrl-nece.technopark.gmd.de [193.175.160.67]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id KAA20176; Wed, 21 Jan 1998 10:55:44 -0500 (EST) Received: from sgi7.ccrl-nece.technopark.gmd.de (sgi7.ccrl-nece.technopark.gmd.de [193.175.160.89]) by sun1.ccrl-nece.technopark.gmd.de (8.7/3.4W296021412) with SMTP id QAA01123; Wed, 21 Jan 1998 16:50:13 +0100 (MET) Received: (from hempel@localhost) by sgi7.ccrl-nece.technopark.gmd.de (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA11663; Wed, 21 Jan 1998 16:54:00 +0100 Date: Wed, 21 Jan 1998 16:54:00 +0100 From: hempel@ccrl-nece.technopark.gmd.de (Rolf Hempel) Message-Id: <199801211554.QAA11663@sgi7.ccrl-nece.technopark.gmd.de> To: parkbench-comm@CS.UTK.EDU Subject: NEW COMMS1 benchmark Cc: eckhard@ess.nec.de, tbeckers@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, maciej@ccrl-nece.technopark.gmd.de, ritzdorf@ccrl-nece.technopark.gmd.de, zimmermann@ccrl-nece.technopark.gmd.de, springstubbe@gmd.de, hempel@ccrl-nece.technopark.gmd.de Reply-To: hempel@ccrl-nece.technopark.gmd.de In the recent discussion on the low-level benchmarks, Roger repeatedly asked us to base our evaluation of the COMMS1 benchmark on his new version, and not on the one which is still in the official PARKBENCH distribution. At NEC we now have repeated the tests on the NEC SX-4 machine, and I would like to make a few comments on the results. First of all, the raw data as reported by the table Primary Measurements more closely match the figures given by other ping-pong tests than the older version. The correction for oeverheads, however, is still problematic for the following reasons: 1. In every loop iteration, the returned message is compared with the message sent. If one is concerned with the correctnes of the MPI library, this could be checked in a separate loop before the timing loop. The check inside the timing loop, done only by the sender process, delays the sender and thus makes sure that the receiver is already waiting in the receive for the next message. This aggravates the "Receiver ready" situation which I discussed in an earlier mail. 2. The authors take great care in correcting for the overhead introduced by the do loop. This is done by the loop over the dummy routine before the main loop. On the other hand, the correction for the check routine call introduces an overhead of one timer call which is NOT taken into account. (Here I assume that the internal clock is read out at a fixed point in time during every call of DWALLTIME00().) I would argue that on most machines the loop overhead per iteration is negligible as compared to a function call. On our machine, MPI_Wtime calls a C function which in turn calls an assembly language routine. The time needed for this is about 10% of our message latency! Another problem in the measuring procedure is that the test message contains a single constant, repeated as many times as there are words in the message. Did the authors never think about the possibility of data compression in interconnect systems? I would not be surprised to see bandwidths of Terabytes/sec on some Ethernet connection between workstations. Apart from this, the raw data are much better now than they were before, and when the above points were fixed, the resulting table would be satisfactory. The interesting question is, however, how much added value we get from the parameter fitting. In my earlier note, I called the fitting procedure in the earlier COMMS1 benchmark "crude". I cannot find a more appropriate word for a model which in cases deviates from the measured values by more than 100%. So, how much improvement do we get from the revised COMMS1 version? As Roger said himself, the increase in modeling sophistication led to a more complicated output file. Results are now given for two models, the first one using two parameters, and the second one three. As could be expected, the two-parameter model does not work better than in the previous version. For our machine, latency is over-estimated by 18.9 percent, and the bandwidth at the last data point is off by 27%. Since a linear model is just too simple to be applied to modern message-passing libraries, I wonder why these results are still in the output file at all. The three-parameter fit is better than the two-parameter one. The major advantage is that it exactly matches the first data point in time, and the last data point in bandwidth. That is what people would look at, if there were no parameter fitting at all. So, the reported latency is the time measured for a zero-byte message, and is as good or as bad as this measurement. For our MPI library, the RMS fitting error for the whole data set is 14.04%, and the maximum relative error is 33.4%. We now can discuss the meaning of the word "crude" (and I apologize if as a non-native speaker I don't use the right word here), but I would at least call it unsatisfactory. Given those differences between model and measurements, I was not surprised to see the projected RINFINITY as being too high. The 7.65 GBytes/s are well beyond a memcpy operation in our shared memory, and measured rates never exceeded 7.1 GBytes/s. To summarize, in my opinion there is no added value given by the parameter fitting. The latency value is the first entry in the raw data table, and the asymptotic bandwidth is easy to figure out by just looking at the bandwidths as measured for very long messages. As explained above, the extrapolation by the parametrized model does not add any precision as compared with a guess based on the long-message table entries. For message lengths in between, what does a model help me if it deviates from the measurements by up to 33%? So, my conclusion would be to drop the whole parameter fitting from the PARKBENCH low-level routines. In a separate mail I will send the COMMS1 benchmark output, as produced with our MPI library, to Roger. I don't want to swamp the whole PARKBENCH forum with the detailed data. Best regards, Rolf ------------------------------------------------------------------------ Rolf Hempel (email: hempel@ccrl-nece.technopark.gmd.de) Senior Research Staff Member C&C Research Laboratories, NEC Europe Ltd., Rathausallee 10, 53757 Sankt Augustin, Germany Tel.: +49 (0) 2241 - 92 52 - 95 Fax: +49 (0) 2241 - 92 52 - 99 From owner-parkbench-comm@CS.UTK.EDU Fri Jan 23 12:24:12 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA07290; Fri, 23 Jan 1998 12:24:11 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA06737; Fri, 23 Jan 1998 12:04:42 -0500 (EST) Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.154]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA06686; Fri, 23 Jan 1998 12:04:23 -0500 (EST) Received: from minnow.demon.co.uk ([158.152.73.63]) by post.mail.demon.net id aa1003594; 23 Jan 98 16:49 GMT Message-ID: <1GgxMFAgVMy0EwfI@minnow.demon.co.uk> Date: Fri, 23 Jan 1998 16:29:20 +0000 To: hempel@ccrl-nece.technopark.gmd.de Cc: parkbench-comm@CS.UTK.EDU, eckhard@ess.nec.de, tbeckers@ess.nec.de, lonsdale@ccrl-nece.technopark.gmd.de, maciej@ccrl-nece.technopark.gmd.de, ritzdorf@ccrl-nece.technopark.gmd.de, zimmermann@ccrl-nece.technopark.gmd.de, springstubbe@gmd.de From: Roger Hockney Subject: Re: NEW COMMS1 benchmark In-Reply-To: <199801211554.QAA11663@sgi7.ccrl-nece.technopark.gmd.de> MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a To: The Parkbench discussion group From: Roger Hockney First the 3-parameter fit that is produced by New COMMS1 and discussed by Rolf can be found in the html version of this reply at: www.minnow.demon.co.uk/Pbench/emails/hempel1.htm Or by bringing up the PICT tool on your browser at: www.minnow.demon.co.uk/pict/source/pict2a.html Then: (1) select a suitable frame size for the PICT display (2) change the data URL at top from .../data/t3e.res to .../data/sx4.res (3) press the "GET DATA at URL" button, and the data should download. (4) press the 3-PARA button then the APPLY3 button, and the 3-para curve should be drawn. ************************************************************************ Rolf has especialy asked me to point out that the results that he has supplied are for the SX4 using Release 7.2 MPI software which is will soon be replaced by a newer version with significantly better latency and bandwidth. This data does not therefore represent the best that can be achieved on the SX4. ************************************************************************ I now reply to specific points in Rolf Hempel's email to group on 21 Jan 1998. >In the recent discussion on the low-level benchmarks, Roger repeatedly >asked us to base our evaluation of the COMMS1 benchmark on his new >version, and not on the one which is still in the official PARKBENCH >distribution. At NEC we now have repeated the tests on the NEC SX-4 >machine, and I would like to make a few comments on the results. > Thank you, Rolf, for taking the trouble to install New COMMS1 and sending me the results. I discuss the results below. In answer to your other points: >First of all, the raw data as reported by the table Primary Measurements >more closely match the figures given by other ping-pong tests than the >older version. The correction for oeverheads, however, is still The two points you raise could easily be incorporated in the code. I was reluctant to tamper with the measurement part of the COMMS1 code because it would introduce systematic differences in the measurements and make comparison with older measurements invalid. But of course this has to be done from time to time. My changes were deliberately kept to a minimum and confined largely to the parameter fitting part which was causing the main problems being reported. >Another problem in the measuring procedure is that the test message >contains a single constant, repeated as many times as there are words in >the message. Did the authors never think about the possibility of >data compression in interconnect systems? I would not be surprised to >see bandwidths of Terabytes/sec on some Ethernet connection between >workstations. Yes I did think about this, but decided I did not know enough about compression to devise a way to prevent it. Compression algorithms are so clever now that this may be impossible to do. Anyway this is not yet a problem, so I suggest we leave it until it becomes one. Perhaps software should get benefit in its performance numbers for the use of compression but then we need something more difficult than a sequence of constants to use as a standard test. > >Apart from this, the raw data are much better now than they were before, >and when the above points were fixed, the resulting table would be >satisfactory. I would have no objection to this. >The interesting question is, however, how much added value >we get from the parameter fitting. In my earlier note, I called the The added value provided in the case of the NEC SX4 results is that the 3-parameter fit (see graph) gives a satisfactory fit to ALL the data. This reduces 112 numbers to 3 numbers and an analytic formula that can be manipulated. This is called "Performance Characterisation" and provides very useful data compression. Furthermore the parameters themselves can be interpreted as characterising various aspects of the shape and asymptotes of the performance curve. In contrast reporting just the first time and last performance value and calling them the Latency and Bandwidth only tells us about these two points. Further the choice of which message lengths to use for this type of definition is entirely arbitrary and open to much argument at both ends. However, New COMMS1 does provide this type of output in the lines marked KEY SPOT VALUES but I deliberately avoided calling them values of Latency and Bandwidth in order to avoid senseless argument. Some people are very interested in the parametric representations, others not. One is not obliged to use or look at the parametric representations, but they are there for those who want them. For those interested just in the Raw data those are reported first in the output file of New COMMS1. >As could be expected, the two-parameter model does not work better than >in the previous version. For our machine, latency is over-estimated >by 18.9 percent, and the bandwidth at the last data point is off by >27%. Since a linear model is just too simple to be applied to modern >message-passing libraries, I wonder why these results are still in the >output file at all. The 2-PARA results are reported just so that one can see that they are unsatisfactory, and that therefore one must lose simplicity and consider a 3-para fit. Actually there is a switch that can be set in the comms1.inc file to suppress reporting of output if the errors exceed specified values. Every time I have used this, however, I have tended to rerun with the output on, in order to see just what the 2-para gave. If the 2-para can be accepted it is much preferable to the 3-para because of its simplicity and clearer interpretation of the significance of the parameters. >as bad as this measurement. For our MPI library, the RMS fitting >error for the whole data set is 14.04%, and the maximum relative error >is 33.4%. We now can discuss the meaning of the word "crude" (and I If you look at the graph itself (see above), I think you will find the agreement much more satisfactory than is apparent from the reported errors. You also may have too high an expectation of what parametric fitting can reasonably be expected to provide, especially for data with discontinuities. In my experience agreement in RMS error rarely is better than 7% and anything up to 30% is probably still useful. A maximum error of 30% is not bad at all, and may be due to a single rogue point or an isolated discontinuity. Although error numbers are reported in the output, one really has to look at the graph of all data before drawing conclusions. >Given those differences >between model and measurements, I was not surprised to see the >projected RINFINITY as being too high. The 7.65 GBytes/s are well >beyond a memcpy operation in our shared memory, and measured rates never >exceeded 7.1 GBytes/s. Actually 7.65 differs from 7.1 by 8% which is very good agreement indeed. >To summarize, in my opinion there is no added value given by the >parameter fitting. The latency value is the first entry in the raw >data table, and the asymptotic bandwidth is easy to figure out by just >looking at the bandwidths as measured for very long messages. As Your definitions of Latency and Bandwidth will have to be more precise than the above. What does "by looking at the B/W for very long messages" actually mean. What are "very long messages?". "What message length should the first entry in the Raw data table be for?" ... etc. >explained above, the extrapolation by the parametrized model does not >add any precision as compared with a guess based on the long-message >table entries. Strictly-speaking it is invalid to extrapolate the fitted curve outside the range of measured values. However we will always do this, and in this case the fit predicts the known hardware limit as well as can be reasonably expected. >For message lengths in between, what does a model help >me if it deviates from the measurements by up to 33%? So, my conclusion >would be to drop the whole parameter fitting from the PARKBENCH >low-level routines. I think the graph of the results and the 3-para fit shows remarkably good and useful agreement. But this is a subjective personal opinion. What do others think? Best wishes Roger -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk University of and link to my new book: "The Science of Computer Benchmarking" Westminster UK suggestions welcome. Know any fish movies or suitable links? From owner-parkbench-comm@CS.UTK.EDU Mon Jan 26 06:39:21 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA02920; Mon, 26 Jan 1998 06:39:21 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA09063; Mon, 26 Jan 1998 06:22:47 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA09055; Mon, 26 Jan 1998 06:22:36 -0500 (EST) Received: from mordillo (p112.nas1.is3.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA12226; Mon, 26 Jan 98 11:19:15 GMT Date: Mon, 26 Jan 98 10:14:38 GMT From: Mark Baker Subject: Re: Low Level Benchmarks To: Charles Grassl , parkbench-comm@CS.UTK.EDU Cc: solchenbach@pallas.de X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199801151711.RAA07227@magnet.cray.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Charles, Thanks for your thoughts and experiences with the Pallas PMB codes - I will forward them to the authors... The main points in favour of the PMB codes are that they are in C and potentially produce results for a variety of MPI calls... Obviously if the results they produce are flawed... Regarding new low-level codes I would be in favour of taking up your kind offer of writing a set of codes in C/Fortran. I guess the main problem is getting a concensus with regards methodology and measurements that are used with these codes. Maybe we can decide that a number of actions should be undertaken... 1) It seems clear that no one is 100% happy with the current version of the low-level codes. So, this implies that they need to be replaced !? 2) If we are going to replace the codes we can go down a couple of routes; start from scratch, replace with Roger's new codes or some combination of both... 3) I would be happy to see us start from scratch and create C/Fortran codes where the methodology and design of each can be "hammered out" by discussion first and then implemented (and iterated as necessary). 4) Assuming that we want to go down this route, I suggest we make a starting point of Charles' "suggestions and requirements for the low level benchmark design" - towards the end of this email. I am happy to put these words on the web and update/change them as our dicussions evolve... 5) Charles has offered his services to help write/design/test these new codes - I'm willing to offer my services in a similar fashion. I'm sure that others interested in the low-level codes could contribute something here as well. Overall, it seems clear to me that we have enough energy and manpower to produce a new set low-level codes whose methodology and design is correct and relevant to todays systems... I look forward to your comments... Regards Mark --- On Thu, 15 Jan 1998 11:11:39 -0600 (CST) Charles Grassl wrote: > > To: Parkbench interests > From: Charles Grassl > Subject: Low Level benchmarks > > Date: 15 January, 1998 > > > Mark, thank you for pointing us to the PMB benchmark. It is well written > and coded, but has some discrepancies and shortcomings. My comments > lead to suggestions and recommendation regarding low level communication > benchmarks. > > First, in program PMB the PingPong tests are twice as fast (in time) > as the corresponding message length tests in the PingPing tests (as run > on a CRAY T3E). The calculation of the time and bandwidth is incorrect > by a factor of 100% in one of the programs. > > This error can be fixed by recording, using and reporting the actual > time, amount of data sent and their ratio. That is, the time should not > be divided by two in order to correct for a round trip. This recorded > time is for a round trip message, and is not precisely the time for > two messages. Half the round trip message passing time, as reported in > the PMB tests, is not the time for a single message and should not be > reported and such. This same erroneous technique is used in the COMMS1 > and COMMS2 two benchmarks. (Is Parkbench is responsible for propagating > this incorrect methodology.) > > In program PMB, the testing procedure performs a "warm up". This > procedure is a poor testing methodology because is discards important > data. Testing programs such as this should record all times and calculate > the variance and other statistics in order to perform error analysis. > > Program PMB does not measure contention or allow extraction of network > contention data. Tests "Allreduce" and "Bcast" and several others > stress the inter-PE communication network with multiple messages, > but it is not possible to extract information about the contention from > these tests. The MPI routines for Allreduce and Bcast have algorithms > which change with respect to number of PEs and message lengths, Hence, > without detailed information about the specific algorithms used, we cannot > extract information about network performance or further characterize > the inter-PE network. > > Basic measurements must be separated from algorithms. Tests PingPong, > PingPing, Barrier, Xover, Cshift and Exchange are low level. Tests > Allreduce and Bcast are algorithms. The algorithms Allreduce and Bcast > need additional (algorithmic) information in order to be described in > terms of the basic level benchmarks. > > > With respect to low level testing, the round trip exchange of messages, > as per PingPing and PingPong in PMB or COMMS1 and COMMS2, is not > characteristic of the lowest level of communication. This pattern > is actually rather rare in programming practice. It is more common > for tasks to send single messages and/or to receive single messages. > In this scheme, messages do not make a round trip and there is not > necessarily caching or other coherency effects. > > The single message passing is a distinctly different case from that > of round trip tests. We should be worried that the round trip testing > might introduce artifacts not characteristic of actual (low level) usage. > We need a better test of basic bandwidth and latency in order to measure > and characterize message passing performance. > > > Here are suggestions and requirements, in an outline form, for a low > level benchmark design: > > > > I. Single and double (bidirectional) messages. > > A. Test single messages, not round trips. > 1. The round trip test is an algorithm and a pattern. As > such it should not be used as the basic low level test of > bandwidth. > 2. Use direct measurements where possible (which is nearly > always). For experimental design, the simplest method is > the most desirable and best. > 3. Do not perform least squares fits A PIORI. We know that > the various message passing mechanisms are not linear or > analytic because different mechanisms are used for different > message sizes. It is not necessarily known before hand > where this transition occurs. Some computer systems have > more than two regimes and their boundaries are dynamic. > 4. Our discussion of least squares fitting is loosing tract > of experimental design versus modeling. For example, the > least squares parameter for t_0 from COMMS1 is not a better > estimate of latency than actual measurements (assuming > that the timer resolution is adequate). A "better" way to > measure latency is to perform addition DIRECT measurements, > repetitions or otherwise, and hence decrease the statistical > error. The fitting as used in the COMMS programs SPREADS > error. It does not reduce error and hence it is not a > good technique for measuring such an important parameter > as latency. > > B. Do not test zero length messages. Though valid, zero length > messages are likely to take special paths through library > routines. This special case is not particularly interesting or > important. > 1. In practice, the most common and important message size is 64 > bits (one word). The time for this message is the starting > point for bandwidth characterization. > > D. Record all times and use statistics to characterize the message > passing time. That is, do not prime or warm up caches > or buffers. Timings for unprimed caches and buffers give > interesting and important bounds. These timings are also the > nearest to typical usage. > 1. Characterize message rates by a minimum, maximum, average > and standard deviation. > > E. Test inhomogeneity of the communication network. The basic > message test should be performed for all pairs of PEs. > > > II. Contention. > > A. Measure network contention relative to all PEs sending and/or > receiving messages. > > B. Do not use high level routines where the algorithm is not known. > 1. With high level algorithms, we cannot deduce which component > of the timing is attributable to the "operation count" > and which is attributable to the actual system (hardware) > performance. > > > III. Barrier. > > A. Simple test of barrier time for all numbers of processors. > > > > > Additionally, the suite should be easy to use. C and Fortran programs > for direct measurements of message passing times are short and simple. > These simple tests are of order 100 lines of code and, at least in > Fortran 90, can be written in a portable and reliable manner. > > The current Parkbench low level suite does not satisfy the above > requirements. It is inaccurate, as pointed out by previous letters, and > uses questionable techniques and methodologies. It is also difficult to > use, witness the proliferation of files, patches, directories, libraries > and the complexity and size of the Makefiles. > > This Low Level suite is a burden for those who are expecting a tool to > evaluate and investigate computer performance. The suite is becoming > a liability for our group. As such, it should be withdrawn from > distribution. > > I offer to write, test and submit a new set of programs which satisfy > most of the above requirements. > > > Charles Grassl > SGI/Cray Research > Eagan, Minnesota USA > ---------------End of Original Message----------------- ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 01/26/98 - Time: 10:14:38 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Mon Jan 26 11:54:37 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id LAA07118; Mon, 26 Jan 1998 11:54:37 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA18845; Mon, 26 Jan 1998 11:21:36 -0500 (EST) Received: from timbuk.cray.com (timbuk-fddi.cray.com [128.162.8.102]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id LAA18837; Mon, 26 Jan 1998 11:21:33 -0500 (EST) Received: from ironwood.cray.com (root@ironwood-fddi.cray.com [128.162.21.36]) by timbuk.cray.com (8.8.7/CRI-gate-news-1.3) with ESMTP id KAA23428 for ; Mon, 26 Jan 1998 10:21:26 -0600 (CST) Received: from magnet.cray.com (magnet [128.162.173.162]) by ironwood.cray.com (8.8.4/CRI-ironwood-news-1.0) with ESMTP id KAA29079 for ; Mon, 26 Jan 1998 10:21:24 -0600 (CST) From: Charles Grassl Received: by magnet.cray.com (8.8.0/btd-b3) id QAA29329; Mon, 26 Jan 1998 16:21:23 GMT Message-Id: <199801261621.QAA29329@magnet.cray.com> Subject: Low Level Benchmarks To: parkbench-comm@CS.UTK.EDU Date: Mon, 26 Jan 1998 10:21:23 -0600 (CST) X-Mailer: ELM [version 2.4 PL24-CRI-d] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: Parkbench interests From: Charles Grassl Subject: Low Level benchmarks Date: 26, January, 1998 A short review of where we have been and decided: Last year we agreed (via email exchanges) that the Parkbench Low Level benchmark suite is not intended to be an -MPI- -test- suite. There was a consensus that we intended to measure low level performance, not algorithm design or implementation. This is why the Pallas benchmark, though useful for testing the performance of several important MPI functions, is not the basic low level test which we desire. (I believe that the performance measurement of the MPI functions is a worthwhile project for this group, but it needs to be separate from the low level benchmarks.) At the May, 1997 Parkbench meeting in Knoxville, TN, we unanimously decided that the measurement and analysis (fitting) portions of the COMMS programs would be made into a separate program. This from Michael Berry's minutes (23 May 1997): After more discussion, the following COMMS changes/outputs were unanimously agreed upon: 1. Maximum bandwidth with corresp. message size. 2. Minimum message-passing time with corresp. message size. 3. Time for minimum message length (could be 0, 1, 8, or 32 bytes but must be specified). 4. The software will be split into two program: one to report the spot measurements and the other for the analysis. Some of the objections with the Parkbench Low Level codes are that they are difficult to build, run and analyze. This attributable to their organization and design. Separating the analysis would greatly simply the programs, but the programs still need to be rewritten. I include in this email message a simple replacement code for COMMS1. It uses the "back and forth" methodology, reports maximum and minimum times with corresponding sizes and and does not include "analysis". It is equivalent to the measurement portion of COMMS1, though it is much simpler and easier to use. I will comment on the experimental methodology used in this program. - The reported times in standard out are actual round trip times. It is a poor experimental practice to modify raw measurements too early. We should not mix measured times with derived times. The practice leads to confusion and errors (witness the Pallas benchmark code and and an earlier version of Parkbench). If we desire to divide the times by two (because of the round trip), then this should be done in a analysis portion. Otherwise we misrepresent round trip times as actual single trip times, which hay are not. - All times are saved and written to unit 7. The reported times in standard out are the first and the last measurements for each message size. The experimental principle is that no data should be discarded with out analysis. We can use statistical analysis or graphics or fitting routines to analyze the raw output. (I favor graphics and statistical analysis.) If we look at the raw output, we will see interesting features, such as the actual "warm up" count (usually five or less repetitions) and the distribution of times (not Gaussian!). - Each repetition is individually timed. If the timer does not have adequate resolution, then the times for a number of repetitions, from two to all, can be aggregated and used. This aggregation can be done in the analysis phase. (Most computers should be able to time and resolve single round trip messages.) This aggregation should not be done before adequate analysis or evidence that it needs to be done. - Each message size is tested the same number of repetitions. We prefer to keep this number a constant so that the experimental sampling error (proportional to 1/sqrt[repetitions]) is the same for each message size. Also, it is difficult to cleanly and simply adjust the repetition count relative to the message size. I also have one replacement program for both COMMS2 and COMMS3 (note that the COMMS2 measurement is a subset of COMMS3 measurements). More on that later. Charles Grassl SGI/Cray Research Eagan, Minnesota USA ----------------------------------------------------------------------- program Single ! Compile: f90 file.f -l mpi character*40 Title data Title/' Single Messages --- MPI'/ integer log2nmax,nmax,n_repetitions parameter (log2nmax=18,nmax=2**log2nmax,n_repetitions=50) integer n_starts,n_mess parameter (n_starts=2,n_mess=2) include 'mpif.h' integer ier,status(MPI_STATUS_SIZE) integer my_pe,npes integer log2n,n,nrep,i real*8 t_call,timer,tf(0:n_repetitions) real*8 A(0:nmax-1) save A call mpi_init( ier ) call mpi_comm_rank(MPI_COMM_WORLD, my_pe, ier) call mpi_comm_size(MPI_COMM_WORLD, npes, ier) radian=1 do i=0,nmax-1 A(i) = acos(radian)*i end do tf(0) = timer() do nrep=1,n_repetitions tf(nrep) = timer() end do t_call=(tf(n_repetitions)-tf(0))/n_repetitions if (my_pe.eq.0) then call table_top(Title,npes,n_starts,n_mess,n_repetitions,t_call) end if do log2n=0,log2nmax n = 2**log2n call mpi_barrier( MPI_COMM_WORLD, ier ) tf(0) = timer() do nrep=1,n_repetitions if (my_pe.eq.1) then call MPI_SEND(A,8*n,MPI_BYTE,0,10,MPI_COMM_WORLD,ier) call MPI_RECV(A,8*n,MPI_BYTE,0,20,MPI_COMM_WORLD,status,ier) end if if (my_pe.eq.0) then call MPI_RECV(A,8*n,MPI_BYTE,1,10,MPI_COMM_WORLD,status,ier) call MPI_SEND(A,8*n,MPI_BYTE,1,20,MPI_COMM_WORLD,ier) end if tf(nrep) = timer() end do if (my_pe.eq.0) then call table_body(8*n,n_mess,n_repetitions,tf,t_call) end if end do call mpi_finalize(ier) end subroutine table_top( Title,npes, . n_starts,n_mess,n_repetitions,t_call) integer M parameter (M = 1 000 000) character*40 Title integer npes,n_starts,n_mess,n_repetitions real*8 t_call write(6,9010) Title,npes,n_starts,n_mess,n_repetitions,t_call*M return 9010 format(//a40, . // ' Number of PEs: ',i8 . // ' Starts: ',i8, . / ' Messages: ',i8, . / ' Repetitions: ',i8, . / ' Timer overhead: ',f8.3,' microsecond', . // 8x,' First ', . ' Last ', . /' Length',2x,2(' Time Rate ',1x), . /' [Bytes]',2x,2(' [Microsec.] [Mbyte/s]',1x), . /' ',8('-'),2x,2(21('-'),2x)) end subroutine table_body(n_byte,n_mess,n_repetitions,tf,t_call) integer M parameter (M = 1 000 000) integer n_byte,n_mess,n_repetitions,i real*8 tf(0:n_repetitions) real*8 t_call real*8 t_first,t_last t_first = (tf(1)-tf(0))-t_call t_last = (tf(n_repetitions)-tf(n_repetitions-1))-t_call write(6,9020) n_byte,t_first*M,n_mess*n_byte/(t_first*M), . t_last *M,n_mess*n_byte/(t_last *M) write(7) n_byte,n_repetitions,n_mess write(7) ((tf(i)-tf(i-1))-t_call,i=1,n_repetitions) return 9020 format(i8, 2x,2(f10.1,1x,f10.0,2x)) end From owner-parkbench-comm@CS.UTK.EDU Mon Jan 26 13:06:36 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id NAA08767; Mon, 26 Jan 1998 13:06:36 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA23400; Mon, 26 Jan 1998 12:31:16 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA23166; Mon, 26 Jan 1998 12:30:05 -0500 (EST) Received: from mordillo ([195.102.195.125]) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA15447; Mon, 26 Jan 98 17:31:15 GMT Date: Mon, 26 Jan 98 17:23:08 GMT From: Mark Baker Subject: Fw: Re: Low Level Benchmarks To: parkbench-comm@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <34CCB99F.2B3C3D63@cumbria.eng.sun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This came direct to me... The rest of Parkbench are probably interested in Bodo's comments. Mark --- On Mon, 26 Jan 1998 08:28:15 -0800 Bodo Parady - SMCC Performance Development wrote: > The key items to find are: > > Lock time (defined as time to release a lock remotely) > Example would be reader spinning on memory, waiting > for change in memory word, or receipt of interrupt. > This is the effective ping-pong half time. Sadly > subroutine and library call overhead can render > this result meaningless. > > Measuring one way rates is no good here since the response > time must be factored in. This is a two-way transfer > > Channel rate (defined as large block transfer rate). > > Block size at half channel rate. > > Block size at twice lock time latency. > > Full curve, stepping at 1, 2, 4, 8, 16, ..., 2*n byte block sizes > at full issue rate. This is probably the least important > since it involves coalescence of transmitted data. > > The fear is that given the limitations of MPI/PVM, and to some degree > of C and Fortran that accurate measures of these quantities may > not be practical. > > Regards. > > Bodo Parady > > Mark Baker wrote: > > > Charles, > > > > Thanks for your thoughts and experiences with the Pallas PMB codes - > > I will forward them to the authors... The main points in favour of > > the PMB codes are that they are in C and potentially produce results > > for a variety of MPI calls... Obviously if the results they produce are > > flawed... > > > > Regarding new low-level codes I would be in favour of taking up your > > kind offer of writing a set of codes in C/Fortran. I guess the main > > problem is getting a concensus with regards methodology and measurements > > that are used with these codes. > > > > Maybe we can decide that a number of actions should be undertaken... > > > > 1) It seems clear that no one is 100% happy with the current version > > of the low-level codes. So, this implies that they need to be > > replaced !? > > > > 2) If we are going to replace the codes we can go down a couple of routes; > > start from scratch, replace with Roger's new codes or some combination of > > both... > > > > 3) I would be happy to see us start from scratch and create > > C/Fortran codes where the methodology and design of each can be > > "hammered out" by discussion first and then implemented > > (and iterated as necessary). > > > > 4) Assuming that we want to go down this route, I suggest we make a starting > > point of Charles' "suggestions and requirements for the low level > > benchmark design" - towards the end of this email. I am happy to > > put these words on the web and update/change them as our dicussions > > evolve... > > > > 5) Charles has offered his services to help write/design/test these new codes - > > I'm willing to offer my services in a similar fashion. I'm sure that others > > interested in the low-level codes could contribute something here as well. > > > > Overall, it seems clear to me that we have enough energy and manpower to > > produce a new set low-level codes whose methodology and design is correct > > and relevant to todays systems... > > > > I look forward to your comments... > > > > Regards > > > > Mark > > > > --- On Thu, 15 Jan 1998 11:11:39 -0600 (CST) Charles Grassl wrote: > > > > > > To: Parkbench interests > > > From: Charles Grassl > > > Subject: Low Level benchmarks > > > > > > Date: 15 January, 1998 > > > > > > > > > Mark, thank you for pointing us to the PMB benchmark. It is well written > > > and coded, but has some discrepancies and shortcomings. My comments > > > lead to suggestions and recommendation regarding low level communication > > > benchmarks. > > > > > > First, in program PMB the PingPong tests are twice as fast (in time) > > > as the corresponding message length tests in the PingPing tests (as run > > > on a CRAY T3E). The calculation of the time and bandwidth is incorrect > > > by a factor of 100% in one of the programs. > > > > > > This error can be fixed by recording, using and reporting the actual > > > time, amount of data sent and their ratio. That is, the time should not > > > be divided by two in order to correct for a round trip. This recorded > > > time is for a round trip message, and is not precisely the time for > > > two messages. Half the round trip message passing time, as reported in > > > the PMB tests, is not the time for a single message and should not be > > > reported and such. This same erroneous technique is used in the COMMS1 > > > and COMMS2 two benchmarks. (Is Parkbench is responsible for propagating > > > this incorrect methodology.) > > > > > > In program PMB, the testing procedure performs a "warm up". This > > > procedure is a poor testing methodology because is discards important > > > data. Testing programs such as this should record all times and calculate > > > the variance and other statistics in order to perform error analysis. > > > > > > Program PMB does not measure contention or allow extraction of network > > > contention data. Tests "Allreduce" and "Bcast" and several others > > > stress the inter-PE communication network with multiple messages, > > > but it is not possible to extract information about the contention from > > > these tests. The MPI routines for Allreduce and Bcast have algorithms > > > which change with respect to number of PEs and message lengths, Hence, > > > without detailed information about the specific algorithms used, we cannot > > > extract information about network performance or further characterize > > > the inter-PE network. > > > > > > Basic measurements must be separated from algorithms. Tests PingPong, > > > PingPing, Barrier, Xover, Cshift and Exchange are low level. Tests > > > Allreduce and Bcast are algorithms. The algorithms Allreduce and Bcast > > > need additional (algorithmic) information in order to be described in > > > terms of the basic level benchmarks. > > > > > > > > > With respect to low level testing, the round trip exchange of messages, > > > as per PingPing and PingPong in PMB or COMMS1 and COMMS2, is not > > > characteristic of the lowest level of communication. This pattern > > > is actually rather rare in programming practice. It is more common > > > for tasks to send single messages and/or to receive single messages. > > > In this scheme, messages do not make a round trip and there is not > > > necessarily caching or other coherency effects. > > > > > > The single message passing is a distinctly different case from that > > > of round trip tests. We should be worried that the round trip testing > > > might introduce artifacts not characteristic of actual (low level) usage. > > > We need a better test of basic bandwidth and latency in order to measure > > > and characterize message passing performance. > > > > > > > > > Here are suggestions and requirements, in an outline form, for a low > > > level benchmark design: > > > > > > > > > > > > I. Single and double (bidirectional) messages. > > > > > > A. Test single messages, not round trips. > > > 1. The round trip test is an algorithm and a pattern. As > > > such it should not be used as the basic low level test of > > > bandwidth. > > > 2. Use direct measurements where possible (which is nearly > > > always). For experimental design, the simplest method is > > > the most desirable and best. > > > 3. Do not perform least squares fits A PIORI. We know that > > > the various message passing mechanisms are not linear or > > > analytic because different mechanisms are used for different > > > message sizes. It is not necessarily known before hand > > > where this transition occurs. Some computer systems have > > > more than two regimes and their boundaries are dynamic. > > > 4. Our discussion of least squares fitting is loosing tract > > > of experimental design versus modeling. For example, the > > > least squares parameter for t_0 from COMMS1 is not a better > > > estimate of latency than actual measurements (assuming > > > that the timer resolution is adequate). A "better" way to > > > measure latency is to perform addition DIRECT measurements, > > > repetitions or otherwise, and hence decrease the statistical > > > error. The fitting as used in the COMMS programs SPREADS > > > error. It does not reduce error and hence it is not a > > > good technique for measuring such an important parameter > > > as latency. > > > > > > B. Do not test zero length messages. Though valid, zero length > > > messages are likely to take special paths through library > > > routines. This special case is not particularly interesting or > > > important. > > > 1. In practice, the most common and important message size is 64 > > > bits (one word). The time for this message is the starting > > > point for bandwidth characterization. > > > > > > D. Record all times and use statistics to characterize the message > > > passing time. That is, do not prime or warm up caches > > > or buffers. Timings for unprimed caches and buffers give > > > interesting and important bounds. These timings are also the > > > nearest to typical usage. > > > 1. Characterize message rates by a minimum, maximum, average > > > and standard deviation. > > > > > > E. Test inhomogeneity of the communication network. The basic > > > message test should be performed for all pairs of PEs. > > > > > > > > > II. Contention. > > > > > > A. Measure network contention relative to all PEs sending and/or > > > receiving messages. > > > > > > B. Do not use high level routines where the algorithm is not known. > > > 1. With high level algorithms, we cannot deduce which component > > > of the timing is attributable to the "operation count" > > > and which is attributable to the actual system (hardware) > > > performance. > > > > > > > > > III. Barrier. > > > > > > A. Simple test of barrier time for all numbers of processors. > > > > > > > > > > > > > > > Additionally, the suite should be easy to use. C and Fortran programs > > > for direct measurements of message passing times are short and simple. > > > These simple tests are of order 100 lines of code and, at least in > > > Fortran 90, can be written in a portable and reliable manner. > > > > > > The current Parkbench low level suite does not satisfy the above > > > requirements. It is inaccurate, as pointed out by previous letters, and > > > uses questionable techniques and methodologies. It is also difficult to > > > use, witness the proliferation of files, patches, directories, libraries > > > and the complexity and size of the Makefiles. > > > > > > This Low Level suite is a burden for those who are expecting a tool to > > > evaluate and investigate computer performance. The suite is becoming > > > a liability for our group. As such, it should be withdrawn from > > > distribution. > > > > > > I offer to write, test and submit a new set of programs which satisfy > > > most of the above requirements. > > > > > > > > > Charles Grassl > > > SGI/Cray Research > > > Eagan, Minnesota USA > > > > > > > ---------------End of Original Message----------------- > > > > ------------------------------------- > > CSM, University of Portsmouth, Hants, UK > > Tel: +44 1705 844285 Fax: +44 1705 844006 > > E-mail: mab@sis.port.ac.uk > > Date: 01/26/98 - Time: 10:14:38 > > URL http://www.sis.port.ac.uk/~mab/ > > ------------------------------------- > > > > ---------------End of Original Message----------------- ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 01/26/98 - Time: 17:23:08 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Mon Jan 26 14:08:38 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id OAA11289; Mon, 26 Jan 1998 14:08:37 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA02837; Mon, 26 Jan 1998 13:52:54 -0500 (EST) Received: from haven.EPM.ORNL.GOV (haven.epm.ornl.gov [134.167.12.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id NAA02817; Mon, 26 Jan 1998 13:52:50 -0500 (EST) Received: (from worley@localhost) by haven.EPM.ORNL.GOV (8.8.3/8.8.3) id NAA11755; Mon, 26 Jan 1998 13:52:49 -0500 (EST) Date: Mon, 26 Jan 1998 13:52:49 -0500 (EST) From: Pat Worley Message-Id: <199801261852.NAA11755@haven.EPM.ORNL.GOV> To: parkbench-comm@CS.UTK.EDU Subject: Re: Fw: Re: Low Level Benchmarks In-Reply-To: Mail from 'Mark Baker ' dated: Mon, 26 Jan 98 17:23:08 GMT Cc: worley@haven.EPM.ORNL.GOV (From Charles Grassl) > Last year we agreed (via email exchanges) that the Parkbench Low Level > benchmark suite is not intended to be an -MPI- -test- suite. There was a > consensus that we intended to measure low level performance, not algorithm > design or implementation. (From Bodo Parady via Mark Baker) > The fear is that given the limitations of MPI/PVM, and to some degree > of C and Fortran that accurate measures of these quantities may > not be practical. > I have a problem with attempting to determine low level communication performance parameters independent of the communication library when it a) is such a difficult task (I doubt that any portable program will be "accurate enough" across all the interesting platforms.) b) does not reflect what users would see in practice (since they will be using MPI or PVM in C or Fortran). Am I missing something? The primary utility (for me) of the low level benchmarks is to help explain the performance observed in the Parkbench kernels and compact applications, or in my own codes. What level of accuracy is required for such an application? Are more accurate or detailed measurements useful or doable? Upon reflection, such low(er) level performance data would be useful to the developer of a communication library, to help evaluate its performance, but that appears to require system-specific measurements (and system-specific interpretation). Is this really something we want to attempt? Pat Worley From owner-parkbench-comm@CS.UTK.EDU Thu Jan 29 16:29:33 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id QAA19023; Thu, 29 Jan 1998 16:29:33 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA09768; Thu, 29 Jan 1998 16:18:48 -0500 (EST) Received: from haven.EPM.ORNL.GOV (haven.epm.ornl.gov [134.167.12.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA09756; Thu, 29 Jan 1998 16:18:45 -0500 (EST) Received: (from worley@localhost) by haven.EPM.ORNL.GOV (8.8.3/8.8.3) id QAA01325; Thu, 29 Jan 1998 16:18:43 -0500 (EST) Date: Thu, 29 Jan 1998 16:18:43 -0500 (EST) From: Pat Worley Message-Id: <199801292118.QAA01325@haven.EPM.ORNL.GOV> To: parkbench-comm@CS.UTK.EDU Subject: Re: Fw: Re: Low Level Benchmarks In-Reply-To: Mail from 'Mark Baker ' dated: Mon, 26 Jan 98 17:23:08 GMT Cc: worley@haven.EPM.ORNL.GOV In a private exchange, Charles Grassl made a comment that he may come to regret: " We need more input, such as yours, as to what are the important parameters and what accuracy is needed. " so here are some random comments. I have been organizing my own performance data over the last couple of weeks. I never paid too much attention to the detailed output of my own ping-ping and ping-pong tests because it was not the end product of the research. It has been enlightening to look at it now. The entry point is http://www.epm.ornl.gov/~worley/studies/pt2pt.html I tried a couple of different fitting techniques, but decided that fits told me nothing that I was interested in. What I have found mildly interesting is to measure statistics of the data, and try to build a performance model using those. The difference is that the interpretation and value of the statistics (maximum observed bandwidth, time to send 0 length message, etc.) are not functions of any model error. The problem with fitting the data is that, no matter how often I tell myself that it is simply a compact representation of the data, I keep wanting to use assign meaning to the model parameters and use them in interplatform comparisons. In summary, I have changed my mind. I no longer support even simple fits to the data unless well-defined statistical measures of the data are also included (and emphasized). Pat Worley From owner-parkbench-comm@CS.UTK.EDU Mon Feb 9 05:05:12 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id FAA29859; Mon, 9 Feb 1998 05:05:11 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA10483; Mon, 9 Feb 1998 04:57:14 -0500 (EST) Received: from gatekeeper.pallas.de (gatekeeper.pallas.de [194.45.33.1]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA10476; Mon, 9 Feb 1998 04:57:07 -0500 (EST) Received: from mailhost.pallas.de (gatekeeper [194.45.33.1]) by gatekeeper.pallas.de (SMI-8.6/SMI-SVR4) with SMTP id KAA18803; Mon, 9 Feb 1998 10:50:10 +0100 Received: from schubert.pallas.de by mailhost.pallas.de (SMI-8.6/SMI-SVR4) id KAA03909; Mon, 9 Feb 1998 10:50:07 +0100 Received: from localhost by schubert.pallas.de (SMI-8.6/SMI-SVR4) id KAA11268; Mon, 9 Feb 1998 10:46:57 +0100 Date: Mon, 9 Feb 1998 10:46:45 +0100 (MET) From: Hans Plum X-Sender: hans@schubert Reply-To: Hans Plum To: cmg@cray.com, mab@sis.port.ac.uk, parkbench-comm@CS.UTK.EDU cc: snelling@fecit.co.uk Subject: Re: Low Level Benchmarks (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" --MimeMultipartBoundary Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am the "PMB person" at PALLAS Gmbh. I have heard about your discussions. First note that there is a new version PMB1.2, see http://www.pallas.de/pages/pmb.htm Also look at the PMB1.2_doc.ps.gz where we try to give the reasoning for all decisions made in PMB. We think nothing has been designed sloppy .. PMB has been developed from point of view of an application developer which I am. Of course a single person's view is limited, but for myself the information given by PMB provides a solid base for algorithmic estimates and decisions. That exactly what we wanted: Something EASY (and not COMPLETE) that covers may be 80% of the realistic situations. ------------------------------------------------------------- ---/--- Dr Hans-Joachim Plum phone : +49-2232-1896-0 / / PALLAS GmbH direct line: +49-2232-1896-18 / / / Hermuelheimer Strasse 10 fax : +49-2232-1896-29 / / / / D-50321 Bruehl email : plum@pallas.de / / / Germany URL : http://www.pallas.de / / PALLAS ------------------------------------------------------------- ---/--- --MimeMultipartBoundary-- From owner-parkbench-comm@CS.UTK.EDU Wed Apr 22 07:43:42 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id HAA03238; Wed, 22 Apr 1998 07:43:41 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA03111; Wed, 22 Apr 1998 07:05:23 -0400 (EDT) Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.39]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA03104; Wed, 22 Apr 1998 07:05:21 -0400 (EDT) Received: from minnow.demon.co.uk ([158.152.73.63]) by post.mail.demon.net id aa1028865; 22 Apr 98 11:00 GMT Message-ID: Date: Wed, 22 Apr 1998 11:59:51 +0100 To: parkbench-comm@CS.UTK.EDU From: Roger Hockney Subject: Announcing PICT2.1 - Now fully Operational MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a To: the Parkbench discussion group From: Roger ANNOUNCING PICT 2.1 (1 Mar 1998) -------------------------------- I am pleased to announce the first fully-functional version of the Parkbench Interactive Curve-Fitting Tool (PICT). Provision is made for a wide range of screen sizes in pixels by allowing the user to make a suitable choice in the opening HTML page. All buttons now work. In particular Jack can have his least-squares fitting of the 2-parameters direct from the tool, and this can be performed over partial ranges of the data as required. The same applies to the Three-point fitting procedure to obtain the 3-parameter fits. There is also a nice "Temperature Gauge" feature that helps you minimise the error during manual fitting. The results of these fits can be assembled in a results file and annotated using the SAVE buttons. Under MSIE I find I am able to store these results in my local disk file system using SAVE as ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The methodology of the 2-parameter curve fitting is given in detail in my book "The Science of Computer Benchmarking", see: http://www.siam.org/catalog/mcc07/hockney.htm The 3-parameter fit was described quite fully in my talk to the 11 Sep 1997 Parkbench meeting. I have finally written this up with pretty pictures for the PEMCS Web Journal. Look at: http://hpc-journals.ecs.soton.ac.uk/Workshops/PEMCS/fall-97/ talks/Roger-Hockney/perfprof1.html To try out PICT 2.1 please first try my own Demon Web space which has a counter from which I can judge usage: http://www.minnow.demon.co.uk/pict/source/pict2a.html If this gives problems, it is also mounted on the University of Westminster server: http://perun.hscs.wmin.ac.uk/LocalInfo/pict/source/pict2a.html We expect soon to make it available on the Southampton server. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PICT 2.1 has been tested by a small number of friends. Most problems and frustrations arise from either slowness of the server or of the users' computer. If download from Demon is slow or appears to hang, try the other server or try Demon later. Please do not conclude the applet is broken. I am confident it is not. A 10 to 20 second wait is normal when bringing up the requested graphical window/frame even on a good day. Once the graphical window is on your computer and the applet is running, the speed is determined by the speed of your computer. You may even disconnect from the Web at this stage and continue curve fitting with the applet with the data displayed. If you want new data, you must, of course, reconnect to the Web and use the GET DATA at URL button. Experience shows that the PICT applet will not respond satisfactorily on a computer with slower than a 100 MHz clock. This is because a lot of complex calculations must be performed as you drag the curves around the data. MSIE seems to work noticeably faster than Netscape on my Win95 PC. There is no cure for this except to use a faster computer. But again please do not think the applet is brocken. Please report experiences good or bad to: roger@minnow.demon.co.uk Constructive suggestions for improvement are also welcome. -- Roger Hockney. Checkout my new Web page at URL http://www.minnow.demon.co.uk From owner-parkbench-comm@CS.UTK.EDU Sun Jun 21 10:02:47 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA22167; Sun, 21 Jun 1998 10:02:47 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA06272; Sun, 21 Jun 1998 09:47:56 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA06265; Sun, 21 Jun 1998 09:47:54 -0400 (EDT) Received: from mordillo (p4.nas1.is5.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA17767; Sun, 21 Jun 98 14:50:05 BST Date: Sun, 21 Jun 98 14:43:42 +0000 From: Mark Baker Subject: New PEMCS papers To: parkbench-comm@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All, Two new papers have just been published by the PEMCS journal... 3.Comparing The Performance of MPI on the Cray T3E-900, The Cray Origin2000 And The IBM P2SC, by Glenn R. Luecke and James J. Coyle Iowa State University, Ames, Iowa 50011-2251, USA. 4.EuroBen Experiences with the SGI Origin 2000 and the Cray T3E, by A.J. van der Steen, Computational Physics, Utrecht University, Holland* See http://hpc-journals.ecs.soton.ac.uk/PEMCS/Papers/ Regards Mark ------------------------------------- CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 06/21/98 - Time: 14:43:42 URL http://www.sis.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Fri Sep 11 12:05:18 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA19578; Fri, 11 Sep 1998 12:05:18 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA20703; Fri, 11 Sep 1998 11:54:29 -0400 (EDT) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA20636; Fri, 11 Sep 1998 11:53:20 -0400 (EDT) Received: from mordillo (p36.nas1.is5.u-net.net) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA11111; Fri, 11 Sep 98 16:48:17 BST Date: Fri, 11 Sep 98 14:38:08 +0000 From: Mark Baker Subject: CPE - Call for papers - Message Passing Interface-based Parallel Programming with Java To: javagrandeforum@npac.syr.edu, "'mpi-nt-users@erc.msstate.edu'" , "Dr. Kenneth A. Williams" , "Stephen L. Scott" , "Aad J. van der Steen" , Advanced Java , Alexander Reinefeld , Andy Grant , Anne Trefethen , Bryan Capenter , Charles Grassl , Dave Beckett , David Snelling , DIS Everyone , fagg@CS.UTK.EDU, gentzsch@genias.de, Guy Robinson , Hon W Yau , hpvm@cs.uiuc.edu, Jack Dongarra , java-for-cse@npac.syr.edu, Joao Gabriel Silva , jtap-club-clusters@mailbase.ac.uk, Ken Hawick , Mike Berry , mpijava-users@npac.syr.edu, owner-grounds@mail.software.ibm.com, parkbench-comm@CS.UTK.EDU, partners@globus.org, Paul Messina , Roland Wismueller , Steve Larkin - AVS , Terri Canzian , Tony Hey , topic@mcc.ac.uk, Vaidy Sunderam , Vladimir Getov , William Gropp X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Colleague,, Firstly, I apologise for any cross-posting of this email. If this CFP is not in your field we would appreciate you forwarding it to your colleagues who may be in the field. This CFP can be found at http://hpc-journals.ecs.soton.ac.uk/CPE/Special/MPI-Java/ Regards Dr Mark Baker University of Portsmouth, UK ---------------------------------------------------------------------------- Call For Papers Special Issue of Concurrency: Practice and Experience Message Passing Interface-based Parallel Programming with Java Guest Editors Anthony Skjellum (MPI Software Technology, Inc.) Mark Baker (University of Portsmouth) A special issue of Concurrency: Practice and Experience (CPE) is being planned for Fall of 1999. Papers submitted and accepted for this issue will be published by John Wiley & Sons Ltd. in the CPE Journal and in addition will be made available electronically via the WWW. Background Recently there has been a great deal of interest in the idea that Java may be a good language for scientific and engineering computation, and in particular for parallel computing. The claims made on behalf of Java, that it is simple, efficient and platform-neutral - a natural language for network programming - make it potentially attractive to scientific programmers hoping to harness the collective computational power of networks of workstations and PCs, or even of the Internet. A basic prerequisite for parallel programming is a good communication API. Java comes with various ready-made packages for communication, notably an easy-to-use interface to BSD sockets, and the Remote Method Invocation (RMI) mechanism. Interesting as these interfaces are, it is questionable whether parallel programmers will find them especially convenient. Sockets and remote procedure calls have been around for about as long as parallel computing has been fashionable, and neither of them has been popular in that field. Both communication models are optimized for client-server programming, whereas the parallel computing world is mainly concerned with "symmetric" communication, occurring in groups of interacting peers. This symmetric model of communication is captured in the successful Message Passing Interface standard (MPI), established a few years ago. MPI directly supports the Single Program Multiple Data (SPMD) model of parallel computing, wherein a group of processes cooperate by executing identical program images on local data values. Reliable point-to-point communication is provided through a shared, group-wide communicator, instead of socket pairs. MPI allows numerous blocking, non-blocking, buffered or synchronous communication modes. It also provides a library of true collective operations (broadcast is the most trivial example). An extended standard, MPI 2, allows for dynamic process creation and access to memory in remote processes. Call For Papers This is a call for papers about the designs, experience, and results concerning the use of the Message Passing Interface (MPI) with Java are sought for a special issue of Concurrency Practice and Experience. Development of clear understanding of the opportunities, challenges, and state-of-the-art in scalable, peer-oriented messaging with Java are of interest and value to both the distributed computing and high performance computing communities. Topics of interest for this special issue include but are not limited to: -- Practical systems that use MPI and Java to solve real distributed high performance computing problems. -- Designs of systems for combining MPI-type functionality with Java. -- Approaches to APIs for object-oriented, group-oriented message passing with Java. -- Efforts to combine MPI with CORBA in a Java environment. -- Efforts to utilize aspects of the emerging MPI/RT standard are also of interest in the Java context. -- Efforts to do MPI interoperability (IMPI) using Java. -- Issues and both tactical and strategic solutions concerning MPI-1 and MPI-2 standard and features in conjunction with Java. -- Performance results and performance-enhancing techniques for such systems. -- Flexible frameworks and techniques for enabling High-Performance communication in Java Timescales for Submission There is a deadline of 15th December 1998 for submitted papers. Publication is currently scheduled for the third quarter of 1999. Activity Deadline Call For Papers 1st September 1998 Paper Submission 15th December 1998 Papers Returned 15th March 1999 Papers Approved 1st April 1999 Publication Q3 1999 Further details about this special issue can be found at: http://hpc-journals.ecs.soton.ac.uk/CPE/Special/MPI-Java/ ---------------------------------------------------------------------------- ------------------------------------- Dr Mark baker CSM, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 09/11/98 - Time: 14:38:08 URL http://www.dcs.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Tue Sep 15 22:24:43 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id WAA13441; Tue, 15 Sep 1998 22:24:43 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id WAA25353; Tue, 15 Sep 1998 22:23:26 -0400 (EDT) Received: from octane11.nas.nasa.gov (octane11.nas.nasa.gov [129.99.34.116]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id WAA25343; Tue, 15 Sep 1998 22:23:08 -0400 (EDT) Received: (from saini@localhost) by octane11.nas.nasa.gov (8.8.7/NAS8.8.7) id TAA24915; Tue, 15 Sep 1998 19:17:45 -0700 (PDT) From: "Subhash Saini" Message-Id: <9809151917.ZM24910@octane11.nas.nasa.gov> Date: Tue, 15 Sep 1998 19:17:44 -0700 In-Reply-To: Mark Baker "CPE - Call for papers - Message Passing Interface-based Parallel Programming with Java" (Sep 11, 2:38pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "'mpi-nt-users@erc.msstate.edu'" , "Aad J. van der Steen" , "Dr. Kenneth A. Williams" , "Stephen L. Scott" , Advanced Java , Alexander Reinefeld , Andy Grant , Anne Trefethen , Bryan Capenter , Charles Grassl , DIS Everyone , Dave Beckett , David Snelling , Guy Robinson , Hon W Yau , Jack Dongarra , Joao Gabriel Silva , Ken Hawick , Mark Baker , Mike Berry , Paul Messina , Roland Wismueller , Steve Larkin - AVS , Terri Canzian , Tony Hey , Vaidy Sunderam , Vladimir Getov , William Gropp , fagg@CS.UTK.EDU, gentzsch@genias.de, hpvm@cs.uiuc.edu, java-for-cse@npac.syr.edu, javagrandeforum@npac.syr.edu, jtap-club-clusters@mailbase.ac.uk, mpijava-users@npac.syr.edu, owner-grounds@mail.software.ibm.com, parkbench-comm@CS.UTK.EDU, partners@globus.org, topic@mcc.ac.uk Subject: AD _ Workshop Cc: mab@sis.port.ac.uk, saini@octane11.nas.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii You are invited to attend the workshop (see below). Best regards, subhash ============================================================================== ***** REGISTER NOW ***** *** NO REGISTRATION FEE *** **** Last Day to Register is Sept. 23, 1998 **** "First NASA Workshop on Performance-Engineered Information Systems" ----------------------------------------------------------------- Sponsored by Numerical Aerospace Simulation Systems Division NASA Ames Research Center Moffett Field, California, USA September 28-29, 1998 Workshop Chairman: Dr. Subhash Saini http://science.nas.nasa.gov/Services/Training Invited Speakers: ------------------ Adve, Vikram (Rice University) Aida, K. (Tokyo Institute of Technology, JAPAN) Bagrodia, Rajive (University of California, Los Angeles) Becker, Monique (Institute Nationale des Tele. FRANCE) Berman, Francine (University of California, San Diego) Browne, James C. (University of Texas) Darema, Frederica (U.S. National Science Foundation-CISE) Dongarra, Jack (Oak Ridge National Laboratory) Feiereisen, Bill (NASA Ames Research Center) Fox, Geoffrey (Syracuse University) Gannon, Dennis (Indiana University) Gerasoulis, Apostolos (Rutgers University) Gunther, Neil J. (Performance Dynamics Company) Hey, Tony (University of Southampton UK) Hollingsworth, Jeff (University of Maryland) Jain, Raj (Ohio State University) Keahy, Kate (Los Alamos National Laboratory) Mackenzie, Lewis M. (University of Glasgow, Scotland UK) McCalpin, John (Silicon Graphics) Menasce, Daniel A. (George Mason University) Nudd, Graham (University of Warwick UK) Reed, Dan (University of Illinois) Saltz, Joel (University of Maryland) Simmons, Margaret (San Diego Supercomputer Center) Vernon, Mary (University of Wisconsin) Topics include: -------------- - Performance-by-design techniques for high-performance distributed information systems - Large transients in packet-switched and circuit-switched networks - Workload characterization techniques - Integrated performance measurement, analysis, and prediction - Performance measurement and modeling in IPG - Performance models for threads and distributed objects - Application emulators and simulation models - Performance prediction engineering of Information Systems including IPG - Performance characterization of scientific and engineering applications of interest to NASA, DoE, DoD, and industry - Scheduling tools for performance prediction of parallel programs - Multi-resolution simulations for large-scale I/O-intensive applications - Capacity planning for Web performance: metrics, models, and methods Contact: Marcia Redmond, redmond@nas.nasa.gov, (650) 604-4373 Registration: Advanced registration is required. Registration Fee: NONE. Registration Deadlines: Friday, September 23, 1998 There will be no onsite registration. Contact: Send registration information and direct questions to Marcia Redmond, redmond@nas.nasa.gov, (650) 604-4373. DESCRIPTION: The basic goal of performance modeling is to predict and understand the performance of a computer program or set of programs on a computer system. The applications of performance modeling are numerous, including evaluation of algorithms, optimization of code implementations, parallel library development, comparison of system architectures, parallel system design, and procurement of new systems. The most reliable technique for determining the performance of a program on a computer system is to run and time the program multiple times, but this can be very expensive and it rarely leads to any deep understanding of the performance issues. It also does not provide information on how performance will change under different circumstances, for example with scaling the problem or system parameters or porting to a different machine. The complexity of new parallel supercomputer systems presents a daunting challenge to the application scientists who must understand the system's behavior to achieve a reasonable fraction of the peak performance. The NAS Parallel Benchmarks (NPB) have exposed a large difference between peak and achievable performance. Such a dismal performance is not surprising, considering the complexity of these parallel distributed memory systems. At present, performance modeling, measurement, and analysis tools are inadequate for distributed/networked systems such as Information Power Grid (IPG). The purpose of performance-based engineering is to develop new methods and tools that will enable development of these information systems faster, better and cheaper. ================================================================================ Registration "First NASA Workshop on Performance-Engineered Information Systems" Send the following information to redmond@nas.nasa.gov Name _____________________________________________ Organization _____________________________________ Street Address ___________________________________ City ____________________ State __________________ Zip/Mail Code ___________ Country ________________ Phone ___________________ Fax ____________________ Email address ____________________________________ U.S. Citizen __________ Permanent Resident with Green Card ________ ******************************************************************************* Foreign National ________ (non-U.S. Citizen). Must complete the following information: Passport number ______________________ Name as it appears on passport _______________________________________ Date issued _____________ Date expires _________________ Country of citizenship____________________________ From owner-parkbench-lowlevel@CS.UTK.EDU Wed Oct 21 02:28:56 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id CAA13270; Wed, 21 Oct 1998 02:28:55 -0400 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA23157; Wed, 21 Oct 1998 02:24:45 -0400 (EDT) Received: from mail2.one.net (mail2.one.net [206.112.192.100]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id CAA23150; Wed, 21 Oct 1998 02:24:43 -0400 (EDT) Received: from port-29-44.access.one.net ([206.112.210.106] HELO aol.com ident: IDENT-NOT-QUERIED [port 22788]) by mail2.one.net with SMTP id <17237-27384>; Wed, 21 Oct 1998 02:10:48 -0400 From: Online@nj.com To: Online@nj.com Subject: Advertise with Bulk Email! Message-Id: <19981021061048Z17237-27384+1398@mail2.one.net> Date: Wed, 21 Oct 1998 02:10:42 -0400 ___________________________________________________________ Anouncing a Bulk Friendly Isp! We Bulk Email! Are you tired of getting kicked offline for Bulk Emailing? Well now you can bulk email without getting kicked offline. Call Online Direct a Bulk Friendly ISP. 513 874 7437 For only 125$ a month plus a 50$ setup fee we will send out 35,000 emails a week for you. Plus provide you with a bullet proof pop 3 email acount so you can recieve all of your mail. Ask About our special offers up to 100,000 emails per day! Any type of bulk adversting! We Do it Right! Advertise Smart Bulk Email Today! Call Online Direct at 513 874 7437 We can also Provide bullet pop 3 email acounts! CALL TODAY! 513 874 7437 if you wish to be removed from this list please type remove in reply box From owner-parkbench-comm@CS.UTK.EDU Sun Oct 25 12:41:55 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA29754; Sun, 25 Oct 1998 12:41:54 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA29327; Sun, 25 Oct 1998 12:36:00 -0500 (EST) Received: from pan.ch.intel.com (pan.ch.intel.com [143.182.246.24]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA29319; Sun, 25 Oct 1998 12:35:58 -0500 (EST) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by pan.ch.intel.com (8.8.6/8.8.5) with ESMTP id RAA16591; Sun, 25 Oct 1998 17:35:56 GMT Received: from ccm.intel.com ([143.182.69.127]) by sedona.intel.com (8.9.1a/8.9.1a-chandler01) with ESMTP id KAA27181; Sun, 25 Oct 1998 10:35:54 -0700 (MST) Message-ID: <36336126.B26DEE2C@ccm.intel.com> Date: Sun, 25 Oct 1998 10:34:30 -0700 From: Anjaneya Chagam X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: parkbench-comm@CS.UTK.EDU, Anjaneya.Chagam@intel.com Subject: Question on parkbench source code in c X-Priority: 1 (Highest) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: I am looking for packbench benchmarking programs source code in c language to do benchmarking comparison on Chime and PVM on NT platform @ Arizona State University. Could you please let me know if the parkbench programs are ported to c, if so where can I find them? Thanks a million. Name: Anjaneya R. Chagam Email: Anjaneya.Chagam@intel.com From owner-parkbench-comm@CS.UTK.EDU Mon Oct 26 06:36:26 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id GAA11147; Mon, 26 Oct 1998 06:36:25 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA07390; Mon, 26 Oct 1998 06:27:13 -0500 (EST) Received: from osiris.sis.port.ac.uk (root@osiris.sis.port.ac.uk [148.197.100.10]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA07383; Mon, 26 Oct 1998 06:27:10 -0500 (EST) Received: from mordillo (pc297.sis.port.ac.uk) by osiris.sis.port.ac.uk (4.1/SMI-4.1) id AA15115; Mon, 26 Oct 98 11:29:54 GMT Date: Mon, 26 Oct 98 11:14:06 GMT From: Mark Baker Subject: Re: Question on parkbench source code in c To: Anjaneya.Chagam@intel.com, parkbench-comm@CS.UTK.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <36336126.B26DEE2C@ccm.intel.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anjaneya, The official Parkbench code are only available in Fortran 77. I rememer vaguely sometime back hearing about a graduate-students attempt to "port" some of the low-level codes to C. Charles Grassl (Cray) and I did a little work on some simple C PingPong codes. You can check-out these on... http://www.sis.port.ac.uk/~mab/TOPIC/ Regards Mark --- On Sun, 25 Oct 1998 10:34:30 -0700 Anjaneya Chagam wrote: > Hi: > I am looking for packbench benchmarking programs source code in c > language to do benchmarking comparison on Chime and PVM on NT platform @ > Arizona State University. Could you please let me know if the parkbench > programs are ported to c, if so where can I find them? > > Thanks a million. > > Name: Anjaneya R. Chagam > Email: Anjaneya.Chagam@intel.com > > ---------------End of Original Message----------------- ------------------------------------- DCS, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: mab@sis.port.ac.uk Date: 10/26/98 - Time: 11:14:07 URL: http://www.dcs.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Mon Nov 16 10:06:23 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA11375; Mon, 16 Nov 1998 10:06:23 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA08949; Mon, 16 Nov 1998 09:01:33 -0500 (EST) Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id JAA08936; Mon, 16 Nov 1998 09:01:28 -0500 (EST) Received: from sameer.myasa.com ([202.54.106.39]) by del2.vsnl.net.in (8.9.1a/8.9.1) with SMTP id TAA13392 for ; Mon, 16 Nov 1998 19:30:37 -0500 (GMT) From: "Kashmir Kessar Mart" To: Subject: Information Date: Mon, 16 Nov 1998 19:30:48 +0530 Message-ID: <01be1169$838dd020$276a36ca@sameer.myasa.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01BE1197.9D460C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 This is a multi-part message in MIME format. ------=_NextPart_000_006D_01BE1197.9D460C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir,=20 I have seen your Web Site but could not understand what = your company is. Please let me know if you can provide me information regarding Walnut = Kernels. Regards Azad. ------=_NextPart_000_006D_01BE1197.9D460C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sir,
          &nbs= p; =20 I have seen your Web Site but could not understand what your company=20 is.
Please let me know if you can = provide me=20 information regarding Walnut Kernels.
 
Regards
Azad.
------=_NextPart_000_006D_01BE1197.9D460C20-- From owner-parkbench-comm@CS.UTK.EDU Fri Dec 4 15:44:53 1998 Return-Path: Received: from CS.UTK.EDU by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id PAA21941; Fri, 4 Dec 1998 15:44:53 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA21231; Fri, 4 Dec 1998 15:18:56 -0500 (EST) Received: from gimli.genias.de (qmailr@GIMLI.genias.de [192.129.37.12]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA21223; Fri, 4 Dec 1998 15:18:51 -0500 (EST) From: Received: (qmail 14706 invoked by uid 233); 4 Dec 1998 20:14:46 -0000 Date: 4 Dec 1998 20:14:46 -0000 Message-ID: <19981204201446.14705.qmail@gimli.genias.de> Reply-to: majordomo@genias.de To: parkbench-comm@CS.UTK.EDU Subject: Newsletter on Distributed and Parallel Computing Dear Colleague, as already announced a few weeks ago, this is now the very first issue of our bi-monthly electronic Newsletter on Distributed and Parallel Computing, DPC NEWS. !! If you want to receive DPC NEWS regularly, please just return this !! !! e-mail to majordomo@genias.de with !! !! !! !! subscribe newsletter or subscribe newsletter !! !! end end !! !! !! !! in the first two lines of the email-body (text area). !! This newsletter is a FREE service to the DPC Distributed and Parallel Computing community. It regularly informs on new developments and results in DPC, e.g. conferences, important weblinks, new books and other relevant news in distributed and parallel computing. We also keep all the information in the special newsletter section of our webpage ( http://www.genias.de/dpcnews/ ) to provide a wealth of infos for the DPC community. If you have any information which might fit into these DPC subjects, please send it to me together with the corresponding weblink, for publication in DPC News. We aim to reach a very broad community with this DPC Newletter. With Season's Greetings from GENIAS Wolfgang Gentzsch, CEO and President ===================================================================== DPC NEWSletter on Distributed and Parallel Computing GENIAS Software, December 1998 ------------------------------ http://www.genias.de/dpcnews/ GENIAS NEWS: EASTMAN CHEMICAL USES CODINE FOR MOLECULAR MODELING Eastman Chemical uses commercial quantum chemistry programs, like Gaussian, Jaguar, and Cerius2, to model chemical products, intermediates, catalysts, etc. The simulation jobs take between 1 hour and 6 days to complete. Queuing software is an important part of keeping the processors working at full utilization, without being overloaded. Since October, with the new CODINE release 4.2, Eastman has maintained over 95% CPU utilization on the available systems: http://www.genias.de/dpcnews/ BMW USES CODINE AND GRD FOR CRASH-SIMULATION At the BMW crash department, very complex compute-intensive PAM-CRASH simulations are performed on a cluster of 11 compute servers and more than 100 workstations, altogether over 370 CPUs. CODINE and GRD have optimized the utilization of this big cluster by distributing the load equally, dynamically and in an application oriented way, transparent to the 45 users: http://www.genias.de/dpcnews/ GRD MANAGES ACADEMIC COMPUTER CENTER http://www.genias.de/dpcnews/ QUEUING UP FOR GRD AT ARL ARMY RESEARCH LAB http://www.genias.de/dpcnews/ GENIAS ADDS DYNAMIC RESOURCE & POLICY MGMT TO LINUX http://www.genias.de/dpcnews/ GRD STOPPS FLOODING SYSTEM WITH MANY JOBS http://www.genias.de/dpcnews/ PaTENT MPI ACCELERATES MARC K7.3 FE ANALYSIS CODE http://www.genias.de/dpcnews/ + http://www.marc.com/Techniques/ CONFERENCES on DPC, Dec'98 - March'99: - Workshop on Performance Evaluation with Realistic Applications (sponsored by SPEC), San Jose, CA USA, Jan 25 1999: http://www.spec.org/news/specworkshop.html - ACPC99, 4th Int. Conf. on Parallel Computation, ACPC Salzburg, Austria, February 16-18 1999: http://www.coma.sbg.ac.at/acpc99/index.html - MPIDC'99, Message Passing Interface Developer's and User's Conference, Atlanta, Georgia USA, March 10-12 1999: http://www.mpidc.org - 9th SIAM Conf. on Parallel Processing for Scientific Computing, San Antonio, Texas USA, March 22-24 1999: http://www.siam.org/meetings/pp99/ - 25th Speedup Workshop, Lugano, Switzerland, March 25-26 1999: http://www.speedup.ch/Workshops/Workshop25Ann.html - CC99, 2nd German Workshop on Cluster Computing, Karlsruhe, Germany, March 25-26 1999: http://www.tu-chemnitz.de/informati/RA/CC99 More on GENIAS Webpage. http://www.genias.de/dpcnews/ NEW DPC BOOKS: - Parallel Computing Using Optimal Interconnections, Kequin Li, Yi Pan, Si Qing Zheng. Kluwer Publ 1998: http://www.mcs.newpaltz.edu/~li/pcuoi.html - High-Performance Computing, Contributions to Society,T.Tabor(Ed.),1998: http://www.tgc.com - Special Issue on Metacomputing, W. Nagel, R. Williams (Eds.), Int. J. Parallel Computing, Vol. 24, No. 12-13, Elsevier Science 1998: http://www.elsevier.nl/locate/parco More books on DPC on GENIAS Webpage: http://www.genias.de/dpcnews/ DPC WEBPAGES: - PRIMEUR: HPC electronic news magazine: http://www.hoise.com - PRIMEUR List of ESPRIT Projects: http://www.hoise.com/CECupdate/contentscecdec98.html - HPCwire, Email Newsletter: http://www.tgc.com/hpcwire.html/ - EuroTools, European HPCN Tools Working Group http://www.irisa.fr/eurotools - PTOOLS, Parallel Tools Consortium: http://www.ptools.org - TOP500: 500 fastest supercomputers: http://www.top500.org - PROSOMA: Technology fair describing hundreds of European CEC funded projects: http://www.prosoma.lu/ - Links to Linux Cluster Projects: http://www.linux-magazin.de/cluster/ More DPC WebLinks: http://www.genias.de/dpcnews/ NEWS ON HPC BENCHMARKS: - STREAM, Memory Performance Benchmark from John McCalpin: http://www.cs.virginia.edu/stream/ GENIAS JOBS: - For our CODINE/GRD Devel.Team: Software engineer with experience in GUI development under OSF/Motif, Java and Windows, distributed computing, resource mgnt systems under Unix and NT: http://www.genias.de/jobs/ CALL FOR PAPERS in upcoming Journals: - Message Passing Interface-based Parallel Programming with Java: deadline Dec. 15 1999: http://hpc-journals.ecs.soton.ac.uk/CPE/Special/MPI-Java End of DPC Newsletter ========================================================================== From owner-parkbench-comm@CS.UTK.EDU Sun Jan 24 12:15:02 1999 Return-Path: Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id MAA26189; Sun, 24 Jan 1999 12:15:01 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA08151; Sun, 24 Jan 1999 12:08:47 -0500 (EST) Received: from serv1.is4.u-net.net ([195.102.240.252]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA08144; Sun, 24 Jan 1999 12:08:44 -0500 (EST) Received: from mordillo [195.102.198.114] by serv1.is4.u-net.net with smtp (Exim 1.73 #1) id 104T1E-0003IJ-00; Sun, 24 Jan 1999 17:08:17 +0000 Date: Sun, 24 Jan 1999 17:05:53 +0000 From: Mark Baker Subject: New PEMCS paper. To: parkbench-comm@CS.UTK.EDU X-Mailer: Z-Mail Pro 6.2, NetManage Inc. [ZM62_16H] X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 A new PEMCS paper has just been accepted and published... Comparing the Scalability of the Cray T3E-600 and the Cray Origin 2000 Using SHMEM Routines, by Glenn R. Luecke, Bruno Raffin and James J. Coyle, Iowa Sate University, Ames, Iowa USA Check out... http://hpc-journals.ecs.soton.ac.uk/PEMCS/Papers/ Regards Mark ------------------------------------- DCS, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: Mark.Baker@port.ac.uk Date: 01/24/1999 - Time: 17:05:53 URL: http://www.dcs.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Tue Feb 2 08:17:19 1999 Return-Path: Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id IAA08459; Tue, 2 Feb 1999 08:17:19 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id HAA01393; Tue, 2 Feb 1999 07:42:18 -0500 (EST) Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id HAA01386; Tue, 2 Feb 1999 07:42:16 -0500 (EST) Received: from [148.197.205.63] (helo=mordillo) by serv1.is1.u-net.net with smtp (Exim 2.00 #2) for parkbench-comm@cs.utk.edu id 107f7u-0005uS-00; Tue, 2 Feb 1999 12:40:22 +0000 Date: Tue, 2 Feb 1999 12:40:29 +0000 From: Mark Baker Subject: New PEMCS Paper - resend... To: parkbench-comm@CS.UTK.EDU X-Mailer: Z-Mail Pro 6.2, NetManage Inc. [ZM62_16H] X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Apologies for the resend - I think this email get lost when I sent it a couple of weeks back. --------------------------------------------------------------------------- A new PEMCS paper has just been accepted and published... "Comparing the Scalability of the Cray T3E-600 and the Cray Origin 2000 Using SHMEM Routines", by Glenn R. Luecke, Bruno Raffin and James J. Coyle, Iowa Sate University, Ames, Iowa USA Check out... http://hpc-journals.ecs.soton.ac.uk/PEMCS/Papers/ Regards Mark ------------------------------------- DCS, University of Portsmouth, Hants, UK Tel: +44 1705 844285 Fax: +44 1705 844006 E-mail: Mark.Baker@port.ac.uk Date: 02/02/1999 - Time: 12:40:29 URL: http://www.dcs.port.ac.uk/~mab/ ------------------------------------- From owner-parkbench-comm@CS.UTK.EDU Tue Mar 2 10:35:47 1999 Return-Path: Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id KAA18531; Tue, 2 Mar 1999 10:35:46 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA01804; Tue, 2 Mar 1999 10:18:56 -0500 (EST) Received: from gimli.genias.de (qmailr@GIMLI.genias.de [192.129.37.12]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA01781; Tue, 2 Mar 1999 10:18:49 -0500 (EST) Received: (qmail 8905 invoked from network); 2 Mar 1999 15:19:10 -0000 Received: from fangorn.genias.de (192.129.37.74) by gimli.genias.de with SMTP; 2 Mar 1999 15:19:10 -0000 Received: (from daemon@localhost) by FANGORN.genias.de (8.8.8/8.8.8) id QAA13715; Tue, 2 Mar 1999 16:19:05 +0100 Date: Tue, 2 Mar 1999 16:19:05 +0100 Message-Id: <199903021519.QAA13715@FANGORN.genias.de> To: parkbench-comm@CS.UTK.EDU From: Majordomo@genias.de Subject: Welcome to newsletter Reply-To: Majordomo@genias.de -- Welcome to the newsletter mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe newsletter or from another account, besides parkbench-comm@CS.UTK.EDU: unsubscribe newsletter parkbench-comm@CS.UTK.EDU If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: The GENIAS Newsletter keeps you informed about new products, services and information about High Performance Computing. It serves as an addition to our printed newsletter that is distributed to our customers. To see our printed version, just visit our web-site http://www.genias.de and follow the link 'newsletter'. From owner-parkbench-comm@CS.UTK.EDU Wed Mar 3 02:34:35 1999 Return-Path: Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by netlib2.cs.utk.edu with ESMTP (cf v2.9t-netlib) id CAA01271; Wed, 3 Mar 1999 02:34:35 -0500 Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA00679; Wed, 3 Mar 1999 02:32:28 -0500 (EST) Received: from gimli.genias.de (qmailr@GIMLI.genias.de [192.129.37.12]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA00668; Wed, 3 Mar 1999 02:32:25 -0500 (EST) Received: (qmail 10306 invoked from network); 3 Mar 1999 07:32:58 -0000 Received: from gandalf.genias.de (192.129.37.10) by gimli.genias.de with SMTP; 3 Mar 1999 07:32:58 -0000 Received: by GANDALF.genias.de (Smail3.1.28.1 #30) id m10I69J-000B10C; Wed, 3 Mar 99 08:32 MET Message-Id: From: gentzsch@genias.de (Wolfgang Gentzsch) Subject: sorry! To: parkbench-comm@CS.UTK.EDU Date: Wed, 3 Mar 99 8:32:57 MET Cc: gent@genias.de (Wolfgang Gentzsch) Reply-To: gentzsch@genias.de X-Mailer: ELM [version 2.3 PL11] Dear colleagues, I just discovered that the parkbench-comm@CS.UTK.EDU has been collected into our mailing list for our electronic DPC Newsletter. I very much appologize for this mistake. Thank you for your understanding! Kind regards Wolfgang -- -- subscribe now to http://www.genias.de/dpcnews/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - Wolfgang Gentzsch, CEO Tel: +49 9401 9200-0 GENIAS Software GmbH & Inc Fax: +49 9401 9200-92 Erzgebirgstr. 2 http://www.geniasoft.com D-93073 Neutraubling, Germany gentzsch@geniasoft.com - - - - - - - - - - - - - - - - - - - - - - - - - - - GENIAS Software Inc. Tel: 410 455 5580 UMBC Technology Center Fax: 410 455 5567 1450 S. Rolling Road http://www.geniasoft.com Baltimore, MD 21227, USA gentzsch@geniasoft.com = = = = = = = = = = = = = = = = = = = = = = = = = = = From info@enne.online.pt Wed Feb 26 06:01:59 2003 Return-Path: Received: from fep03-svc.mail.telepac.pt (fep03-svc.mail.telepac.pt [194.65.5.202]) by netlib2.cs.utk.edu (8.12.3/8.12.3) with ESMTP id h1QB1vaN019072 for ; Wed, 26 Feb 2003 06:01:58 -0500 (EST) Received: from cat1335 ([213.13.76.63]) by fep03-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20030226110150.IYQO11175.fep03-svc.mail.telepac.pt@cat1335> for ; Wed, 26 Feb 2003 11:01:50 +0000 From: ":: enne magazine ::" To: parkbench-method-archive@netlib2.cs.utk.edu Subject: :: enne magazine 07 :: X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Reply-To: info@enne.online.pt Date: Wed, 26 Feb 2003 11:01:35 -0000 Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-Id: <20030226110150.IYQO11175.fep03-svc.mail.telepac.pt@cat1335> :: enne magazine ::

:::::: Notícias
:::::: ... Macworld SF 2003
:::::: ... Gotan Project
:::::: ... Phuturesoul.org

:::::: Midem
:::::: ... ENNE no 37º MIDEM em Cannes

:::::: Entrevista
:::::: ... Michael Mayer - Kompakt Discothèque

:::::: Moda
:::::: ... Queens of kitsch

:::::: Reporter X
:::::: ... Alô Lisboa

:::::: Brasil @ enne
:::::: ... Elas comandam as pistas no Brasil

:::::: Figuras da Música
:::::: ... Larry Heard - O Pai do Deep House

:::::: Trance
:::::: ... Os Momentos que mudaram o Trance Portugês (Parte1)

:::::: Entrevista
:::::: ... Seiji - O Londrino tranquilo

:::::: Entrevista
:::::: ... Mellow Kitty entrevista Tó Ricciardi

:::::: Top Ten
:::::: ... Vinyl Market - Barcelos
:::::: ... WorldMusic - Braga
:::::: ... BimotorDJ - Coimbra

:::::: Design
:::::: ... Ross Lovegroove

:::::: Destaques
:::::: ... Por Mellow Kitty

:::::: Ao Vivo
:::::: ... Cinematic Orchestra
:::::: ... William Parker Quartet feat. Leena Conquest

:::::: Teatro
:::::: ... A Treta Continua (parte 2)


:::::: Casas e Discotecas
:::::: 3º Aniversário Cuba Libre
:::::: Must caffé
:::::: Mambo
:::::: Maré Cheia
:::::: Astória
:::::: Azenha Bar
:::::: La Gloria Cubana
:::::: Histórico
:::::: Mercado Bar
:::::: Amadeo
:::::: Barbieri café
:::::: Buda Bar
:::::: Zonagrícola
:::::: Pedra do Couto
:::::: Lagar's
:::::: Danúbio
:::::: Vogue
:::::: Versus caffé
:::::: Estado Novo
:::::: SanMiguel
:::::: Vaticano Club
:::::: Ozone
:::::: NewWorld
:::::: Oskar.DJ
:::::: Ar Produções

:::::: Entrevistas
:::::: ... Nelinho, residente do Pacha - Ofir
:::::: ... D. Isilda, gerente da Discoteca Lagar's - Amares




A enne magazine é uma revista mensal gratuíta com duas capas distintas e inversas, relacionadas com a música de dança, (dance.music.info) e, relacionado com o party people e divulgação de datas de eventos (dance.music.clubs). 


Capa, impressa em papel mate com 350 grms.
Miolo, impresso em papel mate com 150 grms.


Caso tenha recebido este email em duplicado, por favor informe a enne magazine para que seja retirado essa duplicação...Obrigado

Esta newsletter foi-lhe enviada respeitando a legislação em vigor.
Caso pretenda retirar o seu e-mail da nossa mailing-list é necessário o envio de um e-mail para remover@enne.online.pt com a indicação da newsletter que pretende deixar de receber.
Para outras questões relacionadas com a Newsletter contacte a enne magazine.

From info@enne.online.pt Tue Mar 11 03:28:11 2003 Return-Path: Received: from fep04-svc.mail.telepac.pt (fep04-svc.mail.telepac.pt [194.65.5.203]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with ESMTP id h2B8S9SP024584 for ; Tue, 11 Mar 2003 03:28:10 -0500 (EST) Received: from cat1335 ([213.13.76.191]) by fep04-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20030311082802.PIZJ20007.fep04-svc.mail.telepac.pt@cat1335> for ; Tue, 11 Mar 2003 08:28:02 +0000 From: ":: enne magazine ::" To: parkbench-method-archive@netlib2.cs.utk.edu Subject: enne magazine 08 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Reply-To: info@enne.online.pt Date: Tue, 11 Mar 2003 08:28:17 -0000 Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-Id: <20030311082802.PIZJ20007.fep04-svc.mail.telepac.pt@cat1335> :: enne magazine ::





:::::: CRÓNICA
:::::: ... Portugal, Magnólia e a Raquel

:::::: CINEMA
:::::: ... Esquece Tudo o Que Te Disse

:::::: ENTREVISTA
:::::: ... Zé Pedro - Xutos e Pontapés

:::::: DESIGN
:::::: ... Tom Dixon

:::::: MODA
:::::: ... Beayty and the Beast

:::::: ENTREVISTA
:::::: ... Mellow Kitty entrevista Dj Nacho e Lady B.

:::::: TOP TEN
:::::: ... Vinyl Market - Barcelos
:::::: ... WorldMusic - Braga
:::::: ... BimotorDJ - Coimbra

:::::: ENTREVISTA
:::::: ...Mário Motivo entrevista Nuno di Rosso e Felix daCat

:::::: SUPER BOCK SUPER ROCK 2003
:::::: ... Abril, concertos mil

:::::: ENTREVISTA
:::::: ... Mário Motivo entrevista Dj Pena

:::::: ROTEIRO DE VIGO




:::::: CASAS E DISCOTECAS
:::::: Astória
:::::: Triangulo Bar
:::::: Azenha Bar
:::::: Maré Cheia
:::::: Barbieri café
:::::: Cuba Libre
:::::: Mambo
:::::: Amadeo
:::::: Histórico
:::::: La Glória Cubana
:::::: Buda Bar
:::::: Sereia da Gelfa
:::::: Greens Club
:::::: Zonagrícola
:::::: Dominus Club
:::::: Pedra do Couto
:::::: Lagar's
:::::: Danúbio
:::::: Estado Novo
:::::: SanMiguel
:::::: Vogue
:::::: Vaticano Club
:::::: Versus caffé
:::::: NewWorld
:::::: Oskar.DJ
:::::: Karma Produções

:::::: JANTAR DE GALA
 :::::: ...Casino da Póvoa




A enne magazine é uma revista mensal gratuíta com duas capas distintas e inversas, relacionadas com a música de dança, (dance.music.info) e, relacionado com o party people e divulgação de datas de eventos (dance.music.clubs). 


Capa, impressa em papel mate com 350 grms.
Miolo, impresso em papel mate com 150 grms.


Caso tenha recebido este email em duplicado, por favor informe a enne magazine para que seja retirado essa duplicação...Obrigado

Esta newsletter foi-lhe enviada respeitando a legislação em vigor.
Caso pretenda retirar o seu e-mail da nossa mailing-list é necessário o envio de um e-mail para remover@enne.online.pt com a indicação da newsletter que pretende deixar de receber.
Para outras questões relacionadas com a Newsletter contacte a enne magazine.

From Services@ywzc.net Tue Apr 15 12:25:00 2003 Return-Path: Received: from ywzc.net ([218.86.41.42]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id h3FGOrSP019706 for ; Tue, 15 Apr 2003 12:24:59 -0400 (EDT) Message-Id: <200304151624.h3FGOrSP019706@netlib2.cs.utk.edu> From: "Lucy" To: Subject: Hi Sender: "Lucy" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 16 Apr 2003 00:21:48 +0800 Reply-To: "Lucy" Content-Transfer-Encoding: 8bit Email Marketing is one of the most effective and inexpensive ways to promote your products and services. We offer a complete Email Marketing solution with quality service and the lowest prices. The result is that you will enjoy more success. 1. Targeted Email Addresses We can supply targeted email addresses according to your requirements, which are compiled only on your order, such as region / country / field / occupation / Domain Name etc. We will customize your customer email addresses. * We have millions of email addresses in a wide variety of categories. 2. Targeted Mailing If you are worried about any complications or consequences with sending out targeted emails, or want to avoid the work of sending out targeted emails. We will do it for you! We will send your email message to your targeted customers. * We can Bullet Proof your Web Site. We also supply a wide variety of marketing software. For more details, you can refer to our web site: http://www.biz-aiding.com Our services will help you get more business opportunities. Regards! Mrs. Lucy Customer Services www.biz-aiding.com Targeted Marketing, at Great Fee. *************************************************************************** Receiving this email because you registered to receive special offers from one of our partners. If you would prefer not to receive future email, Click here Http://unsubscribe-mail.com *************************************************************************** From info@enne.online.pt Mon Apr 21 22:20:41 2003 Return-Path: Received: from fep05-svc.mail.telepac.pt (fep05-svc.mail.telepac.pt [194.65.5.209]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with ESMTP id h3M2KeSP011005 for ; Mon, 21 Apr 2003 22:20:41 -0400 (EDT) Received: from cat1335 ([213.13.77.250]) by fep05-svc.mail.telepac.pt (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with SMTP id <20030422022034.ODEQ17685.fep05-svc.mail.telepac.pt@cat1335> for ; Tue, 22 Apr 2003 03:20:34 +0100 From: ":: enne magazine ::" To: parkbench-method-archive@netlib2.cs.utk.edu Subject: COMUNICADO >> ENNE MAGAZINE X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Reply-To: info@enne.online.pt Date: Tue, 22 Apr 2003 03:21:03 -0000 Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-Id: <20030422022034.ODEQ17685.fep05-svc.mail.telepac.pt@cat1335> Untitled Document

enne magazine
COMUNICADO

A revista enne magazine vem por este meio informar que o serviço de MSN e o serviço WEBcam LIVE se encontra, a partir de hoje dia 21 de Abril encerrado.

Queremos agradecer a toda gente que tem utilizado o Messenger MSN para retirar qualquer duvida relacionada ou não com a revista enne.

Este encerramento dos serviços de MSN e de WEBcam devesse ao facto de algumas pessoas terem usado nomes (usernames) no Messenger que não correspondiam na realidade às pessoas que estavam a tentar teclar connosco, (fazendo-se passar por pessoas que não eram), recolhendo assim informações de certo modo confidenciais e que não lhes correspondiam.

Nunca pensamos que, algumas pessoas sem escrúpulos pudessem fazer esse tipo de manobras.

É para nós uma chamada de atenção...
Tentamos fazer da enne on-line um portal de musica, onde os utilizadores da enne poderiam colocar as dúvidas ONLINE e terem as respostas imediatamente.

Fomos ignorantes ao ponto de colocarmos uma WEBcam ONLINE 24 horas para as pessoas verem como é que uma revista trabalha.

A enne magazine é a única revista, desde que temos conhecimento a fazer este tipo de marketing, tecla a tecla, cara a cara...

Demos algumas bofetadas em algumas pessoas que se sentiram ofendidas com a nossa imaginação, e que por meios acima descritos nos fizeram tomar esta atitude.

Pedimos desde já desculpas às pessoas que diariamente teclam connosco e que diariamente seguem a nossa WEBcam.

Sem mais de momento
Bruno Gomes
From Marketing123@2911.net Thu Dec 18 03:30:50 2003 Return-Path: Received: from 2911.net ([218.6.9.94]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id hBI8UlMN013100 for ; Thu, 18 Dec 2003 03:30:49 -0500 (EST) Message-Id: <200312180830.hBI8UlMN013100@netlib2.cs.utk.edu> From: "Host" To: Subject: Bulk Friendly Web Hosting & Server Sender: "Host" Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Thu, 18 Dec 2003 16:21:36 +0800 Reply-To: "Host" Content-Transfer-Encoding: 8bit We offer reliable bulk email friendly web hosting services

We offer reliable bulk email friendly web hosting services. You can now have the
peace of mind knowing that your web site is secure during your email marketing
campaigns.

Bullet-Proof Web Hosting 100% Guaranteed! We guarantee that your site will be
99% uptime.

We also offer Bullet-Proof dedicated server:

Two IPs
512MB RAM DDR
PIIII / Two CPU
40 GB SCS
Intel 82559 LAN /(2U)
Unlimited Data Transfer
Linux/Windows/FreeBSD
 		 Three IPs
1024MB RAM DDR
PIIII / Two CPU
120 GB SCS
Intel 82559 LAN /(2U)
Unlimited Data Transfer
Linux/Windows/FreeBSD
 		 Dynamic IP
1024MB RAM DDR
PIIII / Two CPU
180 GB SCS
Intel 82559 LAN /(2U)
Unlimited Data Transfer
Linux/Windows/FreeBSD
 
Price: No setup fee
          US$ 599.00/month		 Price: No setup fee
          US$ 699.00/month		 Price: No setup fee
          US$ 999.00/month


Allowed Usage
You can use the server for any of the following:

Direct Bulk Mailing or Proxy Mailing
Web Site Hosting
Proxy, Relay or Port Scanning

We can supply Targeted Email Addresses according to your requirements, and
send out Targeted Emails for you. For more information, please contact us by 
Vikas@eyou.com

It will be our pleasure to do business with you.


Cheers!

Nebiyu Bellete
Support Teams

****************************************************************************************
Receiving this email because you registered to receive special offers from us.
Please click here to unscbscirbe:Sallywest31@yahoo.com?subject=take-off
****************************************************************************************

From Bulksales@freemail.soim.com Tue Mar 2 02:21:43 2004 Return-Path: Received: from 160.36.58.108 ([218.6.13.78]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id i227LdCn023463 for ; Tue, 2 Mar 2004 02:21:42 -0500 (EST) Message-ID: From: "Web" To: parkbench-method-archive@netlib2.cs.utk.edu X-MS-IAU: PWXVFTDMMV Date: Tue, 02 Mar 04 03:21:42 Öйú±ê׼ʱ¼ä X-Priority: 1 X-MSMail-Priority: High Subject: Bullet Proof Web Hosting & Server X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=WC_MAIL_PaRt_BoUnDaRy_05151998 This is a multi-part message in MIME format. --WC_MAIL_PaRt_BoUnDaRy_05151998 Content-Type: text/html Content-Transfer-Encoding: 7Bit We offer reliable bulk email friendly web hosting services

We offer reliable bulk email friendly web hosting services. You can now have the
peace of mind knowing that your web site is secure during your email marketing
campaigns.

Bullet-Proof Web Hosting 100% Guaranteed! We guarantee that your site will be
99% uptime.

We also offer Bullet-Proof dedicated server:

Two IPs
512MB RAM DDR
PIIII CPU
36 GB SCSI
Intel 82559 LAN /(2U)
Unlimited Data Transfer
Linux/Windows/FreeBSD
 		 Three IPs
1024MB RAM DDR
PIIII / Two CPU
72 GB SCSI
Intel 82559 LAN /(2U)
Unlimited Data Transfer
Linux/Windows/FreeBSD
 		 Dynamic IP
1024MB RAM DDR
PIIII / Two CPU
72 GB SCSI
Intel 82559 LAN /(2U)
Unlimited Data Transfer
Linux/Windows/FreeBSD
 
Price: No setup fee
          US$ 599.00/month		 Price: No setup fee
          US$ 799.00/month		 Price: No setup fee
          US$ 999.00/month


Allowed Usage
You can use the server for any of the following:

Direct Bulk Mailing or Proxy Mailing
Web Site Hosting
Proxy, Relay or Port Scanning

We can supply Targeted Email Addresses according to your requirements, and
send out Targeted Emails for you. For more information, please contact us by 
ContactHosting@tom.com Or Vikas@eyou.com

It will be our pleasure to do business with you.

PS: Please do not reply to this e-mail. Contact us by ContactHosting@tom.com


Thanks!

Mr Bell
Support Teams

****************************************************************************************
Receiving this email because you registered to receive special offers from us.
Please click here to unscbscirbe:llylist@yahoo.com?subject=take-off
****************************************************************************************

hnUvSxVgbFDiIyD --WC_MAIL_PaRt_BoUnDaRy_05151998-- From pagrest@stockcero.com Tue Mar 23 10:51:35 2004 Return-Path: Received: from stockcero.com (host-73.14.60.66-te.adsl.netizen.com.ar [66.60.14.73]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id i2NFpXCn025279 for ; Tue, 23 Mar 2004 10:51:34 -0500 (EST) Message-Id: <200403231551.i2NFpXCn025279@netlib2.cs.utk.edu> From: "Pablo Agrest Berge" To: Subject: Long time out of print books about Latin America may become available again Sender: "Pablo Agrest Berge" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 23 Mar 2004 12:43:58 -0300 Content-Transfer-Encoding: 8bit Dear Sirs, We are a small publishing company, specialized in books related to Latin American topics, both in Spanish and English. We use Print on Demand technology and aim to offer North American readers, Students, Teachers, Librarians and Booksellers, extensive catalogues of high quality books, printed in the US. Besides the titles the Latin American publishers who work with us include in our catalogue, we have access to extensive libraries such as the The History Academy of Argentina, so through special agreements we can bring back into print many long time out of print titles. Please take some time and visit our Academic Services Info Page http://www.stockcero.com/academicservices.php?ref=217914179 Periodically we will send you news about the titles we add to our catalogue. If this in some way may bother you please ask to be removed from the news list by clicking academicservices@stockcero.com and typing "remove" and the recipient email address in the subject line. Sincerely yours, Pablo A. Agrest Berge CEO Stockcero, Inc. From mrsjessica_uba11@email.ro Tue Aug 17 11:15:27 2004 Return-Path: Received: from zerg.astral.ro (zerg.cluj.astral.ro [193.230.240.30]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with ESMTP id i7HFFP7a009552 for ; Tue, 17 Aug 2004 11:15:26 -0400 (EDT) Received: (from httpd@localhost) by zerg.astral.ro (8.11.6/8.11.4) id i7HFEcT12245; Tue, 17 Aug 2004 18:14:38 +0300 Message-Id: <200408171514.i7HFEcT12245@zerg.astral.ro> From: Jessica Uba To: mrsjessica_uba11@email.ro Reply-To: mrsjessicauba@asiamail.com Subject: GOD BLESS YOU Date: Tue, 17 Aug 2004 18:14:38 +0300 MIME-Version: 1.0 X-Originating-IP: [80.179.107.88, 80.179.107.88] X-Mailer: freemail 0.9.8 X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Organization: ASTRAL FreeMail From: MRS.Jessica Uba, Compliments of the day. I am Mrs.Jessica Uba a former staff of the Federal Ministry of Aviation undergoing medical Treatment. I am married to DR.John Uba who worked with National Petroleum Corporation for nineteen years before he died in the year 2003. We were married for eleven years without a child. He died after a brief illness that lasted for only four days. When my late husband was alive he deposited a huge sum of money with one finance/security company in Europe. Presently, this money is still with the Security Company.This money was accumulated from an onshore engineering awards my husband won during the last military regime.Presently, this money is still with the Security Company. Recently, my Doctor told me that i will die any moment.right now,i don't have any alternative rather than to took this BOLD DECISION. Though what disturbs me most is that I'm diagonalized to be having spinal abnormality .Having known my condition of health that i will die any moment from now.I decided to donate this fund to a charity home organization(church) or any individual(person) that will utilize this money with my instructions. The reason why i decided to invest this money outside the country,is because of the high level of corruption here.i feel it is better to invest this money outside the country where the purpose of investment will be fulfilled. I need a trust worthy person or organization who will help me to accomplish my heart desire before my death Here are my instructions: [1] The money must be used for orphanages,widows and less privilege people. [2] The orphanages home must be build and bear my name for remembrance(like JESSICA memorial center) [3] The money should also be used for their educations and maintenance. [4] 15% of the total money will be giving to you for your assitance. If you will be of assistance, I will surely appreciate and thank you for your kindness. Thank you, and God bless. MRS.JESSICA. _________________________________ Vreau sa-mi inregistrez CV-ul la BursaMuncii! Vreti sa publicati oferte de munca? Noi avem solutia! Lasa profesionistii sa lucreze pentru tine! http://www.bursamuncii.ro From Promoteforyou@citiz.net Tue Sep 7 12:38:26 2004 Return-Path: Received: from citiz.net ([218.6.2.231]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id i87GcM17002892 for ; Tue, 7 Sep 2004 12:38:25 -0400 (EDT) Message-Id: <200409071638.i87GcM17002892@netlib2.cs.utk.edu> From: "Nancy" To: Subject: Marketing Solution Sender: "Nancy" Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Wed, 8 Sep 2004 00:38:04 +0800 Reply-To: "Nancy" Content-Transfer-Encoding: 8bit E

We offer a complete E-Marketing solution with quality service and 
the lowest prices.

Professional offer:

1. Email addresses according to your requirements. 

2. Send emailing according to your requirements. 

3. Dedicated Server & Web Hosting solutions.

For more details:  www.3807.com

We will help you get more business opportunities.

Ms Nancy
www.3807.com
info@3807.com
 Customer Support

*******************************************************************************
Take off: Mary@USA.net?subject=169
*******************************************************************************

From nobody@inertia01.solutions-for-learning.com Tue Jan 18 21:30:33 2005 Return-Path: Received: from inertia01.solutions-for-learning.com (146.67-18-53.reverse.theplanet.com [67.18.53.146] (may be forged)) by netlib2.cs.utk.edu (8.12.8/8.12.3) with ESMTP id j0J2UXaZ003288 for ; Tue, 18 Jan 2005 21:30:33 -0500 (EST) Received: from nobody by inertia01.solutions-for-learning.com with local (Exim 4.43) id 1Cr59K-0001zL-7D; Tue, 18 Jan 2005 21:00:46 -0500 To: Subject: WINNING NOTIFICATION From: sirjohn X-Priority: 3 (Normal) CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Message-Id: Date: Tue, 18 Jan 2005 21:00:46 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - inertia01.solutions-for-learning.com X-AntiAbuse: Original Domain - netlib2.cs.utk.edu X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - inertia01.solutions-for-learning.com X-Source: X-Source-Args: X-Source-Dir: British Lottery Headquarters: Customer Service 28 TANFIELD ROAD, CROYDON.LONDON Ref: BTL/491OXI/04 Batch: 12/25/0304 WINNING NOTIFICATION We happily announce to you the draw of the British Lottery International programs held on the 10th of January 2005 in London.Your e-mail address attached to ticket number: 694 75600545 721 with Serial number 886/04 drew the lucky numbers: 31-6-26-13-35-7,which subsequently won you the lottery in the 2nd category.You are therefore, been approved to claim a total sum of US$2,500,000.00(Two million, five hundred thousand, United StatesDollars) in cash credited to file RPC/9080118308/04.This is from a total cash prize of US $125 Million dollars, shared amongst the first Fifty (50) lucky winners in this! category. This year Lottery Program Jackpot is the largest ever for British Lottery .The estimated $125 million jackpot would be the sixth-biggest in U.K. history.The biggest was the $363 million jackpot that went to two winners in a May 2000 drawing of The Big Game, Mega Millions' predecessor. Please note that your lucky winning number falls within our European booklet representative office in Europe as indicated in our play coupon. In view of this, your US$2,500,000.00 (Two million, five hundred thousand,United States Dollars) would be released toyou by our affiliate bank in London. Our agent will immediately commence the process to facilitate the release of your funds to you as soon as you make contact with him . All participants were selected randomly from World Wide Web site through computer draw system and extracted from over 100,000 companies.This promotiontakes place annually. For security reasons, you are advised to keep your winning ! information confidential till your claims is processed and your money remitted to you in whatever manner you deem fit to claim your prize. This is a part of our precautionary measure to avoid double claiming and unwarranted abuse of this program by some unscrupulous elements. Please be warned.To file for your claim, please contact our fiduciary agent with the below details for processing of your claims. AGENT: Mr.Henry James Email: henryjames@britishnationallotto.com To avoid unnecessary delays and complications, please quote your reference/batchnumbers in any correspondences with us or our designated agent.Congratulations once more from all members and staffs of this program.Thank you for being part of our promotional lottery program. Sincerely, Sir john Barckley Zonal Coordinator. ___________________________________________________________________________ Mail sent from WebMail service at PHP-Nuke Powered Site - http://yoursite.com From Mars@bmypc.com Wed Feb 16 18:36:28 2005 Return-Path: Received: from dwp.net (ppp37-68-gw04.athens.access.acn.gr [213.5.37.68]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id j1GNYMTu006135; Wed, 16 Feb 2005 18:34:55 -0500 (EST) Received: from 196.84.55.144 by 213.5.37.68; Wed, 16 Feb 2005 17:39:53 -0300 From: "Meczynski Lukasz" To: "Berggren Henriette" Subject: Stallone Wagemans Ivo Date: Wed, 16 Feb 2005 17:39:53 +0300 Message-ID: <557801c51480$09ca8ff1$442505d5@dwp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Amend solution http://Rocha.jrz874383w.com/cs/?theman From Behnudi@tf1.fr Sat Feb 19 06:16:52 2005 Return-Path: Received: from outblaze.net (69-166-57-110.lkwnny.adelphia.net [69.166.57.110]) by netlib2.cs.utk.edu (8.12.8/8.12.3) with SMTP id j1JBGeTv016460; Sat, 19 Feb 2005 06:16:49 -0500 (EST) From: "Fontaine Christopher" To: "Rajkovic Aleksandar" Subject: Re[5]: talk about their pills Date: Sat, 19 Feb 2005 05:20:26 -0300 Message-ID: <1b7301c51675$225418d4$6e39a645@outblaze.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_456789AB.CDEF0123" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SP -M
UR
  The  we and  Saf Wa Ph acy 
is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim