
Is Scala really Faster than Java? - fogus
http://xebee.xebia.in/2011/06/20/is-scala-really-faster-than-java/
======
jbooth
Can nobody on planet earth read?

That Google paper specifically said that they significantly refactored the
algorithm to be more "scala-like" and got a much cheaper implementation than
the canonical way it was implemented in other languages.

So, no, Scala is not faster than Java and probably won't be for a long time.

But yes, picking your algorithm is more important than language
microbenchmarks.

~~~
loup-vaillant
Your phrasing is slanted. Citing the abstract of the paper:

> _The implementations each use the languages’ idiomatic container classes,
> looping constructs, and memory/object allocation schemes. It does not
> attempt to exploit specific language and run-time features to achieve
> maximum performance._

Meaning, they went out of their way to write idiomatic Scala _and_ idiomatic
Java. No performance tweak in Java _nor_ in Scala. The way you phrased it make
it sound like they paid more attention to their Scala implementation. If you
really think that, say so. Beware though: that would be a direct accusation of
intellectual dishonesty.

To me, Google's paper looks like clear (though not iron strong) evidence that
_idiomatic_ Scala is is faster than _idiomatic_ Java, with the chosen
implementations. Shortening that into "Scala is currently faster than Java"
doesn't seem such a stretch. Now if you want to compare idiomatic Java written
in Java, and idiomatic Java written in Scala, fine, but I don't think it's a
fair comparison.

~~~
jbooth
Read their section specifically on Scala. The algorithm as implemented in
Scala was a different bag of oranges than the apples in the C/Java
implementations.

If you want to say that idiomatic Scala is so great, fine, although I wouldn't
be so absolutist about it (remember the article on HN 2 days ago about the
scala for loop being 20x as expensive as the while loop because of something
to do with closures?).

Anyways the point is that the comparison was not between two things that were
at all the same. All that says is that this particular problem was better
expressed in Scala, and nothing about how one was faster than the other.

~~~
scott_s
And you should probably take a closer look at Figure 8 - note that the non-pro
version of Scala that did not change the fundamental algorithm is still faster
than the non-pro version of Java. The version you're mentioning is _not_ in
Figure 8.

Again, I agree the results are confusing.

------
ColinWright
This sentence stood out for me ...

    
    
        My basic (starter) understanding of Functional
        programming tells me that there should be more
        object churn in a functional language ... and
        thus Scala should have trouble with GC not the
        Java implementation.
    

My experience is that in an OOP language, objects are brought forth, used,
then discarded, oft-times requiring GC. My experience of well-implemented FP
languages data streams through functions that have, in the large part, been
optimised away.

I don't have deep or broad experience, and it's ceretainly true (as I see it)
that naive implementations provoke lots of GC. But it didn't seem obvious to
me that OOPLs should provoke less, and it does seem reasonable that FPLs might
easily provoke less.

I'd be interested to hear some of our more experienced HNers comment on this.

~~~
jmreardon
High object churn shouldn't be a problem for the JVM, whether it is running
Scala or Java code. Allocation lots of little objects and then discarding them
shortly after is a use case the JVM is well optimized for. You would have to
allocate an extraordinary number of such objects to see any real slowdown.

The Oracle JVM uses generational garbage collection[1]. Glossing over some
details, this garbage collector divides objects into generations depending on
how long they've been around, and also keeps track of references that cross
generations. Objects that are newly created go into the first generation. If
the objects don't refer to objects outside of the first generation, it is very
cheap for the VM to determine they are in fact garbage. When the garbage
collector gets run, objects that a still live get copied to another
generation. Once the still live objects are copied out, the VM doesn't need to
do any cleanup to get rid of the dead objects, it simply marks the whole
memory block the first generation was in as available.

[1] Not that other JVMs don't, but I only know the official one.

~~~
bad_user

          simply marks the whole memory block the first 
          generation was in as available
    

That doesn't make any sense.

On that _GC run_ what if you just allocated an object, 0.01ms ago? You mean to
tell me that it's either (a) deallocated before being used or (b) moved to the
second generation already? Also, you need to basically stop the world for
doing first-generation cleanup, as you described it, otherwise you're running
into race-problems. That's insane.

 _Glossing over some details_ , no matter how efficient the GC is in regards
to first generation treatment, you're still accessing the heap, which is an
expensive operation, you're still potentially boxing/unboxing primitives in
loops and you're also making single-dispatch virtual calls on those short-
lived objects.

C++ has terrible performance when using heap-allocated values, but with stack-
allocated objects C++ kicks Java's butt. And that's not the only potential
problem for Scala, unless Scala adds some kind of tracing compiler that can
avoid boxing/unboxing and runtime-dispatch when not necessary.

~~~
jmreardon
I can tell you is isn't being deallocated before being used, that would be a
major bug. So, I guess it would get moved, but the GC probably won't run
unless the first gen space is pretty full. I'm glossing over details because,
well, the GC in the JVM is a very complicated piece of work, and I don't know
much of the details, but the JVM does in fact default to a stop-the-world
garbage collector[1].

I don't think anyone actually expects the JVM to beat C++ using stack
allocated objects[2]. Our concern is how well a garbage collector handles lots
of small objects.

[1] Details on how the JVM GC works:
[http://www.oracle.com/technetwork/java/gc-
tuning-5-138395.ht...](http://www.oracle.com/technetwork/java/gc-
tuning-5-138395.html) [2] There is a switch, which will be on by default one
day, that lets the JVM do escape analysis so it can allocate objects on the
stack automatically.

------
gaius
_Thinking logically if some language is built on some other language then the
derived language can be at most as fast as the underlying language_

That is not true. Why? Because the C compiler optimizes at compile time, and
the VM optimizes at compile time _and_ at runtime. It can be much smarter at
inlining, loop unrolling, etc.

~~~
vetler
Also, Scala is not "built on" the Java language, as far as I know. It compiles
to bytecode, just as the Java language does.

~~~
thomaslangston
Could you elaborate? It is my understanding that 99.9% of Java syntax is valid
Scala syntax. How does that correlate with your statement?

~~~
JoachimSchipper
The compilation path is Scala -> JVM bytecode [-> x86 assembly], not Scala ->
Java -> JVM bytecode [-> x86 assembly]. At least, that's what I think your
parent comment was saying.

------
fizx
My experience with Java and Scala in high profile, high traffic apps is that
they are more or less exactly the same speed. Scala has historically had a
much less performant (and buggy) collections library, so I've often used java
collections from scala, but it's gotten better.

------
brown9-2
It's a gigantic stretch to read an article that benchmarks languages
implementing a single type of function and conclude "It shows Scala to be
faster compared to Java".

Thankfully the author realizes this in his conclusion - "it seems that
difference in implementations is the cause for difference in the time taken by
Java/Scala programs".

~~~
eru
He could probably try to justify: Scala idioms to structure code tend to be
faster than Java idioms.

~~~
eevilspock
Or argue that the Scala language provides more information to the static
compiler allowing it to produce better byte code. Has anyone done that
analysis?

~~~
cb372
In general, the Java static compiler generates pretty poor-performing
bytecode, no matter how much useful info you give it. This is by design, and
relies on HotSpot to provide the necessary optimisations at runtime.

I'm no expert but I would assume that the Scala compiler is quite similar. Not
much point in generating highly optimised bytecode when HotSpot will do the
job for you.

