On Thu, Dec 15, 2011 at 10:13 PM, David Nolen <dnolen.li...@gmail.com> wrote: > Nobody wants map-longs. We have lovely abstractions like map / filter / > reduce, we have primitive fns, we have collections which can hold > primitives, we have type hints. > > What I'd like to see is that by adding one single annotation to this > > (reduce + foo) > > like so: > > (reduce + ^long-vector foo) > > triggers the compiler to eliminate all unnecessary allocations and work only > on unboxed data. Another approach might be some of Rich Hickey's ideas of > about primitive fns that understand chunks. > > Do your ideas get us any closer to writing idiomatic Clojure yet getting > close to the performance of primitive operations on collections of unboxed > data?
They certainly don't get us any further; they aren't trying to address that at all, but instead to address other issues, such as that if I have a function that takes five values I can't optimize it. For instance, if I want to optimize (distance x1 y1 z1 x2 y2 z2), I can't. If I declare anything primitive, the compiler complains as there are more than four arguments. If I change the input format to (distance [x1 y1 z1] [x2 y2 z2]) the numbers are boxed as collection elements, though at least I can now make the return be hinted as ^double without the compiler complaining. Short of creating a Point3D deftype with primitive components, there doesn't seem to be a way with Clojure 1.3 to optimize this; and having to create lots of helper types like Point3D smacks of Java-like coding instead of Clojure-like coding to me. So, I can wait until either larger numbers of primitive arguments are supported, or primitive vectors are supported. But I can see how to support larger numbers of primitive arguments *tomorrow* -- it probably would be that fast to code, for someone already knowledgeable about Clojure's internals and with commit access to the repository. I *can't* see how to easily support collections-of-primitives without a *lot* more work, including new syntax, in a *lot* of parts of the language core, with a *lot* more likely damage to backward compatibility. So there is my argument in a nutshell. There's an improvement we can make *now*, *without* foreclosing on an improvement that *may* be possible *in a few years or so*, and that would make mine, and probably others', projects easier to optimize *now*, and which therefore *should* be made, and quickly. -- 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
