为什么lisp，或者说common lisp现在这么冷门呢？

[Soul-Clinic]

这些语言说白了就是给汇编做翻译嘛

看语言的翻译水平了，有些语言对机器翻译得可能没那么强，但你可以说得比较简单

[cireu]

为什么lisp，或者说common lisp现在这么冷门呢？

OBJ family 完全基于 reduction 和 term rewrite，立足于数学而独立于 Von Neumann 存在。 op nil : -> List . op _._ : Qid List -> List op length : List -> Nat . op _in_ : Qid List -> Bool . vars I J : Qid . var L : List . eq length(nil) = 0 . eq length(I . L) = s length(L) . eq I in nil = false . eq I in J . L = (I == J) or (I in L) . execution(reduction): length(’a . ’b . ’c . nil) = s length(’b . ’c . nil) = s s length(’c . nil) = s s s length(nil) = s s s 0

一看你就没好好看帖子

[Soul-Clinic]

或许这问题关键是，现在用的操作系统就是用C来开发的，如果是在一个CL开发的操作系统，结果可能就另算了

[finalpatch]

跟系统一点关系都没有。上述这些运算密集的应用都完全不调用系统，纯看你能把硬件的潜力发挥到什么程度。如果你写过这样的东西就知道，在内循环里是连函数调用都不可以有的，因为一个函数调用的开销可能比整个循环体还要高。

[tumashu]

我的粗浅感觉是，如果一个程序，不太关注性能，安全性等非功能需求，它的代码就比较容易理解，反之，就及其难理解

[Soul-Clinic]

呃，循环调用和函数都是个GOTO吧？ 可能是因为函数要多分配个栈，所以慢了些？（个人浅薄理解，当然我知道在我们基本每个语言的代码里调用函数是要比 inline 多一些成本开支）

[Soul-Clinic]

说白了，就是我们现在的软件（编译器）还不够智能吧，经常要加一些optimize 参数来提醒它
就像我们写的文章，是比较精简字数少的质量更高
但对编译器来说，还是比较长篇的死板单调的更好！

[finalpatch]

@Soul-Clinic

呃，循环调用和函数都是个GOTO吧？ 可能是因为函数要多分配个栈，所以慢了些？（个人浅薄理解）

1. 函数调用需要把参数压栈，5个参数就是5条指令压栈，假如我的循环体一共才5条指令呢，岂不是翻倍了？
2. 工作变量本来都在CPU寄存器里，先压栈，到函数里再读回来，浪费内存带宽，性能大破
3. 在比较简单的处理器上函数调用可能导致指令缓存miss，性能大破
4. 在先进的处理器上，分支预测往往可以防止指令缓存miss，但是如果调用的函数需要通过动态分派(例如调用对象的多态函数)那分支预测就可能失败。

[LdBeth]

1. inline 这种简单的工作今天只要是个编译器都会做，Haskell 更是默认所有函数做 inline。
2. 你当虎书，鯨书讲的 register allocation 是做什么的，只要编译到 SSA，作为个 NP approx. problem 手工比用算法做提升不了多少。
3. 比较简单的处理器不需要性能，要的不过是 real time
4. 用 Whole Program Optimization 可以把 dynamic dispatch 优化成 direct method call，Swift 就是这么做的。

说白了就是编译器不够先进。

[Soul-Clinic]

是的，毕竟编译器还很young，跟“数学”，“物理”这些比起来，就是个三岁小毛孩

[finalpatch]

@LdBeth

1. inline 这种简单的工作今天只要是个编译器都会做，Haskell 更是默认所有函数做 inline。
2. 你当虎书，鯨书讲的 register allocation 是做什么的，只要编译到 SSA，作为个 NP approx. problem 手工比用算法做提升不了多少。
3. 比较简单的处理器不需要性能，要的不过是 real time
4. 用 Whole Program Optimization 可以把 dynamic dispatch 优化成 direct method call，Swift 就是这么做的。

说白了就是编译器不够先进。

说的就是在高强度内循环里所有的函数都要确保inline，在C/C++之外的语言里大多数都不提供这种“保证”。比较简单的处理器也需要性能，因为牵涉到你能用5块钱的芯片搞定还是非得用20块的。不是所有的动态分配都能devirtualize的，如果能静态证明你只走一条路那就可以，如果有3条路，走哪条取决于输入数据，那就不可能devirtualize。

[finalpatch]

@LdBeth

说白了就是编译器不够先进。

LISP这样高度动态的语言编译器很难做啊，因为你给它的信息太少了，它能推导出的东西有限。这就是为啥SBCL让你到处加类型标注。你要是真按它要求的这么干了，性能倒是能上去一大截，但是你会想写成这样我他妈为什么还要用LISP。

[cireu]

@finalpatch

在C/C++之外的语言里大多数都不提供这种“保证”

C艹的inline我记得是advice而不是instructment。非要说，rust有#[inline(always)]

@finalpatch

如果能静态证明你只走一条路那就可以，如果有3条路，走哪条取决于输入数据，那就不可能devirtualize。

我觉得能静态证明的场合和能人肉控制的场合是一样的

[finalpatch]

@cireu

C艹的 inline 我记得是advice而不是instructment。非要说，rust有 #[inline(always)]

标准C++不支持强制内联，但是所有的编译器都提供 gcc/clang有__attribute__((always_inline)). VC++有__forceinline.

[Soul-Clinic]

可以的吧，也可以把那些常用的配置选项（optimize）封装到一个函数（或者macro）里吧？
编译器知道可能99%+都是可以优化不会错的，但是即使只有1%的错，这99%的优化也赔不起

我觉得即使要这样做，对同一件事你用Lisp都要比C/C++快速很多吧？（假设你在Lisp和C/C++都是老司机）

[LdBeth]

@finalpatch

LISP这样高度动态的语言编译器很难做啊，因为你给它的信息太少了，它能推导出的东西有限。

你问能不能做，Stalin Scheme 就是个“能完全静态化”的例子，它连类型标注都不用写，自动就能推。至于为什么不用，编译时间又不是完全不重要，都比 Rust 慢了，我干嘛不用类型安全而且有个牛爹的 Rust。

都 9012 了，绝大多数場合人的时间比机器贵。 至于机器时间比人贵的場合，写程序的人心里会沒数？

---

回錯人了

[glgl-schemer]

clang其实不辣，辣的是llvm。

[finalpatch]

@LdBeth

Stalin Scheme 就是个“能完全静态化”的例子

这种毫无用处的东西C++也能搞啊，来来给你看个纯静态的贪吃蛇 GitHub - mattbierner/STT-C-Compile-Time-Snake: Snake/Nibbler implementation using C++ template metaprogamming 喏，还有纯静态的连连看 Jean Guegant's Blog – Meta Crush Saga: a C++17 compile-time game

[LdBeth]

你给的完全不是一个级別的。

我就这么说吧，ECC 能像你给的那样“静态化”么

[cireu]

哪啥，whole program optimization在C/C++里又叫Link Time Optimization。和这个静态贪吃蛇完全跟不上号。