User stories - Revision history

imported>Jcphill: /* Functional requirements */

2017-03-23T16:28:05Z

Functional requirements

@@ Line 89: / Line 89: @@
 * Whether tasks need to be able to spawn child tasks
 * Whether task dependences only need to be enforcable among siblings (currently restriction for OpenMP tasks), or also at different levels of a hierarchy
 == Retargetable for different kinds of execution resources and data layouts ==

imported>Cnewburn at 04:30, March 20, 2017

2017-03-20T04:30:30Z

← Older revision		Revision as of 04:30, March 20, 2017
Line 1:		Line 1:
	The purpose of this page is to gather requirements, in the form of user stories, for HHAT.		The purpose of this page is to gather requirements, in the form of user stories, for HHAT.

			A link to get back up to the parent page is [[Hierarchical_Heterogeneous_Asynchronous_Tasking \| here]].

	= Overview =		= Overview =

imported>Liakhdi: /* Fortran */

2017-01-23T18:07:33Z

Fortran

← Older revision		Revision as of 18:07, January 23, 2017
Line 72:		Line 72:
	''Lessons learned from the MPI standard: decide whether we use pointers or integer handles.		''Lessons learned from the MPI standard: decide whether we use pointers or integer handles.
	Also, asynchronous interfaces break Fortran's rule of local variables not being changed		Also, asynchronous interfaces break Fortran's rule of local variables not being changed
	after a function returns as in:''		after a function returns as in (unless the ASYNCHRONOUS attribute is used):''

	MPI_Isend(&var);		MPI_Isend(&var);

imported>Luszczek: Move content from main page

2017-01-17T16:50:57Z

Move content from main page

@@ Line 47: / Line 47: @@
 Entered by CJ on behalf of many ISVs,
 including Siemens, MSC, Simulia, Convergent Science
 = Functional requirements =

imported>Cnewburn at 16:13, January 17, 2017

2017-01-17T16:13:37Z

← Older revision		Revision as of 16:13, January 17, 2017
Line 1:		Line 1:
	The purpose of this page is to gather requirements, in the form of user stories, for HHAT.		The purpose of this page is to gather requirements, in the form of user stories, for HHAT.

			= Overview =
	A user story captures the essence of the requirement without over-constraining the implementation. It's tied to a role and a benefit. User stories take the following form:		A user story captures the essence of the requirement without over-constraining the implementation. It's tied to a role and a benefit. User stories take the following form:

Line 11:		Line 12:
	* Start each user story with a new subsection, using two equals signs and a space on either side of a title		* Start each user story with a new subsection, using two equals signs and a space on either side of a title
	* Follow the template shown below		* Follow the template shown below

			== User story template (please leave as an example) ==
			As a <role>,
			I want <function>,
			so that <benefit>,
			subject to the following acceptance criteria
			* item 1
			* item 2
			* item 3
			* item 4
			<Your Name>
			<Project(s) that this would benefit>
			<Link to other related collateral>


	= Provisioning constraints =		= Provisioning constraints =
Line 47:		Line 62:
	so that my code can be retargetable and portable,		so that my code can be retargetable and portable,
	subject to the following acceptance criteria		subject to the following acceptance criteria
	* Invocation of a function can be made with a name which is implementation agnostic		* Invocation of a function can be made with a name which is implementation agnostic
	* Someone in a tuning role or a runtime can choose the best implementation, based on feasibility, earliest completion time, etc.		* Someone in a tuning role or a runtime can choose the best implementation, based on feasibility, earliest completion time, etc.
	* Implementations for new kinds of execution resources and new data layouts for operands can be added over time		* Implementations for new kinds of execution resources and new data layouts for operands can be added over time
	* Operands can be specified in a way that describes the set of elements, but that does not necessarily overconstrain the layout		* Operands can be specified in a way that describes the set of elements, but that does not necessarily overconstrain the layout
	CJ Newburn		CJ Newburn
	ECP and CAAR apps, perhaps QMCPACK		ECP and CAAR apps, perhaps QMCPACK

	=~~= User story template (please leave as an example) =~~=		= Performance constraints =
	~~As a <role>,~~		Please provide detailed user stories for items like the following:
	~~I want <function>,~~		* Scalability
	~~so that <benefit>,~~		** Avoid serialization of startup on multiple nodes
	~~subject to~~ the following ~~acceptance criteria~~		** Avoid or minimize centralized data structures
	* ~~item 1~~		* Overheads
	* ~~item 2~~		** Minimize indirection, e.g. with lookups
	* ~~item 3~~		** Enable costs to be shifted to startup rather than per-usage
	* ~~item 4~~
	~~<Your Name>~~
	~~<Project(s) that this would benefit>~~
	~~<Link~~ to ~~other related collateral>~~

imported>Cnewburn: /* Functional requirements */

2017-01-17T16:08:45Z

Functional requirements

← Older revision		Revision as of 16:08, January 17, 2017
Line 35:		Line 35:
	= Functional requirements =		= Functional requirements =
	Please provide detailed user stories for items like the following:		Please provide detailed user stories for items like the following:
	* ~~Execution~~ of a given task can be ~~selected for different~~ kinds of execution resources, e.g. Xeon, Xeon Phi, GPUs, FPGAs, TPUs, ARM		* Selection among implementations of a given task can be made based on kinds of execution resources, e.g. Xeon, Xeon Phi, GPUs, FPGAs, TPUs, ARM
	* ~~Execution~~ of a given task can be ~~selection for different~~ layouts of its data operands		* Selection among implementations of a given task can be made based on layouts of its data operands
	* Whether global variables are permitted		* Whether global variables are permitted
	* Whether task functions are pure, i.e. all inputs are available at the start and they run to completion, or whether they can block when they reach an internal point of execution until additional conditions (e.g. data or control dependences) are met		* Whether task functions are pure, i.e. all inputs are available at the start and they run to completion, or whether they can block when they reach an internal point of execution until additional conditions (e.g. data or control dependences) are met
	* Whether tasks need to be able to spawn child tasks		* Whether tasks need to be able to spawn child tasks
	* Whether task dependences only need to be enforcable among siblings, or also at different levels of a hierarchy		* Whether task dependences only need to be enforcable among siblings (currently restriction for OpenMP tasks), or also at different levels of a hierarchy

			== Retargetable for different kinds of execution resources and data layouts ==
			As a tuner,
			I want to be able to provide a different tuned implementation for each of several kinds of execution resources,
			so that my code can be retargetable and portable,
			subject to the following acceptance criteria
			* Invocation of a function can be made with a name which is implementation agnostic
			* Someone in a tuning role or a runtime can choose the best implementation, based on feasibility, earliest completion time, etc.
			* Implementations for new kinds of execution resources and new data layouts for operands can be added over time
			* Operands can be specified in a way that describes the set of elements, but that does not necessarily overconstrain the layout
			CJ Newburn
			ECP and CAAR apps, perhaps QMCPACK

	== User story template (please leave as an example) ==		== User story template (please leave as an example) ==

imported>Cnewburn: /* Provisioning constraints */

2017-01-17T15:56:32Z

Provisioning constraints

← Older revision		Revision as of 15:56, January 17, 2017
Line 16:		Line 16:
	Examples:		Examples:
	* Library or compiler		* Library or compiler
	* C ABI that supports layering of C++, Python on top		* C ABI that supports layering of C++, Fortran, Python on top
	* Does not have to own main		* Does not have to own main
	* Composable and interoperable		* Composable and interoperable, e.g. with OpenMP, Kokkos, MPI, HDF5
	* Can target heterogeneous systems		* Can target heterogeneous systems, e.g. Xeon, Xeon Phi, GPUs, FPGAs, TPUs, ARM
	Please fill out user stories for these and others below.		Please fill out user stories for these and others below.

	== Library-based solution ==		== Library-based solution ==
	As an ISV,		As an ISV,
	I want a C library-based solution,		I want a C-ABI library-based solution,
	so that I don't have to rebuild all of my code because of a new compiler every time I want a new feature,		so that I don't have to rebuild all of my code because of a new compiler every time I want a new feature,
	subject to the following acceptance criteria		subject to the following acceptance criteria
	* static or dynamic linking of library, invoked through an API		* static or dynamic linking of library, invoked through an API
	* ok to update my compiler only every 2-3 years		* ok to update my compiler only every 2-3 years
	* C ABI, so that I can build other language interfaces on top, like C++ or Python		* C ABI, so that I can build other language interfaces on top, like C++, Fortran or Python
	Entered by CJ on behalf of many ISVs,		Entered by CJ on behalf of many ISVs,
	including Siemens, MSC, Simulia, Convergent Science		including Siemens, MSC, Simulia, Convergent Science

imported>Cnewburn: /* Functional requirements */

2017-01-09T19:58:20Z

Functional requirements

← Older revision		Revision as of 19:58, January 9, 2017
Line 34:		Line 34:

	= Functional requirements =		= Functional requirements =
			Please provide detailed user stories for items like the following:
			* Execution of a given task can be selected for different kinds of execution resources, e.g. Xeon, Xeon Phi, GPUs, FPGAs, TPUs, ARM
			* Execution of a given task can be selection for different layouts of its data operands
			* Whether global variables are permitted
			* Whether task functions are pure, i.e. all inputs are available at the start and they run to completion, or whether they can block when they reach an internal point of execution until additional conditions (e.g. data or control dependences) are met
			* Whether tasks need to be able to spawn child tasks
			* Whether task dependences only need to be enforcable among siblings, or also at different levels of a hierarchy

	== User story template (please leave as an example) ==		== User story template (please leave as an example) ==

imported>Cnewburn: /* Provisioning constraints */

2017-01-09T19:52:47Z

Provisioning constraints

← Older revision		Revision as of 19:52, January 9, 2017
Line 13:		Line 13:

	= Provisioning constraints =		= Provisioning constraints =
	List features of the deployed solution that will make or break its usability for you		List features of the deployed solution that will make or break its usability for you.
			Examples:
			* Library or compiler
			* C ABI that supports layering of C++, Python on top
			* Does not have to own main
			* Composable and interoperable
			* Can target heterogeneous systems
			Please fill out user stories for these and others below.

	== Library-based solution ==		== Library-based solution ==

imported>Cnewburn at 15:32, December 20, 2016

2016-12-20T15:32:10Z

← Older revision		Revision as of 15:32, December 20, 2016
Line 12:		Line 12:
	* Follow the template shown below		* Follow the template shown below

			= Provisioning constraints =
			List features of the deployed solution that will make or break its usability for you

	== Library-based solution ==		== Library-based solution ==
Line 24:		Line 26:
	including Siemens, MSC, Simulia, Convergent Science		including Siemens, MSC, Simulia, Convergent Science

	== User story ~~name 2~~ ==		= Functional requirements =

			== User story template (please leave as an example) ==
	As a <role>,		As a <role>,
	I want <function>,		I want <function>,