CloudDSM.EndUserView History

Show minor edits - Show changes to output - Cancel

January 25, 2014, at 12:15 PM by 80.114.134.224 -
Changed line 8 from:
* Development tools. They fit into the standard build process as the first tools to run and feed the rest of the toolchain. The end result is a standard executable. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity.
to:
* Development tools. They fit into the standard build process as the first tools to run and feed the rest of the toolchain. The end result is a standard executable. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the calls to the DSM system each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity.
January 25, 2014, at 12:14 PM by 80.114.134.224 -
Changed line 7 from:
* A convenient and productive set of "embedded" languages, systems of pragmas, and language features. The application developer chooses one of these and uses it to provide information to the CloudDSM development tools.
to:
* A convenient and productive set of systems of pragmas, "embedded" languages, and language features. The application developer chooses one of these and uses it to provide information to the CloudDSM development tools.
Changed line 19 from:
The one thing the application programmer must do in order to use the CloudDSM system is to include code that divides the work to be performed into pieces, and also to make the data structures, plus the code that accesses them, known to the tools. The project will develop new pragmas for OpenMP that are used for this, and the project includes a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
to:
The one thing the application programmer must do in order to use the CloudDSM system is to include code that divides the work to be performed into pieces, and also to make the data structures, plus the code that accesses them, known to the tools. The project will develop new pragmas for OpenMP that are used for this, and the project includes a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
January 25, 2014, at 12:13 PM by 80.114.134.224 -
Changed lines 1-2 from:
!End user View of CloudDSM
to:
!!End user View of CloudDSM
Changed line 8 from:
* Development tools. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity. The tools fit into the standard build process as the first tools run and feed the rest of the toolchain. The end result is a standard executable.
to:
* Development tools. They fit into the standard build process as the first tools to run and feed the rest of the toolchain. The end result is a standard executable. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity.
Deleted line 19:
January 25, 2014, at 12:08 PM by 80.114.134.224 -
Changed line 8 from:
* Development tools, which fit into the standard build process. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity. The tools sit at the start of the standard build toolchain, and the end result is a standard executable.
to:
* Development tools. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity. The tools fit into the standard build process as the first tools run and feed the rest of the toolchain. The end result is a standard executable.
Changed lines 10-14 from:
* A deployment tool. The end-user interacts with the tool in order to start execution of their application. The deployment tool sits as an application above the standard Cloud software stack, and employs the API of the stack to dynamically provision machines. The end user supplies an executable, which was previously created using the CloudDSM development tools, and the deployment tool then runs it on the Cloud infrastructure.


The CloudDSM deployment tool is launched as an SaaS application, and appears as a portal on the web. It is itself a Cloud application, that sits on top of whatever Cloud stack the machine Host provider is using. The CloudDSM deployment tool can either be installed by the end user, or we foresee the partner who develops the tool as making a permanent installation available as a service. Either way, once the deployment tool is up and running, then an end-user interacts with it, uploads their executable code to it, and then launches a run of their application.
to:
* A deployment tool. The end-user interacts with the tool in order to start execution of their application. The deployment tool runs as an application inside the standard Cloud software stack, and employs the API of the stack to dynamically provision machines. The end user supplies an executable that was previously created using the CloudDSM development tools, and the deployment tool then runs it on the Cloud infrastructure.


The CloudDSM deployment tool is launched as an SaaS application, and appears as a portal on the web. It is itself a Cloud application, that sits on top of whatever Cloud stack the machine Host provider is using. The CloudDSM deployment tool can either be installed by the end user, or we foresee the partner who develops the tool as making a permanent installation available as a service. Either way, once the deployment tool is up and running, then an end-user interacts with it. They upload their executable code to it, and it then launches a run of their application.
Changed line 19 from:
The one thing the application programmer must do in order to used the CloudDSM system is to include code that divides the work to be performed into pieces, and also makes the data structures, plus the code that accesses them, known to the tools. The project will develop new pragmas for OpenMP that are used for this, and the project includes a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
to:
The one thing the application programmer must do in order to use the CloudDSM system is to include code that divides the work to be performed into pieces, and also to make the data structures, plus the code that accesses them, known to the tools. The project will develop new pragmas for OpenMP that are used for this, and the project includes a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
January 25, 2014, at 11:57 AM by 80.114.134.224 -
Changed line 8 from:
* Development tools, which fit into the standard build process. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity. The tools sit at the start of the standard build toolchain, and the end result is an executable.
to:
* Development tools, which fit into the standard build process. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity. The tools sit at the start of the standard build toolchain, and the end result is a standard executable.
January 25, 2014, at 11:56 AM by 80.114.134.224 -
Changed line 7 from:
* A convenient and productive set of "embedded" languages, systems of pragmas, and language features. The application developer chooses one of these and uses it provide information to the CloudDSM development tools.
to:
* A convenient and productive set of "embedded" languages, systems of pragmas, and language features. The application developer chooses one of these and uses it to provide information to the CloudDSM development tools.
January 25, 2014, at 11:56 AM by 80.114.134.224 -
Changed lines 8-12 from:
* Development tools, which fit into the standard build process. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to make the DSM calls each transfer large chunks of data, so that computation on the data dominates overhead of the DSM activity. The end result is an executable.
* A DSM runtime system that handles machine-to-machine communication during
the run of an application, and handles mapping addresses, so that the same pointers are valid on all machines. The communication and mapping make the collection of Cloud servers appear to the application developer as if they are a single desktop machine.
* A deployment tool that the end-user interacts with in order to start execution of their application
. It sits as an application above the standard Cloud software stack, and employs the API of the stack to dynamically provision machines and to begin execution of the application that was specified by the user on those machines. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the application executable on the Cloud infrastructure.
to:
* Development tools, which fit into the standard build process. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to rearrange code so that the DSM calls each transfer a large chunk of data, so that computation on the data dominates overhead of the DSM activity. The tools sit at the start of the standard build toolchain, and the end result is an executable.
* A DSM runtime system. It handles machine-to-machine communication during the run of an application,
and handles mapping addresses, so that the same pointers are valid on all machines. The communication and mapping make the collection of Cloud servers appear as a single desktop machine, which simplifies application development.
* A deployment tool
. The end-user interacts with the tool in order to start execution of their application. The deployment tool sits as an application above the standard Cloud software stack, and employs the API of the stack to dynamically provision machines. The end user supplies an executable, which was previously created using the CloudDSM development tools, and the deployment tool then runs it on the Cloud infrastructure.
Changed lines 17-19 from:
The application does not include any awareness of the Cloud aspects. Rather, the same executable runs on a desktop the same as on a cluster, the same as on the distributed Cloud (future projects may enable also running on supercomputer and Grid, without changing the source, but may require a recompile in order to let the tools tune the executable to the targer machines. See http://opensourceresearchinstitute.org/pmwiki.php/PRT/HomePage for technology that helps enable this).

The one thing the application must do is include code that divides the work to be performed into pieces, and also make the data structures, plus the code that accesses them, known to the tools. We have included a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
to:
The application does not include any awareness of the Cloud aspects. Rather, the same executable runs on a desktop the same as on a cluster, the same as on the distributed Cloud (future projects may enable also running on supercomputer and Grid, without changing the source, but may require a recompile in order to let the tools tune the executable to the target machines. See http://opensourceresearchinstitute.org/pmwiki.php/PRT/HomePage for technology that helps enable this).

The one thing the application programmer must do in order to used the CloudDSM system is to include code that divides the work to be performed into pieces, and also makes the data structures, plus the code that accesses them, known to the tools. The project will develop new pragmas for OpenMP that are used for this, and the project includes a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
January 25, 2014, at 11:42 AM by 80.114.134.224 -
Changed line 3 from:
The CloudDSM platform consists of two parts:
to:
The CloudDSM platform consists of four parts:
Changed lines 5-7 from:
* Development tools, which are used by the application developer. The application developer uses a convenient and productive "embedded" language, or system of pragmas, which enable compiler tools to transform the code, into a form that is computationally efficient on Cloud servers. Such tools fit into the standard build process. The end result is an executable. These tools will all be open source.
* Deployment tool, which runs as an application on Cloud based servers. An executable
that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the application executable on the Cloud infrastructure.
to:

* A convenient and productive set of "embedded" languages, systems of pragmas, and language features. The application developer chooses one
of these and uses it provide information to the CloudDSM development tools.
* Development tools, which fit into the standard build process. They use the information provided by the pragmas/language-features to transform the code into a form that is highly efficient on the target Cloud machines. Their main task is to make the DSM calls each transfer large chunks of data, so
that computation on the data dominates overhead of the DSM activity. The end result is an executable.
* A DSM runtime system that handles machine-to-machine communication during the run of an application, and handles mapping addresses, so that the same pointers are valid on all machines
. The communication and mapping make the collection of Cloud servers appear to the application developer as if they are a single desktop machine.
* A deployment tool that the end-user interacts with in order to start execution of their application. It sits as an application above the standard Cloud software stack, and employs the API of the stack to dynamically provision machines and to begin execution of the application that was specified by the user on those machines. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the application executable on the Cloud infrastructure.
Changed line 19 from:
The one thing the application must do is include code that divides the work to be performed into pieces, and also make the data structures, plus the code that accesses them, known to the tools. We have included a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
to:
The one thing the application must do is include code that divides the work to be performed into pieces, and also make the data structures, plus the code that accesses them, known to the tools. We have included a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
January 18, 2014, at 01:58 PM by 46.172.218.101 -
January 18, 2014, at 01:57 PM by 46.172.218.101 -
Changed line 6 from:
* Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the executable on the Cloud infrastructure.
to:
* Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the application executable on the Cloud infrastructure.
January 17, 2014, at 09:46 AM by 46.172.218.101 -
Changed lines 3-7 from:
to:
The CloudDSM platform consists of two parts:

* Development tools, which are used by the application developer. The application developer uses a convenient and productive "embedded" language, or system of pragmas, which enable compiler tools to transform the code, into a form that is computationally efficient on Cloud servers. Such tools fit into the standard build process. The end result is an executable. These tools will all be open source.
* Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the executable on the Cloud infrastructure.
Deleted lines 11-15:
In total, the CloudDSM consists of two parts:

* Development tools, which are used by the application developer. The application developer uses a convenient and productive "embedded" language, or system of pragmas, which enable compiler tools to transform the code, into a form that is computationally efficient on Cloud servers. Such tools fit into the standard build process. The end result is an executable. These tools will all be open source.
* Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the executable on the Cloud infrastructure.
January 17, 2014, at 09:45 AM by 46.172.218.101 -
Changed lines 4-6 from:
The CloudDSM deployment tool is launched as an SaaS application, and appears as a portal on the web. It is itself a Cloud application, that sits on top of whatever Cloud stack the machine Host provider is using. The CloudDSM deployment tool can either be installed by the end user, or we foresee the partner who develops the tool as making a permanent installation available as a service. Either way, once the deployment tool is up and running, then an end-user interacts with it, uploads their executable code to it, and then launches a run of their application.

Thus, we have a stack -- end application on top of deployment tool application, on top of Cloud stack.
to:
The CloudDSM deployment tool is launched as an SaaS application, and appears as a portal on the web. It is itself a Cloud application, that sits on top of whatever Cloud stack the machine Host provider is using. The CloudDSM deployment tool can either be installed by the end user, or we foresee the partner who develops the tool as making a permanent installation available as a service. Either way, once the deployment tool is up and running, then an end-user interacts with it, uploads their executable code to it, and then launches a run of their application.

Thus, we have a stack -- end application on top of deployment tool application, on top of Cloud stack.
Changed lines 8-14 from:
In total, the CloudDSM consists of two parts:
1) Development tools, which are used by the
application developer. The application developer uses a convenient and productive "embedded" language, or system of pragmas, which enable compiler tools to transform the code, into a form that is computationally efficient on Cloud servers. Such tools fit into the standard build process. The end result is an executable. These tools will all be open source.
2) Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs
the executable on the Cloud infrastructure.

The application does not include any awareness of the Cloud aspects. Rather, the same executable runs on a desktop the same as on a cluster, the same as on the distributed Cloud (future projects may enable also running on supercomputer and Grid, without changing the source, but may require a recompile in order to let the tools tune the executable to the targer machines. See http://opensourceresearchinstitute.org/pmwiki.php/PRT/HomePage for technology that helps enable this).

The one thing the application must do is include code that divides the work to be performed into pieces, and also make the data structures, plus the code that accesses them, known to the tools. We have included a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
to:
In total, the CloudDSM consists of two parts:

* Development tools, which are used by the application developer. The
application developer uses a convenient and productive "embedded" language, or system of pragmas, which enable compiler tools to transform the code, into a form that is computationally efficient on Cloud servers. Such tools fit into the standard build process. The end result is an executable. These tools will all be open source.
* Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the executable on
the Cloud infrastructure.

The application does not include any awareness of the Cloud aspects. Rather, the same executable runs on a desktop the same as on a cluster, the same as on the distributed Cloud (future projects may enable also running on supercomputer and Grid, without changing the source, but may require a recompile in order to let the tools tune the executable to the targer machines. See http://opensourceresearchinstitute.org/pmwiki.php/PRT/HomePage for technology that helps enable this).

The one thing the application must do is include code that divides the work to be performed into pieces, and also make the data structures, plus the code that accesses them, known to the tools. We have included a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.
January 17, 2014, at 09:44 AM by 46.172.218.101 -
Added line 2:
January 17, 2014, at 09:44 AM by 46.172.218.101 -
Added lines 1-13:
!End user View of CloudDSM

The CloudDSM deployment tool is launched as an SaaS application, and appears as a portal on the web. It is itself a Cloud application, that sits on top of whatever Cloud stack the machine Host provider is using. The CloudDSM deployment tool can either be installed by the end user, or we foresee the partner who develops the tool as making a permanent installation available as a service. Either way, once the deployment tool is up and running, then an end-user interacts with it, uploads their executable code to it, and then launches a run of their application.

Thus, we have a stack -- end application on top of deployment tool application, on top of Cloud stack.

In total, the CloudDSM consists of two parts:
1) Development tools, which are used by the application developer. The application developer uses a convenient and productive "embedded" language, or system of pragmas, which enable compiler tools to transform the code, into a form that is computationally efficient on Cloud servers. Such tools fit into the standard build process. The end result is an executable. These tools will all be open source.
2) Deployment tool, which runs as an application on Cloud based servers. An executable that was previously created using the CloudDSM tools is made available to the deployment tool, which then runs the executable on the Cloud infrastructure.

The application does not include any awareness of the Cloud aspects. Rather, the same executable runs on a desktop the same as on a cluster, the same as on the distributed Cloud (future projects may enable also running on supercomputer and Grid, without changing the source, but may require a recompile in order to let the tools tune the executable to the targer machines. See http://opensourceresearchinstitute.org/pmwiki.php/PRT/HomePage for technology that helps enable this).

The one thing the application must do is include code that divides the work to be performed into pieces, and also make the data structures, plus the code that accesses them, known to the tools. We have included a language, called Reo, that will make this simpler, and also a pattern, called Divider Kernel Undivider. The value of these is that they feed the tools, and the tools then have all they need in order to adapt the code to different machines and deployment technologies.