| QUESTIONS
|
XPRESS
|
TG X-Stack
|
DEGAS
|
D-TEC
|
DynAX
|
X-TUNE
|
GVR
|
CORVETTE
|
SLEEC
|
PIPER
|
| PI |
Ron Brightwell |
Shekhar Borkar |
Katherine Yelick |
Daniel Quinlan |
Guang Gao |
Mary Hall |
Andrew Chien |
Koushik Sen |
Milind Kulkarni |
Martin Schulz
|
| What system calls does your RTS currently use?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
SLEEC
|
The PIPER runtime will be used to collect performance information - it will be out of band, potentially running on external (non-compute node) resources. As such, we require additional communication mechanisms, which is currently mostly done through sockets. Additionally, tools typically use ptrace, signals, and shared memory segments, as well as the dynamic linker for their implementation.
|
| Does your RTS span the system? If so, what network interface capability does your RTS need?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
Tools will have a global "runtime" to collect and aggregate data - this network will be out of band. This will span the whole job, in some cases the whole machine. A high performance communication mechanism would be preferable - currently mostly sockets are used.
|
| How does your RTS map user-level and OS-level scheduling?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
N/A
|
| What does your RTS use for locality information?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
Locality/topology information should be exposed by the application facing runtime and will be used for proper attribution of performance data.
|
| What OS or hardware information does your RTS need to monitor and adapt?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
in short: anything and everything - in particular hardware counters (in profiling and sampling) and any kind of system adaptation information (where does system configuration change) is required
|
| Does your RTS require support for global namespace or global address space?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
N/A
|
| What local memory management capability does your RTS require?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
Individual parts of the runtime will require dynamic memory management - additionally, shared memory communication with a target process would be highly beneficial
|
| Does your RTS address external I/O capability?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
N/A
|
| What interface and/or mechanism is used for the OS to request RTS services?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
N/A
|
| How does your RTS support legacy application or legacy RTS capability?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
Yes: PIPER components intend to support tools for MPI+X codes as well as new RTS and DSL approaches
|
| Does your RTS depend on any specific hardware-specific capability?
|
(XPRESS)
|
(TG)
|
(DEGAS)
|
(D-TEC)
|
(DynAX)
|
(X-TUNE)
|
(GVR)
|
(CORVETTE)
|
N/A
|
Full (and well documented) access to performance counters, profiling and sampling
|