在 SBCL 中进行多线程计算的正确方法

Question

上下文

我需要使用多线程进行计算。我使用 SBCL，可移植性不是问题。我知道bordeaux-threads 和lparallel 存在，但我想在特定SBCL 线程实现提供的相对较低级别上实现一些东西。我需要最大的速度，即使以牺牲可读性/编程工作为代价。

计算密集型操作示例

我们可以定义一个充分计算密集型的函数，该函数将从多线程中受益。

(defun intensive-sqrt (x)
  "Dummy calculation for intensive algorithm.
Approx 50 ms for 1e6 iterations."
  (let ((y x))
    (dotimes (it 1000000 t)
      (if (> y 1.01d0)
          (setf y (sqrt y))
          (setf y (* y y y))))
    y))

将每个计算映射到一个线程并执行

给定参数列表llarg 和函数fun，我们要计算nthreads 结果并返回结果列表res-list。这是我使用找到的资源得出的结论（见下文）。

(defmacro splice-arglist-help (fun arglist)
  "Helper macro.
   Splices a list 'arglist' (arg1 arg2 ...) into the function call of 'fun'
   Returns (funcall fun arg1 arg2 ...)"
  `(funcall ,fun ,@arglist))

(defun splice-arglist (fun arglist)
  (eval `(splice-arglist-help ,fun ,arglist)))

(defun maplist-fun-multi (fun llarg nthreads)
  "Maps 'fun' over list of argument lists 'llarg' using multithreading.
   Breaks up llarg and feeds it to each thread.
   Appends all the result lists at the end."
  (let ((thread-list nil)
        (res-list nil))
    ;; Create and run threads
    (dotimes (it nthreads t)
      (let ((larg-temp (elt llarg it)))
        (setf thread-list (append thread-list
                                  (list (sb-thread:make-thread
                                         (lambda ()
                                           (splice-arglist fun larg-temp))))))))
    ;; Join threads
    ;; Threads are joined in order, not optimal for speed.
    ;; Should be joined when finished ?
    (dotimes (it (list-length thread-list) t)
      (setf res-list (append res-list (list (sb-thread:join-thread (elt thread-list it))))))
    res-list))

nthreads 不一定与llarg 的长度匹配，但为了示例简单起见，我避免了额外的簿记。我也省略了用于优化的各种declare。

我们可以使用以下方法测试多线程并比较时间：

(defparameter *test-args-sqrt-long* nil)
(dotimes (it 10000 t)
  (push (list (+ 3d0 it)) *test-args-sqrt-long*))

(time (intensive-sqrt 5d0))
(time (maplist-fun-multi #'intensive-sqrt *test-args-sqrt-long* 100))

线程数相当多。我认为最佳方案是使用与 CPU 一样多的线程，但我注意到性能下降在时间/操作方面几乎不明显。执行更多操作将涉及将输入列表分解为更小的部分。

以上代码输出，在 2 核/4 线程机器上：

Evaluation took:
  0.029 seconds of real time
  0.015625 seconds of total run time (0.015625 user, 0.000000 system)
  55.17% CPU
  71,972,879 processor cycles
  22,151,168 bytes consed

Evaluation took:
  1.415 seconds of real time
  4.703125 seconds of total run time (4.437500 user, 0.265625 system)
  [ Run times consist of 0.205 seconds GC time, and 4.499 seconds non-GC time. ]
  332.37% CPU
  3,530,632,834 processor cycles
  2,215,345,584 bytes consed

什么困扰着我

我给出的示例运行良好且功能强大（即结果不会在线程之间混淆，并且我没有遇到崩溃）。速度增益也在那里，并且计算确实在我测试过这段代码的机器上使用了几个内核/线程。但有几件事我想就以下几点提出意见/帮助：

1. 参数列表llarg和larg-temp的使用。这真的有必要吗？有什么方法可以避免操纵可能很大的列表？
2. 线程按照它们在thread-list 中的存储顺序进行连接。我想如果每个操作都需要不同的时间来完成，这将不是最佳的。有没有办法在完成后加入每个线程，而不是等待？

答案应该在我已经找到的资源中，但我发现更高级的东西很难解决。

目前找到的资源

• http://www.sbcl.org/manual/#Threading
• http://cl-cookbook.sourceforge.net/process.html
• https://lispcookbook.github.io/cl-cookbook/process.html

Answer 1

风格问题

• splice-arglist 助手根本不需要（所以我也将跳过其中的细节）。在你的线程函数中使用apply：

  (lambda ()
    (apply fun larg-temp))
  

• 您不需要（也不应该）对列表进行索引，因为每次查找都是 O(n) - 您的循环是二次的。使用dolist 进行简单的侧有效循环，或者使用loop 当你有e。 G。并行迭代：

  (loop :repeat nthreads
        :for args :in llarg
        :collect (sb-thread:make-thread (lambda () (apply fun args))))
  

• 要在创建相同长度的新列表时遍历列表，其中每个元素都是根据源列表中的相应元素计算的，请使用mapcar：

  (mapcar #'sb-thread:join-thread threads)
  

你的功能因此变成：

(defun map-args-parallel (fun arglists nthreads)
  (let ((threads (loop :repeat nthreads
                       :for args :in arglists
                       :collect (sb-thread:make-thread
                                 (lambda ()
                                   (apply fun args))))))
    (mapcar #'sb-thread:join-thread threads)))

性能

你说得对，一个人通常只创建与 ca 一样多的线程。可用的核心数。如果您总是通过创建 n 个线程来测试性能，然后加入它们，然后进入下一批，那么您的性能确实不会有太大差异。那是因为低效率在于创建线程。线程与进程一样占用资源。

通常做的是创建一个线程池，其中线程不会加入，而是重复使用。为此，您需要一些其他机制来交流论点和结果，例如。 G。频道（例如来自chanl）。

但请注意，e。 G。 lparallel 已经提供了一个 pmap 函数，而且它做对了。此类包装库的目的不仅是为用户（程序员）提供一个漂亮的界面，而且还要认真思考问题并进行明智的优化。我非常有信心pmap 会比您的尝试快得多。