不同解释器/编译器的程序内存占用

Question

以下是摘自 维基百科k编程语言条目:

解释器的小尺寸和语言的紧凑语法使K应用程序完全适合处理器的一级缓存成为可能。

是什么特别使K程序如此之小？当一个人使用 ' k中的操作员, map 在编译函数式语言中，如Haskell，或等效语言 for 循环在像C这样的编译命令式语言中，我无法想象任何编译器生成 从根本上说 不同的汇编代码或解释器内部发生的事情将与 for 循环。K中有什么特别的东西使它的运行时间和程序如此之小吗？

有一个类似的 问题 所以，但那里的答案基本上没有澄清任何事情。

Answer 1

有很多方法可以生成一个非常紧凑的代码。例如，一个 http://en.wikipedia.org/wiki/Threaded_code 前后一致。很可能K被编译成某种形式。

Answer 2

我不是上面维基百科声明的作者，只是一个广泛使用K的人。

至于代码，K不是展开循环或对程序结构进行其他更改，这些更改会增加它的大小超出您的预期。可执行解释器本身很小。而且程序往往很小（虽然不一定如此）。不是执行任何特定的指令进行映射等。这使得代码本身更有可能在缓存中执行所有代码。

K程序往往很小，因为它们是存储中的小而紧密的字节码，并且它们的语法往往会为给定的操作产生非常少量的代码。

比较一下这个Java程序:

int r=0;
for(int i=0; i<100; i++) {
  r+=i;
}

对此K程序产生相同的结果:

+/!100

正在执行的代码量相似，但程序所需的存储（更不用说打字了！）要少得多。K对于那些有重复性压力损伤的人来说是很好的.

至于数据，鼓励使用单个指令处理多个数据项倾向于使访问顺序，以对缓存友好的方式，而不是随机访问。所有这些只是使程序更有可能缓存友好。

但这一切都只是语言内的倾向和最佳实践与K可执行文件本身相结合。如果您在访问数据之前链接大量额外的代码，特殊情况下的大量函数，并随机化索引，您的程序将像您期望的那样对缓存不友好。