Comment Feed for Parallel Computing Platform: Asynchronous Agents for Native Code (Charles on Channel 9)

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

Richard — Wed, 19 Nov 2008 03:54:24 GMT

Hi, really enjoyed the video(s).

I don't generally code in C++ as such, I was just wanting to clear up a couple of questions.

In the video you mentioned that pointers should be discarded as soon as they are passed on to the next agent, and in one of the examples given for an x MB image file the pointer would be handed off from one to the next, and discarded en-route. Where does the responsibility lie for releasing the storage pointed to by the pointer?

You have based this on the dataflow model of computation. Yes?
If so, and this is sort of related to the previous topic, what would be the best approach for handling persistent storage, and/or shared memory?

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

Rick Molloy — Thu, 23 Oct 2008 14:28:33 GMT

A couple of quick responses here.

Craig, OpenMP can be a quick way to get started today. Particularly if all you are looking to parallelize a for loop (make sure you look at the different scheduling options in particular 'dynamic').

WRT to UI threads (or other) threads, the runtime doesn't do anything special for threads it doesn't know about which means that the OS will round-robin those threads with the other running threads on the system. There are some knobs in the runtime which we'll probably discuss at a later which can be used to be more particular with the scheduler and UI threasd. I'll also try to get a blog post up in the next week or so to talk about the message blocks in more detail and I'll probably mention communicating with UI threads at that point.

Jan,
You asked 'will I get into trouble if I call into legacy code' that used traditional threading constructs like mutexes and critical sections. If by trouble, you mean things like deadlocks, it is possible to get into trouble, but it's also possible to avoid it. You would need to take some care to ensure that thisinteraction works well and you aren't creating a deadlock or livelock.

The message blocks (particularly call and tranform) mentioned in the video aren't re-entrant, which can be great at helping correctness, so if I have a pipeline or network built up of a series of transforms there's only going to be one instance of each stage of that pipleine running by-default, though they can all be active at the same time. However if as you mentioned you're interacting with legacy code in each stage that is taking locks, there may be a chance of deadlock.

Regardin erlang, this is still a C++ library so the language constraints of C++ will still apply. However as we mentioned, the message blocks provide a certain degree of ordering and for 'call' and 'transform' they aren't re-entrant. We'll also make copies of messages between blocks. As I'm sure Niklas mentioned, it's possible to get yourself into trouble if you're passing pointers around, but it's also very possible to avoid a lot of trouble by following best practices.

Re: Re: Parallel Computing Platform: Asynchronous Agents for Native Code

jan.devaan — Mon, 20 Oct 2008 22:11:06 GMT

[after watching the full video]

Ah, Erlang is mentioned near the end. Would still like to know which constraints are same or different as compared to erlang....

One more thing. Will I get into trouble if I call into legacy code that uses traditional threading constructs like mutexes and critical sections?

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

jan.devaan — Mon, 20 Oct 2008 21:53:49 GMT

Sounds like a cool addition for C++.

Sounds similar to the Erlang actor based programming model. Although I think the Erlang model is more restrictive.

Do I understand correctly that Actors are not reentrant (so no other messages are handled during a blocking receive)?

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

Craig Lane — Mon, 20 Oct 2008 00:52:36 GMT

Thanks Rick, We have started using OpenMP so it is good to hear both technologies will work togeather. OpenMP seems like a good quick way of getting parallization into existing applications. With future work getting done in future when the Concurrecy Runtime gets released, isolating tasks as you suggested.

One other question you might to able to answer for me is what impact the Concurrency Runtime will have on UI threads. Will there be any features that will aid the Concurrency Runtime in communicating with windows/controls ect. With OpenMP we have few issues when we need to communicate with the UI.

Re: Re: Parallel Computing Platform: Asynchronous Agents for Native Code

mwirth — Sat, 18 Oct 2008 01:56:36 GMT

Thanks for your reply, Rick! This all sounds very nice. im just trying to compare your system with what others came up with. i just like it when COM isn't involved because sometimes on compilers other than msvc this isnt the most of joy.
also things like supporting allocators (e.g. 16 byte aligned allocators) wouldnt be the worst thing to have these days. but, i dont want to annoy you with that any further. it's just the things i 'd be looking for when choosing between the ms falvor and competitors'.
cheers,
martin
btw. bleed is really great stuff.

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

Rick Molloy — Sat, 18 Oct 2008 00:04:54 GMT

mwirth,

Much of the functionality we’ve talked about in the Asynchronous Agents Library and the Parallel Pattern Library in these past 2 videos is implemented as template classes and methods in header files; they aren’t policy driven template classes, but they also don’t require you to implement a COM interface either to use them. The Agents & Parallel Pattern Library (PPL) are built on top of the Concurrency Runtime itself, which will likely have some significant non-template code (e.g. compiled binary).

CraigL,

Regarding OpenMP: Agents and the PPL are not necessarily a replacement for OpenMP, consider them library based alternatives. The Agents library in particular is orthogonal in the scenarios it addresses to what’s provided in OpenMP. We haven’t announced any ship or product dates for the work that we’ve discussed in these two videos or on our blog at http://blogs.msdn.com/nativeconcurrency so when folks ask what to do in the interim in C++, I’ll tend to suggest looking at what’s available right now like OpenMP if it fits the pattern. The other forward looking guidance that can serve is to start preparing by decomposing applications now into isolated tasks and components that minimize shared state to avoid those pesky correctness issues when you go to parallelize them.

Hope this helps,

Rick

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

Craig Lane — Fri, 17 Oct 2008 02:02:16 GMT

Will this new technology be a replacement for OpenMP? What will the future support be like for OpenMP? Some comments on what users should do in the interim before the release of the currency runtime would be appreciated.

Re: Parallel Computing Platform: Asynchronous Agents for Native Code

mwirth — Fri, 17 Oct 2008 00:28:26 GMT

Nice! another c++ video! always appreciated!
There's one question that i think has not been asked yet (well.. there are more i guess): what form does that new c++ concurrency runtime take? i mean.. this all could be done as a pure header-only c++ library thats mainly driven by policy classes. is it "just" that (which i would always prefer) or is there some COM underneath? things like IAgent? (hope not ! :D)

anyways! i think this is a very good approach, i just hope that the underlying machinery is not too heavy (something i've to install on a client machine via msi/msm for instance?).

i hope you can understand what im trying to get at ;) i just have the fear that there's people out there who would do this sort of thing as a header-only library thats included into every module.. and there might be a really heavy-weight approach with COM, libraries, dlls, versioning and whatnot.

on which side are you? :D

cheers!
martin