Runtimes (os/hardware-facing) - Revision history

imported>Admin at 03:35, May 20, 2014

2014-05-20T03:35:45Z

imported>Admin at 03:33, May 20, 2014

2014-05-20T03:33:35Z

← Older revision		Revision as of 03:33, May 20, 2014
Line 1:		Line 1:
	{{PITable]]		{{PITable}}

	'''Questions:'''		'''Questions:'''

imported>Admin at 03:33, May 20, 2014

2014-05-20T03:33:19Z

Show changes

imported>Rlawton at 13:49, May 12, 2014

2014-05-12T13:49:03Z

← Older revision		Revision as of 13:49, May 12, 2014
Line 19:		Line 19:
	\|(DEGAS)		\|(DEGAS)
	\|Typical POSIX calls for memory allocation/deallocation, threads and synchronization operations, support needed for core libc operations.		\|Typical POSIX calls for memory allocation/deallocation, threads and synchronization operations, support needed for core libc operations.
	\|(~~DynAX~~)		\|SWARM requires access to hardware threads, memory, and network interconnect(s), whether by system call or direct access. On today's x86 clusters, SWARM additionally needs access to I/O facilities, such as the Linux select, read, and write calls.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 31:		Line 31:
	\|(DEGAS)		\|(DEGAS)
	\| We run different instances of the X10/APGAS runtime across different OS instances on the system. They coordinate via active messages. We developed an an active-message based transport MPI which we implemented of top of TCP/IP and MPI.		\| We run different instances of the X10/APGAS runtime across different OS instances on the system. They coordinate via active messages. We developed an an active-message based transport MPI which we implemented of top of TCP/IP and MPI.
	\|~~(DynAX)~~		\|Yes, SWARM operates on all available/configured threads of all available/configured nodes. SWARM can operate over stream-, message-, or DMA-based interconnects.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 43:		Line 43:
	\|(DEGAS)		\|(DEGAS)
	\| We allocate a pool of OS level execution resources (eg pthreads). Our scheduler then uses these resources as workers on which to schedule the APGAS level tasks using a work-stealing scheduler.		\| We allocate a pool of OS level execution resources (eg pthreads). Our scheduler then uses these resources as workers on which to schedule the APGAS level tasks using a work-stealing scheduler.
	\|~~(DynAX)~~		\|SWARM uses codelets to intermediate between threads and function/method calls. Threads are set up and bound at runtime startup; codelets are bound to particular threads only when they're dispatched, unless some more specific binding is arranged for before readying the codelet. The runtime can dynamically balance load by shifting readied codelets and/or context data from one location to another. When the OS is in charge of power management, blocking is used to relinquish a hardware thread to the OS so that it can be used for other work, or its core powered down.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 55:		Line 55:
	\|(DEGAS)		\|(DEGAS)
	\| The X10/APGAS runtime system spans over multiple shared-memory domains called places. An application specifies the place of each data object and computational task.		\| The X10/APGAS runtime system spans over multiple shared-memory domains called places. An application specifies the place of each data object and computational task.
	\|~~(DynAX)~~		\|It uses a tree of locale descriptors to associate threads, cores, nodes, etc. with each other, typically in a fashion correlating with the hardware memory hierarchy.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 67:		Line 67:
	\|(DEGAS)		\|(DEGAS)
	\|The X10/APGAS RTS monitors the connections between nodes (hosts) to detect node and network failures.		\|The X10/APGAS RTS monitors the connections between nodes (hosts) to detect node and network failures.
	\|~~(DynAX)~~		\|Reliable notification of hardware failures, and a local or global cycle-based or real time. Performance counters would help for load modeling and balancing.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 79:		Line 79:
	\|(DEGAS)		\|(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.		\| 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)~~		\|SWARM can take advantage of a global name/address space, but provides for a global namespace entirely in software. OS or hardware involvement are only needed for data storage and communication.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 91:		Line 91:
	\|(DEGAS)		\|(DEGAS)
	\| Garbage collection.		\| Garbage collection.
	\|~~(DynAX)~~		\|SWARM requires the ability to allocate physical memory.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 103:		Line 103:
	\|(DEGAS)		\|(DEGAS)
	\| No		\| No
	\|~~(DynAX)~~		\|Yes.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 115:		Line 115:
	\|(DEGAS)		\|(DEGAS)
	\|The X10/APGAS RTS is linked with the application binary.		\|The X10/APGAS RTS is linked with the application binary.
	\|~~(DynAX)~~		\|Current versions of SWARM do not require the OS to request services from the runtime. In the event this is necessary, it's expected that either a signal-/interrupt-based or polling-based interface will be provided, and either of these can be integrated easily.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 127:		Line 127:
	\|(DEGAS)		\|(DEGAS)
	\| N/A.		\| N/A.
	\|(~~DynAX~~)		\|Legacy applications can be converted piecewise or in entirety; while the
			application may block normally during single-threaded regions, parallelized
			regions requires blocking calls to use stack-switching or (equivalently)
			extra software threads, or else break apart blocking operations into
			separate initiation and callback sections. Where possible, SWARM provides
			predefined exports that allow asynchronous use of common legacy runtime/API
			functionality.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)
Line 139:		Line 145:
	\|(DEGAS)		\|(DEGAS)
	\| No. But the X10/APGAS RTS can take advantage of hardware-specific networking capabilities and CUDA GPUs.		\| No. But the X10/APGAS RTS can take advantage of hardware-specific networking capabilities and CUDA GPUs.
	\|~~(DynAX)~~		\|SWARM can operate perfectly well on commodity systems, but benefits from access to performance-counting and power-monitoring/-control facilities.
	\|(X-TUNE)		\|(X-TUNE)
	\|(GVR)		\|(GVR)

imported>Jsstone1 at 03:22, May 12, 2014

2014-05-12T03:22:18Z

Show changes

imported>Groved at 21:05, May 9, 2014

2014-05-09T21:05:36Z

← Older revision		Revision as of 21:05, May 9, 2014
Line 30:		Line 30:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\| We run different instances of the X10/APGAS runtime across different OS instances on the system. They coordinate via active messages we ~~assume are provided by the network layer below us~~.		\| We run different instances of the X10/APGAS runtime across different OS instances on the system. They coordinate via active messages. We developed an an active-message based transport MPI which we implemented of top of TCP/IP and MPI.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 54:		Line 54:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\| The X10/APGAS runtime system spans over multiple shared-memory domains called places. An application specifies the place of each data object and computational task.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 66:		Line 66:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(~~D-TEC~~)		\|The X10/APGAS RTS monitors the connections between nodes (hosts) to detect node and network failures.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 90:		Line 90:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\| Garbage collection.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 114:		Line 114:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\|The X10/APGAS RTS is linked with the application binary.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 126:		Line 126:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\| N/A.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 138:		Line 138:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\| No. But the X10/APGAS RTS can take advantage of hardware-specific networking capabilities and CUDA GPUs.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)

imported>Groved at 22:30, May 8, 2014

2014-05-08T22:30:13Z

← Older revision		Revision as of 22:30, May 8, 2014
Line 18:		Line 18:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\|Typical POSIX calls for memory allocation/deallocation, threads and synchronization operations, support needed for core libc operations.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 30:		Line 30:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\| We run different instances of the X10/APGAS runtime across different OS instances on the system. They coordinate via active messages we assume are provided by the network layer below us.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)
Line 42:		Line 42:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\| We allocate a pool of OS level execution resources (eg pthreads). Our scheduler then uses these resources as workers on which to schedule the APGAS level tasks using a work-stealing scheduler.
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)

imported>Groved at 21:57, May 7, 2014

2014-05-07T21:57:04Z

← Older revision		Revision as of 21:57, May 7, 2014
Line 102:		Line 102:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\| No
	\|(DynAX)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)

imported>Groved at 21:47, May 7, 2014

2014-05-07T21:47:47Z

← Older revision		Revision as of 21:47, May 7, 2014
Line 78:		Line 78:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\| 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)		\|(DynAX)
	\|(X-TUNE)		\|(X-TUNE)

imported>Rbbrigh at 20:07, May 7, 2014

2014-05-07T20:07:31Z

← Older revision		Revision as of 20:07, May 7, 2014
Line 15:		Line 15:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|What system calls does your RTS currently use?		\|What system calls does your RTS currently use?
	\|~~(XPRESS)~~		\|''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)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 27:		Line 27:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|Does your RTS span the system? If so, what network interface capability does your RTS need?		\|Does your RTS span the system? If so, what network interface capability does your RTS need?
	\|~~(XPRESS)~~		\|''The HPX RTX spans the system. It requires global address space and parcels message-driven interface.''
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 39:		Line 39:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|How does your RTS map user-level and OS-level scheduling?		\|How does your RTS map user-level and OS-level scheduling?
	\|(~~XPRESS~~)		\|''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)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 51:		Line 51:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|What does your RTS use for locality information?		\|What does your RTS use for locality information?
	\|(~~XPRESS~~)		\|''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)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 63:		Line 63:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|What OS or hardware information does your RTS need to monitor and adapt?		\|What OS or hardware information does your RTS need to monitor and adapt?
	\|~~(XPRESS)~~		\|''Availability of execution resources, energy consumption, detected errors, delays due to contention.''
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 75:		Line 75:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|Does your RTS require support for global namespace or global address space?		\|Does your RTS require support for global namespace or global address space?
	\|~~(XPRESS)~~		\|''Yes.''
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 87:		Line 87:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|What local memory management capability does your RTS require?		\|What local memory management capability does your RTS require?
	\|~~(XPRESS)~~		\|''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)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 99:		Line 99:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|Does your RTS address external I/O capability?		\|Does your RTS address external I/O capability?
	\|~~(XPRESS)~~		\|''Yes.''
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 111:		Line 111:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|What interface and/or mechanism is used for the OS to request RTS services?		\|What interface and/or mechanism is used for the OS to request RTS services?
	\|(~~XPRESS~~)		\|''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)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 123:		Line 123:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|How does your RTS support legacy application or legacy RTS capability?		\|How does your RTS support legacy application or legacy RTS capability?
	\|~~(XPRESS)~~		\|''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)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
Line 135:		Line 135:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|Does your RTS depend on any specific hardware-specific capability?		\|Does your RTS depend on any specific hardware-specific capability?
	\|~~(XPRESS)~~		\|''HPX at a minimum requires standard hardware functionality of conventional systems but would benefit from new capabilities for efficiency and scalability.''
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)