4 ms·
Interesting post. Another post that I'd like to read would be: How Many Objects Does Scala Allocate (while executing some random code). In my Java shop, we tr
by pacoverdi 16y ago
Interesting post.
Another post that I'd like to read would be: How Many Objects Does Scala Allocate (while executing some random code).
In my Java shop, we try to write ultra-efficient code. Avoiding the creation of numerous small objects in critical sections is one of the best ways to achieve that.
I'd like to start a couple projects in scala or clojure but I'm afraid that the simplicity and expressiveness that these languages bring come at the cost of performance (or at least on control on what the JVM does).
- jongraehl 16y agoAt least you can write java-style code (or call java seamlessly) for whatever is performance-critical. I agree that idiomatic Scala can be too slow in some cases (it should be faster due to static typing than Clojure wherever methods aren't generic, or are specialized).
- loewenskind 16y ago>should be faster due to static typing than Clojure Uh, why? Are all object types known at runtime in Clojure? I bet they are. And this is exactly what Hotspot was designed to make fast [1]. [1] http://www.strongtalk.org http://www.strongtalk.org
- kikibobo69 16y agoUnfortunately "as good or better" performance is not realized yet, at least not at theThe Computer Language Benchmarks Game[1]. More code, more time, more memory required by Clojure than Scala, to solve the same problems. However the Clojure implementations on the site are still quite young, so some improvement may be possible. [1] http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=clojure&lang2=scala http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
- loewenskind 16y agoMy point was that it isn't the typing that makes it fast. Hotspot is based on the idea that the type is known at runtime. The Shootout probably wont show good results for this because it takes a little bit for Hotspot to get the most out of it. If you look at the Mandelbrot demo in Strongtalk it takes about 3 full runs to get the best speed.
- kikibobo69 16y agoEither I don't understand, or you are mistaken. Clojure is significantly slower than Java and Scala in the shootout. Presumably Hotspot kicks in, or doesn't, more or less equivalently in all 3 cases. The dynamic languages (Clojure, Groovy, JRuby) are all slower than the statically typed languages (Java, Scala); what else would cause that?
- loewenskind 16y ago>what else would cause that? How much work the code that they generate does. Clojure is mostly pure right? If you have, e.g. a btree and you change some nodes the old notes won't get deleted, a new tree will be created where some of the nodes point to the still valid old ones and some point to your changes. That's more work then just mutating the variables.
- gtani 16y agoThis raises an interesting question for igouy: there are dozens of jvm knobs you can pull to optimize each benchmark: "-server", "XX:MaxInlineSize", the many "XX" options to play with GC etc. I'm assuming that the same settings would be used for java, scala, and groovy for any single benchmark, but are these switches tuned for that particular benchmark, or the same used for all benchmarks?
- therockhead 16y agoClojure is using a lot more memory, any idea why that is?
- runT1ME 16y agoImmutable data structures?
- Dn_Ab 16y agoWhy and where (which idioms) is this the case? Is this due to type erasure on generics or something else? I ask this as this is the sort of knowledge that remains implicit amongst the experienced. p.s. i'm new to scala (and using it on app engine and android) but have extensive F# and decent haskell and ocaml experience and have found stuff like hyperpolyglot useful but this type of knowledge is not readily found.
- teh 16y agoI'm hacking scala for android and in my experience scala is really awful with allocations. When using idiomatic scala in a game loop the gc kicks in 10 times a seconds, making the app unusable. There are a lot of "invisible" allocations, i.e. allocations that happen even when you don't use "new". But even without scala-idioms scala is so much nicer than java that I never want to go back.
- Dn_Ab 16y agoNice. Can you go over more what scala idioms you mean and how you replaced them with java/imperative? idioms. A friend and I are just starting coding a small android app in Scala for learning and are always on the look out for info. Any resources you can provide would be awesome as well (I've seen you need to take steps to reduce scala-library bloat). Cheers!
- teh 16y agoHi, sorry for the late reply: I have a (short) summary here: http://teh.gitblogs.com/post/how-to-avoid-allocations-when-using-scala-on-android http://teh.gitblogs.com/post/how-to-avoid-allocations-when-u... For reducing the library size see e.g. http://github.com/teh/androidmake http://github.com/teh/androidmake I've seen others do similar things, you'll need to google for their solutions.
- alextgordon 16y agoIn my Java shop, we try to write ultra-efficient code. Avoiding the creation of numerous small objects in critical sections is one of the best ways to achieve that. I don't know anything about Java, but the Objective-C GC recycles old allocations to avoid this exact problem. For example for (int i = 0; i < 10000; i++) { Foo *foo = [[Foo alloc] init]; } Instead of allocating memory for foo 10000 times, older allocations are kept in a pool and reused for subsequent iterations. So the actual cost of -alloc is just a memset (i.e. nothing). Java's GCs are much more mature, so I would assume they have the same optimisation.
- cabalamat 16y ago> In my Java shop, we try to write ultra-efficient code. Are you sure you should be doing that? As Knuth said, "premature optimization is the root of all evil".
- njm 16y agoI would suspect the poster has already weighed the cost vs. benefit of writing efficient code. Many domains do require careful attention to performance.
- pacoverdi 16y agoI should have precised that we only optimize modules where performance is critical. Otherwise, our #1 priority is that code should be beautiful (concise, readable). A nice side effect is that sometimes "nicer" also means more efficient (the JVM likes small methods) :)
- deleted 16y ago[deleted]
- wheaties 16y agoThe great part about the JVM is that you can chose the language which fits the problem. If something needs the fine-grain control of Java, use Java. If another part would benefit greatly from the concise and expressive Scala idioms, use Scala. Eventually it's all going to be broken down into several JARs which are passed along to the next guy, hidden by bytecode as to which JAR was written in which language.
- zootm 16y agoImplicit wrappers have long been an issue for this sort of optimisation, although I was pleased to read that the new JVM escape analysis feature seems to deal with that very effectively: http://www.decodified.com/scala/2010/08/27/scala-rich-wrapping-performance.html http://www.decodified.com/scala/2010/08/27/scala-rich-wrappi... As other comments have noted you can generally degrade to writing near-Java code and the results will be basically the same bytecode. I'm sure there are exceptions but if you want to, you can avoid object creation. Implicit conversions are one of those cases which will not be called out as a warning or similar, though, so something to be careful of.
- runT1ME 16y ago>In my Java shop, we try to write ultra-efficient code. Avoiding the creation of numerous small objects in critical sections is one of the best ways to achieve that. I'd like to know why you think creating numerous small objects is an issue... Short lived small objects should be negligible to an application's performance.