So you propose this: user=> (time (dotimes [i 10000000] (let [ a (Integer. 1) b (Integer. 2)] (+ a b)))) "Elapsed time: 31.14886 msecs" nil
Instead of this: user=> (time (dotimes [i 10000000] (let [ a 1 b 2] (+ a b)))) "Elapsed time: 15.680386 msecs" nil Using a wrapper instead of a primitive type as a significant cost in a computation. One of the purpose of normalizing to 64 bits was to get maximum performance for compute bound Clojure applications. Computing with wrappers is inefficient. Your proposal looks only at one facet of the whole problem. It's not a Java centric issue, it's a Clojure performance enhancement. You are coding in Clojure, not in Java. It happens that Clojure reuses some native types efficiently implemented by the JVM and used by Java (String, long, ....) but not all of them. Let's say one day you end up coding in ClojureScript or Clojure on JS, what do you prefer ? Deal with idiosyncrasies of the underlying environment or have a consistent implementation that provides the best performance for that given pseudo-metal ? What about the day that long long (128 bits) comes around ? Clojure will drag behind because it's carrying 32 bit values ? Obviously it creates issues when you work at the fringe but interop is not the purpose of Clojure. It happens to be much more easier to access the "outside" world than in other environments but it cannot justify to compromise the performance or feature list of Clojure. Luc P. On Thu, 20 Oct 2011 13:11:40 -0700 (PDT) nathanmarz <nathan.m...@gmail.com> wrote: > I'm not sure we're arguing about the same thing. I think that Clojure > only supporting 64 bit primitive arithmetic is fine, and I'm not > proposing that it support 32 bit primitive arithmetic. The sole point > of contention is what Clojure does when it has to box a primitive int. > I think this is orthogonal to primitive args/return, but correct me if > I'm wrong. > > Right now, it boxes ints as a Long, which I think is changing the > type. My proposal is that it box ints as Integer objects. Would > changing the behavior in this way cause a fundamental performance > limitation in Clojure? > > -Nathan > > > > > On Oct 20, 12:50 pm, David Nolen <dnolen.li...@gmail.com> wrote: > > On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz <nathan.m...@gmail.com> > > wrote: > > > But Clojure is already inconsistent. ints and Integers in interop > > > are treated differently. The only way to make Clojure consistent > > > is to either: > > > > Clojure is consistent. Whether or not that makes *interop* easier > > or harder is orthogonal. > > > > You do know that Clojure now supports primitive args and return, > > right? How is what you proposing going to be reconciled with that? > > > > David > -- Luc P. ================ The rabid Muppet -- 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
