Project Euler #10 (sum of primes less than two million) in Clojure
I won't comment on the Java bit because I don't write Java very often. I agree with the other answer though that sqrt should only be called once. Computing the sqrt of a number is relatively expensive.



First, for Clojure, a baseline on my computer:

(defn sieve [size]
    (-&gt; (reduce (fn [prev i]
                  (if (prev i)
                    (vec (reduce #(assoc %1 %2 false)
                                 prev
                                 (range (+ i i) size i)))
                    prev))
                (vec (repeat size true))
                (range 2 (-&gt; size Math/sqrt int inc)))
        vec
        (assoc 0 false)
        (assoc 1 false)))

(defn main []
  (time
    (let [limit 2000000
          s (sieve limit)]
      (reduce #(+ %1 (if (s %2) %2 0))
              0 (range limit)))))

; From REPL
(main)
"Elapsed time: 2274.584779 msecs"
=&gt; 142913828922


I should note that I'm on a crappy M3 Surface Pro 4; not a power machine by a stretch of any definition. If this is taking 14 seconds, you must have something else going on. That's far too long.



I actually prefer wrapping threading calls in parenthesis, even if they aren't required. I'd write lines such as (-&gt; size Math/sqrt int inc) as (-&gt; size (Math/sqrt) (int) (inc)). I find it helps differentiating between the form being a plain function call, and the threading of a value. The only time I omit them is when I'm golfing.



Your nested reduction is a lot going on in only a few lines. I would definitely break the inner reduction off into its own function, give it a descriptive name, and call it in the outer reduction.

(defn calc [size i prev] ; Although give it a better name
  (vec (reduce #(assoc %1 %2 false)
               prev
               (range (+ i i) size i))))

(defn sieve [size]
    (-&gt; (reduce (fn [prev i]
                  (if (prev i)
                    (calc size i prev)
                    prev))
                (vec (repeat size true))
                (range 2 (-&gt; size Math/sqrt int inc)))
        vec
        (assoc 0 false)
        (assoc 1 false)))


I like breaking functions up. Having giant functions forces you to consider a large amount of data and interactions at once. If you split a part off into its own function and ensure that it's pure, you know that no code in that function can manipulate any data that you haven't explicitly given it as a parameter. That's one less bit of the code to need to look at when debugging.



For your second bit, interestingly, it performed the same for me:

(main) ; Using your arrays version
"Elapsed time: 2106.530431 msecs"
=&gt; 142913828922


You're making a critical error though when dealing with arrays in Clojure: don't use aset unless you have to. aset works on Objects, not primitives, as its documentation notes:


  Sets the value at the index/indices. Works on Java arrays of
    reference types. Returns val.


Using aset forces your bools to be boxed into a Boolean, which is pricey when done over and over. aset has multiple overloads for primitive types that should be used instead. I'd switch to aset-boolean, and create the array using boolean-array instead:

(defn sieve2 [size]
  (-&gt; (let [ar (boolean-array (repeat size true))]
        (dorun (map (fn [i]
                      (when (aget ar i)
                        (dorun (map (fn [j] (aset-boolean ar j false))
                                    (range (+ i i) size i)))))
                    (range 2 (-&gt; size Math/sqrt int inc))))
        ar)
      vec
      (assoc 0 false)
      (assoc 1 false)))

(defn main []
  (time
    (let [limit 2000000
          s (sieve2 limit)]
      (reduce #(+ %1 (if (s %2) %2 0))
              0 (range limit)))))

(main)
"Elapsed time: 759.412393 msecs"
=&gt; 142913828922


A little better. I'll also note though that use of (dorun (map is usually a code smell. You're better off just using mapv which is strict. Using laziness when you don't need it can be costly. maping isn't the right tool here for the job anyways. Use map when you want to transform a list. Use doseq when you want to carry out side effects over a list. Think of it as Java's enhanced for-loop. I'm also using doseq's :when clause to replace the use of the when macro:

(defn sieve2 [size]
  (let [ar (boolean-array (repeat size true))]
    (doseq [i (range 2 (-&gt; size (Math/sqrt) (int) (inc)))
            :when (aget ar i)] ; Replacing the call to when
      (doseq [j (range (+ i i) size i)]
        (aset-boolean ar j false)))

    (-&gt; ar
        (vec)
        (assoc 0 false)
        (assoc 1 false))))

(main)
"Elapsed time: 577.607879 msecs"
=&gt; 142913828922


Still not great, but better.



Just for a laugh comparison, here's a implementation of Eratosthenes' Sieve I wrote back in April:

(defn sieve-primes [n]
  (loop [p 2 ; First prime
         marked #{} ; Found composites
         primes []]
    (let [mults (-&gt;&gt; n
                     (range p)
                     (map #(* p %))
                     (take-while #(&lt; % n)))

          next-p (-&gt;&gt; p
                      (inc)
                      (iterate inc)
                      (remove marked)
                      (first))

          new-primes (conj primes p)]

      (if (&gt;= next-p n)
        new-primes
        (recur next-p (into marked mults) new-primes)))))

(time
  (apply + (sieve-primes 2000000)))
"Elapsed time: 8719.010487 msecs"
=&gt; 142913828922


Ouch! I don't think I tried very hard to get it lower though. That was the first time I had ever written the sieve in any language, and was happy with just having a working implementation at the time. It is pretty though, even if it's slow.



Clojure is really not a performance-oriented language though. Yes, you can add all sorts of optimizations to make good use of all cores and limit intermediate lists when doing transformations, but it generally won't perform as well as other languages. It's generally even slower than Java of all languages in my experience. I write Clojure because it's fun to write and produces nice looking code, not because it produces fast code.