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

时间:2011-02-11 21:46:44

标签: compilation memory-footprint k

以下摘自Wikipedia entry on K programming language

  

该语言的小型解释器和紧凑语法使K应用程序完全适合处理器的1级缓存。

特别是K程序如此之小?如果在K中使用'运算符,在Haskell等编译函数语言中使用map,或者在C等编译命令式语言中使用等效for循环,我无法想象编译器生成从根本上不同的汇编代码或者在解释器的内部结构中发生的事情将与for循环非常不同。 K中有什么特别的东西可以使它的运行时和程序变得如此之小吗?

在SO上有类似的question,但那里的答案基本上没有澄清。

2 个答案:

答案 0 :(得分:1)

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

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

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

比较这个Java程序:

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

反对这个K程序产生相同的结果:

+/!100

正在执行的代码量相似,但程序所需的存储空间(更少打字!)要少得多。 K对于那些有重复性压力损伤的人来说非常棒。

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

但这只是语言中的倾向和最佳实践与K可执行文件本身的结合。如果您链接了大量的附加代码,特殊情况下的许多函数,并在访问数据之前随机化您的索引,那么您的程序将对缓存不如您所期望的那样友好。

答案 1 :(得分:1)

有很多方法可以生成非常紧凑的代码。例如,http://en.wikipedia.org/wiki/Threaded_code的Forth和类似的。很可能K被编译成某种形式。

相关问题