为什么这个素数筛的实现速度较慢？

Question

我只是（对我来说）尝试了一种新的编程语言：clojure。我编写了一个相当幼稚的“筛子”实现，然后我尝试对其进行一些优化。

但奇怪的是（至少对我来说），新的实现并没有更快，而是慢得多......

任何人都可以提供一些关于为什么慢得多的见解吗？

我也对如何改进该算法的其他技巧感兴趣......

最诚挚的问候，

Arnaud Gouder

; naive sieve. 
(defn sieve
  ([max] (sieve max (range 2 max) 2))
  ([max candidates n]
    (if (> (* n n) max)
      candidates
      (recur max (filter #(or (= % n) (not (= (mod % n) 0))) candidates) (inc n)))))

; Instead of just passing the 'candidates' list, from which I sieve-out the non-primes,
; I also pass a 'primes' list, with the already found primes
; I hoped that this would increase the speed, because:
; - Instead of sieving-out multiples of 'all' numbers, I now only sieve-out the multiples of primes.
; - The filter predicate now becomes simpler.
; However, this code seems to be approx 20x as slow.
; Note: the primes in 'primes' end up reversed, but I don't care (much). Adding a 'reverse' call makes it even slower :-(
(defn sieve2 
  ([max] (sieve2 max () (range 2 max)))
  ([max primes candidates]
    (let [n (first candidates)]
      (if (> (* n n) max)
        (concat primes candidates)
        (recur max (conj primes n) (filter #(not (= (mod % n) 0)) (rest candidates)))))))

; Another attempt to speed things up. Instead of sieving-out multiples of all numbers in the range,
; I want to sieve-out only multiples of primes.. I don't like the '(first (filter ' construct very much...
; It doesn't seem to be faster than 'sieve'.
(defn sieve3
  ([max] (sieve max (range 2 max) 2))
  ([max candidates n]
    (if (> (* n n) max)
      candidates
      (let [new_candidates (filter #(or (= % n) (not (= (mod % n) 0))) candidates)]
        (recur max new_candidates (first (filter #(> % n) new_candidates)))))))

(time (sieve 10000000))
(time (sieve 10000000))
(time (sieve2 10000000))
(time (sieve2 10000000))
(time (sieve2 10000000))
(time (sieve 10000000)) ; Strange, speeds are very different now... Must be some memory allocation thing caused by running sieve2
(time (sieve 10000000))
(time (sieve3 10000000))
(time (sieve3 10000000))
(time (sieve 10000000))

Answer 1

我有好消息和坏消息。好消息是你的直觉是正确的。

(time (sieve 10000)) ; "Elapsed time: 0.265311 msecs"

(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211 223 227 229 233 239 241 251 257 263 269 271 277 281 283 293 307 311 313 317 331 337 347 349 353 359 367 373 379 383 389 397 401 409 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499 503 509 521 523 541 547 557 563 ...)

(time (sieve2 10000)) ; "Elapsed time: 1.028353 msecs"

(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211 223 227 229 233 239 241 251 257 263 269 271 277 281 283 293 307 311 313 317 331 337 347 349 353 359 367 373 379 383 389 397 401 409 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499 503 509 521 523 541 547 557 563 ...)

坏消息是，两者都比您想象的要慢得多。

(time (count (sieve 10000))) ; "Elapsed time: 231.183055 msecs"
1229

(time (count (sieve2 10000))) ; "Elapsed time: 87.822796 msecs"
1229

发生的情况是，由于过滤器是惰性的，因此在需要打印答案之前过滤不会完成。第一个表达式所计算的就是将序列包装在过滤器负载中的时间。将计数放入意味着实际上必须在计时表达式内计算序列，然后您就会看到它实际需要多长时间。

我认为在没有计数的情况下，sieve2 需要更长的时间，因为它在构建过滤序列时做了一些工作。

当您输入计数时，sieve2 更快，因为它是更好的算法。

PS 当我尝试 (time (sieve 10000000)) 时，我的机器因堆栈溢出而崩溃，大概是因为它正在构建大量嵌套过滤器调用。怎么跑给你了？

Answer 2

对于这种原始数字重数学的一些优化技巧：

1. 使用 clojure 1.3
   clonjure 1.3 允许取消装箱检查算术，因此您不会将所有内容转换为整数。
2. 键入提示函数参数
   否则，每次函数调用时，您最终都会将所有 Ints/Longs 转换为 Integer。 （您没有调用任何可提示的函数，因此我只是将其列为一般建议）
3. 不要调用任何高阶函数。
   目前 (1.3) lambda 函数 #( ...) 无法编译为 ^static，因此它们只接受 Object 作为参数。因此，对 filter 的调用将需要对所有数字进行装箱。

您可能会在装箱/拆箱整数/整数方面浪费足够的时间，这将使得很难真正判断不同的优化。如果您输入提示（并使用 clojure 1.3），那么您可能会得到更好的数字来判断您的优化。