Runtimes (os/hardware-facing)

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?	HPX requires basic calls for memory allocation and deallocation, virtual address translation and management, thread execution resource allocation and deallocation, parcel communication transmit and receive, error detection, and others.	(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?	The HPX RTX spans the system. It requires global address space and parcels message-driven interface.	(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?	The LXK OS allocates a share of its execution resources (e.g., Pthreads) to each relatively root ParalleX Process allocated to the locality. The HPX runtime system uses lightweight scheduling policies to assign user threads to the allocated OS threads.	(TG)	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	N/A
What does your RTS use for locality information?	The “locality” is defined as a synchronous domain that guarantees bounded response time and compound atomic sequences of operations. Compute complexes (thread instances) are to be performed on a single locality at a time and can assume its properties. ParalleX Processes are contexts that define relative logical locality although this may span multiple localities. Parcels permit asynchronous non-blocking operation and move work to data to minimize latency effects.	(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?	Availability of execution resources, energy consumption, detected errors, delays due to contention.	(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?	Yes.	(TG)	(DEGAS)	Currently the APGAS runtime provides a global address space entirely in software. If the lower-level system software provided full or partial support for a global address space, the APGAS runtime could exploit it. However, we do not require global address support from the underlying system.	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	N/A
What local memory management capability does your RTS require?	It must have support for allocation and deallocation of physical memory blocks. It must have support for protected virtual memory addresses at the local level. It must receive error information during memory accesses.	(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?	Yes.	(TG)	(DEGAS)	No	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	N/A
What interface and/or mechanism is used for the OS to request RTS services?	The OS (e.g., LXK) may make user requests of the runtime information to coordinate actions, resources, and services across multiple localities or the entire system and to provide high-level functionality like POSIX calls.	(TG)	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	N/A
How does your RTS support legacy application or legacy RTS capability?	Both MPI and OpenMP software interfaces are being provided to XPI as a target interface to HPX. LXK can also support both in native form.	(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?	HPX at a minimum requires standard hardware functionality of conventional systems but would benefit from new capabilities for efficiency and scalability.	(TG)	(DEGAS)	(D-TEC)	(DynAX)	(X-TUNE)	(GVR)	(CORVETTE)	N/A	Full (and well documented) access to performance counters, profiling and sampling