How Scala faster than Java?

[Chaminda Amarasinghe]

Hi Venket,

I have heard, I think for twitter CTO, Scala is faster than Java. My question is, if scala runs on JVM, why java cant achieve that fast, which is originally designed to run on JVM?

Thanks

[Marco Ehrentreich]

Hi Chaminda,

I'm sure Venkat can give you more information on this because I'm not (yet) very experienced with Scala. Anyway I think discussions of the kind "fast than" or "better than" are pointless. I guess you can always come up with examples where one programming language (or technology in general) is "better" than the other in any way. Without knowing many details about low-level details of either Java or Scala I can't imagine that there will be much difference regarding performance for the average application.

Both languages compile to bytecode and run on the JVM with the same restrictions or features. And I guess both compilers already do a very good job regarding optimizations for the code. At runtime both languages are exectued as bytecode so the only step I see a possibility for a potential advantage for one language over the other is at compile time. And besides some special cases I don't think there can be much performance differences. Although that doesn't mean I wouldn't like to hear that Scala even beats Java here I just can't believe that it makes much difference in bytecode. Of course there's a difference with dynamic languages like Groovy which have to do more things at runtime! But as Scala and Java are both statically typed this can obviously make not a big difference.

But as always I'm interested to hear the opinions and experiences of some experts!

Marco

[Gabriel Claramunt]

Chaminda Amarasinghe wrote:
Hi Venket,

I have heard, I think for twitter CTO, Scala is faster than Java. My question is, if scala runs on JVM, why java cant achieve that fast, which is originally designed to run on JVM?

Thanks

Do you have the original quote? I don't think he means that Scala runs faster than Java.
From what I saw in different benchmarks, Scala runs as fast as Java or around 20% slower.
What I heard from twitter is Scala gives them higher productivity than Java

[Marco Ehrentreich]

What I heard from twitter is Scala gives them higher productivity than Java

Well, that definitely sounds more reasonable to me! And if you're more productive you probably have more time afterward to make performance tunings. But I don't think that Scala applications are more performant per se. Even if the language is more expressive or concise for lots of use cases it still compiles to bytecode which runs on the same VM...

Marco

[Chaminda Amarasinghe]

Scala vs Ruby http://www.scala-lang.org/node/1008

[Marco Ehrentreich]

Interesting to know although the original question was regarding performance comparison of Java vs. Scala?!? As I wrote above it's understandable (in my opinion) that dynamic languages are generally not exactly as fast as statically typed ones. But please don't get me wrong, I don't want to argue here which languages is "better" in any way. I just said that I can't imagine or liked to know why Scala in general should be MUCH more performant than Java

Marco

[Burk Hufnagel]

Marco Ehrentreich wrote:

Even if the language is more expressive or concise for lots of use cases it still compiles to bytecode which runs on the same VM...

Marco,
I'm pretty sure that the things that make a language dynamic are the same things that make it slower to execute than straight Java. Any expert want to weigh in on this?
Burk

[Marco Ehrentreich]

Hi Burk,

my statement you commented on in your post above was about the discussion regarding Scala vs. Java performance! It's in that case where I don't think it makes much difference when both languages can be compiled to bytecode.

For dynamically typed languages I absolutely agree with you and I think it's technically understandable that dynamic languages can't be equally fast even though they compile to bytecode because they have to do additional things at runtime which static typed languages usually don't have to do. But I should note that I'm not one of those who judge a programming language only by it's performance. Thus I don't want to start another dynamic vs. static debate here

Marco

[Burk Hufnagel]

Marco Ehrentreich wrote:It's in that case where I don't think it makes much difference when both languages can be compiled to bytecode.

Marco,
Compiling to bytecode isn't the key. Groovy compiles down to bytecode, but the metaprogramming features that do things like letting you add methods to final classes at runtime make Groovy slower than Java. That's what I was talking about.
Burk

[Marco Ehrentreich]

Compiling to bytecode isn't the key. Groovy compiles down to bytecode, but the metaprogramming features that do things like letting you add methods to final classes at runtime make Groovy slower than Java.

Actually that's what I was talking about, too I basically said that Java and Scala should be similar in performance because they are both statically typed and compile to bytecode running under similar conditions. Additionally I said that I think that is not comparable to the performance of dynamic language even if they compile to bytecode (because of the overhead at runtime).

So I'd say we have the same opinion here Anyway, I'd still like to hear if Scala is really faster than Java for the average application which doesn't focus too much on special features of one language...


Marco

[Burk Hufnagel]

I guess we're in what's been called "violent agreement" - I just didn't know it.

[Vinay Singh]

We have not heard from Venkat on this but I also wanted to know how Scala is better than Java. Twitter's some part has been written in Scala esp the messaging queue. Twitter had really high load going to 5000 tweets per minutes at times.
For Scala - From Scala's site

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application

So a reduced code size does not necessarily mean better performance.

[Venkat Subramaniam]

Quite a bit has been said in this thread already, so I did not feel I need to say anything more. But since you asked here are a few things I would like to say

Write a class in Scala (I will call it YourClassName) and compile it using scalac. Then type javap -c YourClassName and take a look at the bytecode generated.
You will find that the Scala compiler does not add any fluff to the bytecode. In code I have worked with, when I took some Java code and wrote equivalent
Scala code, the performance of the Scala code was in par with that of the equivalent Java code. In some examples, slight improvements I saw in Scala was
due to lack of the need for synchronization. I would not want to make any general arbitrary performance claims between the languages as such things are
often misleading and misinterpreted. I would, however, say that I do not expect Scala to perform any worse than Java.

[Marco Ehrentreich]

Hi folks,

the example regarding advantages of Scala due to the lack of synchronization is intersting. Without knowing all the details I think it should be possible to achieve the same in Java with immutable objects and the like if only people would care about such things or start to think in different ways (of course it's not as easy to achieve in Java as it is in Scala).

Anyway, thanks for the whole discussion and for this final statement! Luckily it seems that we generally all agree here

Marco

[Gabriel Claramunt]

I think there's a couple of corner cases where idiomatic Scala runs faster than idiomatic Java.
Particularly when dealing with immutable objects vs mutable ones . Odersky mentioned that in the Scala se-radio episode

[Carl Smotricz]

From what I've learned of Scala so far, there's no big technical advantage to running Scala vs. Java code. In fact, head to head on a single CPU, compiled Scala code often loses a cycle or two against Java, simply because the Scala compiler hasn't yet seen as many years of industrial-strength optimization. The advantage of Scala, where it exists, is in encouraging a different mindset from that in which you program Java. Given a Philips screwdriver, you can stop pounding machine screws into place with your hammer

Java and its ancestor languages were born in times when Moore's Law still held - if your program wasn't fast enough, wait 18 months and you'd have twice as fast a CPU to run it on. CPU speeds have hit a wall and the workaround is to use multiple CPUs. Java's biggest offering to concurrent programming is synchronized, which is essentially a brake you can apply to keep parts of your app from crashing into one another. Scala, on the other hand, encourages functional programming and concurrency using the Actor model. It doesn't produce code that Java couldn't, it just makes it more convenient to create such code. The functional/Actor style is one where different activities simply can't collide, by design, so there's no need for brakes. Also, much of the multithreading can take place behind the scenes, without explicit tweaking by the programmer.

So: In situations where parallel processing is important for performance, a skilled Scala programmer has some likelihood of coming up with a "better" solution than a skilled Java programmer, simply by virtue of being nudged by the language toward a style that's well suited for that kind of task.

[Pat Farrell]

Carl Smotricz wrote:From what I've learned of Scala so far, there's no big technical advantage to running Scala vs. Java code. In fact, head to head on a single CPU, compiled Scala code often loses a cycle or two against Java, simply because the Scala compiler hasn't yet seen as many years of industrial-strength optimization.

You still run on a single CPU? In the past two years, I've bought a laptop and two desktops. I have 10 CPU cores now, two in the laptop, and four each in the desktops.

I see the advantage of Scala, in addition to @carl's different thinking, in the natural extension to parallel processing that Scala (and other functional languages bring). I don't think programmers can write great code using threads and synchronization. Well, some can, but I don't think that the majority of folks are there yet.

[Jesper de Jong]

But I agree with the part of Carl that you quoted: Scala's compiler has not been optimized (and debugged) as much yet as Java's compiler has been, through more than ten years of heavy use in the industry.

By the way, Martin Odersky, the inventor of Scala, has also written the current Java compiler (since Java 1.3, if I remember correctly).

[Pat Farrell]

Oh, yeah. Any compiler that is in active use but much younger than another compiler will tend to produce less optimal code.

Or, in other words:

Compilers get better with time, assuming they are being actively developed.

Java has been around a long time, and some initial complaints were that it was much slower than C/C++. So, to convince folks that Java was the one true light in the future, they improved the compiler. And they improved the JVM.

The good thing is that both Groovy and Scala use the Java JVM, so they get all the benefit of the past decade's worth of work. The JIT optimizers are very impressive.

Much more important, IMHO, is that the JVM can use metrics to see which parts of the code is actually used, and improve that. This avoids the whole "premature optimization" time/effort sink.

[Carl Smotricz]

Pat Farrell wrote:You still run on a single CPU?

I think we mostly agree, but I'd like to clarify what I said.

With "on a single CPU" I was setting up a hypothetical test bed where nothing matters but simple straightforward code execution speed; a level playing field, if you will.

I think it's important to note, though, that most of my code does run on a single CPU - at any given time. My job-related work is mostly about Web applications, so most of what I write runs essentially as a servlet of some kind or other. In a J2EE environment, one is explicitly proscribed from multithreading. Sure, the container is swapping servlet threads between however many CPUs it has available, but the computational work for any given request runs in a single thread at any one time, and that runs on a single CPU at any one time. From the point of view of an individual request, all the task swapping going on in the background is actually just stealing cycles (for the context switch) away from the task at hand.

I see GUI applications in the same category: Usually there's a single background thread doing some work (perhaps only from time to time) and a GUI thread sitting on its thumbs waiting for the user. Except for those moments when there's GUI repainting going on in parallel with the background work, most GUI apps are essentially one-CPU apps as well. The easiest way to tell from the outside is that adding CPUs won't speed up the background task.

As things stand, without having done any research, I'd wager that better than 90% of all Java code worldwide fits in this "single CPU" category. Multi-core systems are being used to run different applications side-by-side (so your virus scanner hurts less) or to run multiple copies of the same job (like ebay bids). Java applications where a single task is distributed to a number of threads/cores form a small minority.

[Pat Farrell]

Carl Smotricz wrote:As things stand, without having done any research, I'd wager that better than 90% of all Java code worldwide fits in this "single CPU" category. Multi-core systems are being used to run different applications side-by-side (so your virus scanner hurts less) or to run multiple copies of the same job (like ebay bids). Java applications where a single task is distributed to a number of threads/cores form a small minority.

I agree in general. Except most Swing apps use two threads, one to do the work, an one for the GUI. You can't get reasonable responsiveness to the GUI without it. I agree that since really distributing a task to separate threads is a challenge, its not done very often.

This is, IMHO, where Scala and Groovy could win big. Which does not answer the original question, because its where Scala *could* be faster, not where it "is faster" today for most users.

[Juan Alvarado]

Forgive me if I am wrong, but isn't the scala compiler written in Java? I mean when you do scalac on some scala file, this is what gets invoked in scalac.bat:

"%_JAVACMD%" %_JAVA_OPTS% %_PROPS% -cp "%_TOOL_CLASSPATH%" scala.tools.nsc.Main %_ARGS%

So would I be correct in saying that the scala compiler is written in java and it uses java for bootstrapping itself?

I'm just curious to find out what programming language the scala compiler is written in.

[Marco Ehrentreich]

Hi Juan,

and welcome to JavaRanch

I think the Java compiler "javac" is a native program written in C like most parts (or all?) of the JVM, too. Maybe some parts are in Java but as far as I know both are the "native" components which are not portable like the Java programs themselves.

The Scala compiler just translates Scala source files into the common ".class" files which is a requirement for any language running on the JVM. So it's not really some kind of bootstrapping. You simply compile some language (Scala) into another language (.class file). Everything else is done by the virtual machine. Unfortunately I'm not sure in which language the Scala compiler itself is written... But I'm sure someone here knows better.

Marco

[Garrett Rowe]

Interestingly, this topic was just discussed on the Scala mailing list recently. The first iterations of the Scala compiler were indeed written in Java, but the current scalac is written in Scala. You can browse the scalac source code here: http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools (Note this is the source of the unreleased 2.8 compiler which changes daily).

By the same token the java compiler, javac, is written in Java.

[Marco Ehrentreich]

I've never really cared about this fact but it sounds interesting that the compilers for both languages are written in the particular language itself. Is it traditionally done that way as a kind of proof of concept for a programming language or are there more practical reasons? OK, obviously you wouldn't invent a new language if you were satisfied with the existing ones... Just out of curiousity, do you how the initial bootstrapping was done for Java?

Marco

[Pat Farrell]

its tradition, it lets you eat your own dog food. Plus its a good way to know that the features and functions are really useful and working.

Nearly all languages do this, first they bootstrap the new language in some existing language, and then rewrite the compiler in the new language.

[ravi grk]

compare Java and Scala perofrmance,speed
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=scala