OSCON 2008 (Day 1 and 2) - Great Tutorial Sessions

It has been a typical bootstrapping for the first 2 days at OSCON 2008. The tutorial sessions have started as per schedule on the usual low-key note, the irc channels yet to set up the buzz tone and all the pubs yet to get heated up with the latest of the conference musings. For the early comers, this is the time to start getting soaked into the spirit of the conference and build up the setting for the next 3 days of fun, frolic and frenzy.

I had registered for 4 tutorial sessions.

OSCON day 1 for me began with the early registration, the usual conference style breakfast and then a jump into the "Python in 3 hours" tutorial. This session was perfect in setting up the tone for Python non-programmers. The initial part of the tutorial was quite slow paced and focused much more on the basics of programming than what the time demanded. As a result, the tutorial faced lots of time pressure towards the end - hence we missed out on the more Pythonesque stuff that I had expected to see as part of this tutorial. Otherwise, it was managed well, Steve Holden is a nice speaker and had all things under control for tutoring on the basics of a language. It's not always that easy to control the entropy of an audience so varied in profile and skill level while teaching on the basics of a programming language.

The second pick for me was "Memcached and MySQL: Everything You Need to Know", which ended up being a great one for me. Both the speakers had been working on memcached codebase for quite some time, I guess. Hence lots of implementation issues were discussed and sorted out with expected seamlessness. In fact after the tutorial I heard some people complaining about the too-much-implementation-level-detail orientation of the session. I liked it though and it gave pointers to many of the memcached internals viz. memory allocation (slab allocators), consistent hashing (the secret sauce of memcached) and lots of tuning and stats tips.

OSCON day 2 began with the tutorial on "Ubiquitous Multithreading for a Multicore World", where the Intel guys took us through the pains of managing shared state concurrency. They introduced Threading Building Blocks (TBB) that offer parallelism within the C++ programming model. TBB offers a higher level task based parallelism that abstracts platform dependencies and threading implementations away from the programmer. TBB is offered as a library with GPLv2 licensing and comes bundled with lots of C++ compilers today. Being a higher level of abstraction, TBB will make concurrent programming easier in C++ than what it is today. But given the clumsiness and verbosity of C++ syntax, and the emergence of newer languages and concurrency paradigms, I have strong doubts on its acceptability to mainstream development community. One other interesting stuff that the Intel guys discussed was the lambda expression implementation in Intel C++ compiler, also part of the official C++ specification coming soon to an implementation near you. A lambda expression in C++ will have to be implemented as an object, which can contain references to local and global variables of the enclosing context. C++, not being a garbage collected language, needs to implement a copy-semantics for all such context elements. It is not yet clear to me how non-copyable objects will be handled in such cases .. need to look up more for implementation details. Overall the tutorial session was informative and it was good to see C++ getting a facelift through some positive movement forward.

The second tutorial that I attended was "An Introduction to Actors for Performance, Scalability and Resilience", conducted by Steven Parkes. The session began with the discussion of the actor model as implemented in Erlang. Steven was thorough in his exercise of designing real life problems modeled with actor based concurrency, implemented first using Erlang and then in Ruby using Dramatis actor library. A straight mapping of actors to native threads does not scale - Dramatis implementation also does not usually dedicate a thread to an actor. The receive is implicit, much like Erlang/OTP's gen_server, though it was not clear from the discussion regarding the exact payload of the actor model implementation in dynamic OO languages like Ruby and Python. Steven also mentioned that there is nothing implicitly functional about actors and that he chose to implement the imperative way with a nice OO scaffolding around the actor interface. Scala also provides a similar interface of objects with event based implementation - it will be a very interesting exercise to benchmark how much all the actor implementations scale under heavy concurrent throttling. The Erlang implementation still stands out tall and large as far as the seamless distribution and fault tolerance of the actor model is concerned. None of the other implementations can be made to distribute as easily as the Erlang model.