不同解释器/编译器的程序内存占用
以下是关于 K 编程语言的维基百科条目的摘录：
解释器的小尺寸和语言的紧凑语法使得 K 个应用程序完全适合处理器的 1 级缓存。
是什么让 K 程序如此之小？当人们在 K 中使用 ' 运算符、在 Haskell 等编译函数语言中使用 map 或在 C 等编译命令式语言中使用等效的 for 循环时，我无法想象编译器会生成完全不同的汇编代码，或者解释器内部发生的情况将与 for 循环有很大不同。 K 有什么特别的地方使得它的运行时间和程序如此之小吗？
SO上有一个类似的问题，但那里的答案基本上没有澄清任何内容。
Here's an excerpt from the Wikipedia entry on K programming language:
The small size of the interpreter and compact syntax of the language makes it possible for K applications to fit entirely within the level 1 cache of the processor.
What in particular makes K programs so small? When one uses ' operator in K, map in compiled functional language like Haskell, or equivalent for loop in a compiled imperative language like C, I can't imagine either compiler generating radically different assembly code or that what happens in interpreter's internals will be very different from for loop. Is there anything special in K that makes its runtime and programs so small?
There's a similar question on SO, but the answers there basically clarify nothing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不是上面维基百科声明的作者，只是广泛使用 K 的人。
至于代码，K 不会展开循环或对程序结构进行其他更改，从而使其大小超出您的预期。可执行解释器本身很小。而且程序往往很小（尽管不一定如此）。并不是执行任何特定的映射指令等，使得代码本身更有可能在缓存中执行所有指令。
K 程序往往很小，因为它们在存储中是小而紧凑的字节码，并且它们的语法往往会为给定操作生成非常少量的代码。
比较这个 Java 程序：
与这个 K 程序产生相同的结果：
执行的代码量相似，但程序所需的存储（更少的打字！）要少得多。 K 对于那些患有重复性压力损伤的人来说非常有用。
至于数据，鼓励使用单个指令处理多个数据项往往会以对缓存友好的方式进行顺序访问，而不是随机访问。所有这些只是使程序更有可能是缓存友好的。
但这只是该语言与 K 可执行文件本身相结合的趋势和最佳实践。如果您链接大量附加代码、特殊情况下的大量函数，并在访问数据之前随机化索引，则您的程序将像您期望的那样对缓存不友好。
I am not the author of the wikipedia statement above, just somebody who uses K extensively.
As for code, K is not unrolling loops or making other changes to the program structure that would increase it in size beyond what you're expecting. The executable interpreter itself is tiny. And the programs tend to be small (though not necessarily so). It's not the execution of any particular instructions for mapping, etc. that make it more likely that the code itself will execute all within cache.
K programs tend to be small because they are a small, tight bytecode in storage, and their syntax tends to yield very small amounts of code for a given operation.
Compare this Java program:
Against this K program to yield the same result:
The amount of code being executed is similar, but the storage required by the program (much less typing!) is far less. K is great for those with repetitive stress injuries.
As for the data, the encouragement to work on multiple data items with single instructions tends to make access sequential, in a manner friendly to the cache, rather than random access. All of this merely makes it more likely that the program will be cache friendly.
But this is all just tendencies and best practices within the language in combination with the K executable itself. If you link in large amounts of additional code, special case lots of functions, and randomize your indices before accessing your data, your program will be just as unfriendly to the cache as you'd expect.
有多种方法可以生成非常紧凑的代码。例如，Forth 等的 http://en.wikipedia.org/wiki/Threaded_code 。 K 很可能被编译成它的某种形式。
There are ways of generating a very compact code. For example, a http://en.wikipedia.org/wiki/Threaded_code of Forth and alike. It is likely that K is compiled into some form of it.