esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: Scala, bytecode and such
Date Tue, 01 Dec 2009 07:49:43 GMT
I actually watched this talk just before I analyzed the memory
problems and the parts about laziness helped me understand what's
going on with the "memoization" of lazy vals.

Lazy vals is a great example of how a high-level construct helps you
write both readable and performant code. Lazy values are computed on
demand and computed only once, so offer enormous advantages
performance improvements. In a lower-level language like Java the
implementation of lazyness would probably be so verbose so as to
discourage people from using it. And if it's used, I wouldn't prefer
finding memory and performance problems in the resulting pages of Java
code rather than the concise Scala version.

I highly recommend David's talk if you need to take a quick look into
what happens under the hood when Scala code is compiled.

I also think that anyone who uses compiled Java code has no right to
complain about compiled Scala code as both compilers are the
brainchild of the same person ;-) I doubt that many people understand
better than Martin what's going on with typed languages generated to
bytecode.


On Tue, Dec 1, 2009 at 2:06 AM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> Folks,
>
> There were some recent rumblings about what kind of byte-code Scala
> generates.  I'd like to take a few minutes discussing the issue.
>
> The Scala compiler and language were designed primarily by Martin
> Odersky<http://lamp.epfl.ch/%7Eodersky/>.
> Everybody on this list has used Martin's most famous work: javac.  Martin
> wrote and maintained the Java compiler versions 1.1-1.4.  Martin also
> co-designed Java generics.  Martin knows his way around JVM byte-code, has a
> direct line to John Rose <http://blogs.sun.com/jrose/>.  Seeing Martin and
> John when they get together is quite a treat for the hardcore JVM geek.
>
> Because Martin co-designed Java Generics and implemented them in the
> compiler, it's pretty safe to say that Scala's claims of full compatibility
> with Java libraries is a true one and with > 250K LoC of Scala code that
> I've written or managed, I can say that there are no cases where Scala is
> not compatible with Java's object model.
>
> Scala takes a different approach to libraries than does Java.  Scala's
> language libraries are skewed towards immutable data structures.  A
> prominent member of the Java ecosystem took a sample of data used by
> enterprise apps and ran that data through Java's collections and Scala's
> collections.  It turns out that Scala's collections were marginally more
> efficient (about 4%).  This is because Java's mutable collections
> preallocate buffers that are typically not used where Scala only allocates
> what it needs.  This puts more pressure on the memory system (more temporary
> objects), but it turns out that it is more efficient.  (Sorry I don't have a
> lot more data as to JVM versions, etc. as this data was relayed to me by
> said Java ecosystem member over > 1 pint of beer.)
>
> It has been my experience that caching and immutability go hand in hand.  In
> Lift, we cache a lot of information (e.g., page templates) and do not need
> to make defensive copies of cached information because, like Java Strings,
> immutable objects can be passed to any thread or returned from any method
> without worrying about synchronization or mutation.
>
> While I'm not an expert on the byte-code generated by the Scala compiler
> (I'm a consumer of Scala rather than a producer of the language), I did this
> presentation at the JVM Language Summit.  It might be helpful for folks to
> understand how Scala translates various constructs into byte-code:
> http://www.infoq.com/presentations/Scala-Basics-Bytecode-David-Pollak
>
> Also, it's been my experience (and this in on the 1.6 JVM) that even though
> Scala produces far more in terms of temporary objects than does Java, that
> performance, even in highly threaded, high CPU load on multi-core Xeon
> boxes, this does not negatively impact performance.  While I'm all for
> tuning apps and I love benchmarks 'cause that's how we can improve code, I'm
> a lot less worried about lots of short-lived objects and a lot more
> concerned about things like lots of array copies.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

Mime
View raw message