为什么这个初筛实施速度较慢？

Question

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

奇怪的是（至少对我而言），新的实现并没有更快，而是很多慢...

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

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

最好的问候，

阿诺·古德

; 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 会更快，因为它是更好的算法。

附：当我尝试（时间（筛 10000000））时，我的机器因堆栈溢出而崩溃，大概是因为它正在构建大量嵌套过滤器调用堆栈。你怎么跑了？

Answer 2

这种 Primative number 重数学的一些优化技巧：

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

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