Comments on Sven Efftinge's Blog: Groovy, Scala, Java, Xtend - an UPDATED stupid com...

This is a bit off topic, but are there any major E...

2011-12-24T17:34:29.650+01:00

This is a bit off topic, but are there any major Eclipse projects, not from those of you who brought us XText/XTend, that are coded in, or anticipating migrating to, XTend? XTend compiles to Java source code, so it can't be too great of a risk to migrate.

And by the way: the main reason why your Scala exa...

2011-12-23T16:49:06.318+01:00

And by the way: the main reason why your Scala example is really slow is because you used the deprecated Application trait. The more recent App trait fixes the issues with Application.

If you change the code to use an ArrayBuffer (which is the equivalent to ArrayList) and use tail recursion the Scala version actually runs faster than the Java one.

I cheated a little by adding the Scala Library to the bootclasspath - if you invoke it using the scala shell script the execution time is the same as for the Java version.

I update both the java and scala versions of the code and got the fastest performance using pure arrays instead of lists.

Both run in exactly the same time.

Java ArrayList performance is similar to Scala ListBuffer.

If you really want performance in scala, use arrays and while loops (there is an otherhead to use 1 to n construct since it generates a list).

@Sven Sorry I did a small mistake which lead to wr...

2011-12-22T16:16:34.746+01:00

@Sven Sorry I did a small mistake which lead to wrong figures. It is actually exactly as fast as your optimized snippet.

@Sven: your java snippet is unbeatable for me (so ...

2011-12-22T00:09:10.628+01:00

@Sven: your java snippet is unbeatable for me (so far). can we add additional languages - e.g. assembler ;-)

@Stefan: Did you mean 5 times faster than
2011-12-22T00:00:36.063+01:00
@Stefan: Did you mean 5 times faster than this Java snippet?

@Jochen: I understood that you think the other sa...

2011-12-21T23:57:58.678+01:00

@Jochen:
I understood that you think the other samples don't have to do dynamic dispatch. If that is really the case the comparison is unfair (despite from that it's actually really unfair since I just hacked away some code without specifying any kind of requirements or even have deeper knowledge of Groovy. And also my measurement technique was bogus...).

But I still think all the examples do dynamic dispatch. Yes, only Groovy and Xtend have to call a different methods for each case, but that doesn't really make a big difference. Calling a method in Java is fast!. If I delegate each case to a method on it's own in the Java example and disable JIT it's only marginally slower (~60ms difference on my machine).

Xtend binds statically just like Java. For a set of visible overloaded dispatch methods (i.e. a multi method) a synthetic dispatch method is inferred using the common super types of the arguments. So it is declaration site dispatching unlike in Groovy where dispatching is done on the call site.

If I subclass such a class I can add new cases (within the bounds of the argument types) and the synthetic dispatch method will be overridden. More details

Sven I think you did understand me a bit wrong. I ...

2011-12-21T22:57:50.786+01:00

Sven I think you did understand me a bit wrong. I wasn't about unfair, I tried to explain why Groovy does it that way and how the result from that then is.

But I wonder what made you think that, performance wise, dynamic dispatch (or I should say multi method dispatch) is a strength?

Anyway... I don't agree that the other examples do dispatch at runtime. For that there should be at least one more method call from your dispatcher method. When I say dispatcher method, then I mean a method, that does some kind of method invocation by calling another method. In your case that would be what follows the instanceof checks. Since you there simply return the value, you do what JIT would have done otherwise. But only if JIT can do that. And that is actually a critical point. If you call bigger methods, then the JIT won't inline the dispatcher anymore very fast. As result you loose inlining of the method you want to dispatch to for everything that calls the dispatcher method. And this then can have severe consequences. The only way around that would be to have the checks at the call sites - with other problems.

I won't now conclude the Groovy version is better in that, I just try to point out a general problem of such dispatcher methods. And I don't know how Xtend does these things, but assuming that it will be only a little bit less fast than a direct method call in Java might in real life not be the real case. For your test here it is still true what Micheal said in the comments, you test mostly ArrayList performance. So at least for Scala, Java and Xtend, you don't test method call performance with this one at all.

I also don't understand how you can claim Xtends doing multi method dispatch while at the same time claiming it will behave like Java in its calling logic... Java does no multi method dispatch. I don't think that Xtend can have per default multi method dispatch and Java dispatch at the same time.

You should also note that Groovy has this multi method logic per default, while in your case, you have to use your keyword to enable it. But assuming I want to enable it... can I subclass that class in Java and add another foo method, that then will be part of the dynamic dispatch, without having to rewrite the dispatcher method? Your text seems to say, that this is possible. If that is possible, then I would be very interested in knowing how. I am always eager to learn how to make something work, that I thought is impossible to do efficient.

Here is a slightly more concise version. // Scala...

2011-12-21T20:01:33.005+01:00

Here is a slightly more concise version.

// Scala needs Java 7 to make use of new fork/join framework (JSR-166)
object Scala extends Application {
// collection.parallel.ForkJoinTasks.defaultForkJoinPool.setParallelism(4)
val before = System.currentTimeMillis()
val absoluteResult = for (
_ <- (1 to 100000)/*.par*/; y <- List("foo", 23, true).map(foo)
) yield y
println("Took : " + (System.currentTimeMillis() - before)
+ " ms, number of elements : " + absoluteResult.size)

def foo(obj: Any) =
obj match {
case _: String => "String"
case _: Boolean => "Boolean"
case _: Integer => "Integer"
case _ => throw new IllegalArgumentException()
}
}

Wondering, if parallelism would make a difference (if using Java 7). But uncommenting the above code seems to result in a dead lock. (I'm no Scala expert...)

- Daniel

Just for fun: A Clojure version using Arrays. Abou...

2011-12-21T19:48:46.848+01:00

Just for fun: A Clojure version using Arrays. About 5 times faster than the optimized Java version. Of course this is far away from functional style ;)

https://gist.github.com/1507155

Finally, here is a Clojure version using mutable d...

2011-12-21T19:21:36.011+01:00

Finally, here is a Clojure version using mutable data:

https://gist.github.com/1506973

For large numbers it's runtime converges on that of the Java implementation. Not bad for a dynamically typed language.

Of course, I didn't try to write efficient but...

2011-12-21T15:51:56.651+01:00

Of course, I didn't try to write efficient but idiomatic code. Since my Scala knowledge is a bit old and mostly forgotten, I'm glad others helped out a bit.

If you're looking for a challenge try to beat this Java version. It's approx. three times faster than Viktor's Scala version.

And that's the infamous Klang effect. Was just...

2011-12-21T15:36:48.597+01:00

And that's the infamous Klang effect. Was just about to post something about using a List.newBuilder within an @tailrec function. Pretty much would cover the same. Besides, you don't append an item to the end of a list. That takes O(N) time for each list (O(N^2) total runtime.) Instead, you prepend a list of results and then reverse them. Takes O(N) in total.

Michel, on my machine Viktor's version is alm...

2011-12-21T14:33:59.435+01:00

Michel,

on my machine Viktor's version is almost twice as fast as yours. But your's is twice as comprehensive and even a bit faster than the Java version.
Very cool! :-)

I punted and missed the call to foo in the loop. ...

2011-12-21T14:30:43.640+01:00

I punted and missed the call to foo in the loop.

And interestingly it does not change the time at all !

So what are we comparing here ... only the time to process a collection based on the collection implementation. The time to call the method is so small we don't see it ! Probably a JVM optimization (I'm on Java 6)

Viktor, I get similar performance with this code which is much easier to read (no explicit use of recursion).

Michel : Took : 452 ms, number of elements : 3000000

Viktor : Took : 421 ms, number of elements : 3000000

Java collections : Took : 748 ms, number of elements : 3000000

2011-12-21T14:15:18.625+01:00

This comment has been removed by the author.

Fast, faster, Scala: https://gist.github.com/1505...

2011-12-21T14:13:37.527+01:00

Fast, faster, Scala:

https://gist.github.com/1505997