Scala 2.9 vs 2.10 Performance(markehammons.wordpress.com)
markehammons.wordpress.com
Scala 2.9 vs 2.10 Performance
http://markehammons.wordpress.com/2012/12/02/2-10-performance/
3 comments
It's incomplete reporting without the JRE heap, inlining, GC and other options used and some kind of residency and median memory usage data. Also, warmups, hardware and OS (Windows seems to frequently produce interesting results. (I haven't seen a GC testbench for java like dons' gc-tune pkg for haskell, but that would be a great tool
Performance improvements are nice and all, but I'm already generally satisfied with the performance of Scala 2.8.x and 2.9.x.
What I'd really like to see is faster compile times. I know it's a tall order given the complexity of implicits, but compared to other languages Scala compilation slowness can be a tough sell.
What I'd really like to see is faster compile times. I know it's a tall order given the complexity of implicits, but compared to other languages Scala compilation slowness can be a tough sell.
Performance improvements are really important given the rise of poor JVMs like Dalvik, though. Scala is really painful on Dalvik due to the amount of garbage it generates.
I wouldn't call Dalvik a poor JVM, just a JVM optimized for a certain mobile application mix (not so GC intensive) that Scala doesn't really support yet.
Can you name an X for which Dalvik performs competitively with HotSpot? Honest question, because I can't think of one.
To get decent GC performance, you need a large space for copying, which doesn't work so well on mobile, so they probably went with a less efficient in-place collector. Its a trade off really: low memory operation or high performance even when a lot of garbage is generated (and memory isn't so expensive)?
WinRT has built in support for reference counting now (both in run-time and in its libraries); that's a big deal for mobile! Sure, the collector is still present and you can use it in C#, but...the game is changing quickly. Apple, of course, supports reference counting already, Dalvik does not as there is no easy way to bolt that onto Java (though I wouldn't be surprised if Google eventually does what MSFT did with WinRT).
Disclosure: MSFT employee and general programming languages hacker.
WinRT has built in support for reference counting now (both in run-time and in its libraries); that's a big deal for mobile! Sure, the collector is still present and you can use it in C#, but...the game is changing quickly. Apple, of course, supports reference counting already, Dalvik does not as there is no easy way to bolt that onto Java (though I wouldn't be surprised if Google eventually does what MSFT did with WinRT).
Disclosure: MSFT employee and general programming languages hacker.
This comparison makes no sense, the two JVM's were designed with fundamentally different goals.
At any rate, if you really wanted to compare, you would have to run the benchmarks on the same platform, i.e. Dalvik on the desktop or HotSpot on Android.
Which makes no sense either.
At any rate, if you really wanted to compare, you would have to run the benchmarks on the same platform, i.e. Dalvik on the desktop or HotSpot on Android.
Which makes no sense either.
This comparison makes no sense, the two JVM's were designed with fundamentally different goals.
What they are designed for and what they are quite commonly used for are different things. Both are used for running my application code. Serious performance problems on one makes that worse, regardless of whether it is worse-as-designed or not.
What they are designed for and what they are quite commonly used for are different things. Both are used for running my application code. Serious performance problems on one makes that worse, regardless of whether it is worse-as-designed or not.
Memory use and startup time?
I'm just guessing here, but I believe, if anything, Dalvik is better at those.
I'm just guessing here, but I believe, if anything, Dalvik is better at those.
> Scala is really painful on Dalvik due to the amount of garbage it generates.
That seems to be a Scala problem, not a Dalvik one.
Dalvik is a JVM that's extremely optimized for one specific purpose: running on mobile phones. And it's doing a fantastic job at that.
That seems to be a Scala problem, not a Dalvik one.
Dalvik is a JVM that's extremely optimized for one specific purpose: running on mobile phones. And it's doing a fantastic job at that.
No, it's a JVM optimized for "not being something Oracle can demand money for."
It's an okay JVM at best, and it's a pain in the ass to deal with because of its lack of support for things that are at this point basic on the JVM, i.e. code generation. And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit--which, in addition to making Groovy, Rhino, etc. unusable, hobbles Scala, too, and will hobble Java 8 when that comes out.
It's an okay JVM at best, and it's a pain in the ass to deal with because of its lack of support for things that are at this point basic on the JVM, i.e. code generation. And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit--which, in addition to making Groovy, Rhino, etc. unusable, hobbles Scala, too, and will hobble Java 8 when that comes out.
> No, it's a JVM optimized for "not being something Oracle can demand money for."
We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
> And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
> And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
"Be different enough to not get sued" is a technical requirement as well as a legal one because it informs the design of your product. For example: the use of a different bytecode format in Dalvik pretty obviously had much more to do with "we can't make it look like a real JVM because we'll get sued" than efficiency; it's not a significantly better format than the standard Java bytecode system and using it trashes your compatibility with common Java libraries and tools.
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
Good ad hominem, bro. How's that working out for you?
I am not an expert, no, but I do know a few things about them and I know a few more about application development, on Android and off. Dalvik is not a good citizen of the Java ecosystem (as evidenced by its inability to do things that are considered very normal, i.e. Groovy or Rhino for scripting). You can't do really basic stuff like LiveConnect because of the twin fails of no bytecode generation (there's no dexer on-device) and, as mentioned, the class limit does a number on Scala and will hose Java 8. These are technical problems that stem from decisions made during the design process, and they're not edge case problems--well, the Scala bit is, but you can surface the same problem by just having a lot of dependencies that pull in a lot of class files.
When you're talking JVMs, you must compare to HotSpot because that's the main game in town. Dalvik doesn't compare well the design decisions inside of Dalvik serve to hobble developers who are not looking to write very simple, Android-idiomatic (which is not Java-idiomatic) CRUD apps. And that sucks. I would like it to be better. It isn't at present. I don't hold out a lot of hopes for improvement, though I would like to be wrong.
"Be different enough to not get sued" is a technical requirement as well as a legal one because it informs the design of your product. For example: the use of a different bytecode format in Dalvik pretty obviously had much more to do with "we can't make it look like a real JVM because we'll get sued" than efficiency; it's not a significantly better format than the standard Java bytecode system and using it trashes your compatibility with common Java libraries and tools.
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
Good ad hominem, bro. How's that working out for you?
I am not an expert, no, but I do know a few things about them and I know a few more about application development, on Android and off. Dalvik is not a good citizen of the Java ecosystem (as evidenced by its inability to do things that are considered very normal, i.e. Groovy or Rhino for scripting). You can't do really basic stuff like LiveConnect because of the twin fails of no bytecode generation (there's no dexer on-device) and, as mentioned, the class limit does a number on Scala and will hose Java 8. These are technical problems that stem from decisions made during the design process, and they're not edge case problems--well, the Scala bit is, but you can surface the same problem by just having a lot of dependencies that pull in a lot of class files.
When you're talking JVMs, you must compare to HotSpot because that's the main game in town. Dalvik doesn't compare well the design decisions inside of Dalvik serve to hobble developers who are not looking to write very simple, Android-idiomatic (which is not Java-idiomatic) CRUD apps. And that sucks. I would like it to be better. It isn't at present. I don't hold out a lot of hopes for improvement, though I would like to be wrong.
True, although it's not entirely clear from this Scala-on-JVM benchmark whether there'd be a comparable speedup for Scala-on-Dalvik. Depends on the reasons for the speedup I assume.
These particular ones, likely not. It was more of a general observation about performance when dealing with crippled environments like Dalvik.
The Scala compiler itself is written in Scala, so improvements in performance will also benefit compile times. Or so I hope.
How is this managed? Is there a "backup compiler" written in some other language to compile the compiler?
You use a previous version of Scala to compile the trunk version. It's turtles all the way down!
Just kidding. The initial Scala compiler was written in Java. After that was working, they rewrote it in Scala using their initial Java compiler, and then it became the process I mentioned.
Just kidding. The initial Scala compiler was written in Java. After that was working, they rewrote it in Scala using their initial Java compiler, and then it became the process I mentioned.
Nice post, I just used your benchmark to also compare running Scala in JDK 6 and 7 http://news.ycombinator.com/item?id=4862035
Could somebody familiar with the changes to 2.10 explain where the performance boost came from and what code it will affect? Does this make Scala a more compelling choice for the discerning functional programmer?