Domain-Specific Metacomputing for Computational Science: Achieving Specificity Through Abstraction By Steven Hackstadt |
Chapter 1
(1) According to corporate press releases, the first three systems
delivered as part of the ASCI program cost $46 mil lion (Intel), $93
million (IBM), and $110 million (SGI/Cray), respectively; the entire
ASCI budget is nearly $1 billion over the next ten years.
(1) The second testbed, Globus Ubiquitous Supercomputing Testbed
(GUSTO), was scheduled to begin in late 1996, but no literature on the
project has yet appeared. Foster and Kesselman [FK96] suggest that
this testbed will focus more on the computer science problems of
metacomputing, such as authentication, scheduling, communication, and
information.
(1) The Intel Paragon used the NX message-passing library and the GNU
g++ and Intel C++ compilers; the IBM machines used the MPL
communications library and the IBM xlC compiler; and the T3D used a
modified version of PVM and Cray C++ [NSD95].
(1) Our use of the term "domain-specific environment" is consistent
with the apparent first application of the term in this way by Cuny et
al. [CDHH96]. In the same work, Cuny et al. also propose these three
requirements for DSEs, though little discussion of their general
importance to DSEs is presented therein. We attempt to expand on these
ideas here and later in this chapter.
(1) Additional viewpoints are undoubtedly possible.
(2) The ASCI performance requirements are based on benchmark results
rather than theoretical machine performance; even so, the performance
of real applications will likely be less (and in some cases
significantly so) than the bench mark performance figures.
(3) Pancake defines "success" based on the "frequency and significance
of tool use" [Panc94].
Chapter 3
(2) More recently, Wolski [WSP97] has proposed an idea similar to the
hierarchical information policy used by Zhou et al. [ZWZD92] in the
Utopia system.
(3) A full comparison between Cheriton and Mann's scheme and URLs is
somewhat irrelevant since URLs define only a name space and Cheriton
and Mann describe a complete name service. The comparisons we have
made rely pri marily on the nature of the name space defined by
Cheriton and Mann.
Chapter 4
(2) The practical reason that DSSA research has not yet targeted
computational science domains is that funding has largely originated
from the Defense Advanced Research Projects Agency (DARPA), whose
focus is naturally on defense-related application areas [Trac94].
Chapter 5
(2) The creators of GEMS, Bruegge et al. [BRRM95], do not use the term
"domain-specific environment" to describe their system.
(3) Since the description of TIERRA by Cuny et al. [CDHH96], the
TIERRA environment has abandoned use of Viz. Future work will likely
utilize easier to use and more stable visualization packages
[Harr97]. In terms of nonfunc tional requirements, this suggests that
programmability and extensibility in the visualization component
proved to be less important than ease of use.
Chapter 6
(2) It is in this spirit that we have applied the term in our own
research [BHMM94, HM97].
(3) Italics in the excerpts are ours.
(4) With only a couple exceptions, all of the excerpts about
frameworks in this section are taken from sources cited elsewhere in
this discussion.
(5) Figure 10 is based on ideas from Shaw and Garlan ([SG96], p. 4,
12-13) and Wiederhold et al. [WWC92]. The figure is a composite of
their ideas but includes our own slight modifications and extensions.
(6) We do not discuss those techniques here since they are not unique
aspects of domain-specific metacomputing for computational science.
Domain-Specific Metacomputing for Computational Science:
Achieving Specificity Through Abstraction
By Steven Hackstadt
Last modified: Wed Nov 5 08:15:46 1997
Steven Hackstadt /
hacks@cs.uoregon.edu
http://www.cs.uoregon.edu/~hacks/