Parallel Computing Runtime for Microsoft .NET Framework

Short Description
The .NET Framework offers comprehensive and flexible thread APIs that allow the efficient implementation of multithreaded applications. These APIs can, however, only be utilized within Symmetric Multiprocessors (SMPs), which have a very limited scalability. For larger systems, which are in the PC world mostly represented as clusters of SMPs, other paradigms like message passing or handcrafted hybrid systems have to be used. These approaches are generally more difficult to program and require major code changes compared to sequential codes. This paper presents an extension to the .NET Framework, which implements the concept of automatic dynamic parallelization of programs. The extension provides both ease-of-use and scalability in development of parallel programs. This drastically eases the use of clusters and opens cluster architectures to a whole range of new potential users and applications.

Website: skif.pereslavl.ru | Filesize: 211kb
No of Page(s): 5

Content
…
The idea to use functional programming features for parallel computations is old enough. The most important of these features is the fact that functions without side effects can be computed in arbitrary order, so a programmer is freed of a number of problems connected to computations synchronization. However, there is no program architecture that is generic enough, and the advantages of functional approach are compensated by programming style limitations which often are hardly compatible with traditional imperative programming languages. That is why a pure parallel graph reduction is primarily used for implementation of functional programming languages [Gph00a].
The T-system has variables, more over the body of each T-function can be written using imperative programming paradigm (this is one of the main advantages of the T-system that allows to combine a global parallelism with a local performance and ease of implementation of separate functions). On the Tfunctions level we have pure functional paradigm. Since these different programming styles (one of which has immutable data and in the other data can change) join on the T-functions interaction level, it is logical to suppose that the data that exist on the joint of these two styles will change for one of them and will look immutable (be implicitly fixed) for the other.
…

Get the file Download here