After much RSS problems (and there are still some in fact), I’m now on Monologue. Thanks to Miguel and Michael for adding me :) .

Now for the usual presentation : my name is Jérémie Laval, I’m a french student participating in this year edition of Google Summer of Code for the Mono Project. The detail of my submission can be found in an older blog post.

To summarize, I’m doing an open-source implementation of ParallelFx, a framework designed to ease the development of parallel application on CLR platform. You can see the current results of my work here and here.

Apart from Mono and Summer of Code, I’m also working on two pet projects : D-Bus Explorer and Circ.

Finally, for more general informations, you can take a look at my “About” page.

So, as I said previously, I went to Google Zurich last Thursday. It was really fun, I indeed met a cool bunch of people and GSoC colleagues. It was really interesting to discuss with Petr (gda2tiles), Peter (Mercurial mentor), Arthur (aptitude-gtk) and the physicist guy whose name I forgot (so sorry :P ). By the way, thanks a ton to him for the laptop lend ;) .

My presentation went smoothly and people seemed interested (you can’t really tell for sure :) ). At least it sparkled some interesting questions. If you want the slides here they are : ParallelFx presentation. The other talks were both diverse and interesting too.

Of course, Google in itself was a blast. Unfortunately I had to catch the train so I wasn’t able to visit the whole building like the others but, even with the short glimpse I had, I’m pretty sure it must be fun to work at Google ;) . Still, I managed to retrieve a nice-looking Google tee-shirt. It’s rather funny to see that GSoC is the way to go if you want to freshen up your clothes stock ;) .

This weekend I played with the Microsoft ParallelFx CTP’s samples, adapting and running them on current Mono ParallelFx implementation. I’m going to show you two of them and the results. I used the same computer than previously for running the samples.

Image Colorizer

The first one is an image colorizer. For the test, I used a .jpg file weighting 8,3 Mio and containing 13273085 pixels (4207×3155). The result of the processing is below :

For the same color region, the parallel-enabled processing was 1.77x faster than the synchronous one (parallel time : 4.3368363s, non-parallel time : 7.6746839s).

As can be seen on the two following cpu graphs, the parallel version take advantages of both core in my CPU :

(Parallel version running)


(Non-parallel version running)

Benchmark sample

The second sample is a benchmark program containing a bunch of test. Each test uses one of the available API in ParallelFx. For the run, I enabled the 3 following benchmarks :

  • Matrix multiplication : two random-filled matrix are multiplied together. Both are 500 by 500 matrix.
  • Tree sum : all nodes of a binary-tree are added together. I set tree depth to 24 and each node’s value was randomly chosen.
  • Searching : a random word is searched among all files present in a directory. I used a novel with each chapter split in a distinct .html file. The content of the directory was duplicated so that its total size was 12,6 Mio.

Each of these tests were run 7 times by the program and the time given back was the average of each run with the two extreme values being removed. Following are the results with, in parentheses, the ParallelFx API used by the test.

  • Matrix multiplication : 2,25x speedup (Parallel.For).
  • Tree sum : 1,58x speedup (Future).
  • Searching : 1,37x speedup (Parallel.ForEach).

Conclusion

So we can see that ParallelFx always provide a boost but that the overall improvement seems to depend on the component used and how it is used. It would be interesting to compare these results with the ones yielded by Microsoft implementation and by the Mono implementation but running on .NET. I will probably do that at the end of GSoC as a conclusion of the work put during the summer ;) .

In addition these samples showed some bugs. Indeed, I had to disable two tests in the benchmark sample because one of them returned different results between parallel/non-parallel version and the other was causing a stack overflow in Mono runtime (I still need to find out if it’s Mono fault or mine).

Damned exceptions that are not propagated through threads…

Tomorrow I will attend GSoC Jam at Google office in Zurich. Looking forward to meet a cool bunch of people :) .

Normally, I will also give a lightning talk about ParallelFX and its current status during the meetup so if you are interested be sure to come by ;) (registration page given in the above link).

I think I pretty much arrived to the point where my work is starting to get useful. With yesterday basic Tasks implementation and today Parallel.For work I was able to run a parallelized version of Luke’s C# RayTracer. There was already a version using ParallelFx in the CTP samples but I preferred to made my custom, simpler one :

After some micro-benchmarking on my dual-core system the overall speed improvement is around 42%. Deductively it should be 50% but due to the work-stealing algorithm overhead it’s a little less. Still it’s a good improvement over the classic and synchronous version.

Like the folks at the ParallelFx blog did I added some color mask to show which thread was doing the work :

As we can see the work is almost homogeneous between each of the processor. The small delta is explained by the fact that while one of the thread is in the middle of queuing all the work, the other is already processing it.

The code for the parallel ray tracer is here : http://monoport.com/25053. If you want to test it out grab a copy of the source from here in addition (warning : it’s probably full of bugs and won’t work on your system ;) ). Run the program with --thread-mask for the color mask.

So guess my surprise when the postman brought me yesterday a box with “Novell” and “Promotional Tee-shirt” written on it :) :


(Hehe, I’m so grim faced on this one :P )

Now I can hack away with all the goodies and a Rupert boss watching over me :


(When will it be able to bark “wake up”, “idiot”, “stop coding with your foot” like a real boss ?)

All of this thanks to über shana (who deserved to be a cited ™ person ;) ).

LE03 - Admis(A)
LO11 - Admis (A)
MT12 - Admis (D)
PH01 - Admis (C)
PS11 - Admis (E)
ST10 - Admis (D)
TN21 - Refusé (F)

Petit commentaire:

  • LE03 : UV d’anglais de niveau 3, le niveau minimum à avoir dans une des 3 langues principales de l’UTBM pour être admissible au diplôme. TP et TD intéressants (séance de préparation au TOEIC ennuyeuse par contre). Il devait me manquer 5 points pour passer l’UV après le médian donc normalement je devrai l’avoir sans trop de problème :) . J’ai également eu 960 au TOEIC donc pas de problème de ce côté là non plus.
  • LO11 :De l’algorithmie de base à la fois en C et en pseudo-langage. Globalement facile si on a l’habitude mais pas trop quand même car les profs sont du genre à barrer tout ce qui n’est pas identique à leur correction (diff | wc -l quoi). Leur style d’écriture C est amha déplorable et certain choix d’enseignement (ex : tableau sans pointeur) assez discutable. Au niveau de l’intérêt je ne peux parler que du TP où les 3-4 exos de fin sont assez sympa.
  • MT12 :Suite logique avec MT11 avec de l’algèbre au début, la continuation des matrices et des applications linéaires. Saupoudrez avec un peu d’équation différentielle et vous avez une UV parfois dur mais globalement intéressante.
  • PH01 : Petite surprise du semestre. Vu mon attrait pour la philo je pensais que ça allait être chiant à mourir mais finalement la plupart du temps c’était pas mal (faut pas abuser quand même :p ). J’ai bien aimé les parties sur Machiavel, Descartes et Foucault personnellement. Le prof est vraiment génial et c’est un plaisir de le voir faire le pitre en cours. Globalement un des seuls défauts c’est d’avoir 3h de cours à la suite.
  • PS11 :Optique et mécanique du point. Première partie peu intéressant selon moi qui est cependant rehaussé par la deuxième moitié. Néanmoins tout est gâché par l’intervenant qui fait le cours et qui ne donne vraiment pas envie de venir (à l’écouter on préférerait plutôt être dans un vrai lit que dans un siège pour dormir). Par contre on a eu la chance d’avoir un prof vraiment très intéressant en TD pour la partie mécanique (plein de petite digression fort sympathique durant les 2 heures et globalement une envie de vouloir nous faire comprendre pourquoi on faisait de la mécanique).
  • ST10 : Le résultat du stage que j’ai fait au premier semestre. No comment, je l’ai c’est le principal.
  • TN21 : UV obligatoire (sinon elle ne serait pas dans la liste) de dessin technique sur plan et sous Catia. Compréhension de plan, recherche de solution technique, farcissage de tableau de norme en tout genre… je vais laisser les gens intéressés (ce qui n’est pas mon cas) en parler.

Je mettrai à jour demain (normalement) les derniers résultats.Et voilà les deux derniers sans surprise mais si je suis soulagé pour PS11 :) .

Long time I hadn’t hacked on DBus-Explorer but as a exam stress killer I brought together all the piece I had already randomly coded. This resulted in a number of appreciable improvements that were long overdue like :

Tabbed browsing :

Good if you get lost like me with multiple DBus-Explorer windows (Ctrl+T to open and tab button to close, who say Firefox ?).

Multiple (possible) languages :



Just write a definition file like the one in the screenshot and drop it in ~/.dbus-explorer/langs, “possible” because I was too lazy to write another language than C# :P .

Stubs autogeneration :



For use with library like Managed D-Bus, yay \o/ .

There has also been work on the UI and other bugfixes but nothing major. All in one I think DBus-Explorer kept its KISS nature together with the few extra features it was missing. Now I just need to add dialogs for managing language definitions and stub generators in a friendly way.

Hot stuff to be grabbed on git at the usual place.

Even though GSoC coding period started two weeks ago, I totally forgot to blog about it so here it is.

First week started very slowly as I had a bunch of school exams to take care of. During that time I set up a Windows VM to play with the library and wrote a first batch of stubs with some simple logic (getter and setter for instance).

This week was much more interesting because of two things : the Google Code Camp at my school and the ParallelFX’s team releasing a new CTP (beta) of the library. GCC was an event organized at my school by sam and Dave. The concept was simple : gather some geeks together in a big place for the night, with pizza and big amount of coffee/DarkDog, courtesy of Google, to hack on what we wanted. The association of these two events resulted in some productive things done.

At first I had planned to start the Scheduler part but with the new release (and thus the API additions) I preferred to stub/code the new parts like System.Threading.Collections which contains lock-free implementations of stack and queue, SpinWait/SpinLock which, as the name implies, provide locking facilities based on processor spinning and LazyInit/WriteOnce which, respectively, allows lazy evaluation of expression and readonly-like variable (which can be be set only one time and anytime). I pushed these changes this morning, together with a start of unit tests, in the Mono SoC repository.

The next three weeks will be at a slow pace as I have to prepare school stuff and my final exams in two weeks.