How does Oslo or DSLs help generate software that exploits parallel execution across multiple cores?

Question

I have heard that DSLs can help ease the generation of software that exploits execution of algorithms across multiple cores.

How does DSL help with this issue?

How can Oslo be used to generate algorithms that can exploit parallel execution across multiple cores?

What features does Oslo have that can aid with parallel execution?

Answer 1

Hi,

That is a very good question. Parallel programming has become a very interesting field in Computer Science these days. IMO, the way to start thinking about how DSLs (either they are built using Oslo or another technology) can contribute to this field, is to first consider the different approachs, cognitive models, underlying parallelism.

For instance, let's think about the Actors model for representing concurrent systems: we'll get a set of tasks, performed by actors, and these tasks will have a set of dependencies on each other, at the same time actors communicate between them by sending messages through channels, etc. You could elaborate on top of that, build your own model and then translate it into an M model. Once you get your own representation of that reality, you could even define an easiest, simplistic, more abstract way to express ideas, sets of tasks, requirements, channels, messages, etc. At this point, we will be getting very close to the world of DSLs. The DSL will provide you the ability to have a concise language, focused on the things that you really care about for your domain, and will even allow domain experts that may not be developers to write down the solution for a problem in a pretty well defined and non-ambiguous way.

I think it is actually a very broad topic to tackle in just one thread (forum thread I mean :P), but you can also check out some incubation projects that use a DSL approach to concurrency models. One of the hottest ones I have recently heard about is Axum (formerly known as Maestro). There are a couple of deep technical videos in Channel 9 about it. I strongly recommend you to take a look at them, they are really didactic.

Regards,
M.

Answer 2

Even expert programmers have difficulty writing correct concurrent software. There are essentially two approaches to solving this problem:

·        Concurrent runtimes that abstract away concurrency issues. For example, SQL Server and BizTalk.

·        Frameworks and language extensions that provide abstractions that are easier to deal with. For example, the concurrency support in the .Net Framework and the abstraction of memory barrier instructions in most programming languages.

DSLs help by allowing you to build special purpose languages over concurrent runtimes and frameworks. These languages succinctly match the semantics of the underlying systems.

So Oslo does not itself help but it is an important part of the solution since it allows the developers of these runtimes and frameworks to create good developer experiences.

Oslo also helps in another way. The really hard problem is cross machine concurrency. How do you mange a network of interconnected machines and applications in a cost efficient way. This is the goal of the repository. Essentially, a store with enough information that impact and root cause analysis is possible. Thus helping to make Microsoft’s DSI vision a reality.

 

Answer 3

Can you provide some example(s) of the concepts and techniques that you mention?

Answer 4

Examples of some of the technologies I am thinking of are:

·         TPL (Task Parallel Library) http://msdn.microsoft.com/en-us/library/dd460717(VS.100).aspx.

·         PLINQ (Parallel LINQ) http://msdn.microsoft.com/en-us/magazine/cc163329.aspx and http://msdn.microsoft.com/en-us/library/dd460688(VS.100).aspx.

·         The Concurrent .Net classes http://msdn.microsoft.com/en-us/library/dd460718(VS.100).aspx.

·         For an example of the strength of DBMS’s implicit parallelism see http://database.cs.brown.edu/sigmod09/benchmarks-sigmod09.pdf.

Answer 5

Can you provide some samples or examples of how Oslo can be used in the manner that you describe?

Answer 6

Don--I just wanted to possibly close this old thread as it's been over a month since the last post. I think the lack of reply indicates that the samples you're looking for aren't forthcoming. I don't know of any myself, so there's nothing concrete here for you.

Generally speaking, though, your question about how "Oslo" might integrate with the technologies that Anthony described is really a matter of how one implements a runtime that executes one's models. "Oslo" itself, so far as I know, doesn't have anything to do with parallel-core technologies. For the most part, its tools are about getting model schema and values into a database, at which point a runtime of some sort works with them.

Of course, at present "Oslo" doesn't come with any runtimes, except to the extent that "Quadrant" can act as such. As an app for viewing and editing data, though, "Quadrant" isn't going to be concerned about parallel processing.

So what this all means is that in the design of a parallel-processing system that utilized "Oslo" modeling technologies, the key work is really left to the developer in (a) how they design and declare the models, (b) how they'd design a DSL to express parallel-processing concepts to populate said model values, and (c) how they implement a runtime that would then take the data in those model values and execute them using one or more of the technologies that Anthony listed.

This is, in essence, what Anthony has said in his prior two posts, and is really all that we can offer on this story at present. If there are specific needs that you feel should be considered, then they should be suggested through the "Oslo" Connect site and worked from there.

.Kraig