Fork me on GitHub

I know the full answer is "run performance tests and see", and/or "read the byte code produced by the Clojure compiler and think hard", but was looking for maybe quicker advice here. If there is some Clojure/Java code that frequently pulls 32-bit int's out of arrays, puts them into let-bound symbols, does a little bit of arithmetic and/or comparisons on them, and sometimes stores them back into int arrays, it is going to be perfectly normal to get boxed math warnings when one compiles the code using (set! *unchecked-math* :warn-on-boxed).


I believe that fn parameters can be type-hinted to be long or double primitive types, and the Clojure compiler can support passing those unboxed.


Can it support let-bound symbols as 32-bit int, unboxed? Or is that also restricted to long and double?


If not, then I am guessing perhaps the most efficient code can be produced in this scenario by converting to primitive long when pulling ints out of the arrays, manipulating them as long, then converting them back to int just before storing them back into int array.

Alex Miller (Clojure team)18:08:16

let bound symbols can be int prims I think


ok, good for me to do some focused experiments around that to verify it.

Alex Miller (Clojure team)18:08:57

the first 2 bullets there being the important ones


Resisting the urge to see when those docs were last updated -- They are definitely getting more impressive over time. Thanks!

Alex Miller (Clojure team)18:08:55

that's been there since 1.3 I think


FYI John Rose the JVM architect just filed an issue where hotspot doesn't apply loop optimizations when the trip counter is a long, only when it's an int


Yes, this is related to such loops being considered "uncounted" . Some more surprising examples here: ("Counted Loops?" section) Also here some notes about uncounted loops and their negative impact on optimizations: (search for "negated")


That comment of mine was intended to express: "Wow, that is more than I remember reading there before, which may have been a long time ago", not "that looks old/out of date"

Alex Miller (Clojure team)18:08:54

I believe it is still accurate

Alex Miller (Clojure team)18:08:27

but I would check the generated bytecode to be sure

Alex Miller (Clojure team)18:08:06

I believe the intention is that you should be able to write hot loops on primitives though if you are sufficiently careful to avoid boxed calls


Excellent. Hopefully I can make this thing sing.


0x000000011f8aced3: vmovdqu ymm0,YMMWORD PTR [r12+r10*8+0x10]
  0x000000011f8aceda: vmovdqu ymm1,YMMWORD PTR [r12+r8*8+0x10]
  0x000000011f8acee1: vpaddd ymm0,ymm1,ymm0
  0x000000011f8acee5: vmovdqu YMMWORD PTR [rax+0x10],ymm0


that’s what I like to see! godmode


so it does inline across Fn's


that will be huge for Tensorflow-like libs on the JVM


Java’s gettin’ fast


and so is Clojure it seems 😄


There is some odd edge cases on comment+reader-macro ( {:read-cond :allow} "[#_#?(:foo [])]")


that's pretty weird


I think it makes sense


there's no :clojure expansion


so it's equivalent to [#_]

👍 4
Alex Miller (Clojure team)21:08:34

#?(:foo []) yields nothing read

Alex Miller (Clojure team)21:08:15

not nil, but literally nothing


reading [#_#?(:foo 42) 43 44] might make the behavior clear

Alex Miller (Clojure team)21:08:34

you could throw a :default branch in there to actually read as nil

Alex Miller (Clojure team)21:08:37

(read-string {:read-cond :allow} "[#_#?(:foo [] :default nil)]")