Performance Tools - Revision history

imported>Admin at 05:50, May 20, 2014

2014-05-20T05:50:51Z

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

2014-05-20T05:47:52Z

imported>Rbbrigh at 18:47, May 12, 2014

2014-05-12T18:47:39Z

← Older revision		Revision as of 18:47, May 12, 2014
Line 13:		Line 13:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What abstractions does your runtime stack use for parallelism?'''		\|'''What abstractions does your runtime stack use for parallelism?'''
	\|		\|''The XPRESS project identifies three levels of parallelism associated with the ParalleX execution model:

			a. The coarse grain parallelism is the ParalleX Process that provides context for other child processes and other forms of computation and may span multiple localities (i.e., nodes),
			b. The medium grain ParalleX compute complex (e.g., thread instantiation) that runs on a single locality and is a partially ordered set of operations, and
			c. The fine grain operations that are coordinated by a static dataflow graph (DAG).''

	\|EDTs and data blocks.		\|EDTs and data blocks.
	\|		\|
Line 68:		Line 73:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|'''What information would your software stack need to maintain in order to measure per-thread or per-task, performance? Can this information be accessed safely from a signal handler? Could a performance tool register its own tasks to monitor the performance of the runtime?'''		\|'''What information would your software stack need to maintain in order to measure per-thread or per-task, performance? Can this information be accessed safely from a signal handler? Could a performance tool register its own tasks to monitor the performance of the runtime?'''
	\|		\|''The APEX component of the HPX runtime system maintains the necessary information to measure per-thread performance including start, stop, suspend/pending event times, and ops counts. A performance tool can register its own tasks to monitor the performance of the runtime. Threads are first class objects and can be directly accessed by other threads.''
	\|Currently, the runtime maintains these information at varying degrees of granularity, depending on developers' choice (from instruction & byte counts all the way to task statistics), and this information is available for offline analysis. Future work will allow a portion of this analysis to be made online, so that custom performance tool tasks are accommodated.		\|Currently, the runtime maintains these information at varying degrees of granularity, depending on developers' choice (from instruction & byte counts all the way to task statistics), and this information is available for offline analysis. Future work will allow a portion of this analysis to be made online, so that custom performance tool tasks are accommodated.
	\|		\|

imported>Rlawton at 15:34, May 12, 2014

2014-05-12T15:34:09Z

← Older revision		Revision as of 15:34, May 12, 2014
Line 17:		Line 17:
	\|		\|
	\|		\|
	\|		\|The basic unit of computation is the SWARM codelet. Codelets are grouped into SCALE procedures that allow the sharing of data across the codelets. On top of codelets and procedures, two higher level notations have been implemented: The Hierarchically Tiled Array object which includes data parallel operations and is implemented as a library, and Sequential C code auto-parallelized and translated by R-Stream into codelets.
	\|		\|
	\|		\|
Line 28:		Line 28:
	\|		\|
	\|		\|
	\|		\|Cost of memory accesses across the different levels of the hierarchy, overhead associated with codelet initiation and coordination, scheduling strategies.
	\|		\|
	\|		\|
Line 39:		Line 39:
	\|		\|
	\|		\|
	\|		\|Cost of communication across different levels of the hierarchy, cost of context switching, size of different memory levels, classes of processors, parameters of the scheduling strategy.
	\|		\|
	\|		\|
Line 50:		Line 50:
	\|		\|
	\|		\|
	\|		\|Within the codelet: (a) Sequential performance of each codelet (e.g. in Gigaflops), and (b) Cost associated with memory accesses by instructions in a codelet. (e.g. how many accesses are cache hits, how many accesses go to scratch pad memory, how may to remote locations). Across codelets: (a) Overhead caused by both local and remote codelet initiation, cost of argument boxing, data communication costs (moving data), (b) Processor utilization and impact of the scheduling choices of the runtime stack, and (c) Other overhead of the runtime system.
	\|		\|
	\|		\|
Line 61:		Line 61:
	\|		\|
	\|		\|
	\|		\|Each codelet could maintain: initiation time, termination time, cache miss rate, number of codelets initiated, total size of parameters, number of reinitiations (due to failures).
	\|		\|
	\|		\|
Line 72:		Line 72:
	\|		\|
	\|		\|
	\|		\|Same as above
	\|		\|
	\|		\|
Line 83:		Line 83:
	\|		\|
	\|		\|
	\|		\|Yes. All of the above.
	\|		\|
	\|		\|
Line 94:		Line 94:
	\|		\|
	\|		\|
	\|		\|To find a balance between performance and power consumption. To have good resiliency for the system and the impact of faults on performance.
	\|		\|
	\|		\|
Line 105:		Line 105:
	\|		\|
	\|		\|
	\|		\|To identify hardware/system/runtime bottlenecks, and to identify poor prioritization of the application's critical path. It's unclear what interfaces would provide sufficient introspection into the necessary systems without paying an unacceptable performance penalty, further discussion on this topic is welcome.
	\|		\|
	\|		\|
Line 116:		Line 116:
	\|		\|
	\|		\|
	\|		\|Execution time, energy consumption, cache miss ratio, fraction of accesses to each class of remote memory, latency of memory accesses, network collisions.
	\|		\|
	\|		\|
Line 127:		Line 127:
	\|		\|
	\|		\|
	\|		\|In the case of HTA, the cost of each HTA operation decomposed into computation (sequential and parallel), communication cost, locality (cache misses or equivalent if scratch pad memories are used), network congestion, energy consumption.
	\|		\|
	\|		\|
Line 138:		Line 138:
	\|		\|
	\|		\|
	\|		\|A system like the parallel study and thread profiler of Intel.
	\|		\|
	\|		\|
Line 149:		Line 149:
	\|		\|
	\|		\|
	\|		\|Tuning for a complex target environment where power, small memory sizes, and redundancy for reliability are issues. Exposing the important factors for parallelism, locality, communication, power, and reliability in a machine independent manner.
	\|		\|
	\|		\|

imported>Jsstone1 at 04:04, May 12, 2014

2014-05-12T04:04:16Z

Show changes

imported>Rbbrigh at 20:06, May 9, 2014

2014-05-09T20:06:56Z

← Older revision		Revision as of 20:06, May 9, 2014
Line 24:		Line 24:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What performance information would application developers need to know to tune codes that use your X-Stack project's software?		\| What performance information would application developers need to know to tune codes that use your X-Stack project's software?
	\|		\|''Critical questions are of granularity of tasks based on overhead costs of managing threads and relative localities of execution and data objects, although both can be addressed in part by compiler and runtime functions.''
	\|		\|
	\|		\|
Line 35:		Line 35:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What would a systems software developer need to know to tune the performance of your software stack?		\| What would a systems software developer need to know to tune the performance of your software stack?
	\|		\|''Critical questions are of granularity of tasks based on overhead costs of managing threads and relative localities of execution and data objects, although both can be addressed in part by compiler and runtime functions.''
	\|		\|
	\|		\|
Line 46:		Line 46:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What information should a performance tool gather from each level in your software stack?		\| What information should a performance tool gather from each level in your software stack?
	\|		\|''Performance information is gathered by the APEX runtime introspection data gathering and analysis tool and the RCR low-level system operation data gathering tool. With HPX runtime system policies this information is used to dynamically and adaptively guide resource allocation and task scheduling.''
	\|		\|
	\|		\|
Line 57:		Line 57:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What performance information can/does each level of your software stack maintain for inspection by performance tools?		\| What performance information can/does each level of your software stack maintain for inspection by performance tools?
	\|		\|''Performance information is gathered by the APEX runtime introspection data gathering and analysis tool and the RCR low-level system operation data gathering tool. With HPX runtime system policies this information is used to dynamically and adaptively guide resource allocation and task scheduling.''
	\|		\|
	\|		\|
Line 79:		Line 79:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What types of performance problems do you want tools to measure and diagnose? CPU resource consumption? CPU utilization? Network bandwidth? Network latency? Contention for shared resources? Waste? Inefficiency? Insufficient parallelism? Load-imbalance? Task dependences? Idleness? Data movement costs? Power or energy consumption? Failures and failure handling costs? The overhead of resilience mechanisms? I/O bandwidth consumed? I/O latency?		\| What types of performance problems do you want tools to measure and diagnose? CPU resource consumption? CPU utilization? Network bandwidth? Network latency? Contention for shared resources? Waste? Inefficiency? Insufficient parallelism? Load-imbalance? Task dependences? Idleness? Data movement costs? Power or energy consumption? Failures and failure handling costs? The overhead of resilience mechanisms? I/O bandwidth consumed? I/O latency?
	\|		\|''All of the above and more.''
	\|		\|
	\|		\|
Line 90:		Line 90:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What kinds of performance problems do you foresee analyzing using post-mortem analysis?		\| What kinds of performance problems do you foresee analyzing using post-mortem analysis?
	\|		\|''Post-mortem information would be useful to analyze non-causal behavioral data that cannot be predicted prior to execution. It must also differentiate this information from that which is entirely data dependent and therefore likely to change from that which is an intrinsic property of the program. A determination of the critical path and side path tasks combined with energy and time consumption requirements for each task would be very useful.''
	\|		\|
	\|		\|
Line 101:		Line 101:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What kinds of performance problems do you foresee analyzing using runtime analysis? What interfaces will be needed to gather the necessary information?		\| What kinds of performance problems do you foresee analyzing using runtime analysis? What interfaces will be needed to gather the necessary information?
	\|		\|''The challenge is to prioritize the critical and sub critical tasks for execution filling in with side-path threads with resource availability. Parallelism governing is important to avoid system jamming through throttling so usage monitoring is crucial. The XPRESS APEX runtime subsystem performs these and other services with additional support from the RCR RIOS subsystem.''
	\|		\|
	\|		\|
Line 112:		Line 112:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What control interfaces will be necessary to enable runtime adaptation based on runtime performance measurements?		\| What control interfaces will be necessary to enable runtime adaptation based on runtime performance measurements?
	\|		\|''The challenge is to prioritize the critical and sub critical tasks for execution filling in with side-path threads with resource availability. Parallelism governing is important to avoid system jamming through throttling so usage monitoring is crucial. The XPRESS APEX runtime subsystem performs these and other services with additional support from the RCR RIOS subsystem.''
	\|		\|
	\|		\|
Line 123:		Line 123:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| There is a gap between the application-level and implementation-level views of programming languages and DSLs. What information should your software layers (compiler and runtime system) provide to attribute implementation-level performance measurement data to an application-level view?		\| There is a gap between the application-level and implementation-level views of programming languages and DSLs. What information should your software layers (compiler and runtime system) provide to attribute implementation-level performance measurement data to an application-level view?
	\|		\|''For purposes of performance portability, the principal information required from programmer level is parallelism and some relative locality information. It is possible that some higher-level idiomatic patterns of control and access may be useful but these have as yet to be determined.''
	\|		\|
	\|		\|
Line 134:		Line 134:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What kind of visualization and presentation support do you want from performance tools? Do you envision any IDE integration for performance tools?		\| What kind of visualization and presentation support do you want from performance tools? Do you envision any IDE integration for performance tools?
	\|		\|''Visualization of resource usage and pending (bottlenecked) work will help to inform about intrinsic code parallelism and precedent constraints.''
	\|		\|
	\|		\|
Line 145:		Line 145:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| List the performance challenges that you think next generation programming languages and models will face.		\| List the performance challenges that you think next generation programming languages and models will face.
	\|		\|''Overhead and its impact on granularity, diversity of forms and scales of parallelism, parallelism discovery from meta data, energy suppression.''
	\|		\|
	\|		\|

imported>Schulzm at 04:12, May 7, 2014

2014-05-07T04:12:19Z

← Older revision		Revision as of 04:12, May 7, 2014
Line 155:		Line 155:
	\|		\|
	\|}		\|}

			Note, PIPER is not listed as a column above, since it is intended as a recipient of this information.

imported>JohnMC at 14:25, May 2, 2014

2014-05-02T14:25:58Z

← Older revision		Revision as of 14:25, May 2, 2014
Line 62:		Line 62:
	\|		\|
	\|		\|
			\|
	\|		\|
	\|		\|

imported>JohnMC at 14:25, May 2, 2014

2014-05-02T14:25:30Z

imported>JohnMC at 14:24, May 2, 2014

2014-05-02T14:24:02Z

← Older revision		Revision as of 14:24, May 2, 2014
Line 120:		Line 120:
	\|		\|
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What control interfaces will be necessary to enable runtime adaptation based on performance measurements?		\| What control interfaces will be necessary to enable runtime adaptation based on runtime performance measurements?
	\|		\|
	\|		\|

← Older revision		Revision as of 14:25, May 2, 2014
Line 11:		Line 11:
	! style="width: 200;" \| CORVETTE		! style="width: 200;" \| CORVETTE
	! style="width: 200;" \| SLEEC		! style="width: 200;" \| SLEEC
	~~! style="width: 200;" \| PIPER~~
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What abstractions does your runtime stack use for parallelism?		\| What abstractions does your runtime stack use for parallelism?
	\|
	\|		\|
	\|		\|
Line 26:		Line 24:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What performance information would application developers need to know to tune codes that use your X-Stack project's software?		\| What performance information would application developers need to know to tune codes that use your X-Stack project's software?
	\|
	\|		\|
	\|		\|
Line 38:		Line 35:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What would a systems software developer need to know to tune the performance of your software stack?		\| What would a systems software developer need to know to tune the performance of your software stack?
	\|
	\|		\|
	\|		\|
Line 56:		Line 52:
	\|		\|
	\|		\|
	\|
	\|		\|
	\|		\|
Line 62:		Line 57:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What performance information can/does each level of your software stack maintain for inspection by performance tools?		\| What performance information can/does each level of your software stack maintain for inspection by performance tools?
	\|
	\|		\|
	\|		\|
Line 73:		Line 67:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What information would your software stack need to maintain in order to measure per-thread or per-task, performance? Can this information be accessed safely from a signal handler? Could a performance tool register its own tasks to monitor the performance of the runtime?		\| What information would your software stack need to maintain in order to measure per-thread or per-task, performance? Can this information be accessed safely from a signal handler? Could a performance tool register its own tasks to monitor the performance of the runtime?
	\|
	\|		\|
	\|		\|
Line 85:		Line 78:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What types of performance problems do you want tools to measure and diagnose? CPU resource consumption? CPU utilization? Network bandwidth? Network latency? Contention for shared resources? Waste? Inefficiency? Insufficient parallelism? Load-imbalance? Task dependences? Idleness? Data movement costs? Power or energy consumption? Failures and failure handling costs? The overhead of resilience mechanisms? I/O bandwidth consumed? I/O latency?		\| What types of performance problems do you want tools to measure and diagnose? CPU resource consumption? CPU utilization? Network bandwidth? Network latency? Contention for shared resources? Waste? Inefficiency? Insufficient parallelism? Load-imbalance? Task dependences? Idleness? Data movement costs? Power or energy consumption? Failures and failure handling costs? The overhead of resilience mechanisms? I/O bandwidth consumed? I/O latency?
	\|
	\|		\|
	\|		\|
Line 97:		Line 89:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What kinds of performance problems do you foresee analyzing using post-mortem analysis?		\| What kinds of performance problems do you foresee analyzing using post-mortem analysis?
	\|
	\|		\|
	\|		\|
Line 109:		Line 100:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What kinds of performance problems do you foresee analyzing using runtime analysis? What interfaces will be needed to gather the necessary information?		\| What kinds of performance problems do you foresee analyzing using runtime analysis? What interfaces will be needed to gather the necessary information?
	\|
	\|		\|
	\|		\|
Line 121:		Line 111:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What control interfaces will be necessary to enable runtime adaptation based on runtime performance measurements?		\| What control interfaces will be necessary to enable runtime adaptation based on runtime performance measurements?
	\|
	\|		\|
	\|		\|
Line 133:		Line 122:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| There is a gap between the application-level and implementation-level views of programming languages and DSLs. What information should your software layers (compiler and runtime system) provide to attribute implementation-level performance measurement data to an application-level view?		\| There is a gap between the application-level and implementation-level views of programming languages and DSLs. What information should your software layers (compiler and runtime system) provide to attribute implementation-level performance measurement data to an application-level view?
	\|
	\|		\|
	\|		\|
Line 145:		Line 133:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| What kind of visualization and presentation support do you want from performance tools? Do you envision any IDE integration for performance tools?		\| What kind of visualization and presentation support do you want from performance tools? Do you envision any IDE integration for performance tools?
	\|
	\|		\|
	\|		\|
Line 157:		Line 144:
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\| List the performance challenges that you think next generation programming languages and models will face.		\| List the performance challenges that you think next generation programming languages and models will face.
	\|
	\|		\|
	\|		\|