Code Monkeyism

Programming is hard by Stephan Schmidt

June 21, 2008

Interesting picture: Benchmarking Erlang versus Java concurrency

I stumbled upon a nice Java framework called Kilim. It implements message passing in Java and it’s interesting to compare to Erlang:

kilim.gif

As I’ve said before, usually comparing Java to Erlang is stupid, because it compares threads to actors, not Java to Erlang. Comparing actors in Java to actors in Erlang is the right thing to do. Also see Scala (Which I don’t use because it won’t make it into the enterprise and I don’t like a type-inferencing language).

About the author: Stephan Schmidt is currently a team manager at ImmobilienScout24 in Berlin. Stephan has been working as a head of development and CTO. He has used a lot of different technologies in the last 20 years including Java, Rails and Python. Stephans main field of interest is maintainablity and productivity in software development. Want to know more? All views are only his own.

If you did like this article but you don't want to subscribe to new articles with your reader, you can follow me on Twitter or subscribe to new posts with your email:

Comments

Ken

Interesting. Suppose you could post another one that goes to, say, 100,000 “tasks”?

June 22nd, 2008
stephan

Sorry, the picture is from the Kilim developers. They have more on their site.

June 22nd, 2008
Erlang vs. Java benchmarking update at Stephans Blog

[...] Productivity in software development « Interesting picture: Benchmarking Erlang versus Java concurrency [...]

June 22nd, 2008
Sean

I think you may be right about Scala not ever being accepted as an Enterprise language.

Scala can perform type inference, but it doesn’t have to - you can always explicitly state the type. Also, Scala is statically typed. So, while you may elect to let Scala perform type inference, it doesn’t open the program to the potential liabilities of dynamically typed languages like Ruby, Perl or Python.

June 22nd, 2008
Sriram Srinivasan

(I’m the author of the Kilim framework).

Ken asked about 100000 tasks. How about a million? Download and try it out.

http://kilim.malhar.net

This particular benchmark is about testing the speed of message passing. 3000 tasks == 9 million messages (each node passes a message to every other, and waits for a return message).

There’s another benchmark that measures task churn speeds (speed of creation and destruction). At the moment, Kilim’s faster than Erlang and Haskell.

–sriram.

June 23rd, 2008
stephan

@Siram: Thanks for commenting. I’ll give Kilim a try to get a feeling about it. Is there an abstraction planned on top of Kilim to make it easier for beginners?

E.g. have an abstract Actor class (Proxy?) where I can send messages to and which has a mailbox (and which does message passing to methods based on type/annotation/… ?

public MyActor extends Actor {

public void handleMyMessage(DeleteEvent event) {
…
}

public void handleMyOtherMessage(NewEvent event) {
…
}
}

I could use this actor with myActor.send(myDeleteEvent).

I’ll think about that.

June 23rd, 2008
Sriram Srinivasan

@stephan,

No, I’m not planning to have any abstractions on top of it. I don’t want to fall into the standard java trap of creating yet another massive framework. I’d like all the essential API to fit within a few pages of text.

I’d prefer to cover most techniques as examples and pull it in as part of the framework only when some pattern catches on.

Also, when time permits, I’ll put in a few more examples to cover nio, standard eventing stuff etc. There’s a jetty example that works easily enought with Jetty’s continuations and I have rewritten the tjws webserver in terms of Kilim threads, but both need cleaning up to show as example code.

June 23rd, 2008
stephan

Ah, interesting. I thought the Java standard trap was a too low level abstraction - see Swing - which results in no one using it.

June 24th, 2008
stephan

I would be interested in Kilim working with Jetty and Jersey - as a very fast REST service endpoint. Hmm. Or a very scalable one.

June 26th, 2008

Leave a Reply