总有些想法，不写下来就忘了
攒机器这个事情，也就是以前在国内才干，当时不仅自己攒，还带着我照顾的留学生攒。对，你没看错，我在国内照顾留学生来着。
留学生的故事咱们先放着，留着以后说。这个攒机器，就是去买一堆零件，回来自己配。以前在国内，跑到小店里面，买好CPU，主板，内存，硬盘，显卡声卡机箱还有显示器鼠标键盘，回来一拼就好了，然后再跑到光盘店里面去淘几张合集回来，或者干脆去同学那里抢，哦不，是借，我们读书人，怎么能干抢东西的事情呢？
现在攒机器其实也差不多，跑到本地的店里去买点CPU加主板的打折货，然后去网上买硬盘和内存机箱，回来装起来，再弄个Ubuntu就好了。一共也就400美元不到的样子，就拼出一台4核，4G，1TB的机器。这样算算，也就是100块钱+100瓦一个核，要是在家里弄一个16核的集群，需要1600美元，没准还有折扣。
唯一的问题就是，通过无线网做remote desktop还是太慢，还不能把集群全都扔到车库里面去。
昨天写了电波和列车，引来Song的专业评论。看来我这里虽然偏僻，但是还是有不少专业人士在看，这样好，我也不靠口水和美女去争取流量，有高质量的读者才重要。
那我今天再写一个物理量让人迷惑的事情：芯片的速度。
通常在通俗读物里面，芯片之所以快，都是因为它们是用电信号来计算的，这个电信号其实不准确：到底这个信号是不是电磁波的速度呢？比如：一个计算的结果，从芯片的一级流水线传递到下一级，是不是用光速传播的呢？
当然你可以说，这个速度不是每秒30万公里，因为芯片的导线是铝或者铜，不是真空，所以没有那么快。事实上，信号在芯片里面传播的速度，比电磁波的速度要小很多很多，否则intel的那群芯片设计师们，也不要努力缩小线宽了，把线路弄短是正经。
说到这里，再提一个问题：为什么线宽越小，芯片的速度越快呢？
答案是：在芯片里面，信号的传递速度，是受限于导线的充电速度的。当电流从一根导线的一段传递到另外一段的时候，这根导线实际上相当于一个电容，而高电平则是对电容充电，低电平则是放电，当充电/放电的过程结束的时候，导线两端的电压一致，信号就传递过去了。电容越大，充电和放电的时间越长，信号就传递的越慢。
导线的电容，正比于导线的面积，所以导线越短，线宽越窄，电容就越小，信号速度就越快。
昨天急着赶路，没时间详细说。为什么会有电波抓不住列车的事情呢？协和号高速列车一个小时也不过跑170到220公里（咦？搜狗怎么看见220，就认为gongli应该是“宫里”不是“公里”？你们的HMM是用辫子戏训练出来的？），电波可是一秒跑30万公里的。要是电波抓不住手机，那我们的列车就是银河铁道999，我们也不用去非洲挖矿了，直接移民人马座。
有点手机常识的人都知道，手机是和基站通信的，各个基站各管一片地方，很多基站管理的区域，组成类似蜂窝的系统覆盖地球表面。所以在美国，手机不叫handphone叫cellphone。在手机运动的时候，如果跨越基站管理区域的边界，那么在两个基站之间会有交接工作，把手机的通信从离开的那个区域的基站交给进入区域的基站。
当然实际的操作比这个复杂多了，比如一个地方三个基站覆盖怎么办？手机去问谁？你去问问丁磊关于魔兽，就知道有多复杂了。
扯远了，接着说基站和手机。手机运动的快了，在切换基站的时候，就会发生基站处理不过来的事情：这边基站还在跟另外一个基站商量谁管这个手机的时候，手机已经跑过去了。
不过，列车再快，和汽车的速度也差不了多少，那么既然高速公路上面开车打手机没问题，为什么高速列车上面打手机就有问题呢？
Intel刚刚宣布取消Larrabe项目。看起来intel进军图形处理器市场的努力再次遭到挫折。
以前intel成功的推出了i740，但是紧随其后的Timna，一款CPU+GPU+Mem controller的低端处理器就失败了。最近Apple又拒绝使用Arrandale，现在Larrabee也取消了。
但是随着游戏市场的继续增长，我相信intel对GPU的努力会继续。
如果说这个系列的前面那些，都是我在忽悠着大家乱跑的话，那么这一贴，请允许我停下来，面对前方的迷雾，说说我不成熟的想法，说说我的惶惑。如果我语无伦次，请多包含。
我在这个系列里面，一直提到计算机和人的共同发展，是以一个系统+语言的模型作为界面的。系统是我们描述现有计算机的抽象模型，语言是我们描述我们希望系统进行的操作的媒介，同时也是我们扩充系统的方式。
在电子管、晶体管和几十年以前的单片机时代，系统是计算和IO模型，语言是汇编；在小型机和PC时代，系统是OS，语言是Algo家族的直系旁系子孙，如 C,Pascal等；那么在现在呢？如果你同意我说的，计算机的发展，已经转移到以数据为中心，那么什么是新的系统？什么是新的语言？
我们过去处理数据，是把它们放到数据库里面，切成整齐的表格，然后用SQL来查询它们。但是数据并不老实，它们说，我们不是表格，我们应该可以扩展，鸟可 以扩展为鸡，鸡可以扩展为芦花鸡和白斩鸡。于是出现了面向对象数据库。但是internet的出现，让数据变成了网状结构，而且每个页面都只有有限的共同 点，剩下的就是不限长度的文字，还有各种资源链接。
在表格结构被各种奇形怪状的数据撑的支离破碎的时候，SQL的命运似乎也应该很惨才对。但是我前面做的一个项目，让我对SQL的描述能力，有了更新的了解。
那个项目是一个web service。限于工作要求，我不能说明具体的实现。但是我可以说的是，我们的数据源绝对不是数据库里面的表格。这个web service的一大任务，是要定义一个查询界面，用来查询数据源里面的数据。
对于这样一个结构复杂的数据源，我们开始定义新的查询语法，设计接近尾声的时候，我们需要确认这个查询语法是完备的，也就是说，它必须能够描述所有数据源里面的数据。
为了这个完备性我们开了四个小时的会，最后我百无聊赖的趴在桌子上面，在笔记本上乱画，随手写出了：
select * from data_source where source.property is like
说实话我把自己吓了一小跳，因为SQL的语法用在这里很合适，尽管我们操作的不是表格。我于是提出，我们应该把SQL作为一个标准来比较，如果标准SQL的查询里面有的东西我们没有，那我们就要认真看看了。
我们的Architect虽然不太情愿说我们重新发明了SQL，但是毕竟这种说法留出了我们的语法是SQL超集的可能性，于是他也接受了。事实证明，我们的数据虽然不是表格，但是SQL语法可以描述我们的查询的绝大多数。
另外一个让我兴奋的事情，就是抛弃了表格这个东西，大多数SQL语法依然成立。比如鸡有腿，兔子也有腿，但是这根本就是两种不同的腿。如果我们局限于表 格，那么鸡和兔子应该是两个不同的schema，鸡兔同笼的题目描述起来就困难了（假如我们的数据组织，不仅仅为了做鸡兔同笼的话）。可是，在SQL里 面，我们是用名字的，只要被操作的数据有“腿”这个属性，我们就可以描述。这比面向对象还要好，我们不必为了这道题目，专门给鸡和兔子建立一个公共的陆生 动物父类。
更进一步，我们可以在笼子里面扔进去蜈蚣，蛇和CPU，只要他们都有N条叫做腿的东西，我们的描述，依然有效。
不过，internet这种网状结构，就是数据的系统模型吗？SQL更是离数据的语言很远。我们怎样用数据描述这个世界？难道为了任何一种抽象，就要建立 一个类。或者做一张表吗？我不认为这样是对的，但是我也不知道什么才是最好的建模方法。或许，这种方法，深深的埋藏在我们的意识里，是我们认识世界的基本 方法。或许，这种方法，本身非常的简单。
面对新的机会，遥远的路程，云深不知处。
【全文完】
但是，讨论还在继续
原文在这里。
大意是说，gmail包括邮件服务器和请求服务器，这次趴下的是请求服务器，主要是web界面，其他的IMAP/POP都还好。
原因是昨天太平洋时间（西岸）早上对部分请求服务器进行维护，于是剩余的请求服务器承载了全部的流量。因为某些新增加的特性，使得流量比较大，于是部分请求服务器过载并且开始拒绝新请求，把多出来的流量推到其他请求服务器，然后就发生了连锁反应。
这么说可能太技术了，基本上就是一只四条腿的狗，你把它的一条腿保养了一下，剩下三条腿走路，然后另外一条腿嫌累，说干脆两条腿走吧，然后那俩腿说，我们也累，还是趴着算了。
计算机系统里面总是会有某些瓶颈，一般就是给这些瓶颈加冗余。这次看来是没有留够冗余。
今儿早上有点空，去铁手的西西河看东西，忽然看到萨苏写的这篇：“【原创】中国早期计算机研制中的小故事 我不看北京人在纽约“，里面提到我说的几句：
”当年我也干过类似的事情，要比较一段x86的汇编翻译+运行时间优化以后变成的另外一种机器的汇编。每天盯着模拟器反汇编出来16进制数字。
后来有天下班的时候坐在车里，从车窗望出去，看到旁边一辆车的牌号，脑子里就直接把那个号当成16进制数据了，先给扩展成二进制的，然后开始想：这是哪个指令呢？“
嗯，想起当年的事情，还是很好玩。
当时是公司在推一个新的指令集的芯片，因为兼容的问题，需要把市场上已有的应用，都用软件转化成新的机器的指令集，然后在新的架构上运行。这里面的技术和商业，以及法律问题很复杂，不是一两句话可以说清楚的，这里只说说好玩的东西。
当时是有一个翻译工具，把机器指令逐条的翻译成新机器的指令，这些东西都是二进制的，翻译本身就有bug，需要去查，另外翻译过后为了运行效率的问题，还要进行运行时间的优化。翻译还好办，就是一条指令对应几条目标机指令；优化就好玩了，是一堆目标机指令对应另外一大堆目标机指令，而且这个优化是运行时间的，就是说只能跑一段程序，然后再去内存里面看结果。所以才会有看见车牌当成16进制的事情。
不过这个项目后来还是没有推出，因为硬件推广不利。软件当时已经很成型了，好多应用都可以跑。我现在想想，其实如果龙芯一类的CPU有这个软件，好多应用就可以跑了。
把这个用PC取代Wii，当成一个项目来分析一下，反正这个想法多半是口盐水井，研究一下也没关系，万一打出天然气呢？
先分析一下Wii的市场和产品构成。Wii的产品有三个主要部分：
Wii的市场细分，是通过游戏和手柄把自己和其他游戏机区分开，定位在休闲游戏；利润上面，一个是游戏收入，另外一个，是刻意的制造Wii主机短缺的现象，刺激人们的购买欲望，同时维持Wii主机的高利润。
如果想在中国市场复制Wii的成功，全盘照抄估计悬，微软的xbox砸了那么多钱，都没什么动静。那么，是否可以通过技术和市场的手段，进入任天堂培育起来的这个用户群，从中分一杯羹呢？
我们先看看这三个产品组成：第一落选的是游戏。在中国，开发单机游戏是没什么利润的，除非你控制了硬件。如果Wii的游戏可以在PC上面运行，那么Wii在中国，也只剩下卖手柄的份了。但是Wii的主机硬件控制权在任天堂手里，复制主机这条路不通。另外，开发一款大家喜欢的游戏也是风险很大的事情，即使有版权保护，也需要认真考虑。
再看看手柄和其他外设，这些东西的利润肯定存在，但是都是很薄的利润，山寨厂做做可以。
针对主机，还有什么办法么？比如做个模拟器？这个模拟器在PC上启动以后，可以让Windows运行Wii当前的游戏，这样也不用绞尽脑汁开发新游戏了，主机硬件的控制权也消失了，还可以用现有的Wii的外设。这个想法可行吗？
先看技术上是否可行：Wii的主机也是一台计算机，有内存CPU硬盘和DVD光驱，有视频输出，有蓝牙红外等等，这些都是PC有的。唯一的问题是：Wii的CPU使用的是IBM的POWER PC架构，不是intel的奔腾架构的东西。也就是说，Wii的游戏，直接放在PC上面，intel的CPU根本读不懂那些指令。那么这个问题有解吗？有。解决方案，要么是把那些游戏的源码拿过来，重新编译，或许能在PC上面跑，不过我们愿意，任天堂还不愿意呢。另外一个办法，就是做一个虚拟机，让奔腾架构的CPU去跑这个虚拟机，让虚拟机去跑Wii游戏的那些POWER PC的指令，就象Java一样。好在Wii的CPU这几年不怎么长进，主频比PC的CPU的主频慢了几倍（ 2006是760MHz左右，现在估计最多1GHz ），这个方案是可行的。
假如我们有了这个虚拟机（ 这个东西也不是随便什么人都能写的，全国估计能把这个虚拟机从头到尾弄清楚的，不超过100人吧 ），那么来第二项检查：这个东西，怎么赚钱？Googol问，谁会为这个不赚钱的东西开发游戏呢？现在我们不愁游戏，但是还是愁赚钱的事情：
如果Wii的游戏都可以在PC上面玩了，那么很多有PC的人就可以去弄这么一个虚拟机，或者叫模拟器，然后玩免费的游戏。卖游戏不赚钱，模拟器也不赚钱，因为电驴上面都会有。那么谁来付开发这个模拟器的人的工资呢？
看来这个想法没有通过赚钱这一关，最后还是一口盐水井。
最近乱翻一些论文，发现龙芯还是在走RISC的乱序执行的路。做CPU体系结构的人都知道，乱序执行是能耗大户，而且对于芯片设计的复杂度也是很大的挑战。龙芯现在走的乱序执行的路，似乎和龙芯的商业目标相左。
现在龙芯在商业化上面的目标，是要成为低价笔记本/终端的芯片。这样的定位，其实对于性能的要求，远没有对于能耗的要求高。也就是说，可以牺牲部分性能，来降低能耗。
2002年的时候，我做过一个项目，是用模拟器来计算RISC芯片的能耗，并对体系结构的改变进行能耗上面的评估。当时的结论是，对于典型的应用，如果能够把纯乱序执行变为有限制的乱序执行，那么可以达到30%左右的能耗优化，而性能的影响小于10%。
Intel新的ATOM架构里面，采用了类似的思想，就是一般的指令序列是顺序执行；对于最常见的容易产生流水线空泡的指令序列，即长周期指令（浮点指令）后面紧跟一个短周期指令（整数指令）的序列，才进行乱序优化。
优化的方法是：先判断后面的整数指令是否对前面的浮点指令有数据依赖，没有的话才进行乱序执行。这是典型的80-20分析方法，将有限的能耗预算，用于优化最常见的影响性能的指令序列。
2002年做研究的时候用的基准应用程序，有很多科学计算的东西，龙芯的基准程序集合，因为是针对日常应用，应该有更多的整数指令序列，对乱序执行的要求应该会更少。换句话说，龙芯的乱序执行部件，应该有很多时候都是闲置在那里，空耗能量的。如果改成有限的乱序执行，应该能节省很多能耗。
相应的为了补偿减弱/取消乱序执行带来的性能减弱，可以考虑增加cache的容量。Cache的设计相对芯片逻辑更简单一些。
不知道新的龙芯是否能借鉴这种设计思想。