1 2 3 4 56 / 6 页

论坛徽章:: 5

51楼 [报告]

发表于 2013-02-12 14:17 |只看该作者

回复 14# coderit

没有谁一次能把代码写对。

先不说需求变更，就算需求明确，你也不能想个一两天，万事俱备然后开始敲码。这是不行的。最终你会发现实际开发和你想象中的距离很远。编码这种事情本来就是需要边写边改，边完善架构的。

看看Lua的开发史（20年开发历程，目前代码行数2W），是经过了多么坎坷的路程，这一点从1.0~5.2的各个发布的版本就能看到。Roberto本身的功底毋庸置疑。连这样大师级的人物真正“认真”思考开发一样东西都如此坎坷，更别说其他人了。

没有什么工业级的代码是可以通过深思熟虑一次搞定的。

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

starwing83

巨富豪门

论坛徽章:: 5

52楼 [报告]

发表于 2013-02-12 14:27 |只看该作者

说个最近发生的真事儿吧。

Lua邮件列表。有人提问，说Lua的字节码编译，OP_CLOSURE这个字节码的功能是创建一个新的闭包。字节码本身可以指定载入到哪个寄存器。但是，实际编码的时候发现，Lua的字节码并不是直接将闭包载入到局部变量所在的寄存器的，而是先将闭包载入到最高的那个寄存器，然后再用一个OP_MOVE字节码移动到局部变量所在寄存器中。他发了一个邮件问到底是什么原因。

Luiz（Lua的维护人）说，Lua的字节码并不是被完全优化的。

那个人很奇怪，那为什么这个地方不优化呢？

后来Roberto出现了。他说这个地方看起来没有完全优化，其实是最优化的选择。因为Lua是增量式垃圾回收的，这个垃圾回收机制对Lua字节码执行和C API执行分别作了优化。这种优化导致的结果就是在执行字节码的时候，回收器不一定能知道当前真正被使用的寄存器的集合究竟是哪几个。因此就指定了一个原则，每个字节码都必须要标示出自己当前使用的有效寄存器的边界。

而OP_CLOSURE字节码不直接将Closure载入到局部变量中的原因，也就是因为在产生Closure和载入Closure的间隙可能会有垃圾回收，甚至产生Closure这个事情本身也可能导致紧急垃圾回收行为，因此它必须要标记自己使用的最高寄存器，所以它将closure先载入到了最高的位置，然后再移动到目的地。

说这件事的原因是，很多东西，如果你不写代码，你根本不知道在实现的时候，可能会遇到什么样的细节。Lua仅仅是一个2W+的项目，就会有这样的细节，其他的项目会是怎样就不言而喻了。而且Lua的代码风格十分良好，结构上也十分优美，这样都不能完全杜绝这种问题，更别提其他的项目了。