Universities anyway get free dollars from Uncle Sam, so they can afford to be Santa Claus to award PhDs to Java frameworks or perhaps to even product manuals!

Research is no more about being selfless and working for benefit of mankind. It is about outsmarting the system to get a degree!

“I never perfected an invention that I did not think about in terms of the service it might give others… I find out what the world needs, then I proceed to invent….” – Thomas Alva Edison

Fred, the graph is not random but from the Kilim site which is linked. Sorry that I did not made this more clear to you so you could have followed the link and read the Kilim presentation.

http://www.malhar.net/sriram/talks/kilim-google.pdf

“What is the message sending pattern? [...] Byte code vs natively compiled code?”

Questions are answered on the linked Kilim site. Again, sorry I haven’t made it clear enough for you to follow the link.

For me a random graph without context is not very interesting at all. Usually it smells more like marketing than engineering. I could probably produce a graph showing that Ruby is faster than Java for a specific area if I wanted. It would be against conventional wisdom, yet it would not really be interesting unless I told you what it is I am actually comparing.

In other words *the framework* may be interesting depending on what happens in the Java world (I am hoping we will see the actor model used more widely!) but the single graph in itself without context isn’t.

Before I would consider it interesting I would like to know if this micro benchmark corresponds to a relevant use case in the real world. What is the message sending pattern? How many messages are sent between the “tasks”? What is the message size? What type of data is being sent? Do the tasks do anything but pass messages to each other? Is the data immutable? How do they pass messages? Is the message sending order guaranteed? Is it single core or multi core (or perhaps even tasks on different processors)? Is the benchmarking code concise and readable and following the recommended coding style? What is actually being measured and compared in the graph? Zero-copy vs copying? Byte code vs natively compiled code?

I find it interesting if something unusual happens that goes against common wisdom.

If it’s a micro benchmark, I’m interested why the micro benchmark behaves in such a way. I’m curious (see e.g. the Java access benchmark on this blog).

But as I’ve said, peoples interest is sparked by different things.

I hope you’re not a dull Erlang which doesn’t see his preconception scratched. If you’re interested in knowledge, there are other benchmarks of Java actor frameworks around, from the top of my head they show Java around 50% slower than Erlang with actors. I guess the JVM isn’t scheduler optimized for this kind of thing.

When can a single micro benchmark taken out of context without corresponding source code and compiler options ever be considered “interesting”?

It is however quite interesting to note that concurrency oriented programming seems to gain in popularity.

My personal, often disputed opinion, with the web, itunes, chrome, AIR (tweetdeck) native widgets are most often not important anymore.

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.

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.

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.

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.