October 2, 2009

当年那么多网络协议,为什么http最后活的最好,用户最多?

September 5, 2009

如果说这个系列的前面那些,都是我在忽悠着大家乱跑的话,那么这一贴,请允许我停下来,面对前方的迷雾,说说我不成熟的想法,说说我的惶惑。如果我语无伦次,请多包含。

我在这个系列里面,一直提到计算机和人的共同发展,是以一个系统+语言的模型作为界面的。系统是我们描述现有计算机的抽象模型,语言是我们描述我们希望系统进行的操作的媒介,同时也是我们扩充系统的方式。

在电子管、晶体管和几十年以前的单片机时代,系统是计算和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更是离数据的语言很远。我们怎样用数据描述这个世界?难道为了任何一种抽象,就要建立 一个类。或者做一张表吗?我不认为这样是对的,但是我也不知道什么才是最好的建模方法。或许,这种方法,深深的埋藏在我们的意识里,是我们认识世界的基本 方法。或许,这种方法,本身非常的简单。

面对新的机会,遥远的路程,云深不知处。

【全文完】

但是,讨论还在继续

September 2, 2009

原文在这里

大意是说,gmail包括邮件服务器和请求服务器,这次趴下的是请求服务器,主要是web界面,其他的IMAP/POP都还好。

原因是昨天太平洋时间(西岸)早上对部分请求服务器进行维护,于是剩余的请求服务器承载了全部的流量。因为某些新增加的特性,使得流量比较大,于是部分请求服务器过载并且开始拒绝新请求,把多出来的流量推到其他请求服务器,然后就发生了连锁反应。

这么说可能太技术了,基本上就是一只四条腿的狗,你把它的一条腿保养了一下,剩下三条腿走路,然后另外一条腿嫌累,说干脆两条腿走吧,然后那俩腿说,我们也累,还是趴着算了。

计算机系统里面总是会有某些瓶颈,一般就是给这些瓶颈加冗余。这次看来是没有留够冗余。

April 11, 2009

今儿早上有点空,去铁手的西西河看东西,忽然看到萨苏写的这篇:“【原创】中国早期计算机研制中的小故事 我不看北京人在纽约“,里面提到我说的几句:

”当年我也干过类似的事情,要比较一段x86的汇编翻译+运行时间优化以后变成的另外一种机器的汇编。每天盯着模拟器反汇编出来16进制数字。

后来有天下班的时候坐在车里,从车窗望出去,看到旁边一辆车的牌号,脑子里就直接把那个号当成16进制数据了,先给扩展成二进制的,然后开始想:这是哪个指令呢?“

嗯,想起当年的事情,还是很好玩。

当时是公司在推一个新的指令集的芯片,因为兼容的问题,需要把市场上已有的应用,都用软件转化成新的机器的指令集,然后在新的架构上运行。这里面的技术和商业,以及法律问题很复杂,不是一两句话可以说清楚的,这里只说说好玩的东西。

当时是有一个翻译工具,把机器指令逐条的翻译成新机器的指令,这些东西都是二进制的,翻译本身就有bug,需要去查,另外翻译过后为了运行效率的问题,还要进行运行时间的优化。翻译还好办,就是一条指令对应几条目标机指令;优化就好玩了,是一堆目标机指令对应另外一大堆目标机指令,而且这个优化是运行时间的,就是说只能跑一段程序,然后再去内存里面看结果。所以才会有看见车牌当成16进制的事情。

不过这个项目后来还是没有推出,因为硬件推广不利。软件当时已经很成型了,好多应用都可以跑。我现在想想,其实如果龙芯一类的CPU有这个软件,好多应用就可以跑了。

January 20, 2009

把这个用PC取代Wii,当成一个项目来分析一下,反正这个想法多半是口盐水井,研究一下也没关系,万一打出天然气呢?

先分析一下Wii的市场和产品构成。Wii的产品有三个主要部分:

  1. 独特的外设,比如带有加速度传感器的手柄。这个是区分Wii和其他游戏机的主要因素之一。
  2. 有自己独特体系结构的主机。这个是Wii的主要收入来源之一。
  3. 配合外设和主机的休闲游戏。这个是区分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的人就可以去弄这么一个虚拟机,或者叫模拟器,然后玩免费的游戏。卖游戏不赚钱,模拟器也不赚钱,因为电驴上面都会有。那么谁来付开发这个模拟器的人的工资呢?

看来这个想法没有通过赚钱这一关,最后还是一口盐水井。

November 24, 2008

最近乱翻一些论文,发现龙芯还是在走RISC的乱序执行的路。做CPU体系结构的人都知道,乱序执行是能耗大户,而且对于芯片设计的复杂度也是很大的挑战。龙芯现在走的乱序执行的路,似乎和龙芯的商业目标相左。

现在龙芯在商业化上面的目标,是要成为低价笔记本/终端的芯片。这样的定位,其实对于性能的要求,远没有对于能耗的要求高。也就是说,可以牺牲部分性能,来降低能耗。

2002年的时候,我做过一个项目,是用模拟器来计算RISC芯片的能耗,并对体系结构的改变进行能耗上面的评估。当时的结论是,对于典型的应用,如果能够把纯乱序执行变为有限制的乱序执行,那么可以达到30%左右的能耗优化,而性能的影响小于10%。

Intel新的ATOM架构里面,采用了类似的思想,就是一般的指令序列是顺序执行;对于最常见的容易产生流水线空泡的指令序列,即长周期指令(浮点指令)后面紧跟一个短周期指令(整数指令)的序列,才进行乱序优化。

优化的方法是:先判断后面的整数指令是否对前面的浮点指令有数据依赖,没有的话才进行乱序执行。这是典型的80-20分析方法,将有限的能耗预算,用于优化最常见的影响性能的指令序列。

2002年做研究的时候用的基准应用程序,有很多科学计算的东西,龙芯的基准程序集合,因为是针对日常应用,应该有更多的整数指令序列,对乱序执行的要求应该会更少。换句话说,龙芯的乱序执行部件,应该有很多时候都是闲置在那里,空耗能量的。如果改成有限的乱序执行,应该能节省很多能耗。

相应的为了补偿减弱/取消乱序执行带来的性能减弱,可以考虑增加cache的容量。Cache的设计相对芯片逻辑更简单一些。

不知道新的龙芯是否能借鉴这种设计思想。

« Previous Page