NAS Grid Benchmarks Version 1'0

1

• NAS Grid Benchmarks Version 1.0
• Rob F. Van der Wijngaart, Michael Frumkin
• presenter George Tsouloupas

2
History-NPB1

• The NAS Parallel Benchmarks (NPB1)
• designed as an objective measure for the
  capabilities of HW/SW to solve computationally
  intensive CFDs.
• circa 1991 no accepted standards for programming
  parallel computers, so an implementation would
  probably be biased in terms of configuration or
  programming paradigm.
• Hence, a pencil-and-paper specification

3
History-NPB1

• All aspects of implementation are left to the
  implementor
• A reference implementation was provided for
  convenience.
• No claims of algorithmic efficiency or
  appropriateness for any specific system.
• NPB1 was widely embraced by vendors and
  researchers

4
History-NPB2

• Trigger Considerable convergence to the MPI
  programming paradigm.
• NAS created the source code implementation (as
  NGB2) that is intended for minimal tampering.
• Revisions 2.1-4

5
NGB Rationale

• Computational grids are at a development stage
  comparable to that of high perf. computers in the
  late 80's.
• Several prototype toolkits (Globus, Legion,
  CORBA, Condor, SGE, etc. .... each with relative
  metrics that are not well understood.)
• We need to explore the capabilities of Grids
• Enter NGB

6
NGB Aims

• Provide an exploration tool for grids, just as
  the NPB did for high perf. computing systems.
• Provide a pencil-and-paper specification to serve
  as a uniform tool for test functionality and
  efficiency of grid environments.
• Does not specify implementation (authentication,
  security, fault tolerance, scheduling, grid
  environment, mapping of NPB tasks onto the Grid.

7
NGB Design

• As NPB, NGB is made available in several problem
  sizes (classes).
• An NGB problem is specified by a Data Flow Graph
  made up of
• nodes encapsulating NGB Tasks (i.e. NPB programs)
• communication between these tasks
• Each DFG contains a Report node that collects and
  verifies the status of the tasks.

8
Motivation for NPB problem selection

• BT, SP, LU, MG and FT are selected
• Good specifications and implementations exist
• The NPB are well-studied, well-understood, widely
  accepted, with solid verification procedures.
• NPB problems need no interaction or data to start
• but they can use data if so desired
• NPB problems produce sizable arrays that can be
  used as input to other NPB problems.

9
Motivation for NPB problem selection

• Varying granularity by varying the number of
  iterations
• Sensible scientific computations
• Flow solvers (SP, BT, LU)
• Data Smoother (MG)
• Visualization (spectral analysis FT)

10
Data Flow Graphs

• An NGB instance is specified by a DFG.
• A DFG is a set of nodes connected be directed
  arcs.
• Computational nodes are NPB problems that are
  specified by
• class (mesh size iterations)
• data sources
• consumers of solution

11
DFG Nodes and Arcs

• Nodes
• Launch node initiates benchmark by passing
  control to the nodes
• Report node collects and validated results
• Computational tasks for filtering(MF) and
  solving.
• Arcs
• Exchange of data / control
• Type of data is determined by the receiving node.
• Mechanisms are of course not defined.
• Output is sent by the producer to all nodes
  connected to it.

12
The four NGB problems (benchmarks)

• Embarrassingly Distributed (ED)
• Helical Chain (HC)
• Visualization Pipe (VP)
• Mixed Bag (MB)

13
Embarrassingly Distributed
Launch
SP.S
SP.S
SP.S
SP.S
SP.S
SP.S
SP.S
SP.S
SP.S
Report

• Can represent parameter studies
• Multiple independent runs of the same program but
  with different input parameters
• No communication between instances of SP

14
Helical Chain (HC)
Launch
BT.S
SP.S
LU.S
MF
MF
MF
BT.S
SP.S
LU.S
MF
MF
MF
BT.S
SP.S
LU.S
MF
MF
Report

• Much like the breakup of a long running
  simulation
• Long chains of repeating processes

15
Visualization Pipe (VP)
Launch
BT.S
MF
MG.S
MF
FT.S
BT.S
MF
MG.S
MF
FT.S
BT.S
MF
MG.S
MF
FT.S
Report

• Visualizing solutions as a simulation progresses
• Flow Solver (BT) gtgt Post Processor(MG) gtgt
  Visualization (FT)

16
Mixed Bag (MB)

• Similar to VP but with emphasis on asymmetry.
• Some tasks require more work than others, making
  it more difficult for the scheduler.
• Load imbalance
• Synchronization between levels
• Additional complexity varying iterations/time-ste
  ps, indicated by subscripts

Launch
LU.Sk
LU.Sl
LU.Sm
MF
MF
MF
MG.Sk
MG.Sl
MG.Sm
MF
MF
MF
FT.Sk
FT.Sl
FT.Sm
Report
17
Some DFG notes

• Width of the DFG is the maximum number of nodes
  that can be executed concurrently.
• Depth of the DFG is the length of the critical
  path of the nodes
• Size of the DFG is the Width x Depth.
• Launch, Report and Filter nodes don't count.
• DFGs can scale to be useful on more capable
  systems by both increasing the computation of the
  nodes and by sizing the graph.

18
NGB classes
19
Recap and thoughts

• These are still pencil-and-paper...
• but they build upon the respected NPB
• Implementation (including mapping) not
  specified...
• The four NGB problems (don't) cover the main
  usage paradigms for the Grid (?)