On Monday 30 November 2009 18:48:36 Charles Oliver Nutter wrote: > On Fri, Nov 20, 2009 at 10:54 PM, Jon Harrop <[email protected]> wrote: > > I was referring to a thread local *heap* rather than a generation. For > > example, linked lists held as an array of cons cells where tails are > > indexes into the array. This offers substantial performance improvements > > on the CLR because it doesn't introduce any contention for the shared > > heap at all (beyond the single allocation of the whole array) but it > > requires the array elements (head+tail pairs) to be value types. > > I'm not sure I understand how CLR's support for stack-based value > types constitutes a thread-local heap. My understanding is that CLR > does not have any support for thread-local heaps, though the > stack-based stuff helps reduce GC pressure.
The CLR just facilitates this, it doesn't support it. You're essentially writing your own pool allocator by hand in a .NET language. > > Perhaps the most compelling example of value types is hash tables: > > inserting 10M float->float bindings into a hash table is 32x faster in F# > > than in Java. I suspect the reason is primarily that the JVM is boxing > > those floats whereas the CLR is not. > > This also has nothing to do with thread-local heaps, and is a result > of CLR having fully-reified generics that can support primitive > values. A hand-written float->float map in Java should perform as well > or better than the generic version in CLR. Yes, exactly. I was talking generally about the advantages of value types there and not specifically about thread-local heaps. Hash table performance is probably the most compelling example for general interest in case you ever need one. > Of course not having to write the primitive version by hand would be > nice. I've written several myself over the years. Next best thing is to write code to write the primitive versions by hand, i.e. Greenspun type-specializing generics. Clojure's macros might be good for this. I'd hope Scala tries its hardest to do this itself but I haven't actually looked. > > Does relying upon escape analysis make it impossible to pass unboxed > > arrays through the FFI? > > If you're referring to the FFI for calling into Java from Ruby, then > we're already pretty well stuck since there's a lot of megamorphic > code in the reflection call chain that would never inline enough for > EA to eliminate those arrays. This is a cost paid for all Ruby to Java > calls in JRuby and paid for even more calls in Groovy since most calls > end up being reflective. Method handles would make it possible for EA > to work across Java FFI, since the actual call target could inline all > the way back to the dynamic call site. Yes. Except for graphics, the performance of the FFI is growing less important as high-level languages overtake low-level ones in terms of speed due to parallelism. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
