The costs of concurrency and the actor model

I was interested to understand more about how actors are implemented in Erlang. In an old but still relevant article, an argument is raised:

These days every third grader knows that processes are expensive. Ok, so we're not using real processes, we're using threads, but if you constantly create, destroy, and switch between thousands of threads you'll bring any system to a crawl. Threads are expensive for a number of reasons. They take a long time and a lot of memory to create because the operating system needs to set up many things (the stack, internal data structures, etc.) for them to work. They take a long time to destroy because all the resources they consumed need to be freed. And they take a long time to switch between because unloading registers, storing them, loading them back, and flipping the stacks is complicated business.

So how expensive it really is to create a Thread in java these days?

Peter Lawrey, writer of the excellent Vanilla Java blog, tell us that roughly, creating a Thread takes
about 70μ (microseconds), which is fairly expensive, but not prohibitive. The size of the stack can be configured by command line argument to the JVM, with a default of 512kb. According to some Mac OS X 10.5 docs, a thread takes about 90μ, which is kind of validates his results.

As it was pointed out in the StackOverflow discussion

Creating threads is expensive if you're planning on firing 2000 threads per second, every second of your runtime. The JVM is not designed to handle that. If you'll have a couple of stable workers that won't be fired and killed over and over, relax.

This is slightly different in Erlang, where everything is a Process, so the model leads you to that situation.

Essentially, Erlang uses a kind of lightweight processes, akin to green threads (VM scheduled pseudo-threads as opposed to real threads). Since they only consist of a mailbox implemented as a queue, it takes about 300 words to build one, meaning we can create thousands, even millions of them, so the only constrain is memory.

I read a great post on Erlang lightweight-process actor concurrency and it's inherent problems in terms of message passing costs, i.e., having to serialize the entire message between processes, even within the same node. The lack of zero-copy messaging between actors, even within the same node, can really hurt performance. It also talks a great deal on how the BEAM VM and HiPE JIT compiler aren't anywhere near as good as the industry leader JVM (or his favoured Azul Systems "pauseless" VM).

On that basis, after years of hardcore work on Erlang, he decants for Erjang (using Java's Killim actors) or Clojure, possibly
due to been more functional and lisp syntax. I wonder why Scala wasn't mentioned? Akka
offers the same principles of Erlang actors, but implemented in a much more robust way and running on top of the JVM.

Scala actors, particularly Akka actors, use configurableexecutors that efficiently reuse threads (and in Akka 2.0, this will be declaratively configured). Thus, i can see Akka
as supersiding Erlang, an the heir of the throne in actors concurrency.

The art of GC Tuning

Great presentation discussing best practices when tuning Garbage Collection on the JVM

The different GC Collectors:

Fragmented Heap:

See JVM GC tuning docs here

Also, a comparison of all the JVM GC implementations (particularly valuable given that Java8 will incorporate JRockit's features.

I've came across this links by reading the blog post on the new features of Cassandra 1.0. Some very interesting JVM tuning allowed them to increase performance manyfolds.

The JVM JIT compiler at runtime, and even the java and particularly scala compiler at compile time, love small methods that can be analysed in isolation. It is very important to consider the effect that the compiler can have whenever reading microbenchmarks.

Quoting Brian Goetz:

"Often, the way to write fast code in Java applications is to write dumb code -- code that is straightforward, clean, and follows the most obvious object-oriented principles."
Brian Goetz
Technology Evangelist, Sun Microsystems

For huge collections, is better to use a framework that can handle billions of items, potentially mapped outside of the heap, thus avoiding Full GC completely.

Scala Options: Type and Null Safety

Options are great because they allow you to circumvent the $1 billion bug (Hoare).

Several posts discuss the great values of Options. It was Graham Tackley who really made me click when he presented Options as collections with zero or one elements in it.

Yesterday I was trying to make good use of this idea, and came with the problem of how retain only the elements that actually contain a value. Since you cannot call get on a None for obvious reasons, there must be an easy way to retrieve only the values.

Here's what i found:

I've transformed a List[Option[String]] with possible Nones in it, to a List[String].

How about this then?

Which is basically doing the operation that I've just done before, call flatMap(_.toList)

This makes passing around options a really valuable thing, because you have safety in your operations with minimal effort.

Very useful Scala Option cheatlist by Tony Morris

Supporting different paradigms of Parallelism

Doug Lea's keynote in Scala Days is a really interesting presentation.

It shows the importance of multicore, Amdahl's Law and lots more. Well worth it.

Attending the Low latency summit conference in London

I will be attending the Low-Latency Summit 2011 - Winning Strategies for Deploying Low-Latency Technologies. I expect to get a good insight on vendor technologies used for ultra low latency such as Infiniband networks.

Thanks Eleanna for the invite!

Update: Some interesting panels during the event. The low-latency website is probably one of the best takeaways from here. Here's a good summary on classification of sources of latency and suggestions on how to mitigate them.

Also available is this podcast from NASDAQ OMX’s Bjorn Carlson discussed technologies and approaches that are in use today at markets around the world.

Building Scala applications with SBT + Idea

Intellij IDEA is a great tool for Scala Developers. A couple of days ago I attended a great event of the London Scala User Group where, Richard Hallaway, Phill Wills and Maciej did a very good intro to this tool. This guide explains how to quickly leverage a couple of tools to setup a new Scala project in minutes.

First of all, start downloading right now the latest build of Idea X community edition for your platform, this will probably be ready by the time we finish with the setup. You'll also need the Scala and SBT plugin.

There are basically two ways to setup your idea projects with SBT. The first would be using Heiko Seerbergers guide to setup the project from Idea. I prefer to do it the way that Mikko Peltonen suggests... SBT-Idea.

First, you'll need the great SBT (Simple Build Tool), which is a build tool written in Scala and for Scala. Its power lies in that it relies on convention over configuration and giving you full control over your builds. No longer long XML configurations + Shell scripts. SBT can do everything from one single script. Furthermore, builds can pickup only the changes you made, and recompile and run only those tests. Check it out!

After you setup SBT  , create a new project:

sbt

Name:

Organization:

Scala: 2.8.1

sbt: 0.7.4

this will create most of your project.

then exit the console, go to project folder, and create a folder build and inside, a scala file such as this:

Go back to the sbt console, type update, and it will pull the dependencies.

Use the SBT processor as specified here:

> *sbtIdeaRepo at http://mpeltonen.github.com/maven/
 > *idea is com.github.mpeltonen sbt-idea-processor 0.1-SNAPSHOT 
 ...
 > update
 ...
 > idea
 ...

this will create your project. Now, import in IDEA. All your SBT structure will be recognized.

Now let's setup the FSC (Scala Fast Compiler Server). SBT is great for quick reloads, but i still prefer to have fast compilation within the IDE.

For that, just go to Edit Configurations in your run targets in the toolbar, and create a new Scala Compilation Server using the following details. I had issues in the past when ticking the box shared configurations but it probably has been fixed already.

That's all you need ! Super fast compilation within Idea. And remember if you run your commands in sbt with a tilde ~ they will automatically run every time you switch back to the sbt console and it detects a file change.

Finally, don't forget your .gitignore

.idea/
lib_managed/
project/boot/
project/build/target/
target/

Scala 2.8.1 released

Plenty of bug fixes (more than 100 in 3 months!). Great to see a very active community, kicking the tires and gathering to solve problems. Furthermore, It's fully binary compatible with 2.8, which means no need to match library versions as it happened with the RCs for 2.8. Also, the improvements to Scaladocs make it look very snappy

All in all, we can see the the Scala language growing at a fast pace. Many new books are coming, including Phillip Haller's Actors in Scala and three others by Manning "in Action" series. Browse the complete list of books if you are interested.