简体繁体 English

asm.js对编译器的限制

[英]asm.js limits on the compiler

原文 2013-04-12 13:22:17 0 2 javascript/ performance/ compiler-construction/ emscripten

I would like to know if there are any "limits by design" on the asm.js spec that would prevent any compiler to produce native assembly code directly from it. 我想知道asm.js规范中是否有任何“设计限制”会阻止任何编译器直接从它生成本机汇编代码。

For now firefox seems to be able to be half as fast as native code but I'm wondering why it does not run at native speed. 目前firefox似乎能够比本机代码快一半，但我想知道它为什么不以原生速度运行。 As I see it, asm.js resembles asm a lot.. 在我看来，asm.js很像..

2 个解决方案

The limit is currently using the Typed Array types of Javascript as memory ( stack and heap that is). 该限制目前使用Javascript的Typed Array类型作为内存（堆栈和堆）。 This is due to other scripts interacting with your asm.js generated Javascript, and needing a shared "memory" space. 这是因为其他脚本与您的asm.js生成的Javascript交互，并且需要共享的“内存”空间。 Besides I guess that Typed Array s are implemented as actual heap memory, which will be slower than using stack. 此外我猜测Typed Array被实现为实际堆内存，这将比使用堆栈慢。

Because Firefox's compiler doesn't do as many optimizations which benefit asm.js code as C compilers do. 因为Firefox的编译器没有像C编译器那样进行任何有益于asm.js代码的优化。 On Windows, also because compiled code has to perform bounds checks for array access (on other OSes OdinMonkey, Firefox's asm.js compiler, uses memory protection). 在Windows上，也因为已编译的代码必须执行数组访问的边界检查（在其他操作系统OdinMonkey上，Firefox的asm.js编译器使用内存保护）。