It’s still a research project at Microsoft and it has recently released a preview version of the framework which is designed to work well with the asynchronous features of the latest .NET CTP.

The goal of the framework is similar to PLinq in the sense that you construct a pipeline composed of blocks expressing individual operation (action, transformation, join, fork, …) with the notable difference that the model is push-based instead of pull-based.

Push-based basically means that, in the same way than the Reactive Extensions, you explicitly feed data to your pipeline instead of acquiring it from a source. Then the final data can be received or processed by a block at the other end of the chain.

All of that makes a nice model for asynchronicity that you can use both to send or receive data thanks to a number of extensions method in the framework (suffixed by Async) which returns a Task thus letting you setup continuations or use the new await keyword (also available in Mono master btw).

Under the hood the framework is built upon what ParallelFx provides like the concurrent collections and the task primitive meaning it’s also taking full advantage of the available parallelism on your machine.

The code is now available directly from Mono master and is built in the System.Threading.Tasks.Dataflow assembly with the 4.0 profile. While not totally complete, it’s still already usable.

MSDN doesn’t yet show the documentation so I uploaded the copy shipped with the preview.

You can also watch Stephen Toub introductory video for a tour of the framework (also embedded below).

It took around 20 years for CPU manufacturers to abandon the GHz war on the desktop and start going multicore.

In the mobile space and only 3 years after the first Android smartphone, we are already seeing dual-cores phones (with quad-cores around the corner). Recent tablets are on the same boat.

The brilliant thing is that with Monodroid and Monotouch, we have the possibility to harness this new found processing power today using all the existing ParallelFx constructs since they are part of both distributions (i.e. Tasks, continuations, parallel loops, PLinq and friends).

To illustrate that, I ported the now classic raytracer code from the Parallel sample gallery to Android using Monodroid. Code is on GitHub if you want to give it a spin.

While the application itself is painfully slow since all rendering is in software, it does exhibit the same speed improvement when you ran in parallel mode as with the desktop version on my dual-core smartphone. For iDevices lovers, Geoff also had a similar version running on an iPad 2.

If you are at Monospace and want to talk about that stuff (and ParallelFx in general), don’t hesitate to come and say hi. Anyhow, I’ll continue to post more examples of how you can use ParallelFx practically in your mobile apps.

PS: as you’ll see in the source, there are some hacks bundled because of a couple of Mono bugs but they will get fixed eventually.

Initial efforts have been devoted to integrate patches that had been lying around for some time but never actually got released in a proper way causing some projects to bundle a modified ndesk-dbus source tree in their codebase.

As part of the fork process, we have moved all the relevant project infrastructure over to GitHub including source code, website, tarball downloads and bug tracking.

As stated in the release notes, all the dbus-sharp component are parallel installable with the original ndesk-dbus ones and can co-exist happily. In addition, we made sure the porting effort required to move an existing application to use dbus-sharp instead of ndesk-dbus was reduced to a minimum.

For future work, we are going to continue cleaning and refactoring the binding, improve its test suite and of course add new features so stay tuned!

You can directly jump to the release notes for all the details on how to get dbus-sharp and how to use it.

One of the cool buzzword these days beside parallel computing is GPGPU as in General Purpose GPU.

The base idea of GPGPU is to allow a programmer to tape in the parallel processing capacities of a GPU to do something different than pixel crushing (even though it mostly boils down to that very application most of time).

GPGPU isn’t new and for a long time vendors have provided their own rather low-level toolkit to program arbitrarily a GPU. As often, someone stepped up one day and proposed a unified API on top of all the vendor specificities. In our case, that API is a standard defined by the Khronos group (think OpenGL) and is named OpenCL.

OpenCL defines both a high-level C API to manipulate GPU (plus other friends) and a C-like intermediate language that is compiled and ultimately run on the device. It’s actually the same model as shader programming.

In the pursuit of Mono world-domination and following the implementation of PLinq that strived to be an easy way for programmer to access the multicore architecture of our processors via Linq, I hereby introduce GLinq (unoriginal acronym for GPU Linq) which this time use your graphic card to execute Linq queries via OpenCL.

GLinq is still much in its infancy and currently only support the Linq’s Select operator but I hope to be able to implement several other operators (at least the classic Where-Aggregate combo). The end goal is also to provide a new set of operator to allow OpenGL code to access the results of the computation without doing a roundtrip between CPU and GPU.

As I said previously, GLinq has the same design goal as PLinq which was to provide a totally new execution model for programmer in the most transparent way possible and with little modification to existing code. In our case, this prerequisite is rather tricky since you are juggling between two totally different worlds.

GLinq tries to provide that seamless experience with two features. The first one is the use of expression trees and C# compiler lambda magic to automatically capture the sense of a C# expression and rewrite it to OpenCL intermediate language. The second one is an automatic mapping of C# types and methods (e.g. Math class functions) to corresponding OpenCL symbols without however sacrificing OpenCL specificities which are also exposed through a C# API (not complete).

Of course, the GLinq API is still a transcription of standard Linq so you use it in the same way via the GpuEnumerable class. At the moment, the only input support are Range and Repeat but that will easily be changed to support any kind of IEnumerable.

Below is an example of the kind of query you can already execute:

var query = GpuEnumerable.Range (-20, 50)
			 .Select ((i) => i * -2 + 3)
			 .Select ((i) => Math.Abs (i))
			 .Select ((i) => ExtraMath.Ldexp ((float)i, 2f))
			 .Select ((i) => (int)i);

foreach (var i in query)
	Console.Write ("{0}, ", i.ToString ());

From what you can see, there are a lot of select operators here. It comes from the fact that the compiler is only able to convert a pure expression lambda to its corresponding expression tree. You can circumvent this limitation by building yourself the expression tree or by using any compiler/interpreter that outputs expression trees (e.g. IronPython, IronRuby, Bechamel).

On a final note, there is an acknowledged bug in at least NVidia implementation of OpenCL which makes Mono doesn’t play nice with it. This is due to the fact that (most) OpenCL implementations use LLVM for code generation/optimization which in turns mess with Mono internal working.

This problem is going to be fixed in the next NVidia driver iteration but as a work-around you can apply this simple patch to mono. I put SIGWINCHSIGXFSZ there because it looks cool and seems generally unused but any other should do the trick.

Code in its proof-of-concept form is living here: http://git.neteril.org/glinq/

I’m proud to announce the next release of Zencomic, the comic strip-driven productivity enhancer that periodically makes your day funnier by showing comic like Dilbert or XKCD in a bubble.

New stuff

This release packs a fair number of internal change, UI polishing and a good deal of new comic providers for your pleasure.

Comic backends

Among comic newcomers, you will find Trollcats joining their lolz counterparts and the duo Garfield and Garfield Minus Garfield (contributed by Alan Mc Govern) for even more fluffy fun (or not).

Welcome to the laziest cat on Earth

Cosmetic changes

In Window mode, the comic are now correctly resized to take reasonable space on your screen. A link to the original strip is also supplied at the bottom of the window.

The preferences panel has been overhauled to be less cluttered and provide direct management of comic addins in the UI. It’s also now hopefully completely WM proof when it comes to showing up focused.

Loaded addins configuration

Misc

• Comic are shuffled randomly and served in a round-robin fashion to avoid duplicate fun
• Zencomic haz a new icon
• Repository has been autotool-ified so that you can directly and easily build from git master
• Refactorised addin code

New icon with my poor artistic foo

Download

Tarball: http://neteril.org/projects/zencomic/zencomic-0.3.tar.gz
Git repository: http://git.neteril.org/zencomic/

Cheers!

If you are using Wicd and usually stare at Banshee trying to download cover art or post to last.fm while you are disconnected, the following patch add just the support to fix this.

Here is the associated bug report to get the patch integrated.

In other news, school restarted with its bunch of new responsibilities, limiting significantly free hacking time.

• Use an indexed data structure as your source like an array, a list or anything which implements the generic IList<T> interface.

  You can also use ParallelEnumerable.Repeat and ParallelEnumerable.Range as input. Notice the ‘Parallel’ word in front as it’s not the same as Enumerable.(Range|Repeat)

• Never use an ordering operator like OrderBy and never assume that the query should be ordered.

  The overloads of some operator that provide an index integer are also to avoid.

• As a general rule, try to stick to the general scheme of Select-Where-Aggregate with any number of Select and Where (like the famous MapReduce).

  The syntactic sugar operators based on Aggregate like Min, Max, Average, etc… can also be used.

• If you can manage it in your code, use the ForAll method with an action delegate instead of iterating over the query with foreach

• Of course, forbid any synchronization (locks, semaphore, …) inside the operator selectors/predicates. The purest your lambdas are, the better.

• The functions used with operators should be predictive and stable i.e. not depend on something uncertain time-wise like a network call and should yield approximately the same execution time with each input.

  Sure, this is not always possible but if it is, it does prevent the engine from having to repeatedly balance the query execution itself.

The PLinq MSDN page contains some additional tricks and explanations if you are interested.

Check out the following message on Moonlight mailing-list for instructions on how to get the same thing.

Just to make you salivate :

www.youtube.com/watch?v=Ekfb6jCyDmM

Two hacking days later, I actually got something to « work ». At the moment it’s quite rough, hacky and it probably kills kitteh too (be careful, it makes shana angry, you wouldn’t like that).

Basically, what I did is to plug the OpenVG layer inside Moonlight custom version of cairo (using that code as a base) and then tweaked Moonlight to use the new surface (together with some changes in how drawing and caching is done internally).

Following is a screencast of the thing running Bubble Mark :

www.youtube.com/watch?v=dywInr08ySg

As you can see there are a lot of drawing issues remaining but the basic stuff is here. The code is not terribly faster (+10 fps or so) but that may come either from a bug in my graphic card driver (it already does the bizarre thing of slowing down after some time) or an other part of Moonlight.

It will definitely be better when OpenVG becomes more widespread, has more optimized implementations and can actually run on its own rather than on top of OpenGL (I’m eager to try that on top of Gallium3D when it will be ready).

As for inclusion in the mainline tree, I don’t know. I mostly did the thing for fun as a proof-of-concept and it’s certainly far too crappy to ever get integrated as is, but maybe someone will step up and do it correctly later .