common-lisp - 为什么不能并行执行编译文件?

标签 common-lisp sbcl

我有一个项目,其中有很多文件不是​​由 ASDF 管理的,而是手动编译的。这些文件是完全独立的,能够并行编译它们对我来说似乎是一种减少编译时间的方法。我的计划是并行编译这些文件,然后顺序加载生成的 FASL 文件。但是在我并行编译之后,我发现性能提升几乎为零。然后我去了 SBCL 资源,发现 compile-file takes a world lock ,这实质上是顺序编译。

我的问题是,compile-file 获取这个锁的原因是什么?虽然并行加载 FASL 确实会导致一些竞争条件,但在我看来,Lisp 文件的编译应该是独立的和可并行的。

最佳答案

可以从该语言访问编译器。您可以进行编译时编程,使用编译器宏等。作为示例,有 (eval-when (:compile) …)。一般来说,您不能排除编译时的影响,这必须在任何地方都是线程安全的。我猜想使这种强大的努力比人们愿意投资的要大得多。

不过,您也许可以启动多个 Lisp 镜像进行并行编译。您只需要在编排时处理依赖关系图。

更新:我刚刚偶然发现一段对话似乎暗示 SBCL 比我想象的更接近摆脱那个锁:https://sourceforge.net/p/sbcl/mailman/message/36473674/

关于common-lisp - 为什么不能并行执行编译文件?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52987524/

相关文章:

lisp - sbcl(目录 "*")未返回所有文件(例如缺少 *.lisp)

multithreading - 如何正确终止阻塞的线程(Lparallel Common Lisp)

lisp - Common Lisp 中的 Web 开发

LISP--传递一个结构组件,而不是组件的值

lisp - Common Lisp 相当于 Racket 的 "module languages"

debugging - 在中断时抑制某些 SBCL 调试器输出

arrays - 为什么常量不能用作 Common Lisp 类型说明符中的数组维度?

io - 未读字符行为偏离规范?

class - 使用类的 Common Lisp 替代方案

common-lisp - sbcl 上的 undefined variable ,而不是 clisp 上的 undefined variable