不同解释器/编译器的程序内存占用
-
12-11-2019 - |
题
以下是摘自 维基百科k编程语言条目:
解释器的小尺寸和语言的紧凑语法使K应用程序完全适合处理器的一级缓存成为可能。
是什么特别使K程序如此之小?当一个人使用 '
k中的操作员, map
在编译函数式语言中,如Haskell,或等效语言 for
循环在像C这样的编译命令式语言中,我无法想象任何编译器生成 从根本上说 不同的汇编代码或解释器内部发生的事情将与 for
循环。K中有什么特别的东西使它的运行时间和程序如此之小吗?
有一个类似的 问题 所以,但那里的答案基本上没有澄清任何事情。
解决方案
有很多方法可以生成一个非常紧凑的代码。例如,一个 http://en.wikipedia.org/wiki/Threaded_code 前后一致。很可能K被编译成某种形式。
其他提示
我不是上面维基百科声明的作者,只是一个广泛使用K的人。
至于代码,K不是展开循环或对程序结构进行其他更改,这些更改会增加它的大小超出您的预期。可执行解释器本身很小。而且程序往往很小(虽然不一定如此)。不是执行任何特定的指令进行映射等。这使得代码本身更有可能在缓存中执行所有代码。
K程序往往很小,因为它们是存储中的小而紧密的字节码,并且它们的语法往往会为给定的操作产生非常少量的代码。
比较一下这个Java程序:
int r=0;
for(int i=0; i<100; i++) {
r+=i;
}
对此K程序产生相同的结果:
+/!100
正在执行的代码量相似,但程序所需的存储(更不用说打字了!)要少得多。K对于那些有重复性压力损伤的人来说是很好的.
至于数据,鼓励使用单个指令处理多个数据项倾向于使访问顺序,以对缓存友好的方式,而不是随机访问。所有这些只是使程序更有可能缓存友好。
但这一切都只是语言内的倾向和最佳实践与K可执行文件本身相结合。如果您在访问数据之前链接大量额外的代码,特殊情况下的大量函数,并随机化索引,您的程序将像您期望的那样对缓存不友好。