Runtimes (application-facing) - Revision history

imported>Admin at 01:47, May 20, 2014

2014-05-20T01:47:45Z

imported>Sriram at 07:29, May 13, 2014

2014-05-13T07:29:37Z

← Older revision		Revision as of 07:29, May 13, 2014
Line 16:		Line 16:
	! style="width: 400px" \| PIPER		! style="width: 400px" \| PIPER
	! style="width: 400px" \| Charm++		! style="width: 400px" \| Charm++
			! style="width: 400px" \| Early Career-SriramK
	\|-		\|-
	\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz \|\| Sanjay Kale		\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz \|\| Sanjay Kale \|\| Sriram Krishnamoorthy
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What policies and/or mechanisms will your runtime use to schedule code and place data for 100M objects (executing code, data elements, etc.) in a scalable fashion?'''		\|'''What policies and/or mechanisms will your runtime use to schedule code and place data for 100M objects (executing code, data elements, etc.) in a scalable fashion?'''
Line 31:		Line 32:
	\|N/A		\|N/A
	\|Overdecomposition: A Charm++ program consists of a large number of objects assigned to the processors by the RTS. Initial placement of objects is controlled by map functions that are either system defined or user defined static functions. The RTS dynamically migrates objects across processors as needed. Message driven scheduling is used on individual processors: a message, containing a method invocation for an object, is selected by the scheduler and the corresponding object's execution is triggered.		\|Overdecomposition: A Charm++ program consists of a large number of objects assigned to the processors by the RTS. Initial placement of objects is controlled by map functions that are either system defined or user defined static functions. The RTS dynamically migrates objects across processors as needed. Message driven scheduling is used on individual processors: a message, containing a method invocation for an object, is selected by the scheduler and the corresponding object's execution is triggered.
			\|Work is assumed to be decomposed into finer-grained tasks. The specification of inter-task dependences and task-data relationships is used to automate aspects of locality management, load balance, and resilience. We investigate algorithms based on dynamic load balancing for various classes of inter-task and task-data relationships — strict computations, data-flow graphs, etc. — for intra-node and inter-node scheduling.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''		\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''
Line 44:		Line 46:
	\|N/A		\|N/A
	\|The programming model supported by the runtime ensures that programmers are not programming to processors. Method invocations (i.e. messages) are directed to logical entities (i.e. objects). This feature allows the runtime to migrate individual objects as it sees fit. Scheduling of objects on individual processors (i.e. sequencing of execution) is also controlled by the runtime system. Extensive introspection by the RTS is thus enabled, since the RTS mediates all communication, and controls all scheduling.		\|The programming model supported by the runtime ensures that programmers are not programming to processors. Method invocations (i.e. messages) are directed to logical entities (i.e. objects). This feature allows the runtime to migrate individual objects as it sees fit. Scheduling of objects on individual processors (i.e. sequencing of execution) is also controlled by the runtime system. Extensive introspection by the RTS is thus enabled, since the RTS mediates all communication, and controls all scheduling.
			\|The specification naturally supports task and data migration. We support locality-constrained dynamic load balancing and selective localized recovery. We consider fully-automated and user-supported techniques. These are guided by introspection of the running tasks and feedback from the execution environment.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''		\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''
Line 57:		Line 60:
	\|N/A		\|N/A
	\|The extensive introspection capabilities are used to create a local database of individual object performance and communication behavior. Runtime strategies, such as load balancers, make use of the database (in hierarchical and/or distributed fashion) to make resource management decisions in a scalable manner. Continuous monitoring of temperature, power, energy behavior is used to trigger runtime optimizations. Some of the main mechanisms for resource management include: DVFS/RAPL for chip level power management, object migrations, processor evacuations, automatic failure detection (via buddy-based heartbeat detection, for example) etc.		\|The extensive introspection capabilities are used to create a local database of individual object performance and communication behavior. Runtime strategies, such as load balancers, make use of the database (in hierarchical and/or distributed fashion) to make resource management decisions in a scalable manner. Continuous monitoring of temperature, power, energy behavior is used to trigger runtime optimizations. Some of the main mechanisms for resource management include: DVFS/RAPL for chip level power management, object migrations, processor evacuations, automatic failure detection (via buddy-based heartbeat detection, for example) etc.
			\|Power/energy optimization is not directly addressed in this project.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''		\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''
Line 73:		Line 77:
	\|The PIPER concepts includes performance and correctness data collection across the entire system software stack - this does require runtime support to cleanly and scalably aggregate and process data. This can be combined with work in the Visualization/Data Area.		\|The PIPER concepts includes performance and correctness data collection across the entire system software stack - this does require runtime support to cleanly and scalably aggregate and process data. This can be combined with work in the Visualization/Data Area.
	\|The RTS is extremely lightweight. Aside from a tiny instrumentation system around the core scheduler, all aspects of the runtime itself are libraries and therefore monitored as usual. The fully distributed nature of the runtime makes it easy to balance it. The production version of Charm++ currently supports recovery only from fail-stop failures. For this, the RTS components on buddy nodes are used.		\|The RTS is extremely lightweight. Aside from a tiny instrumentation system around the core scheduler, all aspects of the runtime itself are libraries and therefore monitored as usual. The fully distributed nature of the runtime makes it easy to balance it. The production version of Charm++ currently supports recovery only from fail-stop failures. For this, the RTS components on buddy nodes are used.
			\|The runtime software is lightweight and designed to introduce minimal overhead. Depending on the application and execution scenario, one/few hardware thread(s) might be dedicated to handle incoming communication. The actions of the runtime are fully distributed and for the most part asynchronous and non-collective. Faults are handled through selective localized recovery coupled with dynamic load balancing.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What is the efficiency of the runtime? Specifically, how much impact does the runtime have on a) the total execution time of the application and b) resources taken from algorithmic computations? What are your plans to maximize efficiency? How will runtime overhead scale to 100K sockets?'''		\|'''What is the efficiency of the runtime? Specifically, how much impact does the runtime have on a) the total execution time of the application and b) resources taken from algorithmic computations? What are your plans to maximize efficiency? How will runtime overhead scale to 100K sockets?'''
Line 86:		Line 91:
	\|N/A		\|N/A
	\|The RTS maintains a lightweight presence on every core of the system, recording small bits of information at every scheduling event. Overhead for each scheduling event is less than a microsecond on today's machines, thus creating a very low impact on application performance. Strategies such as load balancing are executed only when needed; their costs vary from very light refinement strategies to extensive global strategies, and are deployed based on the need identified by recognizing runtime patterns.		\|The RTS maintains a lightweight presence on every core of the system, recording small bits of information at every scheduling event. Overhead for each scheduling event is less than a microsecond on today's machines, thus creating a very low impact on application performance. Strategies such as load balancing are executed only when needed; their costs vary from very light refinement strategies to extensive global strategies, and are deployed based on the need identified by recognizing runtime patterns.
			\|The resources taken by the runtime involve (a) the few hardware threads potentially dedicated to process messages and (b) runtime actions to balance load, manage locality, and recover from faults. The degree of overheads incurred will depend on the degree of automation desired. Fully user-controlled approaches can achieve very low to no overheads. We have demonstrated elements of the automation on 100K+ cores and expect these to scale further. Ongoing research is investigating additional aspects that can be automated.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''		\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''
Line 99:		Line 105:
	\|(PIPER)		\|(PIPER)
	\|Yes, by normal memory allocation mechanisms. But no OS level protection is used (as that’d be too heavy weight).		\|Yes, by normal memory allocation mechanisms. But no OS level protection is used (as that’d be too heavy weight).
			\|We do not address isolation/contamination issues.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What specific hardware features do you require for proper or efficient runtime operation (atomics, DMA, F/E bits, etc.)?'''		\|'''What specific hardware features do you require for proper or efficient runtime operation (atomics, DMA, F/E bits, etc.)?'''
Line 112:		Line 119:
	\|Yes, that should be the case.		\|Yes, that should be the case.
	\|All the features mentioned are useful when available, though the RTS can function with what is available on each machine. DMA is almost essential to derive the benefits of latency tolerance implicit in Charm++ over-decomposition model.		\|All the features mentioned are useful when available, though the RTS can function with what is available on each machine. DMA is almost essential to derive the benefits of latency tolerance implicit in Charm++ over-decomposition model.
			\| (1) Remote atomic operations, (2) Asynchronous data transfer (DMA), (3) Support for efficient remote method invocation, (4) Hardware locality and topology information.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What is your model for execution of multiple different programs (ie: a single mention would be doing more than one thing) in terms of division, isolation, containment and protection?'''		\|'''What is your model for execution of multiple different programs (ie: a single mention would be doing more than one thing) in terms of division, isolation, containment and protection?'''
Line 128:		Line 136:
	\|N/A		\|N/A
	\|Multiple modules are well-supported by message-driven scheduling paradigm: modules interleave their execution based on availability of data, thus overlapping idle time in one with useful computation in the other. The same idea has been extended to different applications, for the cloud settings. No strong isolation (as in OS protection domains) is supported.		\|Multiple modules are well-supported by message-driven scheduling paradigm: modules interleave their execution based on availability of data, thus overlapping idle time in one with useful computation in the other. The same idea has been extended to different applications, for the cloud settings. No strong isolation (as in OS protection domains) is supported.
			\|We do not address isolation/containment across different applications running on a machine. We support phase-based switching between programming/execution paradigms. Different partitions within an application can employ distinct programming paradigms as long as basic progress guarantees are met.
	\|}		\|}

imported>NikhilJain: Points for Charm++

2014-05-13T04:21:06Z

Points for Charm++

← Older revision		Revision as of 04:21, May 13, 2014
Line 30:		Line 30:
	\|SLEEC does not have a true runtime component, except insofar as we are developing single-node runtimes to, e.g., manage data movement between cores and accelerators. We also perform small-scale inspector/executor-style scheduling for applications. However, we expect to rely on other systems for our large-scale runtime needs.		\|SLEEC does not have a true runtime component, except insofar as we are developing single-node runtimes to, e.g., manage data movement between cores and accelerators. We also perform small-scale inspector/executor-style scheduling for applications. However, we expect to rely on other systems for our large-scale runtime needs.
	\|N/A		\|N/A
	\|		\|Overdecomposition: A Charm++ program consists of a large number of objects assigned to the processors by the RTS. Initial placement of objects is controlled by map functions that are either system defined or user defined static functions. The RTS dynamically migrates objects across processors as needed. Message driven scheduling is used on individual processors: a message, containing a method invocation for an object, is selected by the scheduler and the corresponding object's execution is triggered.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''		\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''
Line 43:		Line 43:
	\|N/A		\|N/A
	\|N/A		\|N/A
	\|		\|The programming model supported by the runtime ensures that programmers are not programming to processors. Method invocations (i.e. messages) are directed to logical entities (i.e. objects). This feature allows the runtime to migrate individual objects as it sees fit. Scheduling of objects on individual processors (i.e. sequencing of execution) is also controlled by the runtime system. Extensive introspection by the RTS is thus enabled, since the RTS mediates all communication, and controls all scheduling.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''		\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''
Line 56:		Line 56:
	\|N/A		\|N/A
	\|N/A		\|N/A
	\|		\|The extensive introspection capabilities are used to create a local database of individual object performance and communication behavior. Runtime strategies, such as load balancers, make use of the database (in hierarchical and/or distributed fashion) to make resource management decisions in a scalable manner. Continuous monitoring of temperature, power, energy behavior is used to trigger runtime optimizations. Some of the main mechanisms for resource management include: DVFS/RAPL for chip level power management, object migrations, processor evacuations, automatic failure detection (via buddy-based heartbeat detection, for example) etc.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''		\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''
Line 72:		Line 72:
	\|SLEEC's runtimes are intended to operate within the scope of a single node, or at a small scale. We rely on other runtimes to provide higher levels of the hierarchy.		\|SLEEC's runtimes are intended to operate within the scope of a single node, or at a small scale. We rely on other runtimes to provide higher levels of the hierarchy.
	\|The PIPER concepts includes performance and correctness data collection across the entire system software stack - this does require runtime support to cleanly and scalably aggregate and process data. This can be combined with work in the Visualization/Data Area.		\|The PIPER concepts includes performance and correctness data collection across the entire system software stack - this does require runtime support to cleanly and scalably aggregate and process data. This can be combined with work in the Visualization/Data Area.
			\|The RTS is extremely lightweight. Aside from a tiny instrumentation system around the core scheduler, all aspects of the runtime itself are libraries and therefore monitored as usual. The fully distributed nature of the runtime makes it easy to balance it. The production version of Charm++ currently supports recovery only from fail-stop failures. For this, the RTS components on buddy nodes are used.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What is the efficiency of the runtime? Specifically, how much impact does the runtime have on a) the total execution time of the application and b) resources taken from algorithmic computations? What are your plans to maximize efficiency? How will runtime overhead scale to 100K sockets?'''		\|'''What is the efficiency of the runtime? Specifically, how much impact does the runtime have on a) the total execution time of the application and b) resources taken from algorithmic computations? What are your plans to maximize efficiency? How will runtime overhead scale to 100K sockets?'''
Line 84:		Line 85:
	\|Because SLEEC focuses on small-scale runtimes that are directly integrated with application code, we expect our runtime overheads to be negligible and, essentially, independent of scale (because scaling will be provided by other runtime systems.		\|Because SLEEC focuses on small-scale runtimes that are directly integrated with application code, we expect our runtime overheads to be negligible and, essentially, independent of scale (because scaling will be provided by other runtime systems.
	\|N/A		\|N/A
	\|		\|The RTS maintains a lightweight presence on every core of the system, recording small bits of information at every scheduling event. Overhead for each scheduling event is less than a microsecond on today's machines, thus creating a very low impact on application performance. Strategies such as load balancing are executed only when needed; their costs vary from very light refinement strategies to extensive global strategies, and are deployed based on the need identified by recognizing runtime patterns.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''		\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''
Line 97:		Line 98:
	\|SLEEC's runtimes are application/domain-specific and hence intended to closely couple with the application code.		\|SLEEC's runtimes are application/domain-specific and hence intended to closely couple with the application code.
	\|(PIPER)		\|(PIPER)
	\|		\|Yes, by normal memory allocation mechanisms. But no OS level protection is used (as that’d be too heavy weight).
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What specific hardware features do you require for proper or efficient runtime operation (atomics, DMA, F/E bits, etc.)?'''		\|'''What specific hardware features do you require for proper or efficient runtime operation (atomics, DMA, F/E bits, etc.)?'''
Line 110:		Line 111:
	\|N/A		\|N/A
	\|Yes, that should be the case.		\|Yes, that should be the case.
			\|All the features mentioned are useful when available, though the RTS can function with what is available on each machine. DMA is almost essential to derive the benefits of latency tolerance implicit in Charm++ over-decomposition model.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What is your model for execution of multiple different programs (ie: a single mention would be doing more than one thing) in terms of division, isolation, containment and protection?'''		\|'''What is your model for execution of multiple different programs (ie: a single mention would be doing more than one thing) in terms of division, isolation, containment and protection?'''
Line 125:		Line 127:
	\|N/A		\|N/A
	\|N/A		\|N/A
	\|		\|Multiple modules are well-supported by message-driven scheduling paradigm: modules interleave their execution based on availability of data, thus overlapping idle time in one with useful computation in the other. The same idea has been extended to different applications, for the cloud settings. No strong isolation (as in OS protection domains) is supported.
	\|}		\|}

imported>NikhilJain: Minor correction

2014-05-12T21:31:30Z

Minor correction

imported>NikhilJain: Adding column for Charm++.

2014-05-12T21:28:53Z

Adding column for Charm++.

← Older revision		Revision as of 21:28, May 12, 2014
Line 15:		Line 15:
	! style="width: 400px" \| SLEEC		! style="width: 400px" \| SLEEC
	! style="width: 400px" \| PIPER		! style="width: 400px" \| PIPER
			! style="width: 400px" \| Charm++
	\|-		\|-
	\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz		\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz \|\| Sanjay Kale
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What policies and/or mechanisms will your runtime use to schedule code and place data for 100M objects (executing code, data elements, etc.) in a scalable fashion?'''		\|'''What policies and/or mechanisms will your runtime use to schedule code and place data for 100M objects (executing code, data elements, etc.) in a scalable fashion?'''

imported>Jsstone1 at 02:59, May 12, 2014

2014-05-12T02:59:22Z

← Older revision		Revision as of 02:59, May 12, 2014
Line 4:		Line 4:

	{\| class="wikitable"		{\| class="wikitable"
	! style="width: ~~200;~~" \| QUESTIONS		! style="width: 400px" \| QUESTIONS
	! style="width: ~~200;~~" \| XPRESS		! style="width: 400px" \| XPRESS
	! style="width: ~~200;~~" \| TG X-Stack		! style="width: 400px" \| TG X-Stack
	! style="width: ~~200;~~" \| DEGAS		! style="width: 400px" \| DEGAS
	! style="width: ~~200;~~" \| D-TEC		! style="width: 400px" \| D-TEC
	! style="width: ~~200;~~" \| DynAX		! style="width: 400px" \| DynAX
	! style="width: ~~200;~~" \| X-TUNE		! style="width: 400px" \| X-TUNE
	! style="width: ~~200;~~" \| GVR		! style="width: 400px" \| GVR
	! style="width: ~~200;~~" \| CORVETTE		! style="width: 400px" \| CORVETTE
	! style="width: ~~200;~~" \| SLEEC		! style="width: 400px" \| SLEEC
	! style="width: ~~200;~~" \| PIPER		! style="width: 400px" \| PIPER
	\|-		\|-
	\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz		\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz

imported>Jsstone1 at 08:12, May 10, 2014

2014-05-10T08:12:33Z

← Older revision		Revision as of 08:12, May 10, 2014
Line 1:		Line 1:
	Sonia requested the Traleika Glacier X-Stack team to initiate this page. For comments, please contact Shekhar Borkar.		Sonia requested the Traleika Glacier X-Stack team to initiate this page. For comments, please contact Shekhar Borkar.

			Snapshot as of 5/10/14: [[media:Runtimes_(application_facing).pdf\|Runtimes_(application_facing).pdf]]

	{\| class="wikitable"		{\| class="wikitable"

imported>Schulzm: added PIPER

2014-05-01T05:46:09Z

added PIPER

← Older revision		Revision as of 05:46, May 1, 2014
Line 26:		Line 26:
	\|(CORVETTE)		\|(CORVETTE)
	\|SLEEC does not have a true runtime component, except insofar as we are developing single-node runtimes to, e.g., manage data movement between cores and accelerators. We also perform small-scale inspector/executor-style scheduling for applications. However, we expect to rely on other systems for our large-scale runtime needs.		\|SLEEC does not have a true runtime component, except insofar as we are developing single-node runtimes to, e.g., manage data movement between cores and accelerators. We also perform small-scale inspector/executor-style scheduling for applications. However, we expect to rely on other systems for our large-scale runtime needs.
	\|~~(PIPER)~~		\|N/A
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''		\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''
Line 38:		Line 38:
	\|(CORVETTE)		\|(CORVETTE)
	\|N/A		\|N/A
	\|~~(PIPER)~~		\|N/A
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''		\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''
Line 50:		Line 50:
	\|(CORVETTE)		\|(CORVETTE)
	\|N/A		\|N/A
	\|~~(PIPER)~~		\|N/A
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''		\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''
Line 65:		Line 65:
	\|(CORVETTE)		\|(CORVETTE)
	\|SLEEC's runtimes are intended to operate within the scope of a single node, or at a small scale. We rely on other runtimes to provide higher levels of the hierarchy.		\|SLEEC's runtimes are intended to operate within the scope of a single node, or at a small scale. We rely on other runtimes to provide higher levels of the hierarchy.
	\|(PIPER)		\|The PIPER concepts includes performance and correctness data collection across the entire system software stack - this does require runtime support to cleanly and scalably aggregate and process data. This can be combined with work in the Visualization/Data Area.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What is the efficiency of the runtime? Specifically, how much impact does the runtime have on a) the total execution time of the application and b) resources taken from algorithmic computations? What are your plans to maximize efficiency? How will runtime overhead scale to 100K sockets?'''		\|'''What is the efficiency of the runtime? Specifically, how much impact does the runtime have on a) the total execution time of the application and b) resources taken from algorithmic computations? What are your plans to maximize efficiency? How will runtime overhead scale to 100K sockets?'''
Line 77:		Line 77:
	\|(CORVETTE)		\|(CORVETTE)
	\|Because SLEEC focuses on small-scale runtimes that are directly integrated with application code, we expect our runtime overheads to be negligible and, essentially, independent of scale (because scaling will be provided by other runtime systems.		\|Because SLEEC focuses on small-scale runtimes that are directly integrated with application code, we expect our runtime overheads to be negligible and, essentially, independent of scale (because scaling will be provided by other runtime systems.
	\|~~(PIPER)~~		\|N/A
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''		\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''
Line 101:		Line 101:
	\|(CORVETTE)		\|(CORVETTE)
	\|N/A		\|N/A
	\|~~(PIPER)~~		\|Yes, that should be the case.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What is your model for execution of multiple different programs (ie: a single mention would be doing more than one thing) in terms of division, isolation, containment and protection?'''		\|'''What is your model for execution of multiple different programs (ie: a single mention would be doing more than one thing) in terms of division, isolation, containment and protection?'''
Line 116:		Line 116:
	\|(CORVETTE)		\|(CORVETTE)
	\|N/A		\|N/A
	\|~~(PIPER)~~		\|N/A
	\|}		\|}

imported>Kayelick at 04:24, April 9, 2014

2014-04-09T04:24:10Z

← Older revision		Revision as of 04:24, April 9, 2014
Line 20:		Line 20:
	\|Open Community Runtime (OCR) will optimize for data-movement scalability. Our programming model divides an application into event-driven tasks with explicit data-dependences. Our runtime uses of this to schedule code close to its data or move the data close to the code. Scalability will be achieved through hierarchical task-stealing favoring locality.		\|Open Community Runtime (OCR) will optimize for data-movement scalability. Our programming model divides an application into event-driven tasks with explicit data-dependences. Our runtime uses of this to schedule code close to its data or move the data close to the code. Scalability will be achieved through hierarchical task-stealing favoring locality.
	\|The DEGAS runtime uses one-sided communication (put, get, active messages, atomics, and remote enqueue of tasks) to place data and work across a large-scale machine. Within a node there are currently two scheduling approaches being pursued. One (under HCLib/Habanero-C) is built on OCR and uses a dynamic task scheduler; it is being evaluated to determine the need for locality control within the node; the second is derived from the UPC runtime and has both a fixed set of locality-aware threads tied to cores (or hardware threads or NUMA domains -- it's an abstraction that can be used a various machine levels), augmented with voluntary task scheduling for both locality and remotely generated dynamic tasks. A global task stealing scheduler is also part of the DEGAS plan and exists in prototype form; as with dynamic tasking, it is to be used on-demand for applications that are not naturally load balanced (e.g., divide-and-conquer problems with irregular trees).		\|The DEGAS runtime uses one-sided communication (put, get, active messages, atomics, and remote enqueue of tasks) to place data and work across a large-scale machine. Within a node there are currently two scheduling approaches being pursued. One (under HCLib/Habanero-C) is built on OCR and uses a dynamic task scheduler; it is being evaluated to determine the need for locality control within the node; the second is derived from the UPC runtime and has both a fixed set of locality-aware threads tied to cores (or hardware threads or NUMA domains -- it's an abstraction that can be used a various machine levels), augmented with voluntary task scheduling for both locality and remotely generated dynamic tasks. A global task stealing scheduler is also part of the DEGAS plan and exists in prototype form; as with dynamic tasking, it is to be used on-demand for applications that are not naturally load balanced (e.g., divide-and-conquer problems with irregular trees).
	\|D-TEC		\|(D-TEC) The APGAS (Asynchronous Partitioned Global Address Space) runtime uses a work-stealing scheduler to dynamically schedule tasks within a node. We are introducing areas to enable finer-grained locality and scheduling control within a node (Place). By design the runtime does not directly address automatic cross-node data placement. The APGAS runtime/programming model does provide primitive mechanisms (Places and Areas; at/async/finish) that allow application frameworks to productively implement data placement and cross-node scheduling frameworks on top of the runtime.
	\|The SWift Adaptive Runtime Machine (SWARM) has a "locale" hierarchy, which roughly mirrors the hardware architecture hierarchy. Each locale has a set of local scheduler queues, allowing distributed and scalable scheduling. Data allocation and task/data migration are expressed to ensure proper parallelism around the conjunction. SWARM will rely on a single-assignment policy to prevent the need for globally coordinated checkout or write-back operations.		\|The SWift Adaptive Runtime Machine (SWARM) has a "locale" hierarchy, which roughly mirrors the hardware architecture hierarchy. Each locale has a set of local scheduler queues, allowing distributed and scalable scheduling. Data allocation and task/data migration are expressed to ensure proper parallelism around the conjunction. SWARM will rely on a single-assignment policy to prevent the need for globally coordinated checkout or write-back operations.
	\| The compiler for X-TUNE must generate code with hierarchical threading, and will rely on the run-time to manage that threading efficiently. Point-to-point synchronization between threads may be more efficient than barriers to allow more dynamic behavior of the threads.		\| The compiler for X-TUNE must generate code with hierarchical threading, and will rely on the run-time to manage that threading efficiently. Point-to-point synchronization between threads may be more efficient than barriers to allow more dynamic behavior of the threads.

imported>Kayelick at 04:20, April 9, 2014

2014-04-09T04:20:02Z

← Older revision		Revision as of 04:20, April 9, 2014
Line 20:		Line 20:
	\|Open Community Runtime (OCR) will optimize for data-movement scalability. Our programming model divides an application into event-driven tasks with explicit data-dependences. Our runtime uses of this to schedule code close to its data or move the data close to the code. Scalability will be achieved through hierarchical task-stealing favoring locality.		\|Open Community Runtime (OCR) will optimize for data-movement scalability. Our programming model divides an application into event-driven tasks with explicit data-dependences. Our runtime uses of this to schedule code close to its data or move the data close to the code. Scalability will be achieved through hierarchical task-stealing favoring locality.
	\|The DEGAS runtime uses one-sided communication (put, get, active messages, atomics, and remote enqueue of tasks) to place data and work across a large-scale machine. Within a node there are currently two scheduling approaches being pursued. One (under HCLib/Habanero-C) is built on OCR and uses a dynamic task scheduler; it is being evaluated to determine the need for locality control within the node; the second is derived from the UPC runtime and has both a fixed set of locality-aware threads tied to cores (or hardware threads or NUMA domains -- it's an abstraction that can be used a various machine levels), augmented with voluntary task scheduling for both locality and remotely generated dynamic tasks. A global task stealing scheduler is also part of the DEGAS plan and exists in prototype form; as with dynamic tasking, it is to be used on-demand for applications that are not naturally load balanced (e.g., divide-and-conquer problems with irregular trees).		\|The DEGAS runtime uses one-sided communication (put, get, active messages, atomics, and remote enqueue of tasks) to place data and work across a large-scale machine. Within a node there are currently two scheduling approaches being pursued. One (under HCLib/Habanero-C) is built on OCR and uses a dynamic task scheduler; it is being evaluated to determine the need for locality control within the node; the second is derived from the UPC runtime and has both a fixed set of locality-aware threads tied to cores (or hardware threads or NUMA domains -- it's an abstraction that can be used a various machine levels), augmented with voluntary task scheduling for both locality and remotely generated dynamic tasks. A global task stealing scheduler is also part of the DEGAS plan and exists in prototype form; as with dynamic tasking, it is to be used on-demand for applications that are not naturally load balanced (e.g., divide-and-conquer problems with irregular trees).
			\|D-TEC
	\|The SWift Adaptive Runtime Machine (SWARM) has a "locale" hierarchy, which roughly mirrors the hardware architecture hierarchy. Each locale has a set of local scheduler queues, allowing distributed and scalable scheduling. Data allocation and task/data migration are expressed to ensure proper parallelism around the conjunction. SWARM will rely on a single-assignment policy to prevent the need for globally coordinated checkout or write-back operations.		\|The SWift Adaptive Runtime Machine (SWARM) has a "locale" hierarchy, which roughly mirrors the hardware architecture hierarchy. Each locale has a set of local scheduler queues, allowing distributed and scalable scheduling. Data allocation and task/data migration are expressed to ensure proper parallelism around the conjunction. SWARM will rely on a single-assignment policy to prevent the need for globally coordinated checkout or write-back operations.
	\| The compiler for X-TUNE must generate code with hierarchical threading, and will rely on the run-time to manage that threading efficiently. Point-to-point synchronization between threads may be more efficient than barriers to allow more dynamic behavior of the threads.		\| The compiler for X-TUNE must generate code with hierarchical threading, and will rely on the run-time to manage that threading efficiently. Point-to-point synchronization between threads may be more efficient than barriers to allow more dynamic behavior of the threads.

← Older revision		Revision as of 02:59, May 12, 2014
Line 4:		Line 4:

	{\| class="wikitable"		{\| class="wikitable"
	! style="width: ~~200;~~" \| QUESTIONS		! style="width: 400px" \| QUESTIONS
	! style="width: ~~200;~~" \| XPRESS		! style="width: 400px" \| XPRESS
	! style="width: ~~200;~~" \| TG X-Stack		! style="width: 400px" \| TG X-Stack
	! style="width: ~~200;~~" \| DEGAS		! style="width: 400px" \| DEGAS
	! style="width: ~~200;~~" \| D-TEC		! style="width: 400px" \| D-TEC
	! style="width: ~~200;~~" \| DynAX		! style="width: 400px" \| DynAX
	! style="width: ~~200;~~" \| X-TUNE		! style="width: 400px" \| X-TUNE
	! style="width: ~~200;~~" \| GVR		! style="width: 400px" \| GVR
	! style="width: ~~200;~~" \| CORVETTE		! style="width: 400px" \| CORVETTE
	! style="width: ~~200;~~" \| SLEEC		! style="width: 400px" \| SLEEC
	! style="width: ~~200;~~" \| PIPER		! style="width: 400px" \| PIPER
	\|-		\|-
	\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz		\| '''PI''' \|\| Ron Brightwell \|\| Shekhar Borkar \|\| Katherine Yelick \|\| Daniel Quinlan \|\| Guang Gao \|\| Mary Hall \|\| Andrew Chien \|\| Koushik Sen \|\| Milind Kulkarni \|\| Martin Schulz

← Older revision		Revision as of 21:31, May 12, 2014
Line 30:		Line 30:
	\|SLEEC does not have a true runtime component, except insofar as we are developing single-node runtimes to, e.g., manage data movement between cores and accelerators. We also perform small-scale inspector/executor-style scheduling for applications. However, we expect to rely on other systems for our large-scale runtime needs.		\|SLEEC does not have a true runtime component, except insofar as we are developing single-node runtimes to, e.g., manage data movement between cores and accelerators. We also perform small-scale inspector/executor-style scheduling for applications. However, we expect to rely on other systems for our large-scale runtime needs.
	\|N/A		\|N/A
			\|
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''		\|'''What features will allow your runtime to dynamically adapt the schedule and placement for 100K sockets to improve the metrics of code-data affinity, power consumption, migration cost and resiliency?'''
Line 42:		Line 43:
	\|N/A		\|N/A
	\|N/A		\|N/A
			\|
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''		\|'''How will the runtime manage resources (compute, memory, power, bandwidth) for 100K sockets to meet a power, energy and performance objective?'''
Line 54:		Line 56:
	\|N/A		\|N/A
	\|N/A		\|N/A
			\|
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''		\|'''How does the runtime software itself scale to 100K sockets? Specifically, how does it distribute, monitor and balance itself and how is it resilient to failures?'''
Line 81:		Line 84:
	\|Because SLEEC focuses on small-scale runtimes that are directly integrated with application code, we expect our runtime overheads to be negligible and, essentially, independent of scale (because scaling will be provided by other runtime systems.		\|Because SLEEC focuses on small-scale runtimes that are directly integrated with application code, we expect our runtime overheads to be negligible and, essentially, independent of scale (because scaling will be provided by other runtime systems.
	\|N/A		\|N/A
			\|
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''		\|'''Do you support isolation of the runtime code from the user code to avoid violations and contamination?'''
Line 93:		Line 97:
	\|SLEEC's runtimes are application/domain-specific and hence intended to closely couple with the application code.		\|SLEEC's runtimes are application/domain-specific and hence intended to closely couple with the application code.
	\|(PIPER)		\|(PIPER)
			\|
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What specific hardware features do you require for proper or efficient runtime operation (atomics, DMA, F/E bits, etc.)?'''		\|'''What specific hardware features do you require for proper or efficient runtime operation (atomics, DMA, F/E bits, etc.)?'''
Line 120:		Line 125:
	\|N/A		\|N/A
	\|N/A		\|N/A
			\|
	\|}		\|}