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

Reply via email to