今天没出什么太麻烦毛病，只是发现了一个崩溃 - 事实上崩溃本身倒是小问题，反而在我机器上重现崩溃的时候意外发现了一个错误，那个才是大问题，算是歪打正着。修正这两个问题用的时间不算多，其他一切尚好，就看发放到外网以后效果如何了。
对driver来说，内存上可优化的空间仍然有一些，我在考虑去掉value的引用字段，然后将double类型的real退化到float类型，这样可以将变量压缩，可以再节省8M的空间。而且如果取消了引用，那么容器mapping & array都可以考虑压缩空间，那样这一项节省的效果就将超过8M，合计可以节约16M以上的内存。
注：为了使得mapping和array的值能够被引用，我在容器中保存的是指向value的指针而不是value本身，这样就会多申请一些小片的内存，另外，这个指针本身也是要占用4个字节空间的。
另外，针对指令来说，还可以做进一步的优化，提高运算和调用的速度，但是这样要冒更大的不稳定的风险，对指令的优化是最容易出问题的。
但是，不管怎么样，这种优化的结果都无法和上层实现的优化相比。目前上层的逻辑资源开销过于浪费，客户端启动以后，几乎载入了所有的表、很多不需要使用或是偶然需要使用的资源也常驻内存，这样显然有些不划算。所以，针对具体逻辑的调整才是重点。现在，我多做一些profile的工具才是正理。
2009年2月27日星期五
提交代码的痛苦过程
今天将Linux、Mac下的driver都提交了。因为头文件变化的缘故，我必须将所有引用了头文件的库都提交一遍，一路上触雷不断，焦头烂额。下午软件园组织马拉松比赛（当然没有42公里那么夸张，大概是个零头左右），公司有90多人报名参赛，其余的都是啦啦队，结果因为提交到半路，不上不下，我也没能去现场助威。
总的来说，提交的时候大部分都是弱智问题。
下午快下班的时候，QA开始针对已经提交的库进行验收，build各个平台的服务器端、客户端。果然不负期望，故障接连不断。最令人郁闷的是每次一提交库，要提交3个平台的debug/release共8个文件（Windows系统下还有两个pdb，VC没有将pdb和lib二合一真是一个糟糕的想法）。除此之外，因为平台代码组织的缘故，还需要提交链接了driver的几个dll和它们lib & pdb文件，这几个文件非常大，几次提交下来，版本库增大了不少。（显然代码的组织方式需要调整）
不论如何，真正的考验还在后头，当验收完毕版本发布以后出现问题更难检查。希望自动测试能够覆盖的更完全一些，尽量将bug灭杀在实验室里面吧。
ps. 现在记性是越来越差了，晚上没时间回去吃饭，让阿姨送饭过来。当时想可不要把饭盒忘记带回去。结果下班的时候到车上才突然记起来，只好跑回公司拿饭盒。没想到回家上楼的时候才发现饭盒又忘在车里了... 又下去拿了一趟。或许说，现在记性还不算太差，毕竟还是把饭盒弄回家了...
总的来说，提交的时候大部分都是弱智问题。
下午快下班的时候，QA开始针对已经提交的库进行验收，build各个平台的服务器端、客户端。果然不负期望，故障接连不断。最令人郁闷的是每次一提交库，要提交3个平台的debug/release共8个文件（Windows系统下还有两个pdb，VC没有将pdb和lib二合一真是一个糟糕的想法）。除此之外，因为平台代码组织的缘故，还需要提交链接了driver的几个dll和它们lib & pdb文件，这几个文件非常大，几次提交下来，版本库增大了不少。（显然代码的组织方式需要调整）
不论如何，真正的考验还在后头，当验收完毕版本发布以后出现问题更难检查。希望自动测试能够覆盖的更完全一些，尽量将bug灭杀在实验室里面吧。
ps. 现在记性是越来越差了，晚上没时间回去吃饭，让阿姨送饭过来。当时想可不要把饭盒忘记带回去。结果下班的时候到车上才突然记起来，只好跑回公司拿饭盒。没想到回家上楼的时候才发现饭盒又忘在车里了... 又下去拿了一趟。或许说，现在记性还不算太差，毕竟还是把饭盒弄回家了...
driver内存的优化暂时告一段落
上午调试完成，下午提交，折腾了一天，总算将windows下的库文件提交通过了，客户端和服务器端都暂时表现正常。
优化以后客户端driver减少了30M内存的使用量，实际上节省的会更多一些，因为减少了分配同时也意味着内存碎片也减少了。目前客户端启动时占用内存是180M左右，其中代码占了70M，driver占了90M，剩下20M主要是材质、骨骼动画。
虽然接下来还可以针对空间进行优化，但是暂时已经没有必要了，因为客户端重点应从资源管理方面入手进行进行优化，这才是主要开销之处。如果资源能够被合理的组织和调度，控制在50M之内应该比较容易，这样达到最后250M的占用还是比较轻松的。
晚上同事利用OGRE异步加载资源的功能调整了目前的实现，然而看了一下走路，表现还是不够流畅。不过通过诊断，已经有所眉目，看来本周内有望解决。令人头疼的是其他问题也亟需解决，时间苦短啊!
在完成driver内存方面的优化工作以后，我着手尝试进行执行效率方面的优化。通过改写VM的执行指令的相关代码，略微提高了性能（5%左右）。不过这些属于编码级的优化，只能算是小打小闹。另外，我打开了driver还从来没有在商业应用中真正使用过的优化功能 - 以前一直没有这个迫切的需求，为了稳定，我实现后从来没有开放过 - 今天一试，果然有问题，好在都和最近的优化工作相关。打开以后VM编译出来的中间代码有所缩短，性能有一定的提升。接下来两天，我考虑增加更多的优化方式以提高中间代码的效率。
总的来说，VM执行效率优化可提升的空间有限，我倒是很想实现JIT技术，不过时间有限，短期内估计无法做出稳定的版本，只能暂时先不考虑了。最终服务器端还是需要从具体实现入手来解决问题，目前这些只是略尽人事而已。
优化以后客户端driver减少了30M内存的使用量，实际上节省的会更多一些，因为减少了分配同时也意味着内存碎片也减少了。目前客户端启动时占用内存是180M左右，其中代码占了70M，driver占了90M，剩下20M主要是材质、骨骼动画。
虽然接下来还可以针对空间进行优化，但是暂时已经没有必要了，因为客户端重点应从资源管理方面入手进行进行优化，这才是主要开销之处。如果资源能够被合理的组织和调度，控制在50M之内应该比较容易，这样达到最后250M的占用还是比较轻松的。
晚上同事利用OGRE异步加载资源的功能调整了目前的实现，然而看了一下走路，表现还是不够流畅。不过通过诊断，已经有所眉目，看来本周内有望解决。令人头疼的是其他问题也亟需解决，时间苦短啊!
在完成driver内存方面的优化工作以后，我着手尝试进行执行效率方面的优化。通过改写VM的执行指令的相关代码，略微提高了性能（5%左右）。不过这些属于编码级的优化，只能算是小打小闹。另外，我打开了driver还从来没有在商业应用中真正使用过的优化功能 - 以前一直没有这个迫切的需求，为了稳定，我实现后从来没有开放过 - 今天一试，果然有问题，好在都和最近的优化工作相关。打开以后VM编译出来的中间代码有所缩短，性能有一定的提升。接下来两天，我考虑增加更多的优化方式以提高中间代码的效率。
总的来说，VM执行效率优化可提升的空间有限，我倒是很想实现JIT技术，不过时间有限，短期内估计无法做出稳定的版本，只能暂时先不考虑了。最终服务器端还是需要从具体实现入手来解决问题，目前这些只是略尽人事而已。
2009年2月26日星期四
黎明前的黑暗
这几天将所有的时间用于开发上，导致精神状况不是很好，今天打球以后有所好转，还是要和体力消耗相结合才是。
今天中午先将前两天的工作提交，然后继续进行优化。
应该说，现在提交以后的给版本带来了非常大的混乱 - 因为我并没有同时提交完整的linux、darwin下的库文件，因此头文件无法和所有的库都匹配上，我只是认为不匹配的部分并不会影响工程中其他的代码。
事实上，我先遇到了一个库导致崩溃的情况，在我的机器上重新编译以后才解决此问题。
接下来，服务器遇到了其他问题 - 这应该是我提交的driver库逻辑不正确导致的。不过我暂时却无法解决这个问题，因为今天的优化工作是一个半吊子，我的代码也没有版本分支可供修改。
忙活到11:30，完成了编码修改和编译，但是调试工作未能完成。看来只有明天持续，尽快解决问题了。
陈拓琳在诊断客户端的资源使用情况已经有了初步结果，即是好消息，也是坏消息。因为客户端的资源组织可以说是一个非常无序的状态，很多材质组织的不合理，还有很多则是浪费了，调度也几乎没有。因此，关于这部分的优化有着非常广阔的空间，但是还有很漫长的路要走。我想，在完成了几个主要的优化工作以后，应该足以将内存降低到250M以内。（考虑到系统启动时的DLL就用了将近70M的空间，这个目标还算是合理了，万恶的STL啊！）
虽说现在是一团漆黑，不过按照惯例，光明就在后面。
今天中午先将前两天的工作提交，然后继续进行优化。
应该说，现在提交以后的给版本带来了非常大的混乱 - 因为我并没有同时提交完整的linux、darwin下的库文件，因此头文件无法和所有的库都匹配上，我只是认为不匹配的部分并不会影响工程中其他的代码。
事实上，我先遇到了一个库导致崩溃的情况，在我的机器上重新编译以后才解决此问题。
接下来，服务器遇到了其他问题 - 这应该是我提交的driver库逻辑不正确导致的。不过我暂时却无法解决这个问题，因为今天的优化工作是一个半吊子，我的代码也没有版本分支可供修改。
忙活到11:30，完成了编码修改和编译，但是调试工作未能完成。看来只有明天持续，尽快解决问题了。
陈拓琳在诊断客户端的资源使用情况已经有了初步结果，即是好消息，也是坏消息。因为客户端的资源组织可以说是一个非常无序的状态，很多材质组织的不合理，还有很多则是浪费了，调度也几乎没有。因此，关于这部分的优化有着非常广阔的空间，但是还有很漫长的路要走。我想，在完成了几个主要的优化工作以后，应该足以将内存降低到250M以内。（考虑到系统启动时的DLL就用了将近70M的空间，这个目标还算是合理了，万恶的STL啊！）
虽说现在是一团漆黑，不过按照惯例，光明就在后面。
2009年2月24日星期二
果然是喜忧参半
今天编码、调试，终于将更新后的driver并入了项目，完成了编译和试验。本来我以为节约了20多M内存，但是今天发现原来昨天的计算有误，实际只节约了12M内存，真是令人有些沮丧。
随后我统计了一下，登入游戏以后系统中有近1M条指令，于是我将指令中的两个字段精简掉了，从而节省了8M空间，和之前的加在一起，倒是达到了20M的目标。
现在仍然需要进一步优化，可行的道路有两条：
1. 继承时进行代码复用
目前在继承时拷贝了代码，这样的好处是执行更快，加载对象时不会因为基类的变化而载入错误。若容忍微小的效率损耗，那么可以换得一定空间上的节约。我没有仔细研究该项优化工作能够节约的空间，但是我预估能节省10M左右的空间。
2. 将源文件信息用更精简的结构存放
目前我简单的将所有的指令都对应了一份源信息（文件名 & 行号），对1M的指令节点来说，也就是使用了8M的空间。倘若优化这部分工作，应该可以节约其中的4/5，也就是节省6M左右的空间。
如果将前两项合并，那么可能可以节约13M的空间。
3. 使用RISC指令模式
目前所有的指令均采用一个32位（opcode），两个32位的操作数（operand）。倘若使用RISC模式，可以压缩opcode，并且根据opcode跟随0-2个操作数。
这个的缺点将处理代码会复杂很多，并且如果使用gdb切入时，阅读也变得更加困难。如果在前两项的基础上再使用这个技术，应该可以再节约3M的空间。
考虑到复杂性和实际的效果，我对方案3的兴趣不大。
明天值得仔细考虑一下1、2两个方案。
随后我统计了一下，登入游戏以后系统中有近1M条指令，于是我将指令中的两个字段精简掉了，从而节省了8M空间，和之前的加在一起，倒是达到了20M的目标。
现在仍然需要进一步优化，可行的道路有两条：
1. 继承时进行代码复用
目前在继承时拷贝了代码，这样的好处是执行更快，加载对象时不会因为基类的变化而载入错误。若容忍微小的效率损耗，那么可以换得一定空间上的节约。我没有仔细研究该项优化工作能够节约的空间，但是我预估能节省10M左右的空间。
2. 将源文件信息用更精简的结构存放
目前我简单的将所有的指令都对应了一份源信息（文件名 & 行号），对1M的指令节点来说，也就是使用了8M的空间。倘若优化这部分工作，应该可以节约其中的4/5，也就是节省6M左右的空间。
如果将前两项合并，那么可能可以节约13M的空间。
3. 使用RISC指令模式
目前所有的指令均采用一个32位（opcode），两个32位的操作数（operand）。倘若使用RISC模式，可以压缩opcode，并且根据opcode跟随0-2个操作数。
这个的缺点将处理代码会复杂很多，并且如果使用gdb切入时，阅读也变得更加困难。如果在前两项的基础上再使用这个技术，应该可以再节约3M的空间。
考虑到复杂性和实际的效果，我对方案3的兴趣不大。
明天值得仔细考虑一下1、2两个方案。
2009年2月23日星期一
driver的优化进展喜忧参半
更新完后，启动开销少了20多M。一共3K多对象，每个节约空间8K左右。
不过周一折腾了一天，调整后的代码仍然有一些不稳定，在离开公司前没有做到完全稳定，符号信息管理的设计思路不够简洁，有些混乱。另外，在此期间，发现工程中还有一些小问题需要调整。
明天仍需努力啊... 一旦涉足开发，就会发现时间不够用，积压了一堆事务未能完成。问鼎我也没时间登录，只好睡觉前抽点时间做10个酒肆任务。
不过周一折腾了一天，调整后的代码仍然有一些不稳定，在离开公司前没有做到完全稳定，符号信息管理的设计思路不够简洁，有些混乱。另外，在此期间，发现工程中还有一些小问题需要调整。
明天仍需努力啊... 一旦涉足开发，就会发现时间不够用，积压了一堆事务未能完成。问鼎我也没时间登录，只好睡觉前抽点时间做10个酒肆任务。
2009年2月22日星期日
房价还得拦腰砍
中午和同事谈论房价的事情，我说：现在的房价还是太高，得拦腰砍。当然，这并不是指所有的房子，有些房子得对着脚脖子砍。
当然，有很多反驳的理由：
1. 不太可能跌那么多吧？
股市能从6000点跌到1800，房子凭什么不行？当年（96年）深圳的房价已经表演过跳水了。
2. 厦门是一个岛，岛内的面积有限
香港也是一个岛，房价照样跳过水。
3. 中国住房的刚性需求大，而且中国人的观念就是喜欢买房
很好，我要重点反驳的就是这一条。
什么是刚性需求？什么是价值？房子真正的价值是有人去住（不论是租还是自住），各个行业都要想办法为他的客户创造价值，而不是让客户去进行所谓的“投资”，倒买倒卖。买了房子等升值，然后再卖掉赚取差价，这是击鼓传花，是博傻，看谁接最后一棒，和老鼠会没有本质的区别，就如当年的网站热潮一样，没有产生真正的价值，是泡沫，是不能长久的。
所以，真正的刚性需求是“住”的需求，房子真正的价值要由租金来决定。
比如我同事租的房子，80平米，目前市价50万左右，但月租只有1000元。按照20倍市盈率来计算，也就是20年的租金，那就是1K * 12月 * 20年 = 24万元。也就是说，那个房子只应卖到每平方米3000不到（因为还要扣除简单装修的成本）。倘若超过这笔钱，我大可以考虑用24万元做投资，只要平均做到年回报5%就可以租房住了。事实上，以中国最近10年来看，或是国外成熟的金融市场来看，平均5%的回报是一个理性的目标 - 事实上，很多成熟的行业，股票都不到20倍的市盈率，投资这些股票长期持有，就能够取得年入5%收益。
当然，有人说：中国人喜欢拥有自己的房子。我的回答是：中国人的观念是会变化的，而且用不了多久。80年代泡MM那叫流氓罪，要进监狱去唱铁窗泪，现在呢？
还有人说：结婚了，总的要买房，不然对不起老婆大人，岳父岳母大人也不能同意。没错，的确如此。但是钱谁来出？以这种不合理的房价，能出的起人是少数，也就是要榨长辈的钱。等你榨干了，让你的儿子来榨你吗？难，因为你的钱都用来还贷了。所以，短期的繁荣可以有，长期的效益是不可能的。
或许有人还指望政府救市。我的看法是，救也没用，经济规律不可违抗啊！如果政府能抵挡经济规律，就不会有经济危机了。政府只能因势利导，不能逆天改命。
那么，是不是要等老百姓都懂了经济规律，房价才能拦腰砍？我说不必，规律就是普遍存在的一种现象，并不是你“知道”才存在的。当年国民党滥发钞票，现在的津巴布韦狂印冥币，老百姓不懂的货币流通那些理论，但是米价还是会一路上涨。其实元朝不就体验过嘛！
房价不跌或是少跌，只有一条路，那就是房租上涨 - 基本上，也就要是通胀吧。
当然，有很多反驳的理由：
1. 不太可能跌那么多吧？
股市能从6000点跌到1800，房子凭什么不行？当年（96年）深圳的房价已经表演过跳水了。
2. 厦门是一个岛，岛内的面积有限
香港也是一个岛，房价照样跳过水。
3. 中国住房的刚性需求大，而且中国人的观念就是喜欢买房
很好，我要重点反驳的就是这一条。
什么是刚性需求？什么是价值？房子真正的价值是有人去住（不论是租还是自住），各个行业都要想办法为他的客户创造价值，而不是让客户去进行所谓的“投资”，倒买倒卖。买了房子等升值，然后再卖掉赚取差价，这是击鼓传花，是博傻，看谁接最后一棒，和老鼠会没有本质的区别，就如当年的网站热潮一样，没有产生真正的价值，是泡沫，是不能长久的。
所以，真正的刚性需求是“住”的需求，房子真正的价值要由租金来决定。
比如我同事租的房子，80平米，目前市价50万左右，但月租只有1000元。按照20倍市盈率来计算，也就是20年的租金，那就是1K * 12月 * 20年 = 24万元。也就是说，那个房子只应卖到每平方米3000不到（因为还要扣除简单装修的成本）。倘若超过这笔钱，我大可以考虑用24万元做投资，只要平均做到年回报5%就可以租房住了。事实上，以中国最近10年来看，或是国外成熟的金融市场来看，平均5%的回报是一个理性的目标 - 事实上，很多成熟的行业，股票都不到20倍的市盈率，投资这些股票长期持有，就能够取得年入5%收益。
当然，有人说：中国人喜欢拥有自己的房子。我的回答是：中国人的观念是会变化的，而且用不了多久。80年代泡MM那叫流氓罪，要进监狱去唱铁窗泪，现在呢？
还有人说：结婚了，总的要买房，不然对不起老婆大人，岳父岳母大人也不能同意。没错，的确如此。但是钱谁来出？以这种不合理的房价，能出的起人是少数，也就是要榨长辈的钱。等你榨干了，让你的儿子来榨你吗？难，因为你的钱都用来还贷了。所以，短期的繁荣可以有，长期的效益是不可能的。
或许有人还指望政府救市。我的看法是，救也没用，经济规律不可违抗啊！如果政府能抵挡经济规律，就不会有经济危机了。政府只能因势利导，不能逆天改命。
那么，是不是要等老百姓都懂了经济规律，房价才能拦腰砍？我说不必，规律就是普遍存在的一种现象，并不是你“知道”才存在的。当年国民党滥发钞票，现在的津巴布韦狂印冥币，老百姓不懂的货币流通那些理论，但是米价还是会一路上涨。其实元朝不就体验过嘛！
房价不跌或是少跌，只有一条路，那就是房租上涨 - 基本上，也就要是通胀吧。
光阴荏苒
早晨有个人要面试，正好有一些driver的优化工作想做，所以一早就来到公司。
没想到带了钥匙，门禁卡却忘记了带，踟蹰了一分钟，还是回去拿，来回浪费了22分钟。
坐在计算机前面，发现自己已经很久没有在周日上班了，比起三年前紧张程度降低了很多。以目前的工作进展来看，我还远不到可以松懈的时候，需要反省。
目前客户端表现为内存占用较多，而服务器端则是CPU开销较大。也就是说，要对driver同时针对空间和效率进行优化。总的来说，随着经验的丰富，我的设计方案执行效率是越来越低，资源占用则是越来越多，带来的好处是易用性和易维护性。目前看来，随着应用程度的加深，这方面的优化工作不能再忽略了。
就内存而言，我统计了一下driver使用内存的情况。客户端启动以后driver使用了100M内存，其中66M是脚本代码编译后的中间代码，而16M是值（计1M个），剩余的为其他（共享字符串，sqlite等第三方库，还没做详细统计），值一个为16字节（节省空间不大），所以先考虑节约编译后的中间代码。
目前第一阶段的工作是每个“程序”（即一个对象对应的program）都有一个符号表，占内存8K。这个表可以根据名字查询程序中相应函数的入口，供跨对象调用使用。因为系统存在大量的小对象，比如脚本、公式。它们基本只有2个函数，但是却使用一个符号表。那么1k个脚本、公式则用掉了8M空间（实际上会更多，因为一个表的符号节点也会占内存），但是实际发挥的作用很小。
基于这点，我有两个解决方案：
1. 增加一个压缩符号表的功能，生成代码段以后，根据符号表中实际符号的数量重新生成符号表
2. 增加快速函数表，生成代码段以后，删除符号表，生成一个可以查询函数入口的快表
第一个方案实现简单，但是有一个缺憾。首先，这个符号表每个符号节点需要申请一个小内存块，这就是为什么实际上一个符号表超过8K的缘故。一个脚本、公式对象目前只有两个函数，即需要两个符号节点，虽然单个量不多，但是整体也会消耗几百K的内存。
第二个方案实现起来会复杂一些，因为所有查询符号表的代码都要调整为查询快表 - 问题是全局对象不能查询快表，因为全局对象可以动态的增加新方法，不能释放符号表。另外，取消了符号表会导致根据名字查询对象变量的方法失效，必须增加相应方法。
最终我还是考虑用第二个方案实现。
同时，为了避免申请小块内存，快表在出现哈希冲突的时候，采用顺序后移找到空位填入的方法。因此，快表的大小需要比符号数量略多一点，这样在查找表中没有的符号时，不至于遍历所有条目才能知道未命中。
例子：
字符串, 函数编号
"create", 0
"main", 1
目前的符号表是2K条目（每项均为指针），其中计算字符串的哈希值，比如“create”是5，“main”是17，那么只有5 & 17这两个项有指针指向两个符号节点。如果采用小表，可以避免使用2K个条目，可以只用2个条目，那么“create”和“main”可能会冲突，都在第1号位置（5 % 2 = 1, 17 %2 = 1），此时采用链表进行连接这两个条目。
如果采用快表，则申请能包容三个表项的一张表，其中“create”会放置到5 % 3 = 2号位置，而“main”会放置到17 % 3 = 2，因为冲突顺移则到0号位置。查询时，“create”会直接命中，而“main”会检索一次后命中，其他则最多检索两次知道无法命中。
最后，为了避免浪费内存，所有的字符串均采用共享字符串。在查询比较时，也可以提高速度。
没想到带了钥匙，门禁卡却忘记了带，踟蹰了一分钟，还是回去拿，来回浪费了22分钟。
坐在计算机前面，发现自己已经很久没有在周日上班了，比起三年前紧张程度降低了很多。以目前的工作进展来看，我还远不到可以松懈的时候，需要反省。
目前客户端表现为内存占用较多，而服务器端则是CPU开销较大。也就是说，要对driver同时针对空间和效率进行优化。总的来说，随着经验的丰富，我的设计方案执行效率是越来越低，资源占用则是越来越多，带来的好处是易用性和易维护性。目前看来，随着应用程度的加深，这方面的优化工作不能再忽略了。
就内存而言，我统计了一下driver使用内存的情况。客户端启动以后driver使用了100M内存，其中66M是脚本代码编译后的中间代码，而16M是值（计1M个），剩余的为其他（共享字符串，sqlite等第三方库，还没做详细统计），值一个为16字节（节省空间不大），所以先考虑节约编译后的中间代码。
目前第一阶段的工作是每个“程序”（即一个对象对应的program）都有一个符号表，占内存8K。这个表可以根据名字查询程序中相应函数的入口，供跨对象调用使用。因为系统存在大量的小对象，比如脚本、公式。它们基本只有2个函数，但是却使用一个符号表。那么1k个脚本、公式则用掉了8M空间（实际上会更多，因为一个表的符号节点也会占内存），但是实际发挥的作用很小。
基于这点，我有两个解决方案：
1. 增加一个压缩符号表的功能，生成代码段以后，根据符号表中实际符号的数量重新生成符号表
2. 增加快速函数表，生成代码段以后，删除符号表，生成一个可以查询函数入口的快表
第一个方案实现简单，但是有一个缺憾。首先，这个符号表每个符号节点需要申请一个小内存块，这就是为什么实际上一个符号表超过8K的缘故。一个脚本、公式对象目前只有两个函数，即需要两个符号节点，虽然单个量不多，但是整体也会消耗几百K的内存。
第二个方案实现起来会复杂一些，因为所有查询符号表的代码都要调整为查询快表 - 问题是全局对象不能查询快表，因为全局对象可以动态的增加新方法，不能释放符号表。另外，取消了符号表会导致根据名字查询对象变量的方法失效，必须增加相应方法。
最终我还是考虑用第二个方案实现。
同时，为了避免申请小块内存，快表在出现哈希冲突的时候，采用顺序后移找到空位填入的方法。因此，快表的大小需要比符号数量略多一点，这样在查找表中没有的符号时，不至于遍历所有条目才能知道未命中。
例子：
字符串, 函数编号
"create", 0
"main", 1
目前的符号表是2K条目（每项均为指针），其中计算字符串的哈希值，比如“create”是5，“main”是17，那么只有5 & 17这两个项有指针指向两个符号节点。如果采用小表，可以避免使用2K个条目，可以只用2个条目，那么“create”和“main”可能会冲突，都在第1号位置（5 % 2 = 1, 17 %2 = 1），此时采用链表进行连接这两个条目。
如果采用快表，则申请能包容三个表项的一张表，其中“create”会放置到5 % 3 = 2号位置，而“main”会放置到17 % 3 = 2，因为冲突顺移则到0号位置。查询时，“create”会直接命中，而“main”会检索一次后命中，其他则最多检索两次知道无法命中。
最后，为了避免浪费内存，所有的字符串均采用共享字符串。在查询比较时，也可以提高速度。
2009年2月19日星期四
GCC和VC处理浮点数不一致的问题
概述
本文阐述了在工程中遇到的一个精度方法控制不同而导致的问题。背景介绍
我们看这一段代码：#include <stdio.h>int main(int argn, char *argv[]) { // 上面都是废话，这里正文开始 double r1, r2; int x; r1 = 40; r2 = 0.85; x = (int) (r1 * r2); printf("x = %d\n", x); }
完整的分析
为了便于阅读，我这里只给出最相关的资料，如果需要进一步了解需要做试验、检索更详细的资料。x87 FPU的资料
我们先了解一下FPU的数据寄存器（Data Registers）和控制字（Control Word）。数据寄存器是80位，有效数字64位。它可以选择几种工作模式：
| Precision | PC field | 备注 |
|---|---|---|
| 单精度（24位有效数字） | 00 | 32位，即float |
| 保留 | 01 | |
| 双精度（53位有效数字） | 10 | 64位，即double |
| 扩展双精度（64位有效数字） | 11 | 80位 |
另外，控制字的10、11两位为RC字段，如果为11则表示采用向下取整（Truncate）的方式，而为00则表示四舍五入（Round to near）方式。
注：关于PC、RC的说明，见Book1的8-11页。
计算过程
上述代码的计算过程如下（这是gdb反汇编gcc编译的结果）：fldl r2 ; 将r2放入栈
fmull r1 ; 和r1相乘，结果在栈顶
fnstcw cw ; 取FPU的状态字，保存到临时变量cw中
mov cw,%ax ; 将cw复制到寄存器ax中
mov $0xc,%ah ; 修改RC字段为11，即采用向下取整；修改PC字段为00，即单精度（不过这点并不影响结果）
mov %ax,cw2 ; 将修改后的状态字结果放入另一个临时变量cw2中
fldcw cw2 ; 更新FPU的状态字
fistpl x ; 将栈顶的结果取整保存到结果x中注：gdb反汇编标记方法和Intel标准有所不同，第一个操作字是源，第二个则是目的，正好和Intel反过来，需要注意这一点。
因为二进制浮点数是不能准确表达0.85的，会小一点，所以实际40*0.85乘法结果会略小于34，采用向下取整以后就结果为33。
进一步说明
为了便于试验，我将这个计算过程在VC下重新实现一次，代码如下：#include <stdio.h>int main(int argn, char *argv[]) { // 废话结束，正文开始 double r1, r2; unsigned short cw; int x; r1 = 0.85; r2 = 40; __asm { mov cw, 0x037f;
fldcw cw; // 设置状态字的PC字段为11，即采用扩展双精度，windows原先默认是10，即双精度
fld r1; // r1入栈 fld r2; // r2入栈 fmulp st(1), st // 相乘，结果在栈顶 fnstcw cw; mov ax, cw;
mov ah, 0x0c;
mov cw, ax;
fldcw cw; // 这一段代码同gcc的结果，设置PC为00即单精度，设置RC为11即向下取整
fistp x; // 取整，保存到x中 } printf("x = %d\n", x); return 0; }
这个结果就是33。
好，我们要讨论的是结果为什么是33？
我们知道，这是因为计算结果略小于34（但是非常接近，在寄存器中只差2^-64次方以内，即最后一位有效数字），而最后采用的是单精度向下取整，自然就少了1，变成33。然而，我们只要把第一句修改为mov cw, 0x027f，这段代码的结果就正确了。为什么？这是因为FPU内部总是采用高精度（80位）进行计算，如果PC为10即双精度，那么FPU在计算结束以后，需要保存为双精度，此时采用了四舍五入（因为RC为00，四舍五入），那么结果将变成34。
所以，因为gcc for linux编译出来的程序默认是80位精度，在最后取整时简单的采用了向下取整，而VC编译出来的程序则是默认64位的精度，在计算过程中就先进行了四舍五入，最后取整时虽然也作了向下取整，但是已经无碍于最终结果了。
再进一步说明
如果gcc将-msse2开关打开，则可以获得满意的结果。让我们看一下相关代码：...
fstpl r3 ; 将结果保存到r3中
movsd r3,%xmm0 ; 将r3放到xmm0中
cvttsd2si %xmm0,%eax ; 取整，双精度浮点->整数
mov %eax, x ; 将结果放到x中
...按照这个道理，我们可以用这样的方法改写C代码获得正确结果：
...
r3 = r1 * r2;
x = (int) r3;
...结论
gcc for linux的浮点数直接取整实现是一个bug。最后
浮点数计算对完美的移植是一个重大的考验，因为对浮点处理方法的不一致性、或处理顺序的不一致性会导致精度上的微小差异。这个微小的差异随着计算的进行，会逐步的放大。相关文档
Book1：Intel 64 and IA-32 Architectures Software Developer's Manual VOLUME 1: Basic Architecture
2009年2月15日星期日
好一个特仑苏，好一个高科技
蒙牛的OMP添加剂，目前弄得沸沸扬扬。国家六部门联合要求停止添加此成分，蒙牛则跳出来一方面拥护国家决定，一方面辩解此物无害。
我关心的不是这个产品有害无害，毕竟还没听说因为这个喝出毛病的，而是以下这则三年前的新闻（这是我从新闻的网友评论中发现的）。
第一个由中国人命名的乳业技术通过鉴定，第一款中国企业自主研发的世界领先牛奶产品问世——OMP技术和蒙牛特仑苏OMP牛奶研发的成功...
2006年3月29日上午，国家信息中心的会议大厅里气氛热烈。由中国公众营养与发展中心授予蒙牛乳业的“改善国人骨健康”的科研攻关课题取得了可喜的成果”
国家公众营养与发展中心主任于小冬主任在鉴定会上指出：发现OMP造骨牛奶蛋白对人体骨密度提高和促进骨量增加的独特机理，是中国科学家和乳业企业联手对公众营养尤其是钙质增强方面完成的独创性研究...
而蒙牛近日的申辩中则称
近十年的时间里，日本明治乳业公司首先推出每日骨太的牛奶，意思是每天喝牛奶骨头更健康，这个牛奶在日本市场深受欢迎，因为其中添加了含有牛奶碱性蛋白缩写是MBP...
第二方面介绍一下OMP到底是什么东西？OMP牛奶是新鲜牛奶中添加的牛奶碱性蛋白，经过UHT杀菌后形成的产品，OMP是商业产品名称，不是化学属性的名称。
OMP牛奶的同类产品在美国、日本等地已经热销多年...
首先我明确告诉你，刚才母博士展示的新西兰的食品过程中，OMP就是MBP...
显然，所谓的OMP只不过就是一个称呼而已，所谓的“独创性”研究就是把别人的冷饭拿过来炒炒，换个名字罢了。而国家公众营养与发展中心这个自称是发改委下属的政府机构组织一帮不知道哪里刨出来的专家糊里糊涂的鉴定一下（由此可见为什么年画拍的老虎也能通过鉴定，那个技术含量其实还高一点），再扔上一堆赞扬。这就是我们的高科技啊！我一直觉得网游的科技含量很低，但是和蒙牛这类行径一比，我登时觉得我们的游戏科技含量和时光机器仿佛，至于blizzard... Oh！他们是异次元空间的人，已经超出科技所能解释的领域了。
另外，看到蒙牛人如此回答，真是让我莫名惊诧：
第二，关于OMP和IGF-1，我进一步和大家澄清，OMP和IGF-1是截然不同的两种物质。刚才母博士也从分子结构和大家做了一个简单介 绍，IGF-1是有分子结构的，而OMP是一组蛋白，里面有过氧化镁，既然是一组蛋白质，不涉及到分子结构，从理论上讲也好或者其他方面讲也好，已经说得很明确，OMP和IGF-1是截然不同的两回事。
IGF-1是有分子结构的，而OMP是一组蛋白... 难道蛋白质就没有分子结构了？这两个不同概念有什么好比的？这就好比：“克林顿是有名字的，而布什是一个总统，身上长着小弟弟，既然是一个总统，不涉及到名字，从理论上讲也好或者其他方面讲也好，已经说得很明确，克林顿和布什是截然不同的两回事”。TNND，我实在想骂人，蒙牛这人是脑子被驴踢了，还是当听众的脑子都灌满了特仑苏？分子结构和蛋白不是相同的概念，能有什么好比的？还能因此得出结论！
神啊！请让我把当年的酸酸乳都吐出来吧！这些东西还是给春哥喝比较般配！
相关链接：
卫生部的要求：http://news.sina.com.cn/h/2009-02-14/103917214665.shtml
蒙牛的申辩：http://video.sina.com.cn/finance/g/20090214/175513896.shtml
关于特仑苏产品的吹捧：http://news.163.com/06/0403/16/2DQ1JAA30001125P.html
Snow brand的宣传MBP网站：http://www.snowbrand.co.jp/mbp/english/index.html
我关心的不是这个产品有害无害，毕竟还没听说因为这个喝出毛病的，而是以下这则三年前的新闻（这是我从新闻的网友评论中发现的）。
蒙牛OMP牛奶研发成功为中国乳业展示新方向
很有意思，这里面提到的：第一个由中国人命名的乳业技术通过鉴定，第一款中国企业自主研发的世界领先牛奶产品问世——OMP技术和蒙牛特仑苏OMP牛奶研发的成功...
2006年3月29日上午，国家信息中心的会议大厅里气氛热烈。由中国公众营养与发展中心授予蒙牛乳业的“改善国人骨健康”的科研攻关课题取得了可喜的成果”
国家公众营养与发展中心主任于小冬主任在鉴定会上指出：发现OMP造骨牛奶蛋白对人体骨密度提高和促进骨量增加的独特机理，是中国科学家和乳业企业联手对公众营养尤其是钙质增强方面完成的独创性研究...
而蒙牛近日的申辩中则称
近十年的时间里，日本明治乳业公司首先推出每日骨太的牛奶，意思是每天喝牛奶骨头更健康，这个牛奶在日本市场深受欢迎，因为其中添加了含有牛奶碱性蛋白缩写是MBP...
第二方面介绍一下OMP到底是什么东西？OMP牛奶是新鲜牛奶中添加的牛奶碱性蛋白，经过UHT杀菌后形成的产品，OMP是商业产品名称，不是化学属性的名称。
OMP牛奶的同类产品在美国、日本等地已经热销多年...
首先我明确告诉你，刚才母博士展示的新西兰的食品过程中，OMP就是MBP...
显然，所谓的OMP只不过就是一个称呼而已，所谓的“独创性”研究就是把别人的冷饭拿过来炒炒，换个名字罢了。而国家公众营养与发展中心这个自称是发改委下属的政府机构组织一帮不知道哪里刨出来的专家糊里糊涂的鉴定一下（由此可见为什么年画拍的老虎也能通过鉴定，那个技术含量其实还高一点），再扔上一堆赞扬。这就是我们的高科技啊！我一直觉得网游的科技含量很低，但是和蒙牛这类行径一比，我登时觉得我们的游戏科技含量和时光机器仿佛，至于blizzard... Oh！他们是异次元空间的人，已经超出科技所能解释的领域了。
另外，看到蒙牛人如此回答，真是让我莫名惊诧：
第二，关于OMP和IGF-1，我进一步和大家澄清，OMP和IGF-1是截然不同的两种物质。刚才母博士也从分子结构和大家做了一个简单介 绍，IGF-1是有分子结构的，而OMP是一组蛋白，里面有过氧化镁，既然是一组蛋白质，不涉及到分子结构，从理论上讲也好或者其他方面讲也好，已经说得很明确，OMP和IGF-1是截然不同的两回事。
IGF-1是有分子结构的，而OMP是一组蛋白... 难道蛋白质就没有分子结构了？这两个不同概念有什么好比的？这就好比：“克林顿是有名字的，而布什是一个总统，身上长着小弟弟，既然是一个总统，不涉及到名字，从理论上讲也好或者其他方面讲也好，已经说得很明确，克林顿和布什是截然不同的两回事”。TNND，我实在想骂人，蒙牛这人是脑子被驴踢了，还是当听众的脑子都灌满了特仑苏？分子结构和蛋白不是相同的概念，能有什么好比的？还能因此得出结论！
神啊！请让我把当年的酸酸乳都吐出来吧！这些东西还是给春哥喝比较般配！
相关链接：
卫生部的要求：http://news.sina.com.cn/h/2009-02-14/103917214665.shtml
蒙牛的申辩：http://video.sina.com.cn/finance/g/20090214/175513896.shtml
关于特仑苏产品的吹捧：http://news.163.com/06/0403/16/2DQ1JAA30001125P.html
Snow brand的宣传MBP网站：http://www.snowbrand.co.jp/mbp/english/index.html
2009年2月13日星期五
2009年2月9日星期一
2009年2月8日星期日
纪念梁羽生
2009年1月22日，梁羽生辞世。
梁羽生先生开创了现代武侠的流派，若没有他，我们可能还真是无缘欣赏金庸、古龙的作品。虽然我对他老人家的作品实在是欣赏不来，看不动。
另外，梁羽生当年受到陈克夫与吴公仪在澳门比武的启发，写下了《龙虎斗京华》。不过，陈与吴真是两个十足的水货，连带我对中国传统武术也深表怀疑。
比赛过程龌龊，属于街头地痞斗殴的层次，但是经过文字渲染以后，看上去好像还挺有水准，这就是文字的魅力啊。难怪当年金兵占了中原，不爱刀枪爱辞赋。
视频链接：http://you.video.sina.com.cn/b/827764-1229389535.html
文字链接：太极的自我吹嘘
梁羽生先生开创了现代武侠的流派，若没有他，我们可能还真是无缘欣赏金庸、古龙的作品。虽然我对他老人家的作品实在是欣赏不来，看不动。
另外，梁羽生当年受到陈克夫与吴公仪在澳门比武的启发，写下了《龙虎斗京华》。不过，陈与吴真是两个十足的水货，连带我对中国传统武术也深表怀疑。
比赛过程龌龊，属于街头地痞斗殴的层次，但是经过文字渲染以后，看上去好像还挺有水准，这就是文字的魅力啊。难怪当年金兵占了中原，不爱刀枪爱辞赋。
视频链接：http://you.video.sina.com.cn/b/827764-1229389535.html
文字链接：太极的自我吹嘘
2009年2月6日星期五
路上事故隐患不断
下班回家，从停车场出来的路上横着一辆单车，还有一辆肇事的士。这里是园区内的丁字路口，本来就是一个事故隐患区，出来的人看不清楚，外面的车还开的飞快。
从园区出来，回家路上，遇到一个骑自行车逆行的，看到我就往右拐，偏偏我也要偏左规避地上的坑，好在我开的速度很慢，彼此都躲过一劫。
再往前行，有一辆车慢悠悠的靠左开，我只好从右侧超车，看到司机正在打电话。
前行500米，有一辆车闪着双闪逆行奔了过来，我让开，似乎后面打电话那个大哥还挺机灵，也让了。
继续前行500米，有一辆巴士从右侧出来，逆行50米，然后切到左侧的对向车道（因为有隔离护栏，所以从出口的地方不能直接左转到正确的行车道上）。
再往前看，一片漆黑，路灯全灭，黑灯瞎火的往前开，有一个涵洞如果不小心就会逆行进去（这里反而没有隔离护栏了），之前听说涵洞里面遇到过逆行的，而前两天在这段黑漆漆的路面上看到过一起事故，车撞人。
2分钟后，平安抵达家中。真是惊险，4公里，1起事故，5处隐患。
从园区出来，回家路上，遇到一个骑自行车逆行的，看到我就往右拐，偏偏我也要偏左规避地上的坑，好在我开的速度很慢，彼此都躲过一劫。
再往前行，有一辆车慢悠悠的靠左开，我只好从右侧超车，看到司机正在打电话。
前行500米，有一辆车闪着双闪逆行奔了过来，我让开，似乎后面打电话那个大哥还挺机灵，也让了。
继续前行500米，有一辆巴士从右侧出来，逆行50米，然后切到左侧的对向车道（因为有隔离护栏，所以从出口的地方不能直接左转到正确的行车道上）。
再往前看，一片漆黑，路灯全灭，黑灯瞎火的往前开，有一个涵洞如果不小心就会逆行进去（这里反而没有隔离护栏了），之前听说涵洞里面遇到过逆行的，而前两天在这段黑漆漆的路面上看到过一起事故，车撞人。
2分钟后，平安抵达家中。真是惊险，4公里，1起事故，5处隐患。
2009年2月1日星期日
当地导游称美旅游公司一味降低成本导致车祸
前几天一个赴美的旅游团出了交通事故，大巴翻车，7人身亡。
今天在新浪的时候看到一篇文章，里面的内容有点诡秘，节选几段：
张先生告诉东方网记者，为了降低成本，提高效益，美国银河旅游公司租用DW公司廉价的大巴和司机。
张先生告诉东方网记者，银河旅游公司在美国口碑就不是很好。
张先生说，他打过来电话告诉媒体，就是要告诉广大网友，导致事故的真正原因。
让我感到不妥的地方是，这个团是中国组织的而不是说游客到了美国随便找了一个。也就是说，挑选了这个“银河”是我们的“上海东湖旅行社”（中间可能有很多环节，但是总归是“东湖”发起的），如果这个“银河”果然资质很差，那么我们为什么要选择这一家？
所以，这个神秘的“张先生”究竟是谁？是“东湖”驻美负责人，还是承接“东湖”出的团转包给“银河”的二道贩子？这么急迫的来“告诉广大网友，导致事故的真正原因”，或许只是为自己推卸责任罢了。当然，还有一个可能就是趁机打压一下竞争对手。不论如何，这样的一篇文章，只有“张先生”一个人自说自话，记者毫无自己的判断分析，居然能放在新浪的首页，并且标题为“事故原因分析:旅游公司一味降成本”，实在是令人感到神奇。
原文链接：当地导游称美旅游公司一味降低成本导致车祸
今天在新浪的时候看到一篇文章，里面的内容有点诡秘，节选几段：
张先生告诉东方网记者，为了降低成本，提高效益，美国银河旅游公司租用DW公司廉价的大巴和司机。
张先生告诉东方网记者，银河旅游公司在美国口碑就不是很好。
张先生说，他打过来电话告诉媒体，就是要告诉广大网友，导致事故的真正原因。
让我感到不妥的地方是，这个团是中国组织的而不是说游客到了美国随便找了一个。也就是说，挑选了这个“银河”是我们的“上海东湖旅行社”（中间可能有很多环节，但是总归是“东湖”发起的），如果这个“银河”果然资质很差，那么我们为什么要选择这一家？
所以，这个神秘的“张先生”究竟是谁？是“东湖”驻美负责人，还是承接“东湖”出的团转包给“银河”的二道贩子？这么急迫的来“告诉广大网友，导致事故的真正原因”，或许只是为自己推卸责任罢了。当然，还有一个可能就是趁机打压一下竞争对手。不论如何，这样的一篇文章，只有“张先生”一个人自说自话，记者毫无自己的判断分析，居然能放在新浪的首页，并且标题为“事故原因分析:旅游公司一味降成本”，实在是令人感到神奇。
原文链接：当地导游称美旅游公司一味降低成本导致车祸
订阅：
评论 (Atom)