卡坦岛（CATAN）

前几天开始接触桌游，包括卡坦岛、电厂、卡美洛、波多黎各等。

这几天找了一个单机的卡坦岛试验了一下，才发现原先玩的规则居然错了不少。这个游戏规则很简单，难怪适合10岁以上儿童游戏（我看其实5岁就够了），不过这个游戏运气成分太大了。在我和电脑对战的过程中，机器的AI其实很低，可以说毫无策略可言，但是即使这样我也不能保持非常高的胜率，估计也就7、8成的样子。相比之下，波多黎各这样主要靠计算的游戏，更适合程序员的口味。

ps：CATAN可以通过wine在mac下运行。

墙的悲哀

事实证明，力是相互作用的。

虽然我常备翻墙梯，出入互联网如入无人之境 － 但是这只是一厢情愿的想法。

每次我在blogspot上写完文章，一般都会转回baidu的blog上。但是却有一个很麻烦的事情，每次我post帖子以后，我就有一段时间无法访问百度空间。只要断掉VPN就好了，否则就得一遍一遍的刷新主页，等到奇迹的一刻发生，我才能成功的发布帖子。

这本来不是问题，因为我一般只转一篇文章。但是今天我需要转好几篇文章，那就格外痛苦了。我总不能每转一次就断一次VPN吧？虽然我可以先把需要转的帖子全部都打开，然后断开VPN，一次性全部转载好，但是这总是让人感觉非常的不愉快。

所以说，固然你可以准备一把梯子翻墙而走，但是墙是有两面的，有时候，翻进来也是一种挑战。

VM嵌套VM

这两天在折腾Ubuntu，闲暇时想试试看能否在Ubuntu这个虚拟机里面再装一个虚拟机，于是下载了Virtualbox，一试之下，果然可以。

配置：外面是Vmware 7.01 Workstation（Host：Win7x64，Guest：Ubuntu 9.10x32），内部是VirtualBox 3.08 OSE（Host：Outside.Guest，Guest：WinXPx32）。

不过XP安装的速度很慢，号称要50分钟，实际上用了2个小时都不止。XP启动时声音都是断断续续的，我看了一下Ubuntu的CPU占用，Virtualbox和pulseaudio各占50% CPU，于是我给Ubuntu分配了两个CPU，重新启动以后感觉XP的速度快了不少，虽然声音还是断断续续的，但是操作起来还是勉强有了486的感觉，尤其是XP安装了VirtualBox的additional以后，看上去好多了。

为了对比一下Vmware & Virtualbox的性能，我尝试用Virtualbox启动了Ubuntu，然后内部也用Virtualbox启动XP，即Virtualbox in Virtualbox，速度奇慢，明显不如Virtualbox in Vmware。接下来我实验Vmware in Vmware，但是第一次启动内部虚拟机器时失败了，需要在内部的虚拟机配置文件注明“vmx.allowNested = TRUE”才可以。另外我重新在Vmware下安装了XP，速度比Virtualbox快差不多一倍的样子。

总的来说，Vmware in Vmware表现最理想，但是最内部的XP体验还是不好，第一层虚拟使用的硬件虚拟，而第二层则使用软件模拟，虽然软件模拟和硬件模拟相比速度并不会下降太多，但是一旦嵌套，内部的速度的确非常的不理想。我尝试给第一层的Ubuntu配置了2个CPU，4G内存；第二层的XP配置了1G内存，关闭内存交换，设置MemTrimRate=0，但是表现仍然不佳，有点像10年前在互联网上使用PCAnyware的那种感觉。

虽然VM in VM这种方式性能不好，但如果想做实验或是一些开发性质的工作，这个速度也还可以接受了。

附图1：Virtualbox in Vmware

发件人 doing's board

附图2：Vmware in Vmware

发件人 doing's board

集成JIT

今天集成JIT到项目中。

我先找了一个QA帮忙准备环境，光这个工作就花费了他一个上午的时间，期间他还拖了个程序员来帮忙诊断了一些环境的问题。

下午总算将环境搭建好了，调试过程还算顺利，出过几个问题，但是都不难诊断。本来JIT是一个比较独立的功能，针对相关的指令进行本地化编译即可。只不过这个开发工作和汇编打交道要多一些，而汇编这种东西虽说看上去有些神秘唬人，但是实际上只是有点麻烦，却不复杂。

不过，如果我事先针对VM进行过充分的测试的话，今天本不应该出什么问题。但是我一直没有系统的组织过driver的自测代码，这使得我只能做一些很片面的测试，很不充分。当年偷了懒，今天就要还帐了。对一个复杂的系统来说，缺乏完整的单元测试代码对后期的开发效率影响很大，浪费的精力远远要比维护测试代码要多得多。类似的，对工程的组织也是一个重要的事情，不在这上面花精力，就会浪费精力在日常一些毫无意义的工作上。

虽说很多人都明白这些道理，但是却没几个人能做到。知易行难啊！

数据故障与备份

今天到公司，我听到了一个惨绝人寰的消息，公司的存储服务器出了故障，硬盘完蛋了。找DELL的工程师来诊断，他们认为有一部分数据已经无法找回来，只能考虑恢复4月18号的备份，教科书上总是千叮万嘱备份的重要性，今天总算让我遇到了一次大的。

从这次故障我发现了另外一些问题：

除了定期的异地备份以外，我们没有在实验室内的异设备的备份，指望RAID还是不灵的。就备份服务器来说，简单的堆一个多硬盘的机器，定期从存储服务器上复制即可，这样也免得一次故障就导致回档几个星期。

另外，游戏的分析数据都塞在一个数据库中，结果导致数据库太大，无法备份。应该按照时间分割成若干的小的数据库，这样对早期的数据库备份就会容易的多。

ps：第二天数据全部恢复了，虽说也是DELL这帮工程师搞的，但是我还是认为他们就是一群水货，太不专业了。

配置Ubuntu桌面环境

首先，我安装的是英文版本(10.4)，如果安装中文版，用户目录下的会建立一堆中文名路径，有点不太方便。

安装中文语言包

进入：System->Administration->Language Support

选择：Install / Remove Language

勾选：Chinese (simplified)

确认安装

安装SCIM输入法

sudo apt-get install scim

sudo apt-get install scim-chinese

进入：System->Administration->Language Support

设置：Keyboard input method system = scim

注销，重新登录，按下Ctrl+Enter就可以使用中文了。

安装工具

编译器 - sudo apt-get install

浏览器 - Chrome，这个无须介绍了

文本编辑器 - MadEdit，这个编辑器可以在Linux/Windows下使用，基本符合我的使用习惯，支持列编辑。

配置工具 & 环境

安装Chrome插件，Autozoom，将字体放大比例设置为150%

打开：Applications->Accessories->Terminal

选择：Edit->Profile Preferences->General

设置：取消“Use the system fixed width font”，Font = Courier 10 Pitch, size = 18 （这个是我惯用的等宽字体）

以上设置是为了放大我常用软件的字体（没有选择全系统放大是因为某些软件会有点混乱）

进入：System->Preferences->Apperence->Background

选择一张比较黑的作为背景，和浏览器背景色对比强烈

右键选择屏幕上面的网络连接图标->VPN Connections->Configure VPN->VPN->Add，配置VPN，这是必备的翻墙梯。

配置VPN时需要勾选 “Use Point-to-Point encryption (MPPE)”

如果VPN尚没有安装，无法选择Add，需要先安装组件：

sudo apt-get install network-manager-pptp

sudo killall NetworkManager

sudo NetworkManager &

结束

Google退出带来的一点麻烦

本来Google卷了就卷了，也不是什么大事，没想到今天我遇到一点麻烦。

我在撰写blog的时候，需要上传一张图片，但是发现无法上传，而图片只有90多K。我检查了一下，原来是因为我Picasa的付费已经过期，原先已经保存了13G的图片数据，所以无法再上传新的图片了。

本来这也不是什么大事，续费就好了。没想到付费的时候Google提示不接受来自中国的信用卡 - 按照退出的态度的确也应该如此。问题是我立刻就死火了...

看来除了准备VPN这个翻墙梯以外，还要常备一张国外的信用卡作为杀人利器啊！

Try post from linux (ubuntu 9.1)。

LPC JIT优化

这段时间我抽了些空，为LPC driver开发了JIT功能。

我花了两天时间完成了编码，在Windows下调试好以后，一到Mac上果然立刻就崩溃了。系统提示错误：“misaligned_stack_error”

我查了一下资料，原来MacOS的内核要求进入时栈必须保持16字节对齐（因为内核有几个要求16字节对齐的指令操作），这真是有些不方便 - 因为在32模式下所有的call都只推进4个字节的eip，也就是说一旦进行call调用就会出现不对齐的情况。我查看了一下gcc编译生成的代码，原来它在进入函数以后，除了推进ebp以外，还会自动保留一段内存作为继续调用下一层函数的参数buffer，这个buffer的大小等于16n+8。这样加上ebp和推进的eip个字节可以保证堆栈是16字节对齐的。

比如某个函数A在进行下一步调用（如X、Y、Z）时，倘若最多只有两个参数的话，这函数A在入口处会自动保留2个32位的字。

sub esp, 0x08

这样，当进行X、Y、Z调用时，无需push参数，只要简单的设置堆栈中的值作为参数，然后进行调用。比如：

mov [esp + 0],

mov [esp + 4],

call

这样，在返回时还可省去了add esp, 8这样类似的出栈语句，倒也颇为方便。

在解决了32位driver的对齐问题以后，开始调试64位的driver。

本来迁移到64位不该是一个复杂的工作，只要调整一下相关的指令即可，但是没想到花费的时间却远远超出我的预期。

首先，我对AMD64指令并不熟悉，做了一下相关的试验以后发现和我预想的有些差别。其思路并不是像16位到32位那样简单的把指令从32位扩展到64位，很多指令仍然是和32位的立即数打交道，只有极少数指令是针对64位立即数进行操作。我想了一下，这是正解。如果过于频繁的对64位立即数操作，会浪费代码空间，而大部分指令实际上并无访问64位立即数的需求。

指令系统本身并不是太大的问题，只要熟悉格式而已。但是当生成64位指令以后，一执行即告异常。我研究了一会，才确认错误的原因是生成的代码在数据段没有执行权限，只是给出的异常信息有点古怪，一时没有诊断出原因。这点不难解决，用mprotect/VirtualProtect调整页面权限就可以了。

接下来的才是大麻烦，在64位系统下，gcc并不是像C语言传统方式那样用栈传递参数，而是用rdi、rsi、rcx、rdx、r8、r9等寄存器来传递参数，这应该是x64指令增加了8个通用寄存器（r8 - r15），有点类似RISC，寄存器数量比较多，所以采用了这个方案。然而Mac和Win64采用的寄存器顺序不一样，另外不同的编译器对寄存器的处理是不同的，有一些寄存器编译器并不保证在函数调用以后不被破坏（比如几乎所有的x86编译器都使用eax/rax作为返回值，若调用函数，这个寄存器原有的值就会被破坏），关键在于不同的编译器的方式不一样，在这一霎那我真希望世界上只有一种格式，那就是标准。不知道有多少程序员的生命燃烧在这些毫无意义的工作中，不停捣腾各种各样的差异。

Mac上的64位刚调通，返回去32位的却又不通了，没有对齐的问题又冒了出来。我研究了一会不得其解，按照经验，我相信这应该是一个非常弱智的问题。但是很疲倦了，这时候最好的做法就是先休息。

睡了一觉继续干活，看了看，果然是很弱智的问题。因为gcc在编译汇编代码时，可能会自动插入一些指令 - 比如试图进行访问变量、函数地址的时候，gcc会自动通过计算，将结果放到某个寄存器（比如ebx）中，为了避免eb被破坏，gcc还生成了一句push ecx，导致堆栈没有按照我的预期对齐。

考虑了一下，我决定手工书写汇编代码，而不使用内嵌asm语句，因为不同的编译器在处理内嵌汇编指令的方式也是不同的，索性用机器码硬写反而会更简单一些。事后证明这个决定的确是正确无比，因为VC 9的cl根本不支持x64下的汇编。

在调试完Mac下版本以后，继续回到Windows下测试。32位模式很容易解决，64位果然又很麻烦。首先我连编译都编译不过去，查了半天才定位出问题，原来是x64的C编译器cl优化有问题，在做某些优化时编译器会卡死。我很纳闷微软究竟有没有准备好面对64位平台，XP 64已经面世很多年了，没想到VC9的cl即不支持内嵌汇编，优化也没有做稳定。我试着打了一下VC9的SP1（这个安装过程奇慢无比，我真不知道这个安装程序都要做啥），结果没有任何改进。

我想试着切换到Linux下先完成这个平台的测试，没想到我在vmware fusion虚拟机里面安装了64位的ubuntu 10.04以后，键盘无法输入，我连登录都无法完成。我又尝试下载了ubuntu 9.1的x64版本，没想到vmware却不认识这个操作系统，安装失败。而32位的unbuntu 9.1在编译时遇到了一个问题，缺少g++的组件。我顺手就更新了一下ubuntu，没想到更新以后原先通过vmware共享的文件夹无法找到了。这一刻我真是要崩溃了，黎明前的感觉真是无比的黑暗，又一天浪费了。

再睡了一觉，继续。重新安装32位的ubuntu的vmware tools后，解决了共享的文件夹问题。接下来我关闭了VC9 for x64的优化，完成了调试。

下午回到厦门，我重新安装了Ubuntu 10.04 x64版本，键盘的问题其实是一个大众化的问题，选择手工安装即可解决。安装好了以后测试一次通过，我确认了一下gcc生成的代码，和Mac 64位完全一样，很顺利。

优化性能总结（数字的单位是执行时间，ms）：

发件人 doing's board

注：Linux32和64采用的是虚拟机方式，Win32采用的是实体机。

注：没有Win64的测试结果，因为这个无法开启优化，测试数据意义不大。

这次优化对简单运算的效率提升效果明显，但是对外部函数调用等复杂操作没有什么效果，因为后者大部分CPU消耗在C语言而非虚拟机中。总的来说，这个优化对服务器端会有明显的效果，但是对客户端影响很小（就目前客户端的应用来说，脚本本身占CPU很少，任何针对效率的优化都没有太大意义）。

由于在最初设计虚拟机时没有使用渐进式的垃圾收集方式，而采用了引用计数，这导致JIT的实现受到一些限制。如将频繁判断引用，效率比较低而且会使得生成代码太大。另一方面，当初我没有限制类型限制，声明变量时使用的类型更多用于注解而不是限制，而无类型的运算在编译成本地代码时会太长，并且效率也不高。如果采用类型限制，那么在计算方面的效率应该可以提升一个数量级左右。

最后，如果一切均有标准，我想只要2、3天就可以完成这次工作，但是实际上我花费了一周的时间才告一段落。不过，为了建立标准，也许付出的代价比所有程序员浪费的力气还要大得多，如果这样，那就让这个世界继续混乱下去吧！

ps：linux桌面应用已经到了可以接受的地步了。Firefox、Chrome浏览器均可以保持和PC一样的功能和风格，常规使用的办公软件、开发环境也很不错，如果必要还可以通过虚拟机启动Windows操作系统。

ps：Mac默认4个桌面，刚好配一个宿主机、三个虚拟机（Windows、Linux32、Linux64），倒是挺合适的。

ps：Linux在虚拟机下运行driver的性能比Mac在物理机上还高，虽说虚拟机在进行运算时损耗已经相当低了，但是我还是很纳闷：做Mac操作系统的这帮人是怎么搞的？

ps：就做服务器而言，Linux的确是一个很好的选择，不论是32位还是64位。

在Mac之间迁移

新买了一台MacBook Pro，在启动打算安装时，意外发现一个提示：“你是否已经有一台Mac”，根据提示指引看到MacOS提供的同步功能，选择使用以太网进行同步之后，系统自动将我之前所有安装的软件、软件的数据以及配置环境全部同步到了新的电脑上。整个过程异常清爽，非常不错，免去了配置、安装软件等繁琐的过程。

迁移以后发现的两个问题：

1. 微软的RDC（远程桌面）不能正常工作，一启动就会崩溃，重新安装以后解决；

2. XCode没有自动同步，从新安装。

ps：新的MacBook Pro有一个设计上让我不愉快的地方，四边的边缘过于锐利了，摸上去有一种危险的感觉；

ps：新的触控板有点不太适应。

MBTI

最近公司培训，我选了的课题是MBTI性格类型分析，因此翻阅了一些资料，倒是初窥门径，略有小成。

晚上接MM回来，闲聊的时候说起MBTI，我估了一下她的性格，应该是E(S/N)FP，对S/N方面我不能完全肯定，感觉偏向N多一些。我MM很有兴趣的去测了一把，果然是ENFP。

其实对一个比较熟悉的人，判断性格类型是一个非常容易的事情（若非如此，MBTI模型本身就缺乏价值了）。分类本身并不是这个模型的目的，只是一个初步手段，分类后加强群体之间沟通的有效性、个人可以进行针对性的调整才是发挥这个模型的价值。我了解分类只用一两天，但是在试图进一步了解类型之间沟通差异，试图做相关的分析时就难得多，一时间无法掌握。