在Erlang和OTP in Action(第46页)中,作者在一个说明中陈述了以下内容:
可能会发生这样的情况:在一些奇怪的角落情况下,在shell中评估的代码在编译为模块的一部分时与相同的代码略有不同.在这种情况下,编译版本是黄金标准.shell在解释表达式时会尽力做同样的事情.
你能想到这些奇怪的角落案件中的一个或多个吗？这些案件的细微差别是什么？
最重要的区别是shell被解释,而编译的代码是......好...编译.这在函数的执行速度和内存使用方面存在可观察到的差异.换句话说,您可能会发现解释的变体较慢或耗尽了所有内存,而编译后的版本却没有.
这个问题困扰了很多年轻的Erlang程序员.他或她认为与其他语言相比,Erlang相当慢,而实际上它是针对编译的解释代码的测试.
该段是一项保护措施.基本上,解释器和编译器应该同意函数的所有输入/输出.但不幸的是,并非总是如此.实际上,解释器和编译器是不同的执行引擎,因此可能不同.如果您通过HiPE进行本机编译,则更改可能会更大.通常,IEEE 754浮点数出现问题.
erlang解释器erl_eval非常努力地表现得像编译代码一样.如果不是,那很可能是一个bug.
除了一个案例,即接收消息.编译代码可以访问内部指令以访问和操作消息队列.口译员不能这样做.它必须:实际上从队列中删除消息(或多或少receive X -> X end); 测试它们以确定它们是否与接收模式匹配; 保留那些不匹配的; 并将所有当前不需要的消息放回队列中(通过接收所有消息,然后将它们发送回自身).这意味着在短时间内,如果消息到达,它可能不会在消息队列中与编译代码相同的位置.
| 归档时间： |
|
| 查看次数： |
307 次 |
| 最近记录： |