为山九仞，功亏一篑

早晨上班路上，突然想起了"功亏一篑"这个词，但是却不记得前面那句是什么了。依稀有个印象是“为山九仞”，但是似乎有点矮？所谓万丈深渊、万仞高山，这个“九仞”看上去似乎有点小气，不够夸张（就连铁掌帮帮主都要叫做千仞）。但是怎么想也想不起来还有别的什么说法，难道是“为山千仞”？语感就不对。

到了公司一查，果然是“为山九仞”。一仞也就1.6米的样子，看来尚书还是很务实的。这句成语用白话来说就是：堆一个15米高的土坡，差了一筐土没成。

附百度词典出处： http://dict.baidu.com/s?wd=%B9%A6%BF%F7%D2%BB%F3%F1

ps：百度词典里面的英文解释看了真是让人感慨，这么一翻译，味道全无了。所谓信达雅，这个雅怎一个难字了得！

2009·北京

北京对我来说，陌生中带着一丝熟悉。在我记忆中，来这里的次数数不胜数，但是从来没有一次住的超过一个月。北京2环以内和很多地方我都知道并且去过多次，但是却没有让我产生任何归属感。

这次住在宝辰饭店，我事先也没想到离火车站如此之近，窗户下面就是马路，对面则是北京站的广场。我仔细的瞻仰了火车站许久，当年曾有很多次从这里出发前往各地，令人怀念。十几年来，它似乎一丝不变，除了人看上去少了很多（大概都去西客站了吧）。

去国信的路上经过了天安门广场，看到广场上零零碎碎的建筑（最近又多了56个民族柱），感觉广场越发的小而拥挤了。看了以前的照片，我更喜欢40年前的广场。除了天安门广场，其他的建筑很难引起我共鸣，都说北京的建筑大气，可是我除了四四方方，并没有看出所谓的“大气”。如果非要我给一个评价，那就是我只感受到了封闭。当然，这不是有意贬低北京，事实上，除了沙尘暴（这几年似乎已经被按住了）和服务水平不够高以外，北京给我留下的感觉很好。同时，在北京如此密集的人才也说明了大家对这个城市的喜爱。

2009欧洲之旅 - Oct/16

昨天购物，今天前往雅典卫城（也就是小强们奋斗的地方）。

今天没怎么下雨，但是天色仍然阴沉沉的。在卫城遇到Princess Cruise的Tour团，至少有7，8个，游客之多让我感觉有点像是去故宫，不知道平时是否有这么多人。

从Hilton酒店打车到卫城8元多，但是回来打车司机开口就要15元，因为担心时间不够，所以就忍忍挨了一刀，雅典人民不够厚道啊。

回酒店后就前往机场。在机场办理退税的时候遇到一些麻烦 - 只有在希腊境内购买的商品可以在希腊直接退税，其它的则需要在海关退税办公室里盖戳以后回中国办理，或直接邮寄退税单给相关机构办理，总的来说让人感觉很不靠谱。而且在希腊购买的商品的退税单我们也遇到了一些麻烦，办公室的人说到一个兑换货币（Currency Exchange）的地方直接领取现金，但是我们找到附近一个兑换货币的点，却说是在过海关后的地方，不在他那里，最后我们几经折腾才明白其实外面也有一个，就在那个询问的点的不远处，离退税的办公室都很近。

排队过海关的时候我们则又遇到了一个问题，我们排了差不多半个小时的队，结果到海关人家一看登机牌，说在对面。真是让人疯狂，为什么不在队伍一开始排队的地方就安置一个人检查？事实上，我们去对面的时候，的确有一个人检查登机牌，看你是否来对了地方。

希腊人民仍需努力啊！从另一个角度看，办个奥运会其实不用像北京那么费劲，雅典这样子不也搞定了嘛。

虽然我们通过携程购买往返的联程票，但是在办理雅典-巴黎的登记手续时，对方（奥林匹克航空，相当于希腊的国航？）完全不知道我们要去北京的样子，登机牌也只有第一站的。我们问了行李需要怎么办，他们回答只要到巴黎机场确认就行了，感觉很不靠谱。然而我们在巴黎落地的时候，从廊桥出来后则给我了我们一个大大的惊讶，有人举牌子写着我们的名字，带领我们去国航的办票柜台。我们不知道这是谁提供的服务（国航？奥航？戴高乐机场？），总之很让人惊讶。巴黎的机场设计的极其诡秘，如同迷宫一样，而我们下飞机以后，离登机只有一个多小时的时间了，如果没有人带领可能还真成问题（找地方、办票、海关、安检）。当然，我现在称赞他们还为时过早，因为我还在巴黎前往北京的飞机上，落地以后拿到了行李我才能真正的放心啊！

ps. 我们在法国的退税办公室又试验了一下，因为在希腊戳已经盖好了，所以直接去Cash refund即可。但是办公人员说不行，我不能确定是因为我们填写了退税的信用卡卡号的缘故，还是在希腊盖戳的问题，但是有的单子又是可以退的。有点困惑。看来最好还是不要在希腊出境，麻烦会少一些。

ps. 行李果然没有跟上，我们到了北京，但是行李没到。留下通讯方式以后，第二天行李才给我们送到。还好是直接送到深圳和厦门家里。

2009欧洲之旅 - Oct/15

昨天MM做了一番功课，研究了雅典的名牌店位置，都距离酒店不远，走路就可以到达。

今天10:00钟起来，吃了早饭，我们一行4人直奔SHOPPING而去。当然，我还是充当活动购物车的功能。

雅典的品牌店还算比较集中，总之从我们住的酒店（HILTON）走过去也就一刻钟的样子，穿过一条大路和若干小路就可以到达。店铺比较密集，购物不错。只是今天天气不太好，有点下雨，打伞行动有些不太方便，因为雅典的小街人行道实在是太狭窄了。

不知不觉就到了下午16:00，MM和陈拓琳他们均有斩获，算是不虚此行。回来的路上我们在一个地下小餐馆用了一餐（不知道算是午饭还是晚饭），味道挺好。我点了面条和炖牛肉，面条基本没什么味道，和国内的挂面挺接近的，不错。另外炖的牛肉也很香。

在雅典的这些店我感觉还是LV的服务比较好，CHANEL和BURBERRY的感觉不好，其他的差不多。

ps. 希腊人民的素质有待提高，抽烟的太多，开车太猛（尤其是开好车的），路面卫生状况需要提高。

ps. HILTON靠街的房子太吵，我们下面就是大路，晚上吵的我睡不着。尤其是那些开摩托的，引擎太吵了。

ps. 2004雅典申奥时北京没有参加，我原先以为北京和雅典发展尚有差距，今天看来，我觉得当时两个城市发展水平还是比较接近的。如今的北京，我认为早已超越雅典了。当然，申奥也不是只看城市的发展水平的。

2009欧洲之旅 - Oct/14

今天中午起来，前往雅典。本来想在这里呆3天，我和MM觉得这里毕竟不够现代化，有些不太方便（电力时不时还会中断），所以提早一天前往雅典。

中途在一个小店休息了一会，我查了一下GPS，海拔600多米，估计附近的山应该要上千米了。10月中旬这里气温已经显得有些低了，需要穿上外套。

一路顺利到雅典，在希尔顿住下，总算从乡下回到城里了 :) 在酒店房间里，我们远远的望了一下雅典卫城，已经20:00点了，天色已晚，看不太清楚，明天可以出门去看看。

ps. 希腊人开车还是比较猛的，尤其是那些开好车的。估计速度时常超过160Km/h。

ps. 雅典城里开摩托的人不少，开车需要小心一点。

ps. 华人在雅典的似乎不多，我们晚上想吃中餐，查了一下，居然2009年才兴建了一个China town。另外，没有听说有什么好的中餐馆。

2009欧洲之旅 - Oct/13

昨天在古堡住下，略有点吵（似乎白天更安静一些），早晨突然听到下雨，噼里啪啦声音很大，但是等我出门看时，地上已经干了。十月份应该是这里的雨季，比夏天降水要多。

中午吃完饭，我们一起沿着古堡的城墙向上爬，一直到顶。从这里可以俯视整个城堡，我看了一下GPS，应该是160米高。城堡背面是几乎垂直的悬崖（它是沿山而建的），直抵海面，但是用相机拍不出那种凶险的感觉，比较可惜。

下来以后闲逛，MM看中了一个挺有意思的衣服，可以有8种穿法，每种都有些特点。希腊的小店给我的感觉就是总是各有特点，不会让人感觉完全雷同。也许在他们血液里面就流淌着个性化的因子吧。

2009欧洲之旅 - Oct/12

今天从Nafplio离开，前往Monemvasia。

为了欣赏伯罗奔尼撒半岛的景色，我们选择了一条沿海南下，从山间穿过的路。看过才知道，原来这里的山居然很高，有很多至少有上千米。想当年斯巴达人在山上的集训营训练，只怕不是一般的辛苦。

路上一度遇到一次希腊警察查车（估计是查超速），拦下我们以后。陈拓琳亮了一下美国的驾照，租车的证明，希腊警察看上去不是很满意，说不能用加州的驾照，应该是美国签发才对。不过在我们印象中，美国都是各州签发驾照，哪里有标注是US签发的呢？不知道是我孤陋寡闻，还是希腊的警察少见多怪。总之，他们也不能把我们从车里拎出来不管，于是我们还算是顺利的过关了。

我们住的地方在海中一座巨大的岩石背后的古堡内，从海边的小镇有路直接修到岛上，所以可以开车直接抵达古堡的门口，在往里就需要步行了。我们住的酒店在古堡的尽头，走路要走上一段。一路上下台阶，还好有人专门运送行李，否则自己还真不太容易搞定。

所谓百闻不如一见，在亲身体验了古堡内部的建筑结构以后，感觉要比从照片和视频上看到的要强烈得多。事实上，它的结构和指环王电影里面所拍摄的样式并没有什么根本性的不同，但是只有亲身体验以后才能感觉和中国城池那种明显不同的对比。中国的城池类似于城市，而欧洲的城堡则是要塞，或许日本的城池修筑的更类似欧洲，军事性更明显一些。

古堡内的街道狭窄，能容纳的人不多，令我惊讶的是里面居然还有一个小广场，上面还摆着一门大炮。我想，是不是战争爆发时，领主就在这里召集他的士兵们发表讲话动员，然后就开始投入战斗呢？

2009欧洲之旅 - Oct/11

中午起床，在镇里用完午餐（早餐？），然后驱车前往位于Epidaurus的古代歌剧院。

中途迷路一次，没有到目的地，反而是进了一个小镇。我们问路的时候遇到一个很好的拥有希腊血统的加拿大人，他在给我们指路以后，怕我们找到不到，特地开车带了我们10分钟，一直到有路标的大路上。

这个古代的歌剧院应该是建于公元前500年，后来罗马时期又扩建过。它依山坡造成一个1/4的圆筒，上阔下窄，古代希腊人已经掌握了关于声音相关的一些技术，巧妙的利用了回音以增强音量。我们正好遇到一个大妈在舞台中高歌了一曲，虽然听不懂，但是效果的确很不错，即使在最后一排也能听得很清楚。后来有几拨人都兴致很高的上去试验了一下，很有意思。不知道最近几十年有没有人真的在这里举办过音乐会。

夕阳西下的时候我们返回Nafplio，路上居然发现有一个China Town，不过没有进去。在Nafplio我们没有看到华人，不知道他们聚居在何处。

2009欧洲之旅 - Oct/10

今天抵达雅典港口，也到了下船的时间。

昨天我们已经把行李打包好，放到房间外面，船上的服务人员会自动将行李运抵到目的地（如果目的地是机场，那就可以直接免去扛着行李过去了）。

早晨7:00起来，用罢早餐，下船以后我们去了行李存放的地方。因为这里和Hertz租车的地方有点距离，于是我和陈拓琳先去取车，没想到距离还真是有点远，大概和我们的港口有2公里的样子（如果是另一个Terminal出来应该会近很多）。而且租的车居然是一个手动档的，还好陈拓琳是司机，倘若是我那就完蛋了。

从港口驱车前往Nafplio的酒店，大概两个小时左右，GPS导航的路还可以，小路基本走的不多。这里是希腊的前首都（刚从土耳其独立出来的时候定都于此），我们住的酒店正好面对港口中的城堡，位置不错。

Nafplio不大，只能算是一个小镇，但是景色不错，local的气息更浓厚一些。当地的海鲜味道不错，可以品尝一下。这里的作息偏晚一些，20:00出去也不必担心餐馆不营业。而且似乎当地人睡的很晚，夜里还经常听到喧哗的声音。

ps. 希腊这一带的人给我们的感觉就是开大排量的好车比西欧更多，气焰要嚣张的多，有点像是在国内。

2009欧洲之旅 - Oct/9

今天终于进入爱琴海了（确切的说，我不知道昨天停泊的港口是否属于爱琴海，但是今天的肯定是），抵达Mykonos（米克诺斯）岛，据说和圣托里尼岛相齐名。

早餐后下船，做摆渡车到小镇（离港口也就2公里左右的样子，绕过一个海湾即可）。沿着小镇走了走，领略了一下希腊小岛的风光，的确很有特点。白墙、五颜六色（蓝色尤多）的窗子，很有浪漫色彩。从小镇穿过，有很多商店，摆的商品都颇有不同，不知道他们生意如何。只是从态度来说，店主们都很悠闲，并不急于做成生意。到了吃饭时间，门一关，有的说六点再开，有的今天也就不再开了。

穿过小镇的街道，到了一处风车聚集的地方（4个），回头可以看到整个海湾，我们的游轮就静静的停在海湾另一端的码头。据说这个小镇的夜生活有些意思，所以游轮22:30才出发，比前几天都晚的多。不过我们还是18:00就启程回到了船上，今天需要打包收拾行李，明天就要在雅典下船了。

吃晚餐的时候，国内的时间已经过了12:00了，算是到了10月10日，我和MM领证刚好一周年，庆祝一下 :)

今天有一个比较有意思的细节：

我MM前几天都想要一份提拉米苏，但是两次下单他们都说预定了以后需要等到第二天才能拿到，结果我们都放弃了。

第三次我们终于下了单，在隔天拿到了提拉米苏。当天正好有反馈单子要填，我MM抱怨了没有提拉米苏。

第二天也就是今天，我们从小镇回到房间时，我MM又想叫一份提拉米苏，我说可能未必有，没想到他们说已经把点心送到了我们的房间。果然，就放在我们的桌面。我不知道是昨天的抱怨起了作用，还是连续三次下单的结果。但是相应的，我每次吃正餐的时候都会叫tabasco sauce，今天正餐上来，没等我叫，tabasco就送上来了。要知道，我每次用餐的餐馆并不相同，不得不说他们服务的细节处理的不错。

2009欧洲之旅 - Oct/8

今天抵达Gythion。

一日无事，宅在船上看书。看完了《地中海的秩序》，倒是让我有所思悟：

1. 贵在坚持
这个道理当然是人人都懂，但是真正有所悟还是要不断的体会。地中海霸权交叠更替，而笑到最后的（或是说笑得最好的）算是罗马帝国。但是罗马的崛起的确是一波三折，几次都被打的落花流水，惨不忍睹。但是他们韧性最强，一直坚持下来了，最终成就也超越了所有的前辈。

在罗马城被高卢人占领而被迫躲上山时；
在和萨莫奈三番两次交手而胜负难定时；
在面临迦太基强大海军而自己却无军舰时；
在汉尼拔纵横亚平宁而罗马众将却无可奈何时；
在斯巴达克率领起义军呼啸半岛南北时；

罗马总是以它特有的韧性坚持下来了，这才有将来的罗马帝国。

2. 厚积薄发
似乎起步时越是艰难，坚持的越久，越辛苦，爆发起来也就越发不可收拾，也就越持久。但是若积累的不够，那后来的成就也就有限。

马其顿王国积累了一段时间，终于成就了神奇的亚历山大。统一了希腊并且带领军队摧毁波斯，一直打到了印度河流域。但是总的来说积累的还是不够，亚历山大以后，帝国随即也就四分五裂，陷入了衰落，远不如罗马。

所以，不论怎么打造自己的根基都不为过，即使为此可能会错过了许多机遇。

3. 有没有永恒的目标？
罗马最后相当于毁在了自己的手里。他们征服了亚平宁，征服了迦太基，征服了希腊，征服了整个欧洲和小亚细亚，打败了所有的敌人，接着灭掉了所有的盟友。他们终于没什么外在目标了，于是开始内战。

最后，罗马的统治阶层生活日益腐化，但是又不愿意放弃已有的享受，军人的待遇实际上越来越差（已经没有东西可以掠夺了，他们的存在只是为了稳固统治而不是扩张），最终不可避免的走向衰落和灭亡。

我想，在游戏里，一个参与的玩家，会有让他奋斗5年，甚至是10年的目标吗？我想这很难，如果真是如此长久的目标，可能让大家刚参与的时候就放弃了。但是如果目标有限，他们达到目标以后不就会失去兴趣了吗？

这看上去真是一个无解的命题。没有目标就是去了游戏性（玩家可能因为社交性留下来，但是不是因为游戏本身），一个看上去很容易就可以达到但是实际上却很遥远的目标，也许更好。

ps. 今天吃晚饭的时候，侍应生知道我们从中国来以后，问我们是说广东话还是普通话。我们有点奇怪，问了一下才知道，原来他印象中，香港人说的就是广东话，而其他人则是说普通话。中国的语言当然不止这两种，之所以能够让人这么去区分，那就是经济的力量。

2009欧洲之旅 - Oct/7

今天达到的港口是Katakolon。

我们之前预定了一个行程，参观古代奥林匹克运动场遗址。早晨8:30出发，我们起来晚了，没能来得及吃早餐，拎了几块巧克力就狂奔出门，还好赶上了。

这个遗址有宙斯、赫拉的神庙，同时也相当于古代奥林匹克运动会的奥运村。听导游讲解，斯巴达人拿了奥运会40%的金牌（古代希腊是城市联邦，有30多个城市，斯巴达只是其中的一个）。这点和他们的军事化体制应该有很大的关系，斯巴达人是以战斗为荣的。作为奥运会的冠军，是巨大的荣誉，联邦不同的城市也会给与不同的奖励，比如雅典可能就是终身让你可以免费吃喝玩乐，而斯巴达人则是让你享有在战场第一线和国王一同战斗的权力，从这点来看，不同的城邦追求的目标就大不一样。基于这种价值观，第二次希波战争时，斯巴达300勇士在温泉关被波斯包抄时国王亲自带队勇敢断后，掩护主力撤退这种行为也就毫不奇怪了。

类似的，在古代奥林匹克运动场入口有两处石碑，一处是冠军们的名单，另一处是作弊者名单，这代表了荣誉和耻辱 - 这就是一种非金钱的激励机制。

回到船上大概是13:00左右，我们感觉颇为饥饿，冲到餐厅一看... 大家都抱着相同的想法来这里，真是人山人海啊！从这点来说，如果你和大多数人的想法雷同，那就缺乏核心竞争力 - 虽然船上的服务很好，但是我们的午餐用起来还是有点辛苦，至少等饮料就等了半天。

下午正好无事，我把之前买的那本《地中海的秩序》翻出来看了大半，总算把之前古欧洲的历史基本串到一起了（以前了解的过于零散而不系统）。书总的来说还行，但是很多细节让我不满意。比如很多人命地名前后不一致（相同的音，不同的译法）；文章中的名字和引用地图的名字不一致；文章中引用的重要名字（港口、城市、交战地点等）地图上没有。作者不够严谨，让我感觉有些遗憾。

ps: 从斯巴达人对冠军的奖励来看，我认为网游设计是完全可以参考的：荣誉，抑或称之为虚荣也是非常重要的一点。设计者并不一定要给与玩家实惠的奖励。类似的，在公司管理上，我们也经常被提醒或是提醒其他人，不要陷入纯物质奖励这种单调的思路里。当然，这点说起来容易，做到很困难。很为时候非物质奖励容易被人认为是忽悠，或是被对方完全忽视。竖立一个价值观是一个长期的过程，总的来说，如果推行价值观的人自己不信，那就不能指望别人相信。如果不能建立其他的价值观，那就只能用金钱作为衡量了。

ps: 古代奥林匹克运动会起源与776 BC，持续了293届，直到396 AD，从未中断。现代奥运会则起源于1896 AD。不论是古代还是现代，奥运会的诞生和历程的背后都伴随着战争与和平。

2009欧洲之旅 - Oct/6

今天到了希腊的Fiskardho，昨天睡的有点晚（因为时差的缘故，时间调整了一小时，结果凌晨2:00多才睡），早晨送room service人到了以后才把我吵醒。

中午在船尾的餐厅吃了点东西，这里的海产品不错，味道挺好。因为正是一天比较暖和的时候，有些人在船附近玩一些水上运动，可惜我们都不擅长，没什么参与的兴趣。

饭后我们下船到小镇逛了一下，据说这里主要是季节性度假胜地，冬天的时候整个镇子就只剩下50来人了。小镇现在正旅游旺季，还是挺热闹的。MM买了点有当地特色的小东西，这里的店不像超市，是可以砍价的，比较有成就感。

下午16:30左右我们从镇上回到船上。我观察了一下接送小艇的调度，和我预想的一样，从码头到船上有两条小艇对开，这样可以减少客人等待的时间，同时不会过份浪费油料，安排的还是很合理的。

晚上吃饭的时候着实让我们汗颜了一下，因为昨天我们用罢正餐准备上甜品的时候，因为觉得意犹未尽，于是又点了几份沙拉。没想到今天我们吃完正餐，侍应生问我们：“还需要一些沙拉吗？”真是好记性啊... 当然，估计也是昨天我们的点单顺序太让人奇怪了，一时间很难忘掉。

第二天登陆时间是早晨8:30，需要早点休息了。

2009欧洲之旅 - Oct/5

早晨起来船抵达意大利的Bari港，我想了很久，对这个城市没有什么明显的印象。看来90年代这里没有实力很强的球队。

今天无意发现，出房门以后信号急剧增强，从很弱（1-2格）直接到很好（满格）。我沿着房外的走廊走到Bar，信号依然很强。估计信号的基站在船的中央，发射信号时沿着走廊一路无阻，但是如果要到我们房间里则需要斜着穿过几道墙，会有严重的衰减。

在Bar里实验了一下上网，速度不错，国内的游戏也能登录，当然延迟不小。

今天本无下船的打算，顺势在船上宅了一天，吃饭、看书、打牌，看看问鼎的bbs，也很逍遥。

2009欧洲之旅 - Oct/4

我们的游轮在夜里穿过了亚得里亚海，从威尼斯来到了克罗地亚的Sibenik。我查了一下资料，克罗地亚的历史一言难尽，但是其沿海一带曾经被匈牙利国王卖给了威尼斯共和国，也许这里史上和威尼斯还颇有渊源。

早晨被吵醒，已经是9:30了，昨天叫了room service，此时早餐已送到，洗漱完毕就可以用餐了，比较省心。

来之前我们没有办理克罗地亚的签证，今天本不打算上岸。但是昨天船上的工作人员帮助我们解决了这个问题。我们便预定了一个trip（每个人收费$139。需求就是这么创造出来的，如果没有代办了签证，我们就不会有这个需求），前往克罗地亚的国家公园，其主题主要是以瀑布为主。

中午12:30下船乘坐快艇上岸（可能是受港口吨位的限制，游轮没有直接系泊到码头，而是离岸有一定距离），一路上居然没有经过克罗地亚的海关。看来游轮公司的工作人员代替克罗地亚海关行使了海关的权力 - 从这个角度来说，游轮公司经营起来还真是要能搞定各地政府才行。

上岸以后，乘坐了一个小时左右的bus到了公园，途中景色不错，不过也无需大书特书，一切都有照片。克罗地亚名为千岛之国，最不缺的大概就是各种水景。

从公园回来以后，登船以后17:00左右（17:30船就要离港了）。我们感觉有点饿，叫了点沙拉和热狗一类的食物垫了一下，没想到垫得有点过头，因为19:00就是我们的晚餐时间，食欲就没有那么旺盛了。总结经验就是：中午就应该啃点东西，下午就不会这么尴尬了。

ps: 克罗地亚的历史很复杂，有兴趣的可以去了解一下。我原先一直对它的位置（包括巴尔干半岛）都不甚了了，今天才算心里有数。和威尼斯隔海相望，相距不远。

ps: 我关注了一下手机的信号，在海上航行时运营商是NOR 18（应该是通过卫星通讯的），这算是美国的地盘，资费很便宜。但是到了港口附近，则关闭这个链接，自动选择当地的运营上，比如克罗地亚就是HT或VIPnet，资费贵了不少。

ps: 船上的WiFi不是很好用，信号太弱，很容易断。如果浏览网页，上上QQ自然没有问题。但是如果要访问游戏... 我就没有登录成功过。而且在房间里面无法使用有线连接，这也算是服务的一个瑕疵吧。信息化工作仍需加强啊！

2009欧洲之旅 - Oct/3

庆祝中秋合家快乐。

早晨从米兰火车站赶赴威尼斯（票在昨晚已经买好），威尼斯有两个火车站，要在Mestra这站下车，然后打车去港口会比较便捷。如果抵达终点站S.Lucia，那么就要做水上的小船过去港口，相对比较麻烦。这两站的距离其实非常近，Mestra在大陆（通过跨海大桥直抵岛内的港口），另一个则在岛内（岛内是没有汽车的这样的交通工具的），有点像集美和厦门岛内的关系。

下了火车以后，我们看见几辆的士在等，没有太在意，想再打听一下是否有其他方式前往港口，比如乘坐bus。结果是乘坐bus还需要转车，而搭乘的士价格也很便宜（20多欧），于是决定打车。不料此时的士却已经没有了，足足等了半个小时，才打上车。一开始错过了机会，没有珍惜，当你失去了它才追悔莫及...

打车到了港口，地面工作人员会自动上来询问相关资料，给行李打上标签，无需你再扛着打包小包奔波。接下来他们会指引办理Cruise的check in手续，服务很专业。期间护照会被暂时收走，进行核查（当时也不知道他们要核查什么内容）。相应的，他们给我们提供了房卡，其功能除了钥匙作用外，还相当于游客在船上的身份证明，并且可以用于支付费用（当然，check in时已经确认了信用卡的信息）。

我们这次Cruise选中的船比较新（据说2009年才建成下水），Seabourn Odyssey。它排水量不大，上面的房间数量也不多，只有200余间，但是普遍档次不错。登船后看了一下房间，面积虽然不大（40多平方米），但是布置的很巧妙，客厅、卧室、衣帽间、浴室、卫生间、通道布局很合理，细节之处不一一赘述。我们安顿好以后到甲板上参加Party，准备离港出发。天气有点冷，在房间中颇有寒意，但是到了甲板上晒晒，10月份的太阳很是舒服。看了看同船的游客，大多都是老人，我们这组实在是年轻的有点不像话（虽然也有极少几组客人年纪看上去似乎也颇小），Cruise这种活动看来不太是年轻人的爱好（花费过多，活动空间有限）。

Party之后我们前往预定的餐厅就餐，因为这个餐厅在甲板上，10月的地中海夜里还是有点冷的，我披了件毯子感觉才好点。当晚正值中秋，圆月高挂在天际，月光皎洁，照射得海面颇为明亮，隐隐看见海波荡漾，正应了那句“海上生明月”。

正在用晚饭的时候，有人带着我们的护照来访。因为我们第二天停靠的是克罗地亚的一个港口，而我们没有克罗地亚的签证（倘若不是前南斯拉夫分裂，也许我们可以看在同为社会主义兄弟的份上免签？）。之前在国内询问时，因为克方说要去北京签证，我们实在没有这个兴趣，也就罢了。这次船上的服务人员过来询问我们是否有兴趣在克罗地亚上岸参加trip，如果有他们可以代为处理签证手续，我们自然欣然同意，虽然不知克罗地亚有什么值得一游之处，但是见识见识总不是坏事。

关于网络：

在船上用了一下网络，船上本身有覆盖所有房间的wifi，但是收费不菲，我选了7天的package，$234。访问国内延迟较大，速度也不快，下载问鼎15-40KB/S。但是访问国外的网站似乎还行。

手机信号一直通畅，但是在甲板上一直都是vodafone的，信号比较弱（我怀疑是陆地上基站的信号）。回到房间以后变成了NOR 18，信号满格。移动还给我发了一条消息：欢迎来到美国 - 看来这是船上的信号。虽然诡秘一些，但是此时动的资费比vodafone的便宜很多，GPRS流量从每KB 5分变成了1分，短信0.49元一条，接听话费2.99元，价格不贵。

2009欧洲之旅 - Oct/2

抵达米兰，落地时8:30的左右，出关很顺利。我们一行4人，海关人员几乎没有问任何问题就放行了，连VISA上的照片都没有对比（虽说他们看黄种人可能都一样，但是好歹也看看看，意大利人做事不是很靠谱）。

一年前我和MM度蜜月的时候，我们从米兰离开欧洲，今天算是回到米兰开始一轮新的旅行。

出机场以后找bus到米兰火车站（酒店在那里），因为我们不知道米兰是否只有一个火车站，而且和bus卖票的人语言交流不是很通畅，稍微耽搁了一下。不想旁边就有人（应该是来接机的）用汉语说：“这个就是去中央火车站的，没错”，惊讶之余，不得不感慨国人真是无处不在，出门方便了许多。

到酒店（这就是去年在米兰住的那间，虽然我们对其评价不高，但是离火车站的确很近，就在斜对门）以后，发现因为太早（才10:00）还不能办理入住手续，需要下午14:00以后。于是先寄存行李，然后去市里购物。

虽然这次没有地陪，但是我MM记忆力很好，而且米兰的地铁线路简单，购物的地方标志明显（就在dome大教堂旁边），顺利的抵达了目的地。

在大教堂附近的名牌店里逛了几家，规模都不大，其中LV的第二层一直到中午也没开放。我们打听了一下他们的旗舰店的位置，就在附近的名店一条街上，吃罢午饭，按图索骥，很快找到了目的地。看到这些店，才召唤起我去年的些许场景的回忆。我对场景一直记忆不佳，看世界如看游戏地图，总觉得似是而非，很相近，不好区分。

和去年相比，我感受有意思的几点是：

1. Versace的布局发生了变化（不知道他们是不是定期会调整布局）
2. Gucci和Cartier里面有Sales可以说很流利的中文（讲的是普通话，不是华人）
3. LV和Gucci的衣服看上去不错，发现了一些适合MM穿的，以前只注意它们的包包了

因为飞机上几乎是一路睡觉睡过来的，醒来以后就是当地时间7点多了，所以几乎没有感觉到时差的问题。晚上回到酒店，办理入住手续，国内时间已经是夜里4点的样子。而且因为逛了一天，觉得颇为疲倦，但是还不至于到了困乏到睁不开眼睛那种感觉。所以总的来说，选择夜里出发，早晨到米兰似乎是一个不错的主意（当然，若是飞机上没有休息好，那就糟糕的很了）。

ps. 10月初米兰的气温还可以，穿短袖也没有问题。

2009欧洲之旅 - Oct/1

庆祝新中国成立60年。

早晨从厦门出发，先到上海，夜里1:30（第二天）乘坐国航的航班前往米兰。我对比了国航和阿联酋航空的头等舱机票，国航的要贵1万元，大概17%的样子，基于支持国货的考虑，我们还是优选了国航的航班。

在厦门机场的时候，刚好10:00左右，看了一点阅兵，托飞机晚点20分钟的福，多看了一会。可惜掐头去尾，看得很不完整，很不爽，只有将来看重播了。

13:00到上海浦东，给MM打了个电话，没想到居然通了。她要从深圳赶过来，按照道理这时候应该已经出发一个小时了，这岂不是意味至少晚点一个小时？我考虑和陈拓琳先领登机牌，把行李放好，然后再说。没想到到了国航头等舱的办票柜台，居然没人值班。喊了人过来，地勤的小妹说不能办理手续，要到22:00才能办理。我问如果没有行李呢？她说需要请示一下领导。最后我们问了一下行李寄存的地方，她说在一楼，然后就此作罢。

总的来说，我对国航上海的地勤很不满意：

1. 最理想的方式是办理登机手续，他们自己处理好行李的问题
2. 如果受制于流程的不可靠性不能执行1，那么可以帮我办理登机手续，带领我们去寄存行李
3. 至少可以带我们去行李寄存处，而不是急匆匆的回去聊天

当然，做好服务是一个非常困难的事情。我不认为能够让大部分人都“发自内心”的替别人解决问题，但是需要某种方法能够使得组织内成员尽力为客户解决问题。这个很有挑战，我没什么建设性的意见。

我不知道是国航的地勤普遍不行，还是只是上海浦东机场如此，不过对比阿联酋航空在香港的地勤人员来说的确是差了一截。

在机场寄存好行李以后，我们在咖啡厅了蹭了2个小时，等我MM从深圳过来。接到人以后一起去市里逛了逛，体验了一下磁悬浮，速度很快，就是有点不平稳的感觉，不是很舒适。据说上海这个磁悬浮是世界上第一个商业化的项目，算下来开发商用我们的地盘作了一个demo，应该倒贴我们点才是。

晚上登机（候机的时候终于把阅兵从头看了一遍），途中吃饭睡觉，顺利抵达米兰。国航的空中服务水平还不错，可以考虑继续支持国货。

谁能做好服务？盛大不行

恭喜盛大将网络游戏事业部又上了一把市，我的确很佩服，古人云一女嫁二夫我今天算是看到了。

这不是挖苦，我实在是佩服。

我今天不是说这个事情的，而是说说盛大网络游戏的服务水平。一言以蔽之：盛大的客服和第一线主管不是想替玩家解决问题，而只是应付差事的。

注：也许他们的高级主管不是这么想的，不过我一向认为，什么样的主管，就有什么样的下属。

事情的经过简单说说：

1. 我在玩盛大提供的游戏永恒之塔（aion）
2. 我在盛大有16个白金账号（也就是充值200元以上的）
3. 这些账号是最近一个季度贡献的（也就是3个月内充值超过3200元，当然实际上不止）
4. 因为机器中木马，我有一个号被盗了一些装备（成本500-1000元，装备都是绑定的，盗号的只能分解掉卖钱，估计卖不到100元）
5. 我试图用在线客服找回，发现不行，必须绑定了密保才可以（我用的是手机屏蔽来保护的 - 各位看官，为什么手机屏蔽也会导致被盗？且见下面分解）
6. 我委托上海的朋友帮我去盛大公司找回
7. 几天交涉未果，在提供原始注册信息包括：姓名、身份证号、绑定邮箱、绑定手机、密码回答问题以后，还需要提供若干历史密码。据说这个账号曾修改过6次，而我只记得两个准确的（谁要是能闲的没事在有16个帐号的情况下还把自己曾修改过的所有历史密码都记住我会很佩服，我是用一个小本子记录我所有账号的当前密码的）。他们有一个客服主管跳出来说，让我最近两天修改6次密码，每次修改后都登录一次，这样我就可以保证有8/12的正确率了。
8. 很好，我将密码分别修改为sbaaaaaa、sbbbbbbb、sbcccccc、sbdddddd、sbeeeeee、sbffffff，并且每次还要登录之，因为永恒之塔启动很慢，所以我感觉很累，很SB。
9. 我委托朋友再交涉的时候，他们说我的密码一共修改了14次，后面新提供的只有两个是正确的（!@(#*!&@(#!@#&）
10. 几次折腾，东西没有找回，我朋友惹了一肚子气，大骂盛大这些客服都是在推卸责任，根本不想解决问题。

OK，这个结论我认为他得出的太晚。在一个月之前我就是这么认为的（那是另外一个事情）。我知道这应该是盛大的系统本身有问题，客服人员也受到了限制，所以给出了这么SB的解决方案。

但是：盛大密码找回的系统设计的不是一天两天了，到现在迟迟没有修改。这是因为：

1. 开发人员没有接到需求
2. 客服人员没有提出需求（他们并不打算帮用户解决问题，只要把用户敷衍过去就行了，自然无需提需求）

在提供了如此详尽的信息以后，针对“装备找回”对玩家有利的措施还要进行如此强悍的限制（说实话，我随便用绑定的邮箱或是手机都可以轻松的删除这个账号），一方面说明了设计者的愚昧无知，另一方面说明了客服的敷衍心态。

和盛大形成鲜明对比的是：5173，当然招行、携程、万科什么的就更不用说了。

依我看来，盛大并不是一个打算为用户提供良好服务的公司，而且他们选择游戏的能力偏弱，推动游戏改进的能力偏弱（代理了NCSoft的产品，却没有能力推动韩国人工作，不如不代理）。

所以我断言，盛大在可以预见的将来会退出网游的一线舞台（当然他们可能会更加的赚钱，公司更大，名气更大，但是游戏业务必将陨落 - 除非针对服务和游戏内容修改能力进行改正）。

我的需求被蔑视了 - 我很郁闷；
看到竞争对手如此愚昧 - 我很开心。

有得有失。

注：永恒之塔并不会死在劣质服务上 - 虽然我很有可能因为这一点小事而流失，但对项目来说不算什么 - 而是会死在它不适应中国国情，不能快速的更新上。

注：中木马是因为我出差的时候阿姨的电脑坏了，于是擅自动用了我的电脑（当然，责任还是我的，谁叫我走的时候不锁定电脑）

注：之所以有手机屏蔽还能被盗，是因为手机解开屏蔽以后，10分钟内可以任意登录。（就算是同一IP能够在10分钟内任意登录我都认为是不合理的设定，应该是成功登陆以后立刻禁止再登录）

注：盛大的系统显然有明显的通讯不可靠的bug，因为用手机解绑成功以后不能登录的事情我遇到了好几次了。这也许是后面修改6次只有2次正确的原因吧！

Reloaded

很久没有写blog了，原因是blogger.com不幸被封，当然我的picasa的图片也一起遭了灾。

没写的原因有2：
1. 也许某天管理网络的老爷们突然开窍了，不再封blogger了，我以为那天来的不会太久；
2. 太懒。

今天终于觉得应该有点什么作为，否则就真的荒废了。曾国藩说他缺乏的品质是毅力，和他老人家一比，实在令人汗颜啊。

安装了VPN以后，总算可以访问这些国外网站了。恩，还不错。就是发完贴还得断线，不然上国内的网络未免又太慢，也许应该做一个路由的小工具解决这个问题。

问鼎大规模测试开始了

昨天开始测试，很不顺利。

客户端很卡，因为所有人物模型在出现的时候就会创建，而且这是一个同步的过程，结果导致走动异常之卡。这个问题之前发现的太晚，4月中旬才正视它，我不敢改动这个版本，打算硬撑过去，但是结果比我想象的还要差一些。更重要的不是卡，而是因为很卡居然导致客户端的对话出了问题，玩家无法接领任务，这真是一个很糟糕的事情。

相比之下，更令人郁闷的问题是服务器端居然出了问题。诊断结果是pthread_cond_timedwait吊死了进程，而这个函数本身等待时间是0，也就是不应该进行阻塞才对。现在我还不能确诊问题的原因，可能是linux兼容性的问题（build版本的机器和运行版本的机器glibc有点微小的不同），也有可能是CentOS 5.1本身的问题（在进入调用时如果系统时间变化了，可能回导致函数无法超时返回）。好在通过gcc attach到进程上去，手工执行一个发送信号的调用可以使进程恢复过来。等这个问题确诊以后，才能考虑解决方案。

不幸中的万幸，就是现在并没有出无法解决的问题。

网络写手能赚多少？

这几天在翻看网络小说，顺路看到一篇帖子，收录一下。

如果一天写8000字，一个月写26天，那么大概每月收入是3000-4000元。当然了，能够写到像《盘龙》、《诛仙》那个地步的不在此列。

以下为我的转贴
-----------

网络写手的愤怒(转贴)

首先申明，以下内容为转贴来的，虽然我不是全部赞同，但是大部分意见和我想的差不多！看完之后我真的感触很深，这位作者的感受和我简直是如出一辙！废话不说了，下面是转贴的内容：

先说说现在专职写手的经济来源吧！此所谓的专职写手，自然是指专门从事写作，以此为生，以此赚钱的朋友，上着班写着小说的朋友不算在内，因为你们具有固定的收入，写小说也许是爱好，赚钱多少并不会对你们的生活有多大的影响。

只要写小说的人，赚钱的方法有：1加入文学网站的VIP；2出版实体书，分简体繁体两种；3少数人会被游戏公司或者是剧组看中，拍成电影或者电视剧。

先 说说出版成为正规的实体书，我在这里透漏一个信息，你们现在看到的网络小说，基本上每二三十本中就会有一本出版成为实体书，而这二三十本中有三到五本会加 入各大网站的VIP。中国大陆的出版社出版的审批则更加严格，不能涉及到色情，暴力，政治，社会，等等，而且还需要向中国文化局申请出版号才可以出版，所 以现在出版的书以台湾香港地区居多，能够在大陆出版的书，百本里能有一本两本就已经不错了。台湾地区出版的书，千字在20元-50元不等，当然，百元以上 的也有，只是少数中的少数了，我们写小说的人都希望自己的书出版，但是要是签错了中介公司，你就等着被层层克扣吧！千字50元的书为例，中介公司抽取你 25%-30%甚至更多的中介费，这样一本书千字就减少到了30-40元，绝对不会超过40元，然后有的台湾出版社会抽取一部分为做出版费用或者是其他费 用，大约在20%左右，这样，一本原本签成50元每千字的书实际上我们能够得到的只有不到30元。虽然不多，但是毕竟一本书都是在50万字以上的，拿个万 把还是可以的。但是盗版书限制了正版书的销量，实际上我们拿到的能够千字15-20元就不错了。而能够被改编成游戏甚至编成剧本的人，万人中也无其一，少 的可怜，就不用多说了，我没体会过，也不知道他们的收入情况。

再来看看VIP作品，现在各大网站的VIP点击基本为3分钱/千 字，而网站抽取1/3左右作为网站收入（人家也要赚钱，理解万岁吧！），所以加入VIP的写手，千字只是在2分钱而已。那些大叫着我们是看白书的朋友和那 些大叫着我们没钱的朋友，一章1万字你点一下才3毛钱啊！3毛钱是什么概念？丢地上一元钱你可能会拣，而要是地上有三毛钱，我估计你是一定不会弯下腰去 拣，甚至看到都会当作没有看到，可是你们想过没有，我们这些靠这个赚点生活费上网费电费烟水费的写手，就是靠着那些支持我们的VIP成员几毛钱几毛钱的积 累起来的，看书容易写书难，或者可以说不养儿不知父母苦，没有写过小说的人永远无法体会到作为一个写手，用千字每小时的速度写小说的感受，而我们的每小时 只要3分钱，呵呵！我们算是低廉的劳动者吧！

我想问一下那些叫着看白书的朋友们，你们体谅过我们这些专业写手的辛苦吗？不过我不 怪你们，有白书看总比花钱看爽，坐那里抽根烟喝瓶饮料，然后用五到十分钟的时间看完我们写十个小时以上才能出来的万字文章，确实惬意的很，你们有时间的 话，发发书评顶我们一下我们就非常感谢你们了。

我再问问那些叫着我们穷我们没有钱进VIP的朋友们，你们说这话累不？这话说了等 于放屁一样，你看书总要上网吧！网费多少钱？电费多少钱？万字才三毛钱你支付不起？那我鄙视你，你连那些叫着看永远支持不进VIP永远看白书的朋友都不 如，至少人家立场明确，而你们，仅仅是把自己的生活水平降低为以拾垃圾生活的人都不如，而实际上，你们可能每天的消费在二十元以上甚至更多，连几毛钱都舍 不得拿出来给我们这些辛苦劳累的写手的人，你们与葛朗台，你们与周扒皮又有什么区别？不过你们只是说说而已，那我就在这里随便说几句好了，反正对我们这些 专业写手或者是对你们这些随便说话的人都是没有什么伤害的，要是有所伤害，那我只能说句对不起了，此非吾之本意，实为无奈。

加入 VIP一直支持着我们的朋友，兄弟在这里代表广大的写手向你们说声谢谢了，没有你们的支持，或许就没有今天中国网络文学的鼎盛时期的出现，毕竟爱好是不能 当饭吃当水喝的，有了经济效益的写手才能投入更大的精力到小说当中，这是无可厚非的，因为你们的支持，我们这些专业写手才能安心的坐在电脑前有目的有目标 的忙碌，即使再辛苦点，又算得了什么呢？我们这是为了报答你们的滴水之恩，何足挂齿，十字军不是有句很有名气的话嘛：人人为我，我为人人。真正能够理解这 个意思的，就是一直支持我们这些写手的人，其中自然要包括在书评区顶我们的朋友和你们这些加进了VIP看我们写的小说的朋友。

现 在我要说的就是存在于VIP的朋友中的个别败类，虽然现在VIP区基本上都被禁止使用右键作为防止复制VIP文章的限制，不过鼠标右键不能用并不代表不能 复制，键盘上的快捷复制键我想只要是稍微懂点电脑的人就应该熟记于心的吧！你不懂？那我教你，用鼠标左键划出范围，键盘快捷键是Ctrl+C！

无 论是盗版书商还是改头换面的偷书人，跟这种人相比简直就是微不足道的，这种人仗着自己拥有VIP会员可以看VIP章节的特权，复制了VIP的作品，然后粘 贴到其他文学网站的论坛区，美其名曰：我可是分文不取的，这是为人民服务的伟大事业。或者说是帮助你们这些见钱眼开的财迷更新。

对这种人，我不代表其他人了，就代表我自己，我衷心的对你们这样的人说一句：******！

不 要以为写书的人都是文明人，文明是用在尊重其他人劳动成果的人的身上的，而不是用在你们这种没有道德没有教养的人身上的，对于你们，除了倒你们一身脏水， 再打你们一顿以外，没有什么好说的了，就连小孩子都会背：锄禾日当午，汗滴禾下土。这首诗不就是要人学会珍惜他人的劳动成果的吗？你们难道连几岁的小孩子 都不如？

在这里，没有加VIP的作者朋友是幸运的，最多更新慢了点被骂句太监，而跟我一样加进了VIP却被这种卑鄙无耻的人盗走 VIP部分章节去发在其他网站论坛上的兄弟们，我们是不幸的，本来一章能够得到的金钱就少的可怜，而盗我们VIP章节的人却把我们这些辛苦数十小时才能得 到几十大元甚至只有十几元的人打击的体无完肤，请问，我们这些写小说的人得罪了谁吗？

当一个写手看到自己赖以生存的唯一手段被别人盗窃走的时候，请问，盗走我们VIP作品的人，你想过我们的感受吗？你还算是个读书人吗？或者说，你还算是个人吗？再难听的话我不知道怎么骂，只能骂到这种程度了，不好意思。

每个写小说的写手朋友都有自己的写作习惯，不过以半夜写小说的居多，因为夜深人静最能激发灵感，每次我在凌晨两点的时候在作者群上问一句：谁还在。都会有很多人回答：我在，写小说呢！你写的怎么样了？

请 所有的朋友都看看这句话，我在写小说呢！凌晨两点的时候，也许你好梦正酣，也许你酒醉金迷，而我们呢？仍然在电脑的高强度辐射下辛苦的完成我们的作品，如 果你体谅我们，那我代表所有写小说的朋友谢谢你们，如果你说，这不算什么，我也经常熬夜到凌晨几点几点，如果你是位写手，我拍拍你的肩膀说一声兄弟辛苦， 要是你说这话是因为玩游戏或者看白书或者其他与工作无关，那我鄙视你。

凌晨零点前消耗的是体力，凌晨零点以后消耗的是心血啊！

最后，谢谢一直支持我们这些普通写手的朋友，盗版属于正常范畴，我们理解，但是鄙视那些把我们赖以生活的VIP章节发到论坛公众阅览的人。

无论你是看书的还是写书的，如果你支持我们这些写书的人，请将此贴转发，谢谢——

笨的象猪

贫民窟的百万富翁

的确不错，看来奥斯卡奖项还是颇具指导意义的。

一般来说，故事片我不太看得动。我喜欢看那种弱智的，无需思考的动作片。文艺片、故事片很少能让我耐心看下去。但是这个片子的确可以吸引我。

今天比较顺利

晚上又做了一次性能测试，这次两个小时没有出现崩溃的情况，之前修改的一个隐患似乎起了作用。

看了PP的报告，昨天优化的目标基本达成（相比之下比较复杂的就不在这个版本里面做了）。

另外，debugger功能又有了突破。我之前考虑watch一直有点麻烦，毕竟解析表达式、计算很罗嗦，代码很容易造成重复。如果不想重复又容易影响性能。今天突然想到了一个很简单的方法，就是在调试时，允许用户自己输入一段脚本，编译后作为一个伪函数插入到当前执行节点前。这样，不仅可以阅读上下文，还可以执行外部函数，又绕过了解析、计算这个环节。功能既强，实现还简单。

其中主要有两个问题需要考虑：一个是如何读取当前函数的局部变量和参数。我一开始采用的方法是定义一批宏，将宏指向栈里面的变量。但是这样有一个缺点，宏影响范围会超过我的预期（比如一个函数和变量重名，宏会将它们都替换）。后来想了一下，增加了一个debug context，在lex取词时先让debugger根据context翻译token，这样做起来就没有副作用了。

另一个问题就是嵌入的脚本可能会导致执行线程出错、或是删除执行线程。好在这方面driver都有过类似的处理，提供了足够多的钩子处理这些事件。

今天完成了所有的编码和调试，这意味着命令行的debugger已经到达了实用的阶段。很好。

4.1了

不经意，4月1日了，传说中的愚人节。对我而言，这只是平淡的一天，什么都没有发生。

为了配合优化，我先提交了新版本的driver。这个版本已经增加了一个内嵌的命令行debugger，目前调整的基本让我满意。当然，现在还缺少一个重要的功能：watch，考虑这两天加上。

明天更新版本，晚上在试试运行PP看看优化的效果，是否有所改善。

PP的进一步结果

这几天改写了PP以后，今天终于将版本更新上去了。

再次运行PP，结果在收集了一小时的数据以后崩溃了一次，虽然这个在意料之中，但是还是感觉很不爽。因为编译时采用了omit stack frame pointer的优化选项，结果看调用栈没有任何收获。

重启一段时间以后再次运行PP，这次为了保险起见，只运行了5分钟，从统计的角度来说也够了。

这次PP比上一次统计的更精确一些，首先是30us一次，其次可以统计到外部函数的调用情况（上次PP有一个bug，没能做到这一点）。

从这次结果中可以看出，服务器有几个比较明显的开销地方。一处是bzip压缩开销很大，还有一处是逻辑上的缺陷，在处理外观数据时居然每次都处理了一下配置表，结果开销浪费很大。除此之外，还有一些逻辑上的问题，做了一些无用功，重复处理导致浪费。预计这些简单的问题解决以后，服务器端的性能可以提升10-15%左右。如果能进一步解决掉一些比较复杂的问题，还有希望再提升10%。

从这段时间的进展来看，工具可以提升很大的效率。因此选择、开发合适的工具很重要，不过很多开发人员都忽视了这一点。

绕过ReadConsole阻塞的问题

今天我考虑了一下，换了一个角度来看ReadConsole阻塞的问题。

本质上来说，目前我用ReadConsole只是读取一行，中间可能会插入其他读入（比如常规控制台在读入的时候，debug控制台起来了，需要终止控制台输入），采用抢占输入的方式即可。换言之，当ReadConsole完成以后看看是否有人抢占，如果有，则将结果交给抢占者，自己继续读取即可。

采用这个思路以后，问题就简单了，我没有必要考虑如何终止ReadConsole。现在启动debug调试时就舒服多了，不会和控制台冲突。而且，这个解决方案是跨平台的，我也不需要考虑其他系统下是否会有什么兼容性的问题。

如何中断ReadConsole

在做debugger的时候，有一点令人感觉不爽。

在界面输入命令时，在Windows下使用的是ReadConsole，而我现在不知道如何用一个简单的方法打断这个输入。那么，在用户开启控制台输入时，如果进入调试模式，不能自动打断这个调用结果令人感到不愉快。因为必须输入一行内容才可以继续调试。

虽然使用异步的方式，不用LINE_INPUT模式可以解决此问题；或是另外开启一个线程进行读取操作。但是不论如何，都是不够轻便，不够简单。

这两天考虑增加一个命令行的debugger用于调试LPC脚本。

主要让我觉得需要斟酌的一点是：当断点断下时，是挂起整个VM线程，还是只挂起脚本执行，线程依旧。如果是后者，实现起来会有点麻烦，并且需要另外制作一个debugger使用的调度器。而采用前者，会让系统的栈有点深，而且在scan sockets方面的代码会有一些重复。而且在调试时不能进行关闭VM的操作 - 原先是可以这样的。

在权衡的时候我考虑了另外一点，如果VM线程没有挂起，就会导致渲染等操作仍然进行，这种异步操作可能会给调试带来困扰，基于这点，我选择还是让VM线程挂起。

上午开工，比我预期的速度要快，毕竟做一个调试器并不算太麻烦。以前我在做i386的虚拟处理器的时候，制作调试器很容易。目前要做的工作比之前主要麻烦在watch和file这两方面，因为虚拟处理器只需要查阅寄存器和内存即可，也没有文件的符号信息这一说。

晚上还没有完全编码结束，考虑明天工作可能很多，今天晚上就暂时告一段落，明天抽空用几个小时应该可以结束编码，最后调试的时间预计不会太多。

轻重缓急

这几天休息不好，晚上有点困就早点回去了。

在家里上了一会儿问鼎，看到一些问题。这些问题并不是新出来的，可以说是由来已久的，而且也不应难解决。但是到现在迟迟未能得到解决，究竟是有更重要的任务占了先，还是说安排的不妥当？没有分清轻重缓急？

以我以前对项目的观察来看，估计是后者居多。确定优先级看上去并不是想象的那么简单，这是一个很重要的技能。

调试手段

自从我完成了LPC driver并投入实用这段时间以来，其最大的问题就是缺乏调试工具。这使得开发的时候调试很不方便，经常要手工增加printf，然后update object查看结果。当年这么开发还好，但是随着项目越来越复杂，问题也越来越多。

我本来打算针对VC这样的调试终端开发，让VC可以直接连上driver调试脚本。但是因为一直没有时间专心研读这方面的资料，所以这个工作迟迟没有开展。

前两天调试一个问题的时候，感觉工具带来的低效越发的明显。于是我先实现了动态设置陷阱的方法，利用这个功能，我可以方便的在任何一个脚本函数、外部函数上设置陷阱，并且实时取得当时执行的信息。虽然这个离终极解决方案还颇有距离，但是已经是大大的向前跨了一步了。

为了避免这个功能影响正常脚本执行，我为VM增加了一个debug模式的虚拟处理器。当有陷阱断点被设置时就切换到这个虚拟处理器，而当处于非调试状态时则使用常规的虚拟处理器。这样正常运行时就不会有任何性能上的损失。

随着这方面工作的完成，也许我该考虑先完成一个文字界面的调试工具了。

提升PP的性能

因为昨天出门很失败，于是今天我试验了一下us级的PP，果然，对深度调用的情况影响很大。

我看了一下代码，主要是因为同步引起的。在进行profile的时候需要进入临界区，VM在处理调用时（进、退调用栈）也会进入临界区，这样就保证了profile的时候不会发生栈变化的情况。

然而，我试验了33层长函数名的调用栈profile的情况，需要17us，锁住临界区如此长的时间，显然有问题。于是我优化了一下这部分的代码：生成调用树主要是依赖于函数的名字，每次根据函数名进行哈希查找成本有些大，于是我改为根据函数名的指针进行哈希查找。但是这样引发了一个新问题，因为脚本是可以动态卸载的，如果函数被释放了怎么办？我采用的方案是另外记录一个mapping，根据函数名指针可以朝着到对应的函数名。每次在记录调用栈中的函数名时，如果这个指针已经存在了，则忽略，否则就先记录这个指针对应的函数名。

实际上在做profile的时候，几乎不会发生动态析构脚本的情况，直接使用函数名指针效率是最高的。但是我并不希望这个profile依赖用户的行为（比如他无意进行了析构，可能就会导致问题）。我这样做仍然有一个微小的隐患，如果用户析构了脚本函数又重新加载了，新的函数名指针恰好和原先的函数名指针相等的话，统计就会记录错误的名字 - 我认为这并不重要。

另外，我增加了一步：复制调用栈，在临界区内我只复制调用栈，然后在临界区外进行生成调用树的操作，这样就尽可能的减少和VM的冲突了。为了防止在生成调用树的时候发生脚本析构的情况，我另外增加了一个生成调用数时的临界区，在析构脚本的时候VM会进入这个临界区，避免发生不同步的情况。

优化以后速度快了20倍，毕竟每次哈希都不需要处理字符串，而是处理一个64位的整数即可（因为除了函数名，我还需要记录对象名，各32位）。另外临界区冲突的可能性则更是大大的降低了。

但是性能仍然让我不够满意，这还是没有达到1us级别的统计性能，只能进行10us级别的统计。因为统计33层调用本身需要0.7us左右，在这种情况下进行1us间隔的统计意义并不大，因为每次采样之间波动可能就会达到1us。

我暂时采用限制PP最低以10us的间隔进行采用，将来再考虑如何进行进一步优化。现在还有一个问题，就是PP以10us的间隔进行采样时，VM性能大概会降低30%-40%，主要是函数调用会受到影响。如果关掉同步自然皆大欢喜，速度立刻恢复正常。但是我始终不愿意这样做，虽然这样只是会让统计结果稍微有些偏差而已。

公司今年5周年庆，不知不觉，已经过去5年了。以目前的成绩来看，和想象还很有差距啊！

PP投入了实用

下午和蓝港打了一下招呼，我准备开始在服务器上采集数据，毕竟这个模块比较彪悍，还没有真正投入过实用，没准会引起崩溃什么的。

4:30开工，没想到一开始就掉了链子。我们每us采集一次调用栈，结果服务器卡的不行。因为driver出栈的时候会进行同步，如果正在采集中，需要等待本次采集结束以免数据错乱。赶紧改成每ms一次，只要采集的时间长点，倒也没有问题。

5:00去打球，锻炼身体。晚上冲了个凉，满怀期待的心情来看结果。

没想到又掉了链子，因为调用栈太深，所以生成的调用树很深。结果试图用save_string进行保存将mapping转为字符串的时候遇到了问题 - driver只能保存31层的mapping，而这个配置还不能动态修改。没办法，同事只好写了一个脚本进行特别处理，将这个mapping保存下来。

接下来将数据导入viewer查看，再次掉链子。因为数据太大了，结果导入速度实在太慢，结果只好先毙掉了一部分功能暂时先看看结果。

总的来说，因为这块经验不足，设计和实现的时候有太多和实际偏差的地方。还需要总结经验，根据反馈进行改进。

当然，结果很令人满意，之前手工统计的内容在PP的报告完全可以体现，一览无余。另外PP能够揭示更多的问题，让我们有了入手核查的地方。总的来说，这个统计方式算是CPU占用的终极解决方案。接下来两周，我们将有重大突破。

工欲善其事，必先利其器啊！

锻炼了一下身体

今天晚上有同事组织去打羽毛球，去练了一个小时。感觉精神有所好转，算是储备了一点MP。

这两天进展不错，美术资源整理完毕；同事解决了一个导致频繁崩溃的问题；我也干掉了一个出城重复创建资源导致有点卡的问题。另外关注到了两个表现有点卡的地方。而且测试用的破机器也装好了，实验了一下，解决了一个兼容性的问题。因为老的显卡驱动不支持创建和锁定dynamic texture，目前我们只有光标和字体需要用这个特性。将光标改由系统默认的光标，字体则更换为static的（据称性能会差很多），就能跑起来了，有13帧左右，表现可以接受。不过是切换地图，战斗的地方需要考虑如何做的更流畅。

蓝港考虑到版本稳定和广告排期的问题，通知将延期一点时间进行大规模内测。不过我还是要求开发团队按照原计划制定稳定版本，即Apr/5完成待发布的版本，再沉淀5天。毕竟事情赶早不赶晚啊，要延误也不能停留在我这个环节上。

Performance profiler

driver以前主要是针对内存进行统计，一直缺乏对CPU占用率的有效统计手段。虽然可以取得脚本线程占用的时间，但是因为大量短寿命线程（如callback）的存在，加上线程内的复杂执行情况（函数嵌套），所以仅仅取得线程占用时间的作用很有限。必须手工增加很多统计代码才能实用。

考虑了一段时间，上周末的时候我借合并版本的空闲增加了一个性能诊断模块。

统计的主要思路是独起一个线程，定期去记录调用栈，然后将调用栈插入到一个树中，形成调用树，每次给被统计的调用栈在树中的末端节点计数器+1。最终，计数器总和可以看作是100%的CPU，各个结点计数和计数总和的比就是占用CPU的比率。这样，我可以得到每个调用层次不同函数的CPU占用率，也可以得到它们调用其他函数的总开销（将这个分支下面所有节点的计数累加在一起即可）。

当然，统计只是一部分，还需要一个viewr，要能方便的展开这个树，并且进行同层次的排序以便阅读，另外也可以进行一些高级分析。

在实际开发的时候，如果profiler的线程采用休眠的方式的话，每秒中统计的次数太少。Mac下基本可以做到每毫秒一次，我用的Linux就不太好，而Windows最差，因为精度太低每秒只有60多次。既然目前都是双核+的机器，我让profiler线程以不休眠的方式进行，每微妙统计一次。结果下来，还是Mac最好，Linux次之，Windows最差，因为QueryPerformanceCounter实在是开销太大了，一次调用就干掉几微妙。

合并版本

周末已经将最终用于大规模内测的版本制作完成了。按照惯例，我们是周一进行流delivery和rebase的操作。也就是说将之前patch的内容合并到集成流上，并将这些内容建好基线以便分发给所有的开发人员。

为了加快验收速度，以便早日发布，可以及早进行后期的稳定工作。我要求周日就完成这部分工作。

8:00就开工了，没想到夜里2:00钟居然还没有干完...

混乱的原因有待分析，不过这样效率真是底下。

休息

今天比较顺利，QA完成了本周的版本的测试，所有bug都解决的都无惊无险。我也解决了昨天发现的driver的问题，同时为将来的更新也增加了告警并调整了目前的代码。

目前基本上所有的优化工作都已经完成，美术资源方面还有一些小尾巴，客户端有一些地方没有做到完全透彻，但是问题都不大，足以应对接下来的大规模内测。现在真正需要面对是稳定性的问题。

按照我的计划，周日将封闭最新提交的内容，这将是大规模内测的版本。下周QA将验收这个版本，而我们则集中力量解决在外面运行中版本的问题（也就是本周QA完成测试的版本）。如果在一周内基本解决了运行版本的问题，那么和QA下周测试完的版本进行合并，可以得到一个相对稳定的版本，我们还有一周的时间再去扫尾。如果一切顺利，2周以后我们就可以有一个符合要求的大规模内测的版本。

于是，我打算明天给自己放个假，休息一下，下周好几种精力收拾bugs。记得当年玩三国演义，若是选休息，就会有一句提示："休息是为了走更远的路"。谁说不是呢？

今天是烧火的日子

早晨起来的有点晚，9:00才到公司，启动问鼎一看，客户端还没有更新。问了一下，原来是走路又出现了问题，我push了一下，发现解决速度果然很慢，第一个程序员还在琢磨怎么取版本（因为前一天更换了SVN上的流设置，有些变化），当下心头不爽。

接下来我自己看了一下走路相关的代码，发现运行中竟然不能更新此文件，更新以后无法正常工作，完全没有达到预期的设计目标，心头大怒，发了封邮件谴责程序组。

随后看到同事发过来的邮件，指出了一处底层代码居然有策划设定相关的逻辑。我一看狂怒，查了版本树，结果是亘古以来就有的（当年版本数据库迁移过，2008年以前的没有记录了），只好作罢。

中午去打水，发现水池中有一团米粒堵着，心头是怒不可遏，我最恨这类无卫生意识的人。基本上，我发送everyone的找麻烦邮件大抵都是挑卫生方面的毛病，居然在眼皮底下还有这种事情。可惜没有摄像记录，找不到责任人，我发邮件给everyone猛批了一通。

晚上听说“天下评定”活动不能正常开启。我找人问了一下，居然没什么人知道，只有一个程序说了这个bug已经发现并解决了。我就顺便问了一下解决方案，不想一听就觉得有问题：原先搞出毛病的那个人就是乱来，现在的修正方案则是补丁上的补丁，一团混乱，我狂批了半个小时。

唯一值得欣慰的是，昨天总算把服务器端的版本发了。今天将集成出一个无比混乱的大规模内测版本，下周将是集中精力排错的一个过程。如果下周能够顺利排除主要错误，那么内测的计划尚不至于受到影响。

针对VM未来内存方面优化的考虑

我这里只考虑一些立竿见影，成本很低的优化方案。

目前每个值（value）都有一个引用字段，用了4个字节，我在考虑如何不用复杂的垃圾回收机制就能够消除这4个字节。我想了一下，能对值进行引用的只有VM中的栈变量。当对类似如下语句：
a = 7
m["x"] = 99
这样的语句进行操作的时候，会产生对变量a、m、值m["x"]的引用。而a、m只可能是全局变量、对象变量、局部变量这三种情况。针对于这三种变量，都无需考虑引用的问题。全局变量只在driver clean environment时才释放，对象变量在对象析构时释放，局部变量则在返回时释放，都不需要考虑引用的问题。关键在于改写容器内成员值时，有可能发生引用。

事实上这不难解决，我只要为对容器赋值做一些特别操作（比如set_member）即可，问题在于，我支持调用时传入引用，比如foo(&m["x"])，这给我带来很大的麻烦：我必须有一种可以传递容器内值引用的方法。虽然，我可以使用记录容器和容器内索引的方法，但是我仔细思考了一下，这样有点浪费效率（在处理赋值、传递引用指针都会慢一些），并且代码有点复杂，不是正途。

说实话，如果现在能够自由的做决定，我就干掉函数调用时传递引用这种行为，因为很少有需求要使用。然而现在我应该保持和以前代码的兼容性，毕竟我不希望将来问道试图升级driver的时候花费太大的经历。

我从另一个角度考虑了一下，可以对这种引用做一个记录。每次进行这种引用时，就将被引用的指针加入到一个数组里面。当取消引用时则遍历数组然后删除 - 听起来这样开销很惊人，不过实际上，代码中几乎没有对非变量的普通值的引用，所以效率影响微乎其微。

在一个值被释放时，需要检查一下是否在引用数组里面，如果是，则先不释放 - 等到引用消除时在释放，否则直接释放。为了提高速度，我给值保留一个比特的是否被引用字段，因为目前一个值除了引用还由2个32位数表示，找出1位不是难事。这样就可以将值压缩到8个字节。

算法描述：
当对值进行引用时，即I_QUERY_MEMBER_PTR指令，需要进行如下操作：
SET value.attrib.ref = 1

当对引用进行赋值传递时，则：
IF src_value.attrib.ref == 1 THEN
PUT src_value TO ref_array （此时ref_array有两个重复的src_value）
END

当清除引用时，则：
IF value.attrib.ref == 1 THEN
REMOVE value FROM ref_array（此时清除的一般是后面增加的value，这样速度更快）
IF value.attrib.free == 1 THEN
FREE value （原先容器试图释放该值，清除引用）
END
END

当值被试图释放时，则：
value.attrib.free = 1
IF value.attrib.ref == 0 THEN
FREE value （大部分情况都会如此）
END

为了应付最坏的情况，我需要准备一个size能够包容所有VM线程栈变量的数组 - 虽然几乎没可能会用到这么大的情况。但是在赋值的时候出现数组溢出是一个很糟糕的问题，为了简化代码，保证稳定性，这点空间应该无足轻重（大概是线程数x1K空间即可）。

当然，我还有另外一种比较简单的做法，就是从8个字节的value中找出16位作为引用。但是这不太可靠，如果非常不幸的，对值的引用超过了65535（比如有意让栈变量全部去引用这个值），可能会造成意想不到的后果。

更新不顺利并顺利着

昨天感冒，身体颇为不适，于是9:00就先回家休息了。

半夜3:00钟的时候，QA给我打电话（我已经把手机调成了震动，但是我睡觉很轻，即使这样仍然可以唤醒我）。我当时接起电话就知道不妙，果然，服务器和客户端都出现了一些诡秘的bugs。我本想当时就过去解决，但是感觉很不舒服，估计过去效率也很低，还是先安心睡觉。

一早起来，感觉有所好转，用完早餐，8:00就赶到了公司。查看了一下QA留给我的邮件，针对bugs进行排查，还算顺利，9:00前就解决了2个打包版本的问题。令我我有些郁闷的是：之前我没有针对服务器端的打包版本进行测试。我只测试了客户端的Debug、Release x 打包、不打包四种情况和服务器端Debug不打包版本，但是服务器端的打包版本就没有测试，今天果然遭了报应。

由于现在都是QA打包发布版本，结果服务器端工程配置文件年久失修。工程文件中的打包规则基本不可用，我花了半个小时才将缺漏补上。所以说，很多东西只要不用就会慢慢的被腐蚀废弃，如何让它们保持新鲜是一门值得琢磨的学问。一般来说，自动化的测试可以在很大程度上弥补这一点，我们自动化测试的工作还有很漫长的路要走。

上午要开企业文化会议，这个不能耽搁，虽然手头的问题很多，但是我并不打算改期，毕竟磨刀不误砍柴工 - 于是一个上午都在磨刀。

下午尽量集中精力，将服务器端、客户端 x Debug、Release x 打包、不打包全部测试了一遍。因为嗑了药，头比较昏，有些问题思虑不周，反复了几次才彻底解决。

将上述工作弄完以后，再查看QA提出的另外两个诡秘的bugs，研究了一下，果然都和driver有关，一一修改。总算在晚上将所有工作提交并且制作出了发布版本。至于是否能发布，就要看接下来的运气了。

另外，今天同事尝试用stlport替换了VC自带的STL，debug版本速度快了很多，将来客户端总算可以回归debug版本，以便将更多的bugs消灭在实验室中。微软的STL库乱七八糟的判定实在太多，本意虽好，结果是完全不可用。虽说可以通过配置调整，不过，在有stlport的情况下，真的有必要那么做吗？

更新中

昨天发布了版本，今天出了几个比较严重的问题。

晚上我一问，居然还没有更新解决问题。这个版本的确问题比较多，比如以前driver在限制const的时候处理的有点问题，导致某些情况没有诊断出来，脚本可以乱写，新版本的driver修复了这个问题结果不少脚本受到影响。但是，我仍然认为我们反映速度太慢。就这几个问题而言，应该可以短时间内解决，实在不能解决可以先绕过，尽快更新。无论如何，拖延到晚上还没有解决是不应该的。

昨天搞的有点晚，今天早晨想休息一下也未遂，附近太吵了，兼有些感冒，所以9:00点就先回来休息了。但愿明天我过去的时候已经将问题搞定了，阿门。

提交-最终战役揭幕

本来今天就可以提交了，但是我昨天晚上想了一下，仍然有些立竿见影的事情可以做。

目前driver使用了38M内存，但是占用空间达50M，这是管理开销引起的。系统在启动的时候，需要加载大量的脚本bytecode，加载的过程中申请了很多小片内存，但是显然这些内存在整个生命周期内都不会被释放。所以，我引入了稳定堆的做法，准备一块平坦的内存，这些小片内存都优先在这个堆上申请，它们不会被释放，从而达到节约管理开销。

为了做到这一步，我首先整理了一下driver在编译、加载bytecode阶段的代码。将稳定的内存和临时使用的内存分开，这花费了我一个上午的时间。下午又花了点时间顺便优化了加载bytecode的过程，给它加了一个缓冲 - 本来我认为没有必要，因为driver是将整个bytecode文件读入内存然后分析的，但是考虑直接从driver封装的io读取内存数据额外CPU开销还是有点大，所以仍然做了一个本地的小型缓冲，4K。效果还不错，启动速度提高了15%左右。

将申请分开以后，我就开始着手添加稳定堆。这个实现非常简单，就是事先准备好一段内存，当申请的时候简单的将指针累加返回即可。申请的速度非常快，而且额外开销只有0-3字节，这是为了确保对齐。实现本身很简单，不过我还需要增加相应的profile功能 - 事实上，只实现功能只能算做了一半的工作，没有足够的profile方法很难进行维护、优化和各种各种诊断。

采用稳定堆的做法并没有减少任何直接的内存使用，但是管理开销减少了3M多，和我预期的差不多。最终客户端启动只占119M，想想一个月前客户端启动就是210M内存，还算是欣慰。driver占用的内存从130M下降到了43M，节约了90M左右。

晚上开始提交相应的库，这个版本我将尽快更新到外网，以便发现稳定性方面的问题。也不知道该说运气好还是不好，刚刚提交我就发现了一个问题，花了点时间解决。

总的来说，今天的优化工作只是锦上添花，实际意义不大。因为目前已经到到了设计目标，从工程角度来说，并非要做到最节省才好。只是出于个人爱好，我又多花费了一天的时间。

最后：从实现逻辑的角度来说，脚本代码并不比C代码更浪费内存，甚至可以说会节省一些。在STL被广泛使用的今天，C语言的代码急剧增加。脚本代码在处理逻辑的时候，因为指令功能较强，实际上表达相同的逻辑，使用的指令并不会比汇编指令多。当然，使用脚本占用内存的真正问题在于变量上，由于需要携带类型，所以在大量处理整数时，脚本浪费的较多。

优化尾声-打扫战场

在完成继承方式的修改以后，针对driver节约内存的主要工作已经差不多结束了。

接下来我开始从driver内置的内存分配统计工具入手，检查有哪些地方会申请比较多的空间。发现了一些针对服务器端的设置。比如用于封装数据包的缓存size高达256K，允许最大的连接数是2048等等。在客户端做了针对性的配置以后，这部分内存占用基本被压缩到无。当然，由于它们总共加在一起也没有多少，所以这部分效果不算显著，基本上就是打扫战场的行为。

这部分工作完成以后，客户端登录进入游戏以后占用的内存是130M左右，比原先的220M少了近90M。这部分节约主要来自于driver的优化（内存占用从109M下降到39M，另外节约了10M的管理开销，总计80M）。在游戏内的日常行为由于同事对材质组织和资源管理方面进行了优化，基本可以保持稳定在150M左右。当然，目前还需要进行一些收尾的工作，因为实际运行中尚存在一些占用较多释放不及时的问题。

改写了继承时代码复用的方式(2)

昨天完成了编码工作，最后调试没有完，今天过去仔细调试了一下，然后并入客户端看看效果。

出乎我意料之外的是，优化的效果比我预测的要好得多。原先我估算过，每个VM指令大概占10个字节左右，其中4个字节指令，4个字节的runtime。每行符号信息是8个字节，因为平均5个指令一行，所以算下来每个指令用不到2个自己的符号信息。（除了指令，runtime和符号信息可以在发布时去除）

而整个系统启动以后大约是900K条指令，这样指令占用的内存应不到11M。然而我修改了复用方式以后，指令数下降到不到300K以内。按照道理应该是节约600Kx10=6M的内存，但是节约的内存居然是12M，而实际上节省的内存则多达20M。

我想了一下，应该是函数头的开销不可小觑。函数头、局部变量、参数等平均算下来可能消耗多达近300个字节。继承不再复制代码以后，函数的数量锐减了20多K，这部分内存则总计6M。

除此之外，因为函数头有很多小内存片（我已经看这个不顺眼很久了，但是一直没有把它作为重点对象照顾），导致占用了很多额外的内存。削减了函数数量以后也让这部分的空间节省下来了，将近8M。

如此说来，剩下的8K左右的函数，占用的内存额外开销应该也有近3M，如果改善这部分数据使用内存的方式，至少应该可以节约一大半，也就是2M左右。目前看来仍然有进一步压缩的空间。

改写了继承时代码复用的方式

原先在对象继承时，我采用的是复制一份代码，同时对引用对象变量、调用函数、获取字符串资源等操作进行了映射转换。

目前看来，因为复制可能会导致大量的重复内容（尤其是对CEGUI Window的映射基类代码很多），占用不少内存，对客户端来说这点很敏感。在前一段优化工作完成以后，我开始着手修改这方面的实现。

原先所有映射、合并的代码全部删除。新增继承时代码段的组织方式，并且增加处理函数绑定的功能（这点是driver处理较为奇特的一点，一个对象可以声明函数F的prototype，但是并不实现，此时调用代码如果被执行则会出错。如果将来派生对象实现了相应的函数F，则该对象对F函数的调用自动定位到F上）。

同时，VM新增了一个“当前程序段组件"的概念，相当于C++在类调用基类时需要修改类的this指针（比如VC使用的的ECX）一样，如果调用函数，必须更新这个值。同时在访问对象变量、对象字符串资源时，需要根据这个值进行查找，这带来了一些性能上的损耗，不过相比之下，获得了内存上的节省更划算一些。（在服务器端，我更喜欢原先的方式，但是考虑兼顾两种实现数据结构实在太复杂了，只要放弃这点性能了）

ps. 昨天遇到一件很有意思的事情，我在调整代码时，编译出的汇编代码完全没有变化，只是switch-case跳转表偏移了8个字节，结果导致VM执行测试脚本的性能下降一半。具体原因我尚不详，可能和cache命中率有一定关系。当然，根据结果决定是否调整意义不大，因为随便修改一下其他地方的代码都可能会影响结果。这可能导致一个很奇特的情况：有时候你明明将代码优化的更好了，但是实测效果反而更差。如果你不理会这个测试结果，继续修改其他地方，某一天你就会发现你的优化发挥了作用... 相比之下，GCC编译出来的结果要稳定一些，不过这也可能和CPU不同有关系。

更新 & 混乱

昨天下午将最新的driver提交上去了。在这个版本里面，我对driver的行为作了两个重大的修改：

1. 不再支持直接对string、buffer内部数据的修改，而是通过外部函数修改。
比如：
string str = "abc";
str[0] = 'x';
这个将不再支持，修改为：
put_sub_data(&str, 0, 'x')
2. 将实数从double修改为float

第二个修改还好，目前没有发现什么问题。第一个我原以为受到影响的代码应该很少，毕竟直接修改字符串内部数据的需求应该很少才对，相应的修改一下即可。然而，提交上去以后，QA手工又搜索出几处。今天一早过来，QA又在测试中发现几处... 看来，这种修改引起的混乱远比我想象的要大。

针对于driver行为的变化，需要有更好的测试手段才行。

火大了

今天正在折腾driver新一轮的优化，对某些指令在进行改写，试图以此减少最终产生的指令数量。

快走时，外网服务器的性能检查结果出来了，我去看了看，一起讨论了一下。无意中，在检索源文件的时候，突然发现一个让我非常光火的事情：

我们原来有 一组脚本文件，用来让策划编写代码定制功能。后来因为有被滥用的趋势（比如脚本间互相调用，单一脚本太长），所以限制了脚本不能互相调用，单一脚本不能超过30行。因为有很多重复的公式，所以我们将它们抽取出来形成公式文件，允许通过脚本调用这些公式，以增强脚本的能力。

但是没想到现在公式则被滥用的厉害，公式内容极为复杂，完全替代了之前脚本的功能，早已不再是公式。这种开发人员为了达到目的而有意无意的不择手段钻空子的行为，实在是让我光火的厉害。

我想，除了一方面增强这些限制以外，还需要对策划编写的脚本进行code review。然而，不仅如此：还必须培养相关开发人员负责的态度，用正确的方法解决问题的意识，否则，他们终究还是能够找到破绽。

万物皆有因、众人全网游

我在编译库的时候有一个诡秘的bug，如果在工程的根目录下make，那么tinyxml的生成的库就不对；但是如果到tinyxml下面去make就正确。

我一直没有去解决这个问题，只是每次手工进tinyxml再make一次。

最近连续修改driver的头文件，每次都需要重新build tinyxml（因为wrapper使用了头文件），很不方便。检查了一下原因，看了半天竟然没有发现问题，make出来的库是正确的，但是copy以后就不正确了。在Linux、MacOS下面都有这个问题，所以这显然是我的一个弱智错误造成的。

后来我突然想起来，应该在磁盘上搜索一下有没有其他tinyxml的生成库，也许就是从这里copy出来的。一查就发现了原因：我以前增加的csoap使用的也是tinyxml的makefile，忘记修改工程名。因为那个库从来没有在Linux下make并且测试过（在Win32下面测试过，因为没有进入项目，就没有去Linux下测试）。make的时候，进入csoap将生成和tingxml同名的库，然后copy就导致了错误的覆盖。

真是万事皆有因啊！

另外一个挺神奇的事情：陈拓琳的MM也在玩问道。她以前从来不玩网游，所以基本概念全都不知，对游戏也没有什么兴趣，看上去也很不敏感，只是勉强玩玩。我一直宣称她不是我们的目标用户，属于被忽视的对象。但是今天我们下班准备回家的时候，陈拓琳的MM说要刷怪，要等等再去接他...

哎，看来无人不可网游。

临车开了，才发现自己没买票

早晨本来想晚点起床，好好休息一下，结果8点多楼上叮叮咣咣的装修，实在躺不下去了，干脆爬起来上班去了。

昨天更新了driver，本来以为今天可以顺利发布出去。没想到，QA在验收的时候发现一个BUG。虽然在告诉我BUG的一霎那我就知道了错误所在的位置，但是因为正在开发，没法更新，只好先让他们绕过。

正所谓：临车开了，才发现自己没买票。

ps. 中午一个做证券的朋友来拜访，谈到网游企业股票的投资价值问题。我认为现在行业很不错，还有很大的发展空间，要是把中国网游公司的股票打包做个基金，买点还是很不错的。

草率易出错，编码需谨慎

今天等SVN上的版本管理方法稳定下来以后，我开始提交这更新后的driver。

因为改动很多，所以我针对Debug/Release版本都仔细测试了一下，登录进入游戏，看上去很好，没有什么问题，于是放心提交了。

晚上突然出了点意外，有一两个玩家运行客户端以后卡在一开始的启动界面就不动了 - 这个发出去的客户端是上周五晚上build的，尚没有包含我更新后的driver。一个同事检查了半天，最终确认OGRE、CEGUI均无问题，一直到driver启动也没有意外。

于是我在本地build了一个版本，传给对方，没想到一过去就崩溃了。很纳闷，回来看了看，发现版本组织有点变化，原本build出来的平台lib & dll会自动拷贝到发布目录下，现在居然没有这一步了。一问，需要手工拷贝 !@(#*!&@#*(!@ 也就是说，我今天提交的driver其实根本没有经过测试，只是编译通过了而已，生成的dll没有放到发布的目录，所以没有被使用。对工程做出这样的变化没有周知真是添乱啊！

好一番折腾，排除了几个driver的bug以后总算build出来了稳定的客户端。发给对方，没有改善，但是我发现启动以后即使什么都不做，机器的CPU占用率也特别高。回到我本机一试验，果然，一启动就是50%，同时加载脚本的话就到了100%，而我是双核的机器，说明一开始就耗尽了一个核的资源。既然在本地能够重现，问题就好办了。

诊断的结果让我有些无语，原来是启动界面处理消息在PeekMessage以后没有Sleep。最早的代码当然有，但是上周合并版本时，程序员遇到了一些问题，点击退出无效，于是对代码进行了一些调整。显然，他们没有找到真正的原因，只是草率在收到点击退出时调用exit()，进行了很不优雅的退出；另外，他们还随意修改了一处和退出无关的代码，导致CPU占用一个核的100%。而外网那些只有一个核的玩家因此就倒了霉，启动时大部分时间都用来做死循环了。

所以说，处理问题不可草率，要想清楚原因，做出合理的解释，才能针对性的设计解决方案。倘若到处对可疑代码打补丁，那不是排除问题，而是埋地雷。

ps. 既然单独开了一个线程取消息，为什么不用GetMessage而是PeekMessage？想法真诡秘啊！

gettimeofday

昨天走之前测试的时候瞥了一眼，突然发现Linux（CentOS）下面调用外部函数的时间居然比调用脚本函数的时间还要多得多，这是不应该的。当时已经晚了，我没有继续测试。

回到家里我仔细想了想，外部函数和内部函数不同之处在于每次返回的时候都会检查脚本线程使用的tick是否已经超过了预期，如果是则需要进行调度。莫非是取tick的函数执行的太慢？

Windows下面取tick用的是GetTickCount()，虽然这个精度很低，但是速度的确很快。Mac/Linux下面用的都是gettimeofday，Mac下表现的很正常，只是Linux不正常。考虑到这个函数的精度很高（见前文，现在可以真正有微秒级的精度），需要硬件支持，可能问题就出在这里。

今天中午我到公司一测，果然：在Linux下面执行gettimeofday居然用了0.9us，在这台机器上执行一条VM指令也不过才0.02us，这个调用果然有点问题。

显然应该不是所有版本的Linux都会如此，应该和系统内核所配备的驱动程序有关。当初在给问道更换服务器的时候，曾经出现过新装的机器承载人数比老的机器低40%以上的情况。当时我实测了一下环境，CPU很快、内存吞吐很快，服务器耗在网络上的资源也很少，而剩下的脚本逻辑VM基本都不会和系统调用打交道（除了网络，无任何IO），后来将服务器的Linux版本从RedHat4降级到RedHat3解决了问题，说明和驱动相关的可能很大。目前看来，时间函数可能是原因之一。

高精度的计时器

这几天在优化的时候，GetTickCount()的变化频率太低，一个周期超过了10ms，不利于统计，于是想增加高精度的计时器。

在Windows下面这个很容易做，不用GetTickCount()。而是封装使用QueryPerformanceCounter/Frequency()即可。但是在Unix类的系统下则遇到了问题。C/C++标准库中是没有高精度计时器，POSIX也没有。检索了一下Linux下的资料，看样子要对内核做一个小patch才能够使用，很不方便（我并不希望每换一个机器都patch一下）。

于是我打算采用古老的RDTSC来达到这个目的，虽然这个在SPEED STEP等情况会有问题，但是对测试来说是足够了。

RDTSC取的值很精确，但是每秒钟它变化频率则是一个大麻烦。从CPUID中取得的主频不可靠，INTEL的手册中给出的方法很罗嗦，根据XE的值还有不同的分支，而且我怀疑这个方法也不太靠得住。因为Intel的网站上有人给出了这样的方法：即最古老的 - 小睡片刻，然后根据这段时间差的计数变化情况计算。

既然如此，我还是用这个方法好了，算是比较可靠的一种：

#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <errno.h>

/* Return ms counter */
Vm_Tick_T _vm_getOSTick()
{
 /* BSD4.3 get time */
 struct timeval  tv;
 struct timezone tz;

 gettimeofday(&tv, &tz);
 return (Vm_Tick_T) (tv.tv_sec * 1000 + tv.tv_usec / 1000);
}

#ifdef __APPLE__
#define DO_RDTSC \
 __asm { push eax        } \
 __asm { push edx        } \
 __asm { rdtsc           } \
 __asm { mov r_eax, eax  } \
 __asm { mov r_edx, edx  } \
 __asm { pop edx         } \
 __asm { pop eax         }
#else
#define DO_RDTSC \
 __asm__ __volatile__ ("pushl %eax\n"); \
 __asm__ __volatile__ ("pushl %edx\n"); \
 __asm__ __volatile__ ("rdtsc\n"); \
 __asm__ __volatile__ ("movl %%eax, %0\n" : "=m" (r_eax) : ); \
 __asm__ __volatile__ ("movl %%edx, %0\n" : "=m" (r_edx) : ); \
 __asm__ __volatile__ ("popl %edx\n"); \
 __asm__ __volatile__ ("popl %eax\n");
#endif

/* Return us counter */
Vm_Freq_T _vm_getOSUsCounter()
{
#ifdef IA_RDTSC
 /* Use RDTSC */
 static unsigned long long timeFreq = 0;
 union
 {
     unsigned long r_eax_edx[2];
     unsigned long long timestamp;
 } u_now, u_prev;
 static volatile unsigned long r_eax, r_edx;

 if (timeFreq == 0)
 {
     /* First invoking, stat for frequency */
     Vm_Tick_T c_now, c_prev;

     /* Wait clock changed */
     c_prev = _vm_getOSTick();
     while (c_prev == _vm_getOSTick());
     c_prev = _vm_getOSTick();

     /* RDTSC - save time stamp counter */
     DO_RDTSC;

     /* Wait clock changed */
     u_prev.r_eax_edx[0] = r_eax;
     u_prev.r_eax_edx[1] = r_edx;

     /* At least 10 ticks passed */
     while (c_prev + 10 > (c_now = _vm_getOSTick()));

     /* RDTSC - get new time stamp counter after sleep */
     DO_RDTSC;

     /* Get frequency per second */
     u_now.r_eax_edx[0] = r_eax;
     u_now.r_eax_edx[1] = r_edx;
     timeFreq = (u_now.timestamp - u_prev.timestamp) * 1000 / (c_now - c_prev);
 }

 /* Get current counter */
 DO_RDTSC;
 u_now.r_eax_edx[0] = r_eax;
 u_now.r_eax_edx[1] = r_edx;

 /* Convert to us, return in 32bits */
 return (Vm_Freq_T) (u_now.timestamp * 1000000 / timeFreq);
#else
 /* BSD4.3 get time */
 struct timeval  tv;
 struct timezone tz;

 gettimeofday(&tv, &tz);
 return (Vm_Freq_T) tv.tv_sec * 1000000 + tv.tv_usec;
#endif
}

其中Vm_Tick_T & Vm_Freq_T都是32位数即可。

如果使用RDTSC，则在计算时间时，第一次调用会测量10ms，从而得出频率，以后则依据频率计算。

不过，让我吐血的事情在后面：

当我做实验的时候，意外的发现其实gettimeofday返回的很准，相当的精准，准确到了微妙级别（最早我在开发driver即2001年的时候，使用的系统实现这个方法很不准，误差在10ms这个级别。几年过去了，下面的平台早已有了质的飞跃...）。也就是说，我白忙活了半天，算了，留着这段代码在driver里面做纪念吧！也许将来我会需要一个ns级别的计时器，不过那时应该依赖于微妙而不是毫秒计时器来计算Frequency。

微小的性能优化

昨天睡觉的时候想起一个事情可以做做，早晨过来就实验了一下。

LPC支持用文件名直接访问对象，也就是说对象名就是文件名。比如“/daemons/filed.c”，即是文件名，也是这个文件载入后的对象名。因此其他模块可以直接进行类似“/daemons/filed.c”->do_somthing()这样的调用。

我之前的实现针对这点有一定的优化：每个字符串结构带了一个16位的hash值，当字符串做过hash运算以后会保存这个hash值，将来不需要再重复一次。但是，查找对象时，最后比较是否匹配还是要进行整个字符串的比较：STRCMP。

我尝试将对象的名字放入共享字符串池，当进行通过字符串查找对象时，先从共享池中取得字符串，然后直接判断指针是否相等就可以判断名字是否相同了。在实际编码的时候，还是遇到了一些小问题：比如调用者如果没有按照标准的路径名书写对象名，比如“daemons/filed.c”，这样也可以查找到对象才可以。显然，不可能从共享池中取得这个字符串 - 即是取得了，也无法用于判断。因此最终我实现的逻辑如下：

IF string in shared strings pool THEN
DO lookup object
RETURN when found

DO regular string name
IF string name isn't changed
RETURN null

DO raise warning - 这是为了提醒调用者，注意传入正确的字符串，免得每次都要进行规范化操作

DO find string in shared strings pool
IF not found THEN
RETURN null - 字符串名字不在共享池中，自然不可能找到对象

DO lookup object
RETURN result - 不管结果如何，都需要返回了

这样，如果字符串名字本身是标准的，并且在共享池中（代码中的常量都是在字符串的共享池中的），那么将只需要进行整数操作就可以进行hash检索，无需比较字符串的内容了。

实测效率从一次调用耗时0.42us下降到了0.3us。考虑本身循环调用、进出入函数的开销就需要0.18us，相当于检索耗时从0.24us下降到了0.12us，提高了一倍。

不过我做的另一个实验没有达到预期的效果：VM在执行指令时，需要记录一些“当前”信息，比如ip、sp、thisObject等，当进入函数时需要保存这些信息，即将它们记录到context中。原先是逐个变量赋值的，类似：

context->ip = vm_ip;
context->sp = vm_sp;
context->thisObject = vm_thisObject;
...
// 一共5个成员

我尝试将这些信息归入到一个结构中，然后通过结构赋值（编译后即为repz movs）保存，结果效率反而下降了一些。对CPU来说，如果数据不多，它更喜欢“内存->寄存器->内存”这样几个连续的操作。可以并行处理，优于repz movs，因为它还需要准备esi、edi、ecx。

侥幸

今天和蓝港的人交流了一下，本日发号行动只是到媒体，派送到玩家还需要一段时间，所以尚不会出现大规模登录的问题，比较侥幸。一整天，服务器大半时间都在维护，还好这时候没人添乱。

下午在实验室里面果然发现了几个driver的bug，一个是我编译库用的mysql的版本和其他人提交的mysqlclient库不一致，另一个则是driver优化后的逻辑错误，解决这几个问题花的时间不算多，还算是比较顺利，就是提交的时候有点麻烦。

面临考验

下午的时候，QA报过来一个问题，Windows下的DBA启动时driver会崩溃。这个问题还没来得及检查，程序又报过来一个问题，Mysql连接数似乎只能有32个了。

当时我手里的工作正进行到一半，等做完就到了体育锻炼时间，先去打球，8:00钟才回到公司。

在我入手排查bug的时候，突然收到QA的消息：蓝港明天就要放号进行新一轮测试，这个讯息已经发布到媒体了。我感觉很不妙，目前driver正处于更新期间，尚没有稳定下来，眼前已经暴露的问题还好办，如果等到人数上来的时候新暴露问题可就很掉链子了。我询问了一下是否能退回之前运行了一周的版本，被告知不可，因为最新这个版本调整了经验等公式，如果退回之前的版本，就意味着新进来的玩家马上就会面临策划数值的变动，同时之前的版本缺少很多系统，和宣传不符。

总的来说就是一句话：后退是火坑，前进是沼泽。

这让我想起了奥美运营的《孔雀王》，在公测前一天还进行了海量更新，结果惨淡收场，尸体一直铺到苏门答腊。

晚上抓紧定位并解决了DBA启动driver会崩溃的问题，但是我并没有更新，因为我手头的driver又进行了新的优化工作，其中不仅逻辑发生了变化，同时还影响了头文件，这意味着很多库需要重新编译链接。虽然我可以取出历史版本，针对性的修改这个BUG，但是忙中易出错，所以就不修正这个BUG了，毕竟这个BUG理论上只要启动过程OK，就不至于出现危险的结果。倘若真的没顶住... 那只有兵来将挡、水来土掩、见招拆招了。

目前问鼎这个版本服务器端、客户端都在优化进行中，driver不稳定，这可能导致服务器端出现崩溃的可能；服务器端性能目前令人不满意，正在调试优化 中，而新增的任何手段都意味着存在毛病的可能；策划刚刚进行了一轮设定上的改动和更新，需要观察效果；排队机制尚未实现，如果同时涌入人较多可能会在登录 环节遭到非常不好的体验 - 总之，明天将发布一个未经考验并且肯定有问题的版本。

可以预见的是，明天很可能是一个糟糕的局面。担心无用，懊悔也是无用，只能先走一步看一步，将最终的公测做好才是正道。

无题

昨天晚上下班的时候，突然感觉颈椎有些痛，吓了我一跳，这么多年来从未有过这样的情况。本来以为睡一觉即可恢复，但是没想到早起还是很痛，也许是昨天休息的很不好，也许是需要一段时间才能恢复。

我想是前一段时间坐姿有些问题，因为连续10天都在电脑前面工作，很少离座，而电脑在我左前方，要侧着头，很不舒服，时间久了就容易出问题。我一早过去，首先就是把显示器板正，但是因为桌面的东西有点多（还有一个笔记本），怎么摆都有些别扭。

本来我打算今天完成VM指令长度精简的工作，到可以提交的程度。没想到今天会议有点多，用掉了4个小时，结果晚上只完成了driver的自测，放到工程中还是有问题，没来得及全部排查，看来只能明天继续了。

我试验了一下压缩指令长度以后的效果，速度居然比以前版本的driver慢了50%，让我有些纳闷。检查了一下，发现我Release版本的优化选项居然没开（应该是以前检查bug时关闭了），打开了O2以后，速度恢复正常了，但是仍然比原先的driver略慢10%。这有一半在我的意料之中，因为指令精简以后，有一些信息不能再简单的获得了，需要通过指针多索引一次。不过我并不打算到此结束，打开调试看了一下汇编代码，发现几个问题：

1. VC O2优化的程度不够
我将值保存进入栈中的局部变量，然后在用这个局部变量作为参数调用。这个局部变量其实应该被优化掉，但是目标代码仍然进行了一个多此一举的mov，也许开更高的优化选项可以解决这个问题，但是我不想冒险，毕竟O2才是久经考验的。我调整了一下C语言代码的组织，去掉了这个局部变量就解决了问题。

2. switch-case不是我期望的工作方式
有一段代码类似如下：
switch (parameters)
{
default:
VM_ASSERT(parameters == 0);
...
break;

case 1:
...
break;

case 2:
...
break;
}
其中parameters只可能是0、1、2。目标实际上是先判断2，然后dec，判断1，最后跳转到default分支。这不是我想要的，因为大部分VM指令都是无参数的，所以这里进行了一下调整：
if (parameters == 0)
{
...
} else
if (parameters == 1)
{
...
} else
{
...
}
同时，我注意到这段代码之前有一段分支，就是判断是否有从另一处取参数（如果指令参数较长，不能保存在指令内，需要另取），如果是则另取参数，然后再执行到这个分支。我考虑了一下，将以上代码复制了一份。这样如果另取参数时，可以减少一次判断（因为不可能有参数0的情况），同时，如果只有一个参数则不需要取第二个参数，节约了一条指令。

进行以上修改以后，执行VM指令的速度提高了将近30%（当然，这是针对简单指令而言的，如果是复杂指令，提高的不会太多），全面超越了之前的版本。

对VM的进一步优化

今天召集了几个人组成了包括我在内的8人优化小组，专门对问鼎进行优化。三个服务器端、三个客户端、一个策划、一个美术，可以说是公司目前最佳技术力量，争取在1-2个月之内达成优化目标。

因为人力相对充裕，所以我考虑对VM做进一步的优化。本来我并不打算做这部分工作，因为性价比不高，要编写很多代码，而获得的收益有限。但是在小组其他人可以解决发现的主要问题以后，这些次要问题也将上升为主要问题了，所以不如早点动手，让driver能够经受更长时间的考验。

目前我在将driver 12字节长的指令修改为4字节的 - 当初为了省事，我设计每个指令使用两个IntR参数（也就是64位的driver这两个参数占据16个字节，单条指令将有20个字节），这当然很奢侈。不过事实上，在服务器端内存充裕的情况下，这算不了什么，区区20M空间无足轻重，因为cache失效而浪费的CPU资源也有限的很。但是在客户端则有所不同，每节约1M都是令人振奋的，毕竟很多玩家的机器还只有512M内存。

2000以后的我设计思路和90年代初有了很大的不同。在640K内存下编码的时候，每一个比特都要精打细算，思考如何做能够更加节省。而现在，我更多的考虑是如何简洁、可靠、容易维护，效率不再是优先考虑的因素了。毕竟内存已经由不到1M飞涨到了128M+，就连嵌入式系统上也有超过16M的内存空间了。我想，等到用户桌面机器普遍16G内存的时代来临以后，程序设计可以更加轻松。处理逻辑方面几乎不需要考虑内存的问题，主要的内存是用于保存多媒体数据，逻辑占用的数据只是凤毛麟角。就现在而言，真正影响客户端资源占用的还是贴图，节省一张被浪费的贴图，就足以相当于我一天的工作了。

噪音与宁静

前一段时间连续十天保持了每天14小时左右的工作强度，今天感觉有点疲惫，早起的时候懒得动弹，结果早餐也没吃 - 在我印象中，在厦门的时候是极少发生类似情况的。

大概是随着年纪的增长，精力已经不再像以前那样充沛了，不吃不喝不睡似乎也没多大的关系。编码本身似乎还有充能的效果（这听起来有点像永动机）。不过，我认为这并不是主要原因。毕竟每天我还能在12点多休息，可以睡到7:30，从休息时间来说应该是足够的。问题是：我睡眠的质量很差。

我一贯以来的神经衰弱，入睡很困难，而醒来则容易（这在几年以前其实算是好事）；另一方面，我对声音非常敏感，很小的声音我都能听的很清楚（令人沮丧的是我节奏感很差，标准的音盲）；第三点，也是最重要的一点，就是附近实在太吵了，噪音很多。

从 5:30开始，附近的军营就出操了，口号声很响亮，不过这个还好，我倒不觉得很厌烦。而附近路上渐渐的有了车，时不时还会鸣笛，间或还能听到有人很大声的说话。唉，很多国人不以制造噪音为罪恶，确切的说，国人更享受嘈杂。每当这时候，我格外怀念硅谷，那里随处可以找到符合我对声音要求的小区。

在厦门快6年了，期间换过很多地方：禾祥苑、鹭江新城、永升花园、珍珠湾、明发海景苑、云海山庄、还有就是现在的瑞景公园。其中，禾祥苑最安静，永升花园尚好，珍珠湾就比较吵，目前住的瑞景次之，云海山庄就比较吵了，而明发噪音则更大，最让人无法忍受的就是鹭江新城，每天晚上半夜三更还有一小撮人喝酒、大声喧哗。

想找一个离公司不远，而又称得上宁静的地方，真是很难。

关于垃圾回收

嗯，叫做垃圾回收还是叫做垃圾收集，这是一个问题，我在用中文搜索相关资料的时候就遇到了这个别名带来的麻烦。当然，如果叫做garbage collect就没这个问题了，可是那对检索中文资料又带来了困难。

不过事实证明，检索中文资料不是那么重要，因为几乎所有讲具体算法的书，都要付费下载...

我原本一直对垃圾回收有一定的偏见，因为它的不确定性，让我不能准确的使用内存和CPU的资源，也就是会带来那种在掌控之外的感觉，很不好。所以我比较喜欢用引用计数，但是我现在必须改变我的看法，因为引用计数的效率有点低 - 我之前居然一直没有关注到这一点，真是有些不可饶恕。

目前driver使用的值（value）和映射（mapping）的节点分别只有12、8个字节。如果为他们使用一个32位的引用计数字段，那就是4个字节，浪费了33%、50%。事实上，当然还不止这些，因为这些小内存片使用了引用、释放后，大部分情况必须作为独立分配的内存块而存在，否则释放会相当繁琐。既然是独立的内存块，那么指向他们需要一个指针，又是4个字节，管理这些小片内存，往往也需要一点资源 - 很好，一般还是4个字节（虽然有一些精巧的技术可以压缩这些空间，但是会带来很大的使用不便）。这么算下来，有效数据是12、8个字节，而额外的开销却是12个字节，浪费超过了100%。

同时，引用计数一个糟糕的情况就是，不能简单的使用内存拷贝。必须在复制指针的时候进行计数累加，在废弃指针的时候进行计数递减 - 糟糕的是这里还需要判断结果，这是一条判断跳转语句，这一切都使得执行过程显著开销增大。

对于过小的数据单元（类似上面提到的value & mapping node）采用引用计数并不是一个好主意。遗憾的是当年我并没有认真的考虑到这一点，现在真是让我捶胸顿足，后悔的很。

目前driver有一个用简单回收算法（mark-sweep）实现的回收器。但是我却不敢使用它 - 一：效率不高；二：算法是非增量的，导致系统会突然卡一下。

也许我应针对具体应用做具体的改进。

下一步优化的展望

今天没出什么太麻烦毛病，只是发现了一个崩溃 - 事实上崩溃本身倒是小问题，反而在我机器上重现崩溃的时候意外发现了一个错误，那个才是大问题，算是歪打正着。修正这两个问题用的时间不算多，其他一切尚好，就看发放到外网以后效果如何了。

对driver来说，内存上可优化的空间仍然有一些，我在考虑去掉value的引用字段，然后将double类型的real退化到float类型，这样可以将变量压缩，可以再节省8M的空间。而且如果取消了引用，那么容器mapping & array都可以考虑压缩空间，那样这一项节省的效果就将超过8M，合计可以节约16M以上的内存。

注：为了使得mapping和array的值能够被引用，我在容器中保存的是指向value的指针而不是value本身，这样就会多申请一些小片的内存，另外，这个指针本身也是要占用4个字节空间的。

另外，针对指令来说，还可以做进一步的优化，提高运算和调用的速度，但是这样要冒更大的不稳定的风险，对指令的优化是最容易出问题的。

但是，不管怎么样，这种优化的结果都无法和上层实现的优化相比。目前上层的逻辑资源开销过于浪费，客户端启动以后，几乎载入了所有的表、很多不需要使用或是偶然需要使用的资源也常驻内存，这样显然有些不划算。所以，针对具体逻辑的调整才是重点。现在，我多做一些profile的工具才是正理。

提交代码的痛苦过程

今天将Linux、Mac下的driver都提交了。因为头文件变化的缘故，我必须将所有引用了头文件的库都提交一遍，一路上触雷不断，焦头烂额。下午软件园组织马拉松比赛（当然没有42公里那么夸张，大概是个零头左右），公司有90多人报名参赛，其余的都是啦啦队，结果因为提交到半路，不上不下，我也没能去现场助威。

总的来说，提交的时候大部分都是弱智问题。

下午快下班的时候，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技术，不过时间有限，短期内估计无法做出稳定的版本，只能暂时先不考虑了。最终服务器端还是需要从具体实现入手来解决问题，目前这些只是略尽人事而已。

黎明前的黑暗

这几天将所有的时间用于开发上，导致精神状况不是很好，今天打球以后有所好转，还是要和体力消耗相结合才是。

今天中午先将前两天的工作提交，然后继续进行优化。

应该说，现在提交以后的给版本带来了非常大的混乱 - 因为我并没有同时提交完整的linux、darwin下的库文件，因此头文件无法和所有的库都匹配上，我只是认为不匹配的部分并不会影响工程中其他的代码。

事实上，我先遇到了一个库导致崩溃的情况，在我的机器上重新编译以后才解决此问题。

接下来，服务器遇到了其他问题 - 这应该是我提交的driver库逻辑不正确导致的。不过我暂时却无法解决这个问题，因为今天的优化工作是一个半吊子，我的代码也没有版本分支可供修改。

忙活到11:30，完成了编码修改和编译，但是调试工作未能完成。看来只有明天持续，尽快解决问题了。

陈拓琳在诊断客户端的资源使用情况已经有了初步结果，即是好消息，也是坏消息。因为客户端的资源组织可以说是一个非常无序的状态，很多材质组织的不合理，还有很多则是浪费了，调度也几乎没有。因此，关于这部分的优化有着非常广阔的空间，但是还有很漫长的路要走。我想，在完成了几个主要的优化工作以后，应该足以将内存降低到250M以内。（考虑到系统启动时的DLL就用了将近70M的空间，这个目标还算是合理了，万恶的STL啊！）

虽说现在是一团漆黑，不过按照惯例，光明就在后面。

果然是喜忧参半

今天编码、调试，终于将更新后的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两个方案。

driver的优化进展喜忧参半

更新完后，启动开销少了20多M。一共3K多对象，每个节约空间8K左右。

不过周一折腾了一天，调整后的代码仍然有一些不稳定，在离开公司前没有做到完全稳定，符号信息管理的设计思路不够简洁，有些混乱。另外，在此期间，发现工程中还有一些小问题需要调整。

明天仍需努力啊... 一旦涉足开发，就会发现时间不够用，积压了一堆事务未能完成。问鼎我也没时间登录，只好睡觉前抽点时间做10个酒肆任务。

房价还得拦腰砍

中午和同事谈论房价的事情，我说：现在的房价还是太高，得拦腰砍。当然，这并不是指所有的房子，有些房子得对着脚脖子砍。

当然，有很多反驳的理由：
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”会检索一次后命中，其他则最多检索两次知道无法命中。

最后，为了避免浪费内存，所有的字符串均采用共享字符串。在查询比较时，也可以提高速度。

话不能乱说

当年林总给叶群生日赠的手书：“发不同青心同热，生少同衾死同穴。”
叶群回赠：“教诲恩情永不忘，他年定随到黄泉。”

这话真是不能乱说啊。

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);
}

如果用VC编译则输出34，如果用gcc for linux编译则输出33（用gcc for Mac OS X编译也是34）。

完整的分析

为了便于阅读，我这里只给出最相关的资料，如果需要进一步了解需要做试验、检索更详细的资料。

x87 FPU的资料

我们先了解一下FPU的数据寄存器（Data Registers）和控制字（Control Word）。
数据寄存器是80位，有效数字64位。它可以选择几种工作模式：

Precision	PC field	备注
单精度（24位有效数字）	00	32位，即float
保留	01
双精度（53位有效数字）	10	64位，即double
扩展双精度（64位有效数字）	11	80位

PC字段是控制字的8、9两位。
另外，控制字的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反汇编的代码以便于阅读。
注：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;
}

注：在VC下书写汇编代码和Intel的标准一致，目的操作数在前，源在后。
这个结果就是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中
    ...

第一步即fstpl r3将栈顶的计算结果（80位）保存到内存变量（64位）中，这步操作采用了四舍五入（gcc默认的RC也是00，即四舍五入）将80位精度转为64位精度，往后自然全部正确。
按照这个道理，我们可以用这样的方法改写C代码获得正确结果：

...
    r3 = r1 * r2;
    x = (int) r3;
    ...

这样结果也正确，因为r3 = r1 * r2这一步会进行四舍五入。

结论

gcc for linux的浮点数直接取整实现是一个bug。

最后

浮点数计算对完美的移植是一个重大的考验，因为对浮点处理方法的不一致性、或处理顺序的不一致性会导致精度上的微小差异。这个微小的差异随着计算的进行，会逐步的放大。

相关文档

Book1：Intel 64 and IA-32 Architectures Software Developer's Manual VOLUME 1: Basic Architecture

好一个特仑苏，好一个高科技

蒙牛的OMP添加剂，目前弄得沸沸扬扬。国家六部门联合要求停止添加此成分，蒙牛则跳出来一方面拥护国家决定，一方面辩解此物无害。

我关心的不是这个产品有害无害，毕竟还没听说因为这个喝出毛病的，而是以下这则三年前的新闻（这是我从新闻的网友评论中发现的）。

蒙牛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

看了一个WebGame

界面很炫，做的漂亮。

地址：www.civony.com

立场

早晨看到QQ登录时的弹出页面上的两条新闻标题，感觉很有意思。
我们之于英国是否恰似韩国之于我们？

链接如下：
干扰温家宝演讲学生逃离宿舍 不敢见人
韩国SBS电视台报道中国春节"凄凉紧张"

疯狂的赛车

还不错，这部电影挺好看。

缺憾是情节经不住推敲，不过也许导演并不考虑这一点，它已经值得一看了。

ps. 里面的泰国高手让我想起了街霸里面的西班牙那位在铁网上爬来爬去的大哥，可惜啊，高手也怕敲闷棍。

纪念梁羽生

2009年1月22日，梁羽生辞世。

梁羽生先生开创了现代武侠的流派，若没有他，我们可能还真是无缘欣赏金庸、古龙的作品。虽然我对他老人家的作品实在是欣赏不来，看不动。

另外，梁羽生当年受到陈克夫与吴公仪在澳门比武的启发，写下了《龙虎斗京华》。不过，陈与吴真是两个十足的水货，连带我对中国传统武术也深表怀疑。

比赛过程龌龊，属于街头地痞斗殴的层次，但是经过文字渲染以后，看上去好像还挺有水准，这就是文字的魅力啊。难怪当年金兵占了中原，不爱刀枪爱辞赋。

视频链接：http://you.video.sina.com.cn/b/827764-1229389535.html
文字链接：太极的自我吹嘘

路上事故隐患不断

下班回家，从停车场出来的路上横着一辆单车，还有一辆肇事的士。这里是园区内的丁字路口，本来就是一个事故隐患区，出来的人看不清楚，外面的车还开的飞快。

从园区出来，回家路上，遇到一个骑自行车逆行的，看到我就往右拐，偏偏我也要偏左规避地上的坑，好在我开的速度很慢，彼此都躲过一劫。

再往前行，有一辆车慢悠悠的靠左开，我只好从右侧超车，看到司机正在打电话。

前行500米，有一辆车闪着双闪逆行奔了过来，我让开，似乎后面打电话那个大哥还挺机灵，也让了。

继续前行500米，有一辆巴士从右侧出来，逆行50米，然后切到左侧的对向车道（因为有隔离护栏，所以从出口的地方不能直接左转到正确的行车道上）。

再往前看，一片漆黑，路灯全灭，黑灯瞎火的往前开，有一个涵洞如果不小心就会逆行进去（这里反而没有隔离护栏了），之前听说涵洞里面遇到过逆行的，而前两天在这段黑漆漆的路面上看到过一起事故，车撞人。

2分钟后，平安抵达家中。真是惊险，4公里，1起事故，5处隐患。

当地导游称美旅游公司一味降低成本导致车祸

前几天一个赴美的旅游团出了交通事故，大巴翻车，7人身亡。

今天在新浪的时候看到一篇文章，里面的内容有点诡秘，节选几段：

张先生告诉东方网记者，为了降低成本，提高效益，美国银河旅游公司租用DW公司廉价的大巴和司机。

张先生告诉东方网记者，银河旅游公司在美国口碑就不是很好。

张先生说，他打过来电话告诉媒体，就是要告诉广大网友，导致事故的真正原因。

让我感到不妥的地方是，这个团是中国组织的而不是说游客到了美国随便找了一个。也就是说，挑选了这个“银河”是我们的“上海东湖旅行社”（中间可能有很多环节，但是总归是“东湖”发起的），如果这个“银河”果然资质很差，那么我们为什么要选择这一家？

所以，这个神秘的“张先生”究竟是谁？是“东湖”驻美负责人，还是承接“东湖”出的团转包给“银河”的二道贩子？这么急迫的来“告诉广大网友，导致事故的真正原因”，或许只是为自己推卸责任罢了。当然，还有一个可能就是趁机打压一下竞争对手。不论如何，这样的一篇文章，只有“张先生”一个人自说自话，记者毫无自己的判断分析，居然能放在新浪的首页，并且标题为“事故原因分析:旅游公司一味降成本”，实在是令人感到神奇。

原文链接：当地导游称美旅游公司一味降低成本导致车祸

相机应该集成GPS

总算把picasa上的照片都整理完了。

在标注相片地点的时候，我无限的盼望相机具有GPS功能，这样就可以准确的标注出我拍照的地点，而不是像我现在这样笼统的指明城市而已。

如果具有准确的经纬度，那么可以通过照片看到自己旅行的路线，而且还可以通过卫星地图回忆一下当时的场景。

ps. SONY的相机已经有实用配件了，不过，要集成在相机里面就更好了。

iPhoto修改照片时间的功能不错

从三亚回来，整理照片的时候，发现相机的时间竟然设错了，差了一年零一天。想想要将两百多张照片都修改时间，我痛苦的要从凳子上掉下来。

MM说，不能一起修改时间吗？我说这样可能会把时间都修改成一个时间吧？然而一试才发现，iPhoto并没有做这种没有意义的事情，而是将所有的照片平移一个时间。我仔细想想，的确统一将照片修改为某个时间没什么实际意义（虽然很多软件的类似批量功能都是这么做的）。

研究用户的需求是一门学问啊！

ps. 果然什么都经不起表扬，在我写这篇文章的时候，正在上传照片的iPhoto崩溃了。

三亚游记3

今天就要离开三亚了，早晨起来用完早餐便退了房。酒店办理退房手续的效率很低，等待较久，很多客人不满意，我也是其中之一。

从酒店到猴岛大概70公里，路上一个多小时。猴岛本身离大陆不远，应该500米左右，可以乘坐缆车或到渡口坐船上岛。我们选择了缆车，排队的地方很混乱，非常拥挤，管理无序，周围的环境卫生条件也不佳，总的来说这个排队的过程令人很不舒适。

大概排了一个小时左右，总算坐上了缆车。通过整个索道用时十分钟左右，风光不错，而且还有点过山车的感觉（但是不会强烈到令人不适），值得试试。不过这个缆车的安全措施让我有点怀疑，成年人自然无妨，如果携带小孩还是需要加倍小心的。

岛上游览的内容还可以，以猴为主题。其中猴子杂技、毛毛一家的滑稽表演（就是当年的耍猴）都挺好看，整个岛不算大，2个小时足以游览结束。不过拍照的时候需要小心，猴子具有一定的攻击性，最好不要离得太近。

我觉得在岛上小猴的生活不错，吃喝玩乐很自由，成年的就不太爽了，估计都被用绳子拴起来给游客表演了。除了表演杂技的猴子没有被拴着，其他的猴子拴的拴，关的关，都没啥行动自由。或许呆在自然保护区里面的猴子不同吧。

两点钟我们乘船（这个等待的时间很短）下岛，直接前往机场。全天移动距离150公里。

猴岛的管理水平和呀诺达相比差很远，至少差两个层次。出入岛环境不好（卫生差），组织也不到位，让排队者颇为气馁，很消磨耐心。岛上的工作人员素质参差不齐，有的人员状态不好，态度也不佳；路牌指示不清，让人看的很糊涂。另外，在滑稽表演结束以后，是拍照时间。有一家人因为小孩比较怕猴子，总是配合不好，拍照拖延的时间长一些，在其他游客还没怨言时，工作人员就已经很不耐烦了，大声呵斥，想退钱赶游客走，给我留下的印象很差。

总的来说，我对猴岛的评价是：可以一看，不做推荐。




附：三亚相关照片一览

三亚游记2

早上9:10分左右出发。

先去了鹿回头，离酒店很近，开车应该是1.5公里左右。门票不贵，30元一张（司机的车还另需要5元的停车费）。不过一分钱一分货，这里的确也没什么好看的。登高可以俯视三亚，但是景色平平。算是插个旗吧。山顶有一个雕像，不过我没看出什么名堂。

离开鹿回头，奔亚龙湾而去，路上30公里左右。我们从丽兹卡尔顿酒店（本来打算订这个酒店，不过太贵了，作罢）穿过，进入海边的沙滩。沙滩不错，至少是我在国内见过最好的。沙子很细，水的颜色也很好。海边的游客很多，不过这段时间不够暖和，下水的人并不算多。沿着沙滩一直走，经过希尔顿等酒店，到达了红树林酒店，这是我们事先在网上查到的，据说它的泰菜做得不错。

中午在红树林用餐，品尝泰菜。味道不错，我本来不是很喜欢咖喱，但是仍然觉得口感挺好。

午餐过后，我们按照计划去蜈支洲岛，司机先前曾说上岛要排队很久，所以我们特地推迟到午后，想看看是否能排的时间少点。没想到离码头还有两三公里的地方，车就被拦下来了。工作人员说里面车很多，不肯放行，而且里面排队上岛的人还很多，可能还要排3个小时。我们勉强往前又往前开了一小段，实在无法只能调头。结果刚走没多远，工作人员又开始放行了，于是再调头，调到一半的时候，工作人员说今天人员已满，不卖票了。这一圈真实折腾得我们七荤八素，罢了，换地方吧。（所以公众节假日还是别来三亚这种地方凑热闹了，老老实实缩在家里吧）

去不成蜈支洲岛，我们便改去呀诺达，这是一个以热带雨林为主题的园区，从蜈支洲的渡口过去大概是50公里左右。呀诺达是海南本地方言（不知道是不是黎族语）一、二、三的意思，也有打招呼“你好”的意思。

下面就是我对这个景区的重点推荐！

我对这个景区的评价就是：好，非常好。首先，景区管理有序，和中国任何一个优质景区相比，它的管理都毫不逊色，在三亚这个地方就更难得（海南的旅游管理评价水平实在不高）。入口会免抵押派放解说器，它会自动感应，根据你到达的地方播放解说词，内容也还不错（对我来说知识性方面尚有所不足）。途中遇到任何一个工作人员，都会大声而自然的向你打招呼“呀诺达！”，而且他们都有足够的耐心为你指路。旅途路线设计的也颇为合理，不会走回头路，同时针对不同的人有相应的分岔通路，让人可以根据自己的体力选择环路。

总的来说，这里硬、软质量均属上乘。而园区本身的内容也值得一看，能补充知识，开拓眼界，略有博物馆的味道，具有一定的品位，同时也不会让一般的人感到枯燥。评价：两星，到三亚旅游的话值得看看。

距离呀诺达不远（大约10公里）就是槟榔谷，司机向我们推荐了这个，认为呀诺达里面有的槟榔谷都有，而且槟榔谷里面还有呀诺达没有的民俗表演。不过我也曾去过民俗文化村这类景点，对这类表演性过强的景点没有期盼的感觉。没有实地拜访，不好对比，因此不作评价。

时间有限，晚上要赶去乘船游三亚湾。5点我们就下了山离开景区赶回市区。不想到了酒店附近遭遇堵车（应该是游客太多的缘故），勉强在7:30之前赶到了码头。MM父母去乘船游海，我们则去觅食。

注：一天总共移动距离157公里，其中步行6.5公里。

接下来吃饭时遭遇了感觉令人很抓狂的一幕。

我们沿酒店门口的路走了一段，看到两个川菜馆，就随便找了一家坐下。服务员上来扔下菜单和本子，让我们自己写，似乎很忙的样子。我和MM讨论了一会，选好了菜式，但是想找服务员挑选一下青菜，结果喊了半天也没人过来，很不爽，离座而起，去了隔壁那家。

到了隔壁，倒是有人来招呼。我们下了单，要了一支冰冻啤酒和两支可乐。等了许久，无人理会。催了一下，来了一个服务员，我们有些不耐，结果她说：“你们的单不是我下的，所以我也不太清楚啊！”催促之后有了效果，来了一支啤酒，不是冰的，狂不爽，让她回去换。过了一会，再催可乐，此时我们已经颇为光火，结果服务员说：“$A（内容见上文）”，让她去拿，稍后她飘转回来，说：“没有啦，你们去旁边超市买吧！”无语了，自己动手丰衣足食吧，我去旁边超市买了可乐。

抱着可乐又打了两把牌（手机游戏这时候很可爱嘛），我们连续催了几次服务员上菜，一团混乱中，有人眼神迷茫，有人说：“$A”，好不容易飞过来一盘菜，我们刚提起筷子，一看，没点这个嘛！原来是上错了。

再催，等了片刻，飘出某服务员，说：“没有椒盐虾，白灼虾行不行？”我们一听大怒：“这话不早说！？不吃了！”当即拂袖而去。

最后在对面的一个餐厅吃了饭，人少点，老板也比较热情。

总的来说，过年期间，顾客比较多，店员的确不太能忙得过来。但是，其中暴露的问题不是人力不足的问题，而是服务人员丝毫没有服务意识，首先“$A”这种话就不能说，我只认这个店，所有的服务员对我都一样，顾客怎会去管向谁下的单？服务员遇到这个问题，解释毫无意义，应该赶紧研究一下单，看看怎么回事，怎么解决问题才对。

另外，我看服务员就是在瞎忙，店里的顾客不足以让她们忙得这么混乱，调度能力太差。

总结：节假日别来三亚。

三亚游记1

昨天（大年初一）从深圳出发，飞抵海口，转车至三亚，入住宝宏大酒店。

今天用完早饭，通过酒店的侍应生找了一辆蓝牌车（非营运车辆），包一天300（春节期间会比较贵）。

我们先去了南山寺，路上43公里，中途买了几注香。感觉买贵了，一路有很多卖香的，可以往死里还价，总能找到便宜的。如果香是在庙里买的，贵也就罢了（算是香火钱），如果在外面买，还是选择最实惠的价格吧。这点还是弘法寺好，根本就不允许香客自己带，门口每人发三支，烧文明香。上香在于意诚，想捐钱的有功德箱，没必要在香上面下功夫。

入寺买票前，看到墙上贴着胡哥的八荣八耻，MM遮住我眼睛让我温习一下。因为很久没有背了，有点生涩，不过努力回想了一阵，还是都想起来了。

进了南山寺，我们先上了两注高香（这个实在够沉，扛的比较累），去了海上观世音处参拜。这个像高108米，据说耗资8个亿，外部蒙皮为2mm的钛合金（我未能考证，官方资料上没有提及这一点）。还有谣言说这是老江授意建造的，司机说得信誓旦旦：老江做梦得人祝福，故探访到南山，责令立像拜祭。这话当作笑料听听即可，不必当真。



中午到缘起楼南山素斋用餐，春节期间这里只有套餐不能散点，我们选了适合3-5人的498元套餐（据网上说素菜一定要点菜，不要选自助的。因为没有对比过，不知道如何，不过从价格上来说，单点并不亏），味道不错，将豆制品和蘑菇用的出神入化，从外形到味道都有几分相似，值得品尝。

餐后去拜金玉观音，真是金碧辉煌，墙壁上一排排的小型的金玉观音，下书某某合家供奉。在这里我们再进奉了余下的两注小香。



拜后时间不早了，直接赶赴天涯海角，路上15公里。

天涯海角，据说当官的和做生意的大都不喜欢来此，因为这里有“到头了”的意境。而我作为工程师，总有探求边界的欲望，既然天有涯，岂能不来。

从入口到刻有“天涯”、“海角”的两块石头，要走20分钟左右，游客不少，路上还要拍照，总共花费的时间还是不少的。





作为海南岛的著名景点，天涯海角的口碑实在不好，管理方面的纰漏层出不穷，基于前车之鉴，我们都是小心翼翼的，唯恐中招，不过实际感觉还不算差，可能是最近有所改善，也可能是运气不错。总的来说，我对这里的评价：毕竟名气很大，两星，到三亚值得来此拜访。

离开的时候，我和MM在出口意外的碰到了小苏一家人，真令人惊讶啊！正是“相逢在天涯”。

回到酒店，全程85公里。

春运期间火车票总是一票难求？

火车票难买，多年以来便是如此。只不过以前是一年四季都难买，而近10年来平时还好，基本是春运期间难买。关于这个疑难杂症，众人提出的意见不少，比如实名制，看上去似乎可以解决这个问题，不过我并不这么认为。

从经济学的角度来看，春运期间由于供需的原因，实际上一张车票的市场价格是高于票面价格的（我们可以认为黄牛票价才是真正的市场价格）。那么，这个问题首先需要考虑的是多出来这部分利润应该归谁？

1. 归国家所有，也就是由发改委增收春运铁路税
2. 归票源支配者所有
3. 归消费者所有，也就是按照票面价将票卖给乘客

这是有优先顺序的，也就是说，第一个放弃了才轮到第二个，第二个放弃了第三个才有份（像是保研，排第一名的不想要才能给第二名）。显然，发改委不会冒天下之大不韪干这种事情，至少目前的成员没这份胆量，所以国家是不要这份烫山芋了。那么，就轮到票源支配者来考虑是否愿意放弃这份利益了。这里面又分为显式获得利润，或是隐式获得利润。如果想要显式获得利润，那么就需要由发改委同意铁路进行无限制票价上浮（或是大大提高票价上限），发改委当然不会干这种吃力不讨好的事情（反正都挨骂，还不如收税算了）。在这种情况下，票源支配者不能显式获得利润，他们又不愿意放弃，那就只好采用隐式获得的方法了。

至于黄牛，还是在售票终端上打票的工作人员，还是能够暗中操纵票源的大佬也好，他们都不过是这个链条的一个环节而已。大佬们可以说是发起者，但是他们并不能阻止这一切发生，如果有一个青天大老爷进行改革试图放弃这部分利润，要么本人被踢出局，要么就是改革中走样，其他人仍然大捞特捞。就算有一位神一般的青天大老爷解决了这个问题，也不过是一时而已，等他离职后反动势力照样会反扑。（以我们这种自顶而下的社会组织方法，资源协调者拥有非常大的权力，这个群体不腐败是不可能的，正所谓的绝对的权力导致绝对的腐败）

所以，消费者就不要期望自己能够获得这个利益，因为它已经被资源的分配者给取走瓜分了。在社会的监督机制（这个依赖于全民觉悟的提高，政治制度的变革）完善之前，消费者除非运气好（运气是有价值的），或者是门路广（这也是一种资源），否则还是调整心态，安心的按照黄牛价买票吧，总书记也解决不了问题啊！

相关链接：
胡锦涛考察南昌火车站了解售票情况
一位铁路职工对“一票难求”问题的看法

Ada - 第一位程序员

Augusta Ada Byron，19世纪的数学家，她是第一位程序员（显然也是第一位女程序员）。

她的父亲，是英国伟大的诗人George Gordon Byron（拜伦）。一个出色的文科生父亲，一个非凡的理科生女儿。美国军方为了统一而设计了一门“标准”语言以后，将其命名为“Ada”语言。

Ada逝时年仅36岁，而她的诗人父亲，也是逝于36岁。虽然如此，他们的影响远远超过了36年。

春节晚会

都说春晚是鸡肋，我也有好几年没有认真的看了，一般都是上网闲逛，间或出来看看小品。

今年仔细的看了看（这个和我人生重要状态的切换有着直接联系），春晚还是很有其价值的，鸡肋也有味道啊！

大年三十，是一家团圆的时刻。在这个时候，一家老少能做些什么？说实话，我还真不知道。至少目前并没有一种流传下来的传统，春晚这个持续了不到30年的电视节目反而成了传统，成为团圆时的一道不错的菜肴。吃吃年夜饭，看看节目，饭后一起顺便聊聊天。节目可以作为一个话题的开始，也可以填充话题之间的空隙，不至于冷场。

至于晚会的节目，制作的很精良，总有一些能够投自己的口味。当然，不可能所有的节目都合口味，否则，可能对很多人来说，所有的节目都不合口味了。讨厌的节目，我们可以议论它，拉近大家的距离，引起共鸣；不喜欢的节目，我们可以忽视它，继续我们感兴趣的话题；喜欢的节目，我们可以一起欣赏。

年复一年，作为直播时受众群体最大的一个文艺节目，春晚在保守批判的同时顽强的生存了下来。我想，等到大部分人接受了新的团圆形式以后，春晚就会理所当然的消失了吧。换言之，等到大家不怎么批判它的时候，它就退出舞台了，正如当年的综艺大观。

ps. 赵大叔的徒弟小沈阳在网上被骂得不行，不过我看过以后觉得还不错。

来自手机发布的帖子

本文发自手机 NOKIA E71 系统自带的浏览器。

看上去效果还可以，比在百度好用一些，这里应该根据手机浏览器做了专门的设计。

收藏一句妙言

逛天涯的时候，看到一句妙言：

新闻联播：前十分钟，领导们很忙；中十分钟，全国人民都很幸福；后十分钟，世界上其它国家人民都生活在水深火热之中。

原文：『天涯杂谈』中国拿什么去跟BBC和CNN竞争？

总算将照片全部导入到picsa了

从2002年以来拍摄的照片一直都保存在我的机器上，每次换机器的时候都颇为麻烦，担心弄丢，时不时还要备份传到网上的服务器。现在总算将照片都放到比较可靠的网络存储设备上了，查阅方便了不少。

可惜的是2002年之前的照片因为保管不善，已经无法找到了。当初也曾刻录到光盘上备份，结果光盘的寿命未到，但是物理上却已经失踪了，可惜。

总的来说，数字化存储技术的确是比传统的模拟保存的方式进步多了，而网络存储比本地存储的方式又方便了不少。未来会怎么样呢？我想，还会给我们一些惊喜吧。

grep

grep是一个UNIX的shell指令。

用了这么久，我今天在阅读程序设计语言原理时无意中才知道它的缩写是来自：(g)lobal (r)egular (e)xpression (p)rint line。

当年设计shell指令的前辈够节省的。

尾牙的感想

前几天公司尾牙晚宴，公司各个部门自行组织了一些表演节目。

作为研发类型的公司，我本来对节目并没有太高的期望。不过看过以后，我必须完全颠覆自己之前的判断了，同事们很有创造力，节目很精彩。

人的能力永远不能被低估，我们需要的是能够发光的机会。传说中刘邦善于将将，大抵就是能够将其他人的能力充分发挥出来吧！（这倒是有点像暗黑里面脚踏光环的圣骑士，难怪总是这种人做领袖）

不过，能够做到这一步的人，天下又能有多少人呢？

难。

为什么是e

e = 2.71828....

嗯，它的特点很简单，导数等于自身，姑且不提。我只是很纳闷，怎么出现e这个定义的呢？我记得数学教材里面顺理成章的就出现了e，可是我却死活记不起来了。

这几天重温数学的时候，终于看到了：

lim(1+1/n)^n, n->+INF时，极限收敛。
而在计算f(x) = a^x的导数的时候，会出现上述的极限，因此定义上述的极限为e。

注：因为e^x的特性（即f'(x) = f(x) = e^x），所以用泰勒公式展开：
e = 1 + 1/1! + 1/2! + 1/3! + ...
够简洁，数学很优美。

Immigrate to google

Since I choose the picsa service of google, I immigrate my blog to here for more benefit of intergration.

previous blogs' URL is here.

Red Cliff

看了如雷贯耳的《赤壁》。

应该说，片子的确好“看”，视觉效果不错。制作水平的确精良，不过其改编水平实在不敢恭维，大抵吴宇森是给外国人设计的？倘若真的如此，老外的欣赏水平这般的话，中国就很有希望了。

影片神奇之处就不赘言了，评论多的可以灭了烧掉曹操的大军的那把火，还是把剧中的那句台词送给他老人家吧：“老而不死是为贼”！

ps. 我觉得张丰毅演的曹操很不错，真的。

Honey Moon Jan/9-1

今天一早，搭乘阿联酋航空的遁回香港，然后返回深圳。

我到香港时，发现放在旁边的橙汁杯打翻了，结果橙汁洒到了鞋里... 天啊，阿联酋航空果然克我。

总算又达成了一个重大的目的，说实话，旅行有些累，因为换得地点太多了，虽然每站的行程并不紧张，但是过频繁的移动还是会让人感到辛苦。获得的一个经验是：少去城市，多停留，一次不宜超过10天。

Honey Moon Jan/8-1

起床已经是下午了。

预定了楼下的餐厅，结果被告知要正装（穿外套皮鞋），外套倒也罢了，皮鞋可真有点头疼啊。

上顶楼的餐厅拍了照，顺便喝了下午茶（只喝了茶），考虑楼下的餐厅要穿正装，于是就在楼上又预定了一次（这里似乎对鞋要求不严）。喝完发现有点饿... 于是又到二楼吃了全套的下午茶，结果... 发现又有点饱，干脆就把顶楼和水下餐厅的预定都取消了，这下好... 省钱了。

酒店没什么好说的，不妨说说迪拜这个城市（资料网上都有），作为中东的城市，迪拜靠石油起家，但是它目前主要收入并不是来自石油，而是贸易、旅游等，确切的说，石油仅占GDP中微不足道的一部分。可以说，迪拜是一个共同富裕的典范。

Honey Moon Jan/7-3

因为飞机延误（迟了半个小时登机，飞机又在停机坪呆了一个多小时），我们到达迪拜已经是夜里1点多了。

上次经过迪拜，我下飞机时丢了相机；这次来到迪拜，我又丢了毛衣... 阿弥陀佛，不知道是阿航克我，还是迪拜克我。

事先都说迪拜对30岁以下入境的女子要做视网膜扫描，但是我们一直走到passport control也没看到有视网膜扫描的地方，干脆直接排队进关，如果他要求的话应该会给我们指路。不过令我们感到意外的时，移民官并没有刁难我MM，问了 来处和住处就过了，接下来连我的签证都没查都盖章放行了。

出了机场，我们需要解决一下去酒店这个问题。因为酒店派车来接的话，劳斯莱斯要1500迪拉姆，BMW 7s则是750迪拉姆（1迪拉姆折合2人民币），比较贵，而且乘坐这两种车似乎也不是什么特殊的体验，还是自己解决吧。

事先在网上查了一下迪拜的治安，有说好的，有说差的。比如印度人说比他们国家好（但是我对印度的治安也不太信得过啊，虽说可能比中国还好），也有报道说犯罪率正在上升，总之都是盲人摸象。我们出了机场，一看有机场运营的正规TAXI，应该还好，打了一辆车，把酒店的预订单给他看，就出发了。

路程倒是很简单，出了机场在高速上一阵狂奔，下了高速就到了酒店，一看才72迪拉姆，折合14欧元多一点，不过的士司机按照1:4换算那就是18了，OK，都差不多。

进了酒店，办理check in的手续够简洁，有人领了我们的护照和信用卡，帮我们把所有的事情搞定，我们只需坐在沙发上发呆签字即可。

一切顺利。

总的来说，风帆酒店（Burj Al Arab，除了最后一个词，我都不会念）不愧是7星级酒店，我们的客房是复式的（应该是最便宜的一种），一楼会客，二楼卧室，2个洗手间，5个mini bar，房间都很大，全览海景，设施先进，所有器具都擦拭的一尘不染（我冲凉的时候一头撞到了玻璃上）。相比之下，法国和意大利的4星级酒店就跟农民房一样。

房间里面提供了全套的办公设备（传真、打印机、电脑），邪门，难道来这里都是办公的不成？

早晨起来我研究了一下用自己的电脑上网，有点古怪，无线网络是匿名的，和房号相同，不能简单搜索到。好在我是专业人士，不然还真有点麻烦，嘿嘿。

Honey Moon Jan/7-2

逃离欧洲了。

注：米兰大雪，航班受影响。

总的来说，有艺术鉴赏力的人来欧洲旅游非常不错，文化积淀深厚。像我们这些艺术近视眼，来欧洲的主要任务就是插旗...

在法国给我留下最深印象的词语是SORTIE，意大利则是USCITA，到处都是。

这两个国家的人风格可能比较接近，简单来说，就是法国人比较像中国人，意大利人比法国人还像。我想德国、英国应该是另外一种风格，将来可以去领略一下。

不过，旅途辛苦，一次插旗不宜太多，可以选好一两个城市，仔细发呆，那样感受也会多一点。

Honey Moon Jan/7-1

一早起来，米兰仍是大雪，这样我们有点担心航班。拖着沉重的行李赶到机场，发现航班虽有延误，但未取消，于是check in、安检、过移民局，看起来一切都很顺利。

没想到接下来就是痛苦的退税历程。

过了移民局，旁边就是退税的办公室。我们进去拿出退税的单子，但是退税的大哥问：“你们的商品在哪里？”这让我们有点发蒙，因为之前地陪的经验是：到这里再退税是不用亮商品的，因为不能把行李带到这里（早已托运），所以退税的官员并不关心商品。

没办法，实际和经验脱节了。我们看看时间应该还够。就穿过移民局（相当于又入了一次境，Passport control的人倒没为难我们），联系上地陪一起去找外面的退税办公室。结果在那里也是要看行李，我们看了一下其他人，都是拖着checked的行李来验货 - 似乎他们只要看到行李就可以了。我们上前交涉了一下，未遂，看了看门口贴的退税指南，明确的要求一定要带着放在checked的行李中的商品来验货，而且手提包内的商品是不行的（这让我当时颇有些困惑，checked的行李又不意味着密封，验货以后在交付给航空公司之前一样可以从中再拿出来呀）。

不管怎么样，现在没有别的办法，只好去找航空公司，想将行李拿出来。按照我的经验，这本不应该很麻烦。但是没想到地勤的人说，现在离登机时间很近了，将行李拿出来再check in可能来不及了。我们再交涉了一阵，地勤的小妹去请示他们的领导，前后反复，等待良久，最后还是告诉我们来不及了。

无奈，此时时间已经很晚了，离航班预计起飞时间只有50分钟左右（虽然航班延误，但是飞机已经到达，因为机场大雪调度的问题所以时间未定，因此很有可能按照起飞时间准备登机）。我们只好又返回退税的办公室，试图挣扎一下，发现前面已经排了若干人，而且退税官员正在仔细的检查最前面的那个人的行李，将行李拆开一件一件验证。

我们看时间不够，而且八成也没戏。大概是因为经济危机的缘故，欧洲人要收紧裤带，顺便也把退税卡的严一些，这叫不能开源，只好截流。放弃了，准备去最早那个办公室去挣扎。从新过安检、移民局 - 还是找刚才办理出关手续的那位，我们告诉他已经盖过戳了，他倒也没有说什么，挥手通行。

再到退税的办公室试图办理一下手续，当然 - 还是问我们商品在哪里？我倒了一通苦水，他说：“我们只能给我们看到的商品办理手续”。好吧，我们手上还拎着一些（原先都说用过的商品是不能办理退税的），背包里还放着一些，口袋里还有钱包... 全部拎出来show给他看，这次他倒是没说什么，卡卡盖好戳，唯一一个意外是他说在瑞士购买的东西不能办理退税（瑞士这个鸟国，磨磨蹭蹭的才入了申根，死活还不入欧盟，真是一个trouble maker，罢了，以后不去瑞士买东西了）。

盖好章，领钱（出纳小妹欧元不够，飞了一堆美元给我们，这下可好，身上扛着三种货币），算是捡回了1000美元，还不错，心情好转。

折腾完这一次退税，我已经明白欧洲的退税办理流程了：

买东西的时候领取退税的单据
到机场先check in行李，但是不用交付给航空公司
扛着checked的行李去找退税办公室盖章，他要看就show给他看，随身携带的商品他不会盖章（当然，如果他愿意盖我们也没有必要拦着）
将行李交付给航空公司托运
过安检、移民局，到里面的退税办公室给手提的物品盖章
领钱

关于商品不能使用的传言并不属实，你可以使用它。因为这属于随身携带的，所以要在过了移民局后的验货。当然，为了以防万一，可以将这些使用的商品打入行李内。

Honey Moon Jan/6-1

早晨起来，发现外面是白茫茫的一片，下雪了。

出门踩在雪上，嘎吱嘎吱的响，让我想起了很多年前在雪地行走的感觉，应该有十多年了吧。雪中的米兰，给人以一种不同的感觉，不知道罗马如果下雪会是什么样子，竞技场被雪笼罩是否会更加悲凉萧索？可惜，听说罗马并不降雪，不知道是自古以来便是如此，还是现在天气更加暖和了的缘故。

踏着雪，我们来到了法拉利的纪念品专卖店，是一个红彤彤的世界。能够吸引我的纪念品并不算多，因为我既不是法拉利的fans，也不是汽车爱好者。不过价值4千多元的那些车模还是让我有些心动，虽然我对机械并不狂热，但是终究还是感兴趣的。不过这些东西过于沉重，而且不好携带，只好作罢。

从法拉利的纪念品专卖店出来，我们转战AC MILAN的专卖店。多年不玩足球游戏了，我这个伪球迷已经不再知道AC MILAN现在有哪些高人，卡卡算一个，其他的全然不知。看了一会球衣我才知道似乎小罗现在也在AC MILAN。

接下来去了一个颇有特色的商店，里面的商品都很别致。我看中了一个沙漏（这是当年船长用来判断航速的道具），很有意思，拿下。沙漏一次计时是2分40秒的样子，用来控制会议发言时间看来不错。

Honey Moon Jan/5-2

iPhoto果然是个好东西

以前我是将照片简单的保存在文件夹内，每次拍照完整理的时候都觉得很麻烦，分类，删除，修饰都浪费不少时间，使用iPhoto可以大大的简化这些，减少不必要的工作。另外其内置的编辑功能包括消除红眼、去斑点使用足够简便，不错。唯一让我觉得遗憾的地方是不能给照片打批注（也许通过插件可以）。

Picasa也是一个好东西

很多网络相册我都觉得不方便，比如照片的大小有限制（这样就不能传送原始图片上去了），或是上传下载这些管理功能很麻烦，但是Picasa没有这些问题。它可以和iPhoto集成，直接在iPhoto内选择照片上传，并且是原尺寸的。这样我就可以将Picasa作为网络备份和内容发布使用，很好。

Honey Moon Jan/5-1

最早我们的蜜月行程包含了威尼斯，但是听说发大水，就砍掉了。

到了米兰以后，地陪的朋友说，威尼斯年年发大水，这不算什么，早退去了，于是我们就抽了一天从米兰去威尼斯 - 命里有时终须有啊！

原先我以为威尼斯是在大陆上 - 正如我没来厦门之前对厦门的认知一样。到了才知道，威尼斯原来是一系列岛屿组成，而它的主岛... 给我的感觉和鼓浪屿大小差不多，大点也有限。

从米兰到威尼斯，将近300公里，坐火车两个小时多一点。我们8点40出发，10点多就到了。

出了火车站，我们在岛内兜了一个圈子，走的是道路而非水路，因此没能充分领略到威尼斯未尝独特的一面。不过穿越跨越运河水路的桥时，仍然可以略观其貌。总的来说，威尼斯给我的粗略感觉和罗马、佛罗伦萨不一样，它的商业气息有些浓厚，但是和米兰又全然不同。

中午在圣马可广场的室外咖啡店喝了点饮料，没想到刷卡买单的时候侍应生还特地向我们索要消费 - 这在欧洲这么多天还是第一次，事实上，我们一直很困惑小费的问题（欧洲似乎和北美不同，至少刷卡单上没有tips这一栏，无法明确的标出小费），在各个就餐的地方也没看到有人给小费，因此威尼斯此举让我印象特别的深刻。

下午离开前，我们在海边的椅子上小坐了一会，看看斜下的夕阳、起伏的海浪、荡漾在水中破碎的阳光、天上的辉月。而在岸边踱步的海鸥引起了我们的兴趣，它似乎总是和我们保持一点距离（不像鸽子那样游荡在你的脚边）。于是我们拿出了中午未吃的面包，撕下两小块扔在地上。海鸥小心翼翼的靠近，突然窜过来叼走一块扬长而去，在我们的目光注视下潇洒的在海上飞了一个圆圈就完成了它的下午茶。当然它没有忘记地上还有一块，于是又落了下来。但是出乎我们意料之外的是，数十只海鸥、鸽子纷纷飞来，一时间天上地下无数的鸟或飞或跑 - 不知道它们用什么方法通讯，在几秒钟之内就让大家知道这里开餐了 - 我们将面包撕碎扔在地上，诸鸟抢个不停，显然海鸥们胜利了，它们获得了大部分整块的面包，而鸽子只能分享剩下的面包屑。

夕阳完全落下的时候，我们离开了威尼斯。

Honey Moon Jan/4-2

昨天和今天分别在GUCCI和VERSACE店里买了一个包包。

很有意思的一点是，本来并没有打算购买，只是MM看到感觉不错的包，让售货员拿出来看看。在交流过程中，会让人感觉到售货员非常的喜欢这个包，非常的赞颂他们的设计师。OK，不论如何，会让你感觉他是发自内心的喜欢，而不是为了应付你，回想起整个过程中，每个细节处理的都非常体贴，交流让人觉得舒适而不会不自在（不论是过分的热情抑或冷漠，都会让人感觉不舒服），因此这两个交易就成了。不得不说，直到现在，我们仍然认为这个购买的过程是个享受，具有超出商品本身的额外价值。

事后一调查，原来GUCCI的那个是店长，VERSACE那个则是No.1的sales，真是不服不行，是金子总是会发光的呢...

很多时候，从事服务行业需要的不是各种琐碎的小技巧，而是发自内心为了顾客着想，所有的技巧应该围绕着如何更好的给对方带来体验的这个目的，而不是试图忽悠对方，让对方一时糊涂。

网游的行业，也具有强烈的服务性质，但是有多少的策划、程序、客服人员是为了我们的终端用户而着想的呢？如果有，那么终将收获回报。

Honey Moon Jan/4-1

米兰的景点很少，去看了市中心的大教堂，斯卡拉剧院也就没什么太多可看的了。

附近的名牌店里面逛了逛，买了点东西，下午坐车去瑞士边境的一个小镇上的outlet看看打折的商品（米兰这里已经开始打折了），价格的确便宜很多，但是心仪的很少。MM选了一双靴子和墨镜，就没有看中别的什么了。

来去的的时候乘坐地铁遇到一些问题：去得时候换车的时候发现列车停在站台发呆，也不知道为什么，只好上地面走了一站地（还好只有一站地了）；回来的时候因为昨天的票已经到期了，想再买票，结果自动售票机有的不收纸币，有的不予找赎，有的只能充值，有的干脆坏掉，总之就是没有能用的。最后还是地陪跑到地铁检票口里面（她有月卡）的机器上买的票，真是@(#*!&@(#!*@&!

这让我想起昨天在地铁站买汽水的遭遇，投入1.7元以后可乐掉下来的时候卡在一个0.9元的槽上，摇晃了N久试图让它掉下来未遂；结果我们又投入0.9元试图让那个槽往外卷一点... 未遂 - 因为机器说那个位置的饮料卖完了... 啊！钱还不退！

今天回到酒店，一看BODY WASH和浴帽没有（昨天也忘记提供BODY WASH，现叫的），打电话叫了一次... 等了很久没有响应，只好再催了一次。

唉！意大利人真靠不住。