On this particular example, I think we are a bit further that what Transients currently offers. Even using a mutable primitive Java array results in code 2 or 3 times slower than the Java implementation of the benchmarks.
I have no doubt the struct and transients in Clojure will allow to do that at native speed, at some point in the future though. And they are the right way to approach this kind of problem, I agree. Best, Nicolas. Mon, Aug 17, 2009 at 3:26 PM, e <evier...@gmail.com> wrote: > i don't know much about this (haven't followed closely, lately), but do the > new Transients come into play to somewhat address this? Sounds like they > were designed just for this sort of thing: inner-loop optimization and > low-level mutation that still works functionally to everything outside... > > > On Mon, Aug 17, 2009 at 4:38 AM, Mark Engelberg > <mark.engelb...@gmail.com>wrote: > >> >> Here's what I've learned from following this benchmark thread: >> >> From the various things I've read about Clojure's performance, I've >> always had this sense that: >> a) if you have a performance problem, there's probably some inner loop >> that needs to be optimized, and so >> b) you can use Clojure's type-hinting or primitive-casting within that >> inner loop to get Java-like performance. >> >> But these benchmarks are showing that when it comes to performance >> degradation caused by boxing/unboxing primitives it doesn't always >> occur in a single loop that is easily optimized. The most obvious >> problem that is showing up in these benchmark examples is that often >> these primitives tend to be combined in manipulated as some kind of >> struct (e.g., an x,y,z vector). Or sometimes, the logic manipulating >> these primitives can't easily be described in a single loop, but is >> more easily expressed when spread out over several functions. But in >> Clojure, just about everything you do (other than let/loop/recur) >> boxes a primitive right back up again, making it very, very difficult >> to write performant code. Very often, primitives need to be combined >> as part of structured data, passed to a function, etc. >> >> So I agree with those who are pointing to these examples and saying, >> "Hey, what can we do to make it easier to optimize our Clojure >> programs, while maintaining the basic structure and feel of the code?" >> >> I think Nicolas Oury is right on when he suggests that adding a >> Clojure way to build structures with primitive fields would be a >> valuable addition from a performance-within-Clojure standpoint, >> allowing for more localized rewrites to boost performance. >> >> On Sun, Aug 16, 2009 at 12:52 PM, Meikel Brandmeyer<m...@kotka.de> wrote: >> > Why can't we write programs in Clojure and >> > drop down to Java if necessary? >> > >> > Sincerely >> > Meikel >> > >> > >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
