Axum Published! Tutorial: Building your first Axum application (Channel 9)

Axum Published! Tutorial: Building your first Axum application

Posted: May 07, 2009 at 10:45 AM

By: Charles

(1)

44,988 Views

9 Comments

5 minutes, 19 seconds

Download

Right click “Save as…”

High Quality WMV (PC, Xbox, MCE)
MP3 (Audio only)
MP4 (iPod, Zune HD)
Mid Quality WMV (Lo-band, Mobile)
MP4 (iPod, Zune HD)

format
< > embed
+ queue

Sign In first to access your queue.
Close

Sorry, video was not added to the queue, an error occurred. Please Contact Us and let us know.
Close

Embed code for this video

Copy the code above to embed our video on your website/blog.

Video format

Auto
Use our suggested format for this video.
Smooth Streaming
Adaptive bitrate streaming - little buffering but lower video quality at times of low bandwidth.
Progressive
Traditional buffered video format.
HTML5
For browsers that support h264 MP4 or WebM video playback such as:
IE9+, Chrome 5+, or Safari 4+.

Note: These selections will fall back to the next best format depending upon browser capability.

Not familiar with Axum? Here's a C9 interview with the Axum team to refresh your memory (it's a domain specific language for concurrent programming, formerly known as "Maestro", developed by the Parallel Computing Platform team).

Here, Axum PM Josh Phillips walks us through building a simple Axum application in just over 5 minutes. Josh builds a simple “math library” on agents and shows how easy it is with Axum to focus on your code and get parallelism and safety implicitly.

Axum Team Blog: http://blogs.msdn.com/maestroteam

-->Get Axum<--

This is pretty cool, but I think the semantics are overly complicated. I couldn't say that I know of a better way of doing it off hand, but I feel that there *must* be some way of making this simpler. As it stands writing agents still seems to be quite painful and clumsy, and something you would avoid doing up front, and instead do as an afterthought once you realise you need it. I think it's critical that writing agents should be as "light weight" as possible so that people write *all* their code using agents not because they necessarily believe they need them, but because they're the most convenient way of getting stuff done even when running on a single-threaded machine.

For example, there seems to be two main ways of interacting with an agent, either by just passing messages and reading from the channels, or by using request-reply ports if you want to be able to send off multiple requests and then get the reponse back while keeping track of which response belongs to which request. It seems to me that this duplication is unecessary. If you want to send multiple requests couldn't you just be required to use multiple agents, one for each "transaction" (associating a result with a given request is then trivial)? If they need to share state you could use a domain, right? I've only briefly looked at it but it does seem that the request-reply ports just complicate things and aren't actually necessary.

Also, I think first-class tuples will be very important for this, as you tend to want to make quick ad-hoc groupings of data all the time when sending and receiving messages.

The semantics and syntax of this needs to be simplified a lot to make it easier to use, it still seems that you spend far too much time and screen real-estate dealing with the details of coordination, rather than your algorithm.

Follow the Discussion

Subscribe to these comments

Kamujin

May 07, 2009 at 4:48 PM quote reply

This is completely disappointing.

public static int Add(int x, int y)
{
return x + y;
}

is as concurrency safe as this example.

Show me an example that's hard to do with current tools.
phillips.josh

May 07, 2009 at 7:37 PM quote reply

Hey Kamujin,

Thanks for the feedback. This example was meant to be a five-minutes-or-less taste of what Axum looks like. It's pretty difficult to show any complex concurrency in 5 minutes. Keep your eyes peeled though. They'll be much more coming in the complex department. Networks in Axum will rock your world.

Josh
Axum Team
Kamujin

May 08, 2009 at 2:06 PM quote reply

Please don't take me the wrong way. I am excited to see where this is going.

I am particularly curious about how chatty you can get with these agents before latency suffers. I am also curious to know how much memory allocation is going on behind the scenes to services the agents.

If I was overly critical in my first comment, it comes from prior experience where the examples made a language/tool look really simple. Then as soon as you apply it to a real world problem, the kludge, scaffolding, and other gotchas show their head. Haskell being my most recent disappointment.

I don't mean to suggest that this will be the case with Axum. I am simply curious to see something less trivial.
Charles Welcome Change

May 08, 2009 at 5:03 PM quote reply

I'd recommend that you grab the bits and push Axum to the limit. Then, you accomplish two things:

1) You learn how well Axum can scale to complex concurrent problems (that are realistic in context)
2) You are equipped to provide the Axum team with excellent technical feedback that they can use in evolving the technology

It seems to me that you care, and that's awesome. Code on.

C
NiklasG

May 08, 2009 at 5:33 PM quote reply

Kamujin,

I suggest installing the bits and trying some of the samples, which are still meant to be educational rather than realistic.

The messaging overhead is comparable to Erlang, while the memory pressure per agent is close, but not yet close enough to make me happy. Compared threads, the cost per agent is about 0.001 of what a thread requires, as long as you place receives in asynchronous methods (see the WebFetcher sample).

And, unlike some other technoligies that may have disappointed you in the past, we're actively looking for your input. That's why we're getting Axum out there before it's completely baked.
tarlano

May 09, 2009 at 1:33 AM quote reply

Thanks for the bits..

I must say your implementation of channels reminds me of Phil Winterbottom's channels from the old days of playing with Alef and Limbo. Were you guys influenced by either Limbo or Alef?

Regards,

Anthony
sylvan

May 09, 2009 at 4:28 AM quote reply

This is pretty cool, but I think the semantics are overly complicated. I couldn't say that I know of a better way of doing it off hand, but I feel that there *must* be some way of making this simpler. As it stands writing agents still seems to be quite painful and clumsy, and something you would avoid doing up front, and instead do as an afterthought once you realise you need it. I think it's critical that writing agents should be as "light weight" as possible so that people write *all* their code using agents not because they necessarily believe they need them, but because they're the most convenient way of getting stuff done even when running on a single-threaded machine.

For example, there seems to be two main ways of interacting with an agent, either by just passing messages and reading from the channels, or by using request-reply ports if you want to be able to send off multiple requests and then get the reponse back while keeping track of which response belongs to which request. It seems to me that this duplication is unecessary. If you want to send multiple requests couldn't you just be required to use multiple agents, one for each "transaction" (associating a result with a given request is then trivial)? If they need to share state you could use a domain, right? I've only briefly looked at it but it does seem that the request-reply ports just complicate things and aren't actually necessary.

Also, I think first-class tuples will be very important for this, as you tend to want to make quick ad-hoc groupings of data all the time when sending and receiving messages.

The semantics and syntax of this needs to be simplified a lot to make it easier to use, it still seems that you spend far too much time and screen real-estate dealing with the details of coordination, rather than your algorithm.
NiklasG

May 09, 2009 at 12:42 PM quote reply

Sylvan,

This is such a great and insightful piece of feedback that I now feel inspired to write something up on the Axum blog to elaborate on our thoughts on these topics. I was hoping to not work this weekend, but it will be hard to keep myself from writing something. Please look for something later, possibly before Monday morning.

Niklas Gustafsson
Mott

May 11, 2009 at 9:49 AM quote reply

Axum seems really cool. I've downloaded the CTP and plan to play with it. It reminds me of a model I use often where I create a C# class, create an object from it and pass it all of the important information, and then call a Start method on it to tell it to do its work in a BackgroundWorker. Then it fires an event when it's done. At first glance, the Axum concepts seem pretty similar, but it removes some of the boilerplate coding I do as far as managing a BackgroundWorker and creating and handling events. It would be nice if it can reduce the headache of marshalling events to the UI thread as well.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.