Deprecated: Function eregi() is deprecated in /home/opensour/public_html/pub/skins/PStack/cookbook/detect_mobile.php on line 36

Warning: Cannot modify header information - headers already sent by (output started at /home/opensour/public_html/pub/skins/PStack/cookbook/detect_mobile.php:36) in /home/opensour/public_html/pmwiki.php on line 1170
Open Source Research Institutue: PStack/Home Page

PStack.HomePage History

Hide minor edits - Show changes to markup

December 15, 2012, at 10:58 AM by 24.130.186.152 -
Changed line 19 from:

PStack is infrastructure plus an approach, which together enable sponge-like incorporation of tools into a coherent solution.

to:

PStack proposes infrastructure plus an approach, which together enable sponge-like incorporation of tools into a coherent solution.

December 15, 2012, at 10:54 AM by 24.130.186.152 -
Changed line 15 from:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of forms generated. When a machine requests to install an application, the layer sends the form that targets that hardware. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

to:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those patterns, to generate various forms of each application. The layer should then manage the distribution of the variety of forms generated. When a machine requests to install an application, the layer sends the form that targets that hardware. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

December 15, 2012, at 10:53 AM by 24.130.186.152 -
Changed line 15 from:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of forms generated, sending the appropriate form when a machine requests to install an application. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

to:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of forms generated. When a machine requests to install an application, the layer sends the form that targets that hardware. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

December 15, 2012, at 10:52 AM by 24.130.186.152 -
Changed line 15 from:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

to:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of forms generated, sending the appropriate form when a machine requests to install an application. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

December 15, 2012, at 10:49 AM by 24.130.186.152 -
Changed line 15 from:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to automated manipulation by the management layer and the tools within it.

to:

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose their patterns in ways that make them available to automated manipulation by the management layer and the tools within it.

December 15, 2012, at 10:48 AM by 24.130.186.152 -
Changed lines 13-15 from:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a small subset of the patterns existing within application codes. Each tool then produces a form of the code that is specialized to only a subset of the hardware targets existing. Some form of management layer should be able to select patterns within applications and invoke the tools that apply to those, then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

to:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a small subset of the patterns existing within application codes. Each tool then produces a form of the code that is specialized to only a subset of the hardware targets existing. There are no all-applications to all-hardware tools, and it is highly unlikely that such will come into existence.

One path to solution is creating a meta-tool above the individual tools that acts as a management layer. It should be able to select patterns within applications and invoke the tools that apply to those, to generate various forms of each application. The layer should then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to automated manipulation by the management layer and the tools within it.

December 15, 2012, at 10:44 AM by 24.130.186.152 -
Changed line 13 from:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a small subset of the patterns existing within application codes. Each then produces a form specialized to only a subset of the hardware targets existing. Some form of management layer should be able to select patterns within applications and invoke the tools that apply to those, then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

to:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a small subset of the patterns existing within application codes. Each tool then produces a form of the code that is specialized to only a subset of the hardware targets existing. Some form of management layer should be able to select patterns within applications and invoke the tools that apply to those, then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

December 15, 2012, at 10:44 AM by 24.130.186.152 -
Changed line 13 from:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. Some form of management layer should be able to select patterns within applications and invoke the tools that apply to those, then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

to:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a small subset of the patterns existing within application codes. Each then produces a form specialized to only a subset of the hardware targets existing. Some form of management layer should be able to select patterns within applications and invoke the tools that apply to those, then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

December 15, 2012, at 10:43 AM by 24.130.186.152 -
Changed line 13 from:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. A management layer may be able to filter applications by patterns and invoke the tools that apply, then manage distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

to:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. Some form of management layer should be able to select patterns within applications and invoke the tools that apply to those, then manage the distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

December 11, 2012, at 07:18 AM by 24.130.186.152 -
Changed lines 9-11 from:

The shift to parallel hardware being forced by basic physics has been creating a widening software gap. Coding practices remain sequential due to the difficulty, cost, and machine-specificity of parallel programming. This gap slows the progress of software and hardware both, slowing productivity gains throughout the economy. A solution is needed that makes parallel programming highly productive, while also being high performance across hardware types, and that fits with industry practices to be easily adoptable.

Past attempts have been too narrow in scope, focused on a single language, tool, or runtime, which can only manage to apply to a sub-set of hardware targets or application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

to:

The shift to parallel hardware being forced by basic physics has been creating a widening software gap because coding practices remain sequential due to the difficulty, cost, and machine-specificity of parallel programming. This gap slows the progress of software and hardware both, slowing productivity gains throughout the economy. A solution is needed that makes parallel programming highly productive, while also being high performance across hardware types, and that fits with industry practices to be easily adoptable.

Past attempts have been too narrow in scope, focused on a single language, tool, or runtime, which can only manage to apply to a sub-set of hardware targets and application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

December 11, 2012, at 05:04 AM by 24.130.186.152 -
Changed line 22 from:

The runtime infrastructure is system-level software that sits at the hardware-software boundary at the base of the software stack. It exports a simplifying interface to the stack above, while being highly tuned to the low-level details of the hardware below. This approach modularizes the runtime systems of the languages, which simplifies creation of new languages. In particular it supports the domain-specific language approach, which shows promise for both increasing programmer productivity and increasing performance-portability of application code (http://ppl.stanford.edu/main/). Perhaps more importantly, this infrastructure brings application-specific patterns into runtime consideration of scheduling and sharing the hardware, for improved efficiency.

to:

The runtime infrastructure is system-level software that sits at the hardware-software boundary at the base of the software stack. It exports a simplifying interface to the stack above, while being highly tuned to the low-level details of the hardware below. This approach modularizes the runtime systems of the languages, which simplifies creation of new languages. In particular it supports the domain-specific language approach, which shows promise for both increasing programmer productivity and increasing performance-portability of application code (http://ppl.stanford.edu/main/). Perhaps more importantly, this infrastructure brings application-specific patterns into the runtime decisions for scheduling and sharing the hardware, for improved efficiency.

December 11, 2012, at 05:02 AM by 24.130.186.152 -
Changed line 22 from:

The runtime infrastructure is system-level software that sits at the hardware-software boundary at the base of the software stack. It exports a simplifying interface to the stack above, while being highly tuned to the low-level details of the hardware below. This approach modularizes the runtime systems of the languages, which simplifies creation of new languages. In particular it supports creation of the domain-specific language approach, which shows promise for both increasing programmer productivity and increasing performance-portability of application code (http://ppl.stanford.edu/main/). Perhaps more importantly, this infrastructure brings application-specific patterns into runtime consideration of scheduling and sharing the hardware, for improved efficiency.

to:

The runtime infrastructure is system-level software that sits at the hardware-software boundary at the base of the software stack. It exports a simplifying interface to the stack above, while being highly tuned to the low-level details of the hardware below. This approach modularizes the runtime systems of the languages, which simplifies creation of new languages. In particular it supports the domain-specific language approach, which shows promise for both increasing programmer productivity and increasing performance-portability of application code (http://ppl.stanford.edu/main/). Perhaps more importantly, this infrastructure brings application-specific patterns into runtime consideration of scheduling and sharing the hardware, for improved efficiency.

December 11, 2012, at 05:00 AM by 24.130.186.152 -
Changed line 20 from:

The harness houses an array of software tools, coordinates applying them each to their narrow domains, and manages distribution of the executables thus produced. The tools optimize, transform, inject, and otherwise manipulate code to specialize it to particular hardware. The end result is a highly tuned executable for each category of hardware targeted by the infrastructure. It is expected that a portion of the specialization process will also take place during installation of the executable, and more specialization will take place during execution.

to:

The harness houses an array of software tools, coordinates applying them each to their narrow domains, and manages distribution of the executables thus produced. The tools optimize, transform, inject, and otherwise manipulate code to specialize it to particular hardware. The end result is a highly tuned executable for each category of hardware targeted by the infrastructure. The system supports performing a portion of the specialization process during installation of the executable, and more specialization during execution.

December 11, 2012, at 04:57 AM by 24.130.186.152 -
Changed line 13 from:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. A given application will have patterns that match some tools but not others, and the tools that apply will produce images for different hardware targets. A management layer may be able to filter applications by patterns and invoke the tools that apply, then manage distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

to:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. A management layer may be able to filter applications by patterns and invoke the tools that apply, then manage distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

December 11, 2012, at 04:55 AM by 24.130.186.152 -
Changed line 11 from:

Past attempts have been too narrow in scope, focused on a single language, tool, or runtime, which applies to a sub-set of hardware targets or application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

to:

Past attempts have been too narrow in scope, focused on a single language, tool, or runtime, which can only manage to apply to a sub-set of hardware targets or application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

December 11, 2012, at 04:54 AM by 24.130.186.152 -
Changed line 11 from:

Past attempts have been too narrow in scope, focused on a single language or a single run-time, which applies to a sub-set of hardware targets or application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

to:

Past attempts have been too narrow in scope, focused on a single language, tool, or runtime, which applies to a sub-set of hardware targets or application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

December 11, 2012, at 04:53 AM by 24.130.186.152 -
Changed line 13 from:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools exist to perform such specialization, each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. A given application will have patterns that match some tools but not others, and the tools that apply will produce images for different hardware targets. A management layer may be able to filter applications by patterns and invoke the tools that apply, then manage distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

to:

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools already exist to perform such specialization, but each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. A given application will have patterns that match some tools but not others, and the tools that apply will produce images for different hardware targets. A management layer may be able to filter applications by patterns and invoke the tools that apply, then manage distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

December 11, 2012, at 04:51 AM by 24.130.186.152 -
Changed lines 28-29 from:

<!-- to integration of tools, and interfaces that isolate contributions' implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

to:

(:if false:) to integration of tools, and interfaces that isolate contributions' implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

Changed line 40 from:
to:

(:ifend:)

December 11, 2012, at 04:46 AM by 24.130.186.152 -
Changed lines 9-12 from:

Physics is forcing all computer hardware to become parallel, which is in turn forcing all industries that rely upon computers to shift to parallel software development. This is lower productivity than the preceding sequential software development, and because of the pervasiveness of processor chips and information technology, this loss of productivity is threatening the entire economy. To avoid this productivity loss, a means must be found to enable parallel software to be written just once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

Attempts to provide a solution have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces that isolate contributions' implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

to:

The shift to parallel hardware being forced by basic physics has been creating a widening software gap. Coding practices remain sequential due to the difficulty, cost, and machine-specificity of parallel programming. This gap slows the progress of software and hardware both, slowing productivity gains throughout the economy. A solution is needed that makes parallel programming highly productive, while also being high performance across hardware types, and that fits with industry practices to be easily adoptable.

Past attempts have been too narrow in scope, focused on a single language or a single run-time, which applies to a sub-set of hardware targets or application types. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by independent research and industry sources.

The heart of the problem is the requirement to specialize code to the details of the hardware it will run on. An array of tools exist to perform such specialization, each is narrow in scope, operating on a subset of the patterns existing within application codes and then producing a specialized form applicable to only a subset of the hardware targets available. A given application will have patterns that match some tools but not others, and the tools that apply will produce images for different hardware targets. A management layer may be able to filter applications by patterns and invoke the tools that apply, then manage distribution of the variety of executables generated. The management layer may include productivity tools to semi-automate human intervention in the specialization process, as well as technology that encourages languages and applications to expose the requisite patterns and make them available to manipulation by the tools.

Added lines 17-29:

PStack is infrastructure plus an approach, which together enable sponge-like incorporation of tools into a coherent solution. The PStack infrastructure includes a harness that manages specialization tools, system-software level infrastructure for runtime systems, and support for language creation. Each element has a role to play within an over-arching approach, which coordinates the parts to support each other.

The harness houses an array of software tools, coordinates applying them each to their narrow domains, and manages distribution of the executables thus produced. The tools optimize, transform, inject, and otherwise manipulate code to specialize it to particular hardware. The end result is a highly tuned executable for each category of hardware targeted by the infrastructure. It is expected that a portion of the specialization process will also take place during installation of the executable, and more specialization will take place during execution.

The runtime infrastructure is system-level software that sits at the hardware-software boundary at the base of the software stack. It exports a simplifying interface to the stack above, while being highly tuned to the low-level details of the hardware below. This approach modularizes the runtime systems of the languages, which simplifies creation of new languages. In particular it supports creation of the domain-specific language approach, which shows promise for both increasing programmer productivity and increasing performance-portability of application code (http://ppl.stanford.edu/main/). Perhaps more importantly, this infrastructure brings application-specific patterns into runtime consideration of scheduling and sharing the hardware, for improved efficiency.

Support for language creation includes Source-to-Source translation that simplifies creation of embedded style domain languages (http://strategoxt.org/Stratego/MetaBorg, http://rosecompiler.org/). This allows embedding new domain language code into existing sequential code, to incrementally add parallelism in a high productivity way without changing the development process.

<!-- to integration of tools, and interfaces that isolate contributions' implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

Added line 39:
July 19, 2012, at 03:26 AM by 24.130.186.152 -
Changed line 5 from:

Here is a 5-page description from a project proposal submitted to the EU commission.

to:
July 19, 2012, at 03:21 AM by 24.130.186.152 -
Changed line 11 from:

Attempts to provide a solution have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces the isolate contribution's implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

to:

Attempts to provide a solution have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces that isolate contributions' implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

July 19, 2012, at 03:20 AM by 24.130.186.152 -
Changed line 11 from:

Attempts to provide a solution have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces the isolate contributions from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

to:

Attempts to provide a solution have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces the isolate contribution's implementations from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

July 19, 2012, at 03:18 AM by 24.130.186.152 -
Changed line 9 from:

Physics is forcing all computer hardware to become parallel, which is in turn forcing all industries that rely upon computers to shift to parallel software development. This is lower productivity the preceding sequential software development, and because of the pervasiveness of processor chips and information technology, this loss of productivity is threatening the entire economy. To avoid this productivity loss, a means must be found to enable parallel software to be written just once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

to:

Physics is forcing all computer hardware to become parallel, which is in turn forcing all industries that rely upon computers to shift to parallel software development. This is lower productivity than the preceding sequential software development, and because of the pervasiveness of processor chips and information technology, this loss of productivity is threatening the entire economy. To avoid this productivity loss, a means must be found to enable parallel software to be written just once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

July 19, 2012, at 03:18 AM by 24.130.186.152 -
Changed lines 9-12 from:

Physics is forcing all computer hardware to become parallel, which is in turn forcing all industries that rely upon computers to shift to parallel software development. This is lower productivity than current sequential software development, and because of the pervasiveness of processor chips and information technology, this loss of productivity is threatening the entire economy. To avoid this productivity loss, a means must be found to enable parallel software to be written just once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

Attempts to provide this have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself, instead an approach is needed that acts as a sponge, soaking up the pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces the isolate contributions from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of tuning every application across every hardware platform.

to:

Physics is forcing all computer hardware to become parallel, which is in turn forcing all industries that rely upon computers to shift to parallel software development. This is lower productivity the preceding sequential software development, and because of the pervasiveness of processor chips and information technology, this loss of productivity is threatening the entire economy. To avoid this productivity loss, a means must be found to enable parallel software to be written just once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

Attempts to provide a solution have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself. Instead an approach is needed that acts as a sponge, soaking up pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces the isolate contributions from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of effort of tuning every application across every hardware platform.

Changed lines 16-17 from:

The lowest layer presents a family of proto-runtime interfaces, which languages create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the services implemented in the proto-runtime and reuse of the performance tuning done on it. In addition, a language only implements one runtime for all the hardware targets in the class, which reduces the number of runtimes that have to be created, but in a way that maintains high runtime performance and high application code performance on all hardware.

to:

The lowest layer presents the VMS family of proto-runtime interfaces, which languages use to create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the services implemented in the proto-runtime and reuse of the performance tuning done on it. In addition, a language only implements one runtime for all the hardware targets in the class, which reduces the number of runtimes that have to be created, but in a way that maintains high runtime performance and high application code performance on all hardware.

Changed lines 20-22 from:

This project's new, collective, approach can succeed where single-entity solutions have failed in the past. We provide structure that makes it easy and clean for players across industry to each supply one small piece of the solution, and our structure integrates them into a collective solution. To accomplish this, we will exploit two key advances: a recent theoretical model, used to design a set of portability constructs to be incorporated into languages, and a recent promising parallel hardware abstraction that provides an organizing principle and enables reuse. These are further augmented by a toolchain management approach, which makes it practical for 3rd parties to add new performance tools to the stack.

The seeds of each piece of the stack have been demonstrated by one partner or another. In the project, we will tackle the vision of creating an integrated whole from them, in a way that each part relies on and supports the others, and encourages diverse groups add to the stack independently, organically growing the solution.

to:

Above the runtimes, BLIS is a second key interface used to organize source manipulation tools such as compilers, optimizers, and auto-tuners, and to manage the many different executable files produced for a single source file. BLIS is used during installation, so that the binary best suited to the hardware is chosen, and connected to the independently supplied runtime system for that hardware. BLIS allows powerful but narrowly focused techniques such as polyhedral optimization and data-structure flattening to be applied to carefully filtered subsets of the source. In practice, such methods cover too little of the source to justify their use as stand-alone tools, but within the BLIS system, they are automatically applied, and collectively provide a large impact.

This project's new, collective, approach can succeed where single-entity solutions have failed in the past. The seeds of each piece of the stack have been demonstrated and the project will tackle the vision of creating an integrated whole from them, in a way that encourages diverse groups to add to the stack independently, organically growing the solution to productive and performantly portable parallel software.

July 19, 2012, at 02:49 AM by 24.130.186.152 -
Changed lines 16-20 from:

The lowest layer presents a family of proto-runtime interfaces that languages use to create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the services implemented in the proto-runtime and reuse of the performance tuning done on it. In addition, a language only implements one runtime for all the hardware targets in the class, while maintaining high runtime performance as well as high application performance, which reduces the number of runtimes that have to be created.

In effect, the language runtime-portions that plug in to the proto-runtimes become their own layer. One of these plugins is provided by each proto-runtime interface. That multiplicative effect means that the modularization provided by the proto-runtime interface causes a major reduction in the effort required to make all languages run on all hardware.

We are aware that this is a bold claim, which is considered beyond reach by many. However, this project takes a new, collective, approach. We provide structure that makes it easy and clean for players across industry to each supply one small piece of the solution, and our structure integrates them into a collective solution. To accomplish this, we will exploit two key advances: a recent theoretical model, used to design a set of portability constructs to be incorporated into languages, and a recent promising parallel hardware abstraction that provides an organizing principle and enables reuse. These are further augmented by a toolchain management approach, which makes it practical for 3rd parties to add new performance tools to the stack.

to:

The lowest layer presents a family of proto-runtime interfaces, which languages create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the services implemented in the proto-runtime and reuse of the performance tuning done on it. In addition, a language only implements one runtime for all the hardware targets in the class, which reduces the number of runtimes that have to be created, but in a way that maintains high runtime performance and high application code performance on all hardware.

In effect, the language runtime-portions that plug in to the proto-runtimes become their own layer. One of these plugins is provided for each proto-runtime interface. That multiplicative effect means that the modularization provided by the proto-runtime interface causes a major reduction in the effort required to make all languages run on all hardware.

This project's new, collective, approach can succeed where single-entity solutions have failed in the past. We provide structure that makes it easy and clean for players across industry to each supply one small piece of the solution, and our structure integrates them into a collective solution. To accomplish this, we will exploit two key advances: a recent theoretical model, used to design a set of portability constructs to be incorporated into languages, and a recent promising parallel hardware abstraction that provides an organizing principle and enables reuse. These are further augmented by a toolchain management approach, which makes it practical for 3rd parties to add new performance tools to the stack.

July 19, 2012, at 02:44 AM by 24.130.186.152 -
Changed lines 16-19 from:

The lowest layer presents a family of proto-runtime interfaces that languages use to create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the proto-runtime by all languages, so that performance tuning and services are inherited by the languages. In addition, a language only implements one runtime for all the hardware targets in the class, while maintaining high runtime performance as well as high application performance.

That separates the language runtime-portions that plug in to the proto-runtime compiled and executed, without source modification, and with good performance across the full range of current and, foreseeable, future hardware.

to:

The lowest layer presents a family of proto-runtime interfaces that languages use to create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the services implemented in the proto-runtime and reuse of the performance tuning done on it. In addition, a language only implements one runtime for all the hardware targets in the class, while maintaining high runtime performance as well as high application performance, which reduces the number of runtimes that have to be created.

In effect, the language runtime-portions that plug in to the proto-runtimes become their own layer. One of these plugins is provided by each proto-runtime interface. That multiplicative effect means that the modularization provided by the proto-runtime interface causes a major reduction in the effort required to make all languages run on all hardware.

July 19, 2012, at 02:37 AM by 24.130.186.152 -
Changed lines 9-12 from:

The productivity and efficiency of the global ICT industry, and by implication European ICT and its diverse customers, is under threat from the challenge of transitioning to heterogeneous, highly parallel hardware as the mainstream technology. The core need is a means to write parallel software once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

Attempts to provide this have been too narrow in scope, focused on a single language or a single run-time, or sub-set of hardware targets. The problem is larger than any one group can solve, requiring instead a new software stack, from the hardware-interface up to the programming tools, which is cooperatively provided by many players, each adding a small piece. In this way, many languages are supported, and the effort of supporting a language on a machine can be reused by other languages, which makes such a stack practical.

to:

Physics is forcing all computer hardware to become parallel, which is in turn forcing all industries that rely upon computers to shift to parallel software development. This is lower productivity than current sequential software development, and because of the pervasiveness of processor chips and information technology, this loss of productivity is threatening the entire economy. To avoid this productivity loss, a means must be found to enable parallel software to be written just once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones.

Attempts to provide this have been too narrow in scope, focused on a single language or a single run-time, or a sub-set of hardware targets. The problem is larger in scope than any one group can manage to solve by itself, instead an approach is needed that acts as a sponge, soaking up the pieces of the solution provided by many different sources. It will have to provide standards that enable integration of tools, and interfaces the isolate contributions from each other, yet allow them to interact. Most importantly, the solution will have to provide a means to manage the multiplicative explosion of tuning every application across every hardware platform.

Changed lines 14-15 from:

Our proposal addresses this challenge by delivering the seed of such a stack, including the interfaces and the process for independent players to update it with their own additional pieces. This will enable application sources to be compiled and executed, without source modification, and with good performance across the full range of current and, foreseeable, future hardware.

to:

To address the challenge, we propose a software stack approach, which is motivated by fundamental patterns of parallel computation that are used to isolate the layers in ways that are consistent with all parallel languages, and provide powerful reduction in effort. The pieces of the stack are independently provided by many players, while the stack itself acts to organize the pieces and integrate them together, enabling an emergent global solution to arise.

The lowest layer presents a family of proto-runtime interfaces that languages use to create their runtime systems on top of. Each interface makes all members of a class of hardware look the same to the language above, and concentrates the low-level performance tuning of the runtime internals inside the proto-runtime implementation. This provides several sources of effort reduction, including reuse of the proto-runtime by all languages, so that performance tuning and services are inherited by the languages. In addition, a language only implements one runtime for all the hardware targets in the class, while maintaining high runtime performance as well as high application performance.

That separates the language runtime-portions that plug in to the proto-runtime compiled and executed, without source modification, and with good performance across the full range of current and, foreseeable, future hardware.

Changed line 23 from:

The seeds of each piece of the stack have been demonstrated by one partner or another. In the project, we will tackle the vision of creating an integrated whole from them, in a way that each part relies on and supports the others, and encourages diverse groups add to the stack independently, organically growing the solution.

to:

The seeds of each piece of the stack have been demonstrated by one partner or another. In the project, we will tackle the vision of creating an integrated whole from them, in a way that each part relies on and supports the others, and encourages diverse groups add to the stack independently, organically growing the solution.

July 17, 2012, at 12:25 AM by 24.130.186.152 -
Changed line 5 from:

Here is a 5-page description of a project proposal submitted to the EU commission.

to:

Here is a 5-page description from a project proposal submitted to the EU commission.

July 17, 2012, at 12:23 AM by 24.130.186.152 -
Changed lines 5-6 from:

Here is the summary from a project proposal submitted to the EU commission:

to:

Here is a 5-page description of a project proposal submitted to the EU commission.

Summary of Project

The problem

Added line 13:

The PStack Proposed Solution

July 06, 2012, at 03:30 AM by 24.130.186.152 -
Added line 8:
Added line 10:
Added line 12:
Changed lines 14-15 from:

The seeds of each piece of the stack have been demonstrated by one partner or another. In the project, we will tackle the vision of creating an integrated whole from them, in a way that each part relies on and supports the others, and encourages diverse groups add to the stack independently, organically growing the solution.

to:

The seeds of each piece of the stack have been demonstrated by one partner or another. In the project, we will tackle the vision of creating an integrated whole from them, in a way that each part relies on and supports the others, and encourages diverse groups add to the stack independently, organically growing the solution.

July 06, 2012, at 03:30 AM by 24.130.186.152 -
Added lines 2-11:

PStack is a software stack oriented towards high productivity and performant portability of parallel code.

Here is the summary from a project proposal submitted to the EU commission:

The productivity and efficiency of the global ICT industry, and by implication European ICT and its diverse customers, is under threat from the challenge of transitioning to heterogeneous, highly parallel hardware as the mainstream technology. The core need is a means to write parallel software once, productively, then have it automatically run high performance on all available hardware platforms, especially heterogeneous ones. Attempts to provide this have been too narrow in scope, focused on a single language or a single run-time, or sub-set of hardware targets. The problem is larger than any one group can solve, requiring instead a new software stack, from the hardware-interface up to the programming tools, which is cooperatively provided by many players, each adding a small piece. In this way, many languages are supported, and the effort of supporting a language on a machine can be reused by other languages, which makes such a stack practical. Our proposal addresses this challenge by delivering the seed of such a stack, including the interfaces and the process for independent players to update it with their own additional pieces. This will enable application sources to be compiled and executed, without source modification, and with good performance across the full range of current and, foreseeable, future hardware. We are aware that this is a bold claim, which is considered beyond reach by many. However, this project takes a new, collective, approach. We provide structure that makes it easy and clean for players across industry to each supply one small piece of the solution, and our structure integrates them into a collective solution. To accomplish this, we will exploit two key advances: a recent theoretical model, used to design a set of portability constructs to be incorporated into languages, and a recent promising parallel hardware abstraction that provides an organizing principle and enables reuse. These are further augmented by a toolchain management approach, which makes it practical for 3rd parties to add new performance tools to the stack. The seeds of each piece of the stack have been demonstrated by one partner or another. In the project, we will tackle the vision of creating an integrated whole from them, in a way that each part relies on and supports the others, and encourages diverse groups add to the stack independently, organically growing the solution.

July 02, 2012, at 03:08 AM by 24.130.186.152 -
Added line 1:

Welcome to PStack