存档

文章标签 ‘Google’

Siri背后的技术

2011年10月23日 sigma 17 条评论 86,945 views

今年10月,Apple发布了iphone 4S with IOS 5,其中最大的亮点就是一个语音搜索软件-Siri。一时间,各种geek,伪geek,码农,非码农都流行起调戏siri,各种调戏视频,音频大量出现。不过,常言道“外行看热闹,内行看门道”,作为一个“伪内行”,或者“欲做内行而不得”的人,根据自己的知识,以及一些搜索工具,尝试了解了一下Siri的“门道”,在这里做个总结,列出siri所可能用到的技术(所谓可能,是因为很多是我猜测,或者没有准确的来源的资料)。

Siri是IOS上的个人助理应用:此软件使用到自然语言处理技术,使用者可以使用自然的对话与手机进行互动,完成搜寻资料、查询天气、设定手机日历、设定闹铃等服务。(来自维基百科

Siri所用到的技术,很多人会回答,人工智能以及云计算,的确,总体来说,是这两样技术,不过,这种概述感觉几乎没有任何意义,和不直接说“计算技术”(注意,不是计算机技术)呢。因此,在本文,我将介绍下我了解Siri可能采用的技术(由于有个人猜测,不一定准确)。

首先,在前端方面,即面向用户,和用户交互(User Interface,UI)的技术,主要是语音识别以及语音合成技术。语音识别技术是把用户的口语转化成文字,其中需要强大的语音知识库,因此需要用到所谓的“云计算”技术。而语音合成则是把返回的文字结果转化成语音输出,这个技术理论上本地就能完成(以前用过科大讯飞的在windows mobile上的本地语音阅读软件,软件很小,但能读的很好,还支持方言),但不知道Siri是否如此,当然,在云端完成也并无不可,在当前无线带宽下,那点语音流量根本不算什么。

其次,后台技术,这些其实才是真正的大角色(当然,普通用户是不会在意的,他们只会觉得前端很炫,哎,这就是做后端的悲哀,小小感叹一下)。这些技术的目的就是处理用户的请求,并返回最匹配的结果,这些请求类型很多,千奇百怪,要处理好并不简单。基本的结构猜测可能是分析用户的输入(已经通过语音转化),根据输入类型,分别采用合适的技术(合适的技术后面)进行处理。这些合适的后台技术包括,①以Google为代表的网页搜索技术;②以Wolfram Alpha为代表的知识搜索技术(或者知识计算技术);③以Wikipedia为代表的知识库(和Wolfram Alpha不同的是,这些知识来自人类的手工编辑)技术(包括其他百科,如电影百科等);④以Yelp为代表的问答以及推荐技术

下面,对上面提到的各种技术进行简要介绍(如有空,后面的博文可能会对某些技术详细的介绍,大家耳熟能详的就免了),强调下,介绍的有些参考来源是维基百科相关词条,下面不一一列出:

阅读全文…

漫谈Google的Native Client(NaCl)技术(二)–技术篇(兼谈LLVM)

2011年8月14日 sigma 没有评论 66,215 views

上一篇文章介绍Google的Native Client技术的渊源及动力,解释了为什么Google要做这样一个技术。在这篇文章中,将介绍Native Client的一些技术概要。

Native Client简介

Native Client是Google在浏览器领域推出的一个开源技术,它允许在浏览器内编译Web应用程序,并执行原生的编译好的代码。Native Client有以下几个优势(参考Google官方英文介绍):

  • 为Web提供更多的图形,音频以及其他功能:可以直接在web上执行了原生的2D,3D图形渲染程序(对Web游戏很有用),播放音视频,响应鼠标键盘事件,多线程执行代码等等,而这一切,不需要浏览器安装任何插件。
  • 良好的可移植性:一个Web程序,只需要开发一份代码,即可以在所有平台(包括Windows,linux,Mac等)运行。
  • 高安全性:安装不被信任的桌面程序一级浏览器插件,可能带来很高的安全风险(如程序携带木马,病毒)。而Native client使用了双层沙盒(sandbox)设计来保护用户的本地资源。Native Client的架构可以保证web要应用的安全性,并且取得和原声代码相同或相近的性能。
  • 方便从桌面迁移:很多开发厂商之前花了大力气开发桌面程序,随着云计算的到来,越来越多的程序会被移植到互联网上,由于NaCl支持直接执行C/C++/Java等代码,Native Client技术可以简化移植过程,减少移植成本。
  • 高性能:Native Client可以让web应用已接近桌面程序的性能运行,这就为在浏览器内运行性能苛刻的程序提供了基础,如大型3D游戏。

Native Client技术概要

有人说,Native Client技术是抄袭ActiveX的,个人不以为然,ActiveX主要是基于COM的,是操作系统提供一套可重用的接口给web应用,而NaCl则是独立于操作系统的。说实话,感觉这技术更像是抄袭Adobe的Alchemy技术,Achemy技术主要目的是解决Flash的低性能,这和Native Client是接近的,并且,这两种技术都采用了LLVM技术,具体可以看这篇文章http://yjrl.iteye.com/blog/320665

LLVM 是 Low Level Virtual Machine 的简称,这个库提供了与编译器相关的支持,能够进行程序语言的编译期优化、链接优化、在线编译优化、代码生成。简而言之,可以作为多种语言编译器的后端来使用。而基于LLVM ,开源社区开发出了Clang,一个C++ 编写、基于 LLVM、发布于 LLVM BSD 许可证下的 C/C++/Objective C/Objective C++ 编译器,其目标(之一)就是超越 GCC。

Google 的Native Client的关键技术就是PNaCl(Portable Native Client Executables),而PNaCl实现的一个关键就是LLVM。下面是整个PNaCl结构示意图:
PNaCl示意图

在PNaCl中,开发者通过一些前端编译器将C/C++/Fortan源代码用对应的编译器前端编译成LLVM的中间字节码,并且进行优化以及链接(这一整套流程可以在Google提供的SDK中完成)。之后,服务器将链接好的字节码进行分发,在客户端,通过LLVM的后端将字节码翻译成本地的二进制对象文件,并且和本地的相关库链接,最终执行完成(这些功能应该是集成在浏览器中的)。

另外,为了保证安全性,NaCl采用了沙盒技术,具体可以看这篇论文:《Native Client: A Sandbox for Portable, Untrusted x86 Native Code》。

参考:

http://www.lingcc.com/2010/06/02/10955/

http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

漫谈Google的Native Client技术(一)–历史动力篇(Web本地计算发展史)

2011年8月13日 sigma 22 条评论 9,662 views

昨天在CB上看到一篇文章《最新Chrome Beta支持在浏览器内直接执行C/C++代码》,而实现这功能的最基本的技术就是Google几年前提出的Native Client技术,其实之前我在一个计算所师兄的博客里已经看过一篇介绍Native Client技术的文章,个人当时就感觉这东西挺有前途的,今天无聊,也了解了下,写篇博客总结下,其中不免有拾人牙慧之处。

Web计算本地化(前端技术)历史-HTML->CSS->Javascript

最初的网络上传输的内容是纯文本的,从网络上传输回来直接通过字符界面展示出来就够了,本地几乎不用计算。

后来,为了更直观,更层次化展现网络内容,人们在文本的基础上加上了什么<h1>之类的标签,于是出现了html,这时候,就出现了浏览器,浏览器是把这些标签解释,并且按照一定格式渲染,这时,就需要一定的本地计算来进行标签分析,字体渲染之类的。

再往后,出现了CSS,并且互联网有了富媒体元素,可以把网页展示的漂亮了,要求本地计算更多了。

但是,这还不够,除了将网页做得漂亮外,还需要减少用户的等待时间,提高用户体验。这时,有人发现,其实很多网络通信是可以避免的,比如,在用户登陆界面,用户输出email格式的用户名,之前是需要将这个信息发给服务器,服务器收到信息后,检查是否合法,不合法的话,返回一个页面,叫用户重新填写,这一来一往很花时间,用户体验非常不好。于是有人就想到,能不能把这些检查用户名之类的计算放到本地,于是,就出现了JavaScript,在用户提交信息时,JS可以在本地检查是否合法,不合法的话,提示原因并要求重新输入,这样用户体验就好了,并且减少了服务器计算以及通信(这貌似符合绿色通信的概念)。

再往后,有人发现,每次点击一个链接,在载入下一个页面的时候,出现空白页让用户很不爽,于是,有人想出了一个办法,那就是事实上,很多页面很大一部分是共同的,这部分其实不需要重新加载,只需要加载改变的部分,而这又可以通过JS实现,于是出现了Ajax技术。这个技术减少了空白等待,提高了用户体验,并且减少了网络通信量(有时绿色通信!)。

Web计算本地化进一步发展-Java-applet,Flash,html5

但是,用户在互联网上的需求还是没有得到满足,有人还想直接在网页上处理图片,玩游戏之类的,由于这类应用一方面计算量大,都放到服务器,服务器不堪重负,另一方面,这类应用都是实时生成画面的,假如通过服务器来计算生成画面(如游戏),再通过网络将每帧图像实时传送回来,对网络要求极高,几乎不可能实现。

于是,需要新的技术将更多的计算放到本地,这时候,出现Java applet,flash等。Java applet允许在网页中嵌入java程序,并在本地执行。Flash应该也是类似,只不过这些计算需要通过flash提供的api完成(这一点有点类似ActiveX通过COM来完成本地计算?)。

Flash的出现,一段时间内,几乎是一统互联网的视频播放以及网页游戏领域。这时,有人眼红也好,有人有更好的主意也好,结果就是有人抱怨flash不开放(还有不安全),有人就想到,我们做一个开放的标准,这标准里面就允许类似游戏等复杂的交互,于是出现了HTML5和CSS3。HTML5以及CSS3将很多JS以及Flash能完成的功能都已到了一个HTML标签里,其实,本质还是差不多,只是这时候这些渲染的计算不是通过flash程序来了,而是直接通过浏览器执行了。

云计算时代的本地计算-Native Client

再往后,随着网络带宽的增长,以及服务器存储能力的提高,出现了大量的数据中心,为了提高这些中心的利用率,出现了云计算。在云计算时代,用户可以把很多数据都放在云端,并且访问这些应用的方法都是统一的。开发者在云服务器开发程序的接口也是统一的(PaSS),这就可以很容易实现跨平台,给用户一个统一的体验。

在这个时代,由于访问云端的资源都是通过浏览器完成的,浏览器就成为一个很重要的平台,这也就是为什么Google会推出自己的浏览器以及ChromeOS的原因。在浏览器能做的事也越来越多,如玩游戏,但是,由于这些游戏是通过一个类似flash这样的东西执行的,效率很低,为了提高效率,并且进一步的将更多的计算密集的东西(如3D渲染)放到本地完成,Google提出Native Client技术,这种技术就是想直接在本地执行C/C++/Java/Python等代码,从而提高本地计算的效率。

从这里,也可以看出Google的野心,Google希望以后用户所有的需求都能在浏览器上完成,包括大型3D游戏,到时候,什么Windows,Linux,都是透明的了,只剩下一个Chrome Broswer,成为开发者的事实平台,得开发者得天下,Google就此一统江山,虽然不能千秋万代,但也能够衣食无忧上十年。

Web计算本地化的问题-安全性

由于web计算本地化是在本地执行服务器上下下来的代码,因此,服务器上要是发给用户的恶意代码,在本地执行的话,会出现严重的后果,因此,这些技术(包括JS,Java applet,Flash)的安全性非常重要。由于Flash应用最多,因此,Flash也被经常爆漏洞。

而对于Native Client技术,如何保证安全则是更大的挑战,为了保证安全,感觉这技术最好用于计算密集型应用,而尽量不让远程代码执行文件读写操作。为了保证文件读写的安全性,个人觉得有两个办法,一个是不读写本地文件,将文件直接写到云端的云存储(但是计算还是本地);另外一个就是在本地沙盒里面读写,不过这只适合临时数据,永久的还是要写到云端。

最后,附一张图,这张图反映了个人计算机应用平台的进化方向:

推荐两本关于IT历史以及处理器历史(ARM与X86)的书

2011年4月23日 sigma 18 条评论 16,214 views

前几天,在OpenGPU论坛上看到有人推荐一本《ARM与X86》的书,当时马上下下来了,并且当晚看到两点多就把它他看完了(总共也才数十页)。感觉写的不错,在此推荐下搞IT的人都读读,尤其是搞体系结构的同志更应该读读:

该书作者是王奇,弯曲时空的陈怀临进行了整理并发布,该书主要讲了X86以及ARM的发展史,在书中也顺带讲了极少数其他处理器的事情,比如一代传奇处理器alpha,MIPS等。该书主要分为两个部分,第一部分介绍X86,第二部分介绍ARM。

在第一部分中,主要讲Intel是如何凭借向前兼容这个法宝从一个弱者逐渐战胜摩托罗拉,IBM,MIPS等强大的对手的,并且又是如何因为向前兼容这个包袱导致Atom处理器设计失败的。

在第二部分中,主要讲了ARM的整个发展史,讲了ARM的数次起落,数次易主,最搞的是ARM曾属于Intel,最搞的是,Intel能有机会扼杀ARM,(经过某同学指正,前面的一段话有误,删去)但是Intel对其进行技术输入后(Xscale处理器的设计技术)将其卖出,最终亲手培养了在移动处理器这个强大的对手,搬起石头砸了自己的脚。

最后,给一个《ARM与X86》这本书的下载链接:

写到这里,突然又想到另外一本书,一本google 研究员吴军写的一本关于IT历史方面的书,那书写的真不错,差不多可以认为是IT领域的史记,也在这里推荐下,下面的是那本书的引言:

近一百多年来,总有一些公司很幸运地、有意识或者无意识地站在技术革命的浪尖之上。一旦处在了那个位置,即使不做任何事,也可以随着波浪顺顺当当地向前漂个十年甚至更长的时间。在这十几年间,它们代表着科技的浪潮,直到下一波浪潮的来临。

从 一百年前算起,AT&T 公司、IBM 公司、苹果公司 (Apple)、英特尔 (Intel) 公司、微软 (Microsoft) 公司、思科公司 (Cisco) 公司、雅虎 (Yahoo) 公司和谷歌 (Google) 公司都先后被幸运地推到了浪尖。虽然,它们来自不同的领域,中间有些已经衰落或者正在衰落,但是它们都极度辉煌过。它们都曾经是全球性的帝国,统治着自己 所在的产业。

这些公司里面大大小小的人在外人看来都是时代的幸运儿。因为,虽然对于一个公司来讲,赶上一次浪潮不能保证它长盛不衰;但 是,对于一个人来讲,一生赶上这样一次浪潮就足够了。对于一个弄潮的年轻人来讲,最幸运的莫过于赶上一波大潮。要预测未来是很难的,但是看看过去和现在, 我们也许能悟出一些道理。我愿意借谷歌黑板报的空间,将我这些年来看到的和听到的人和事拿出来与大家分享。我会谈一谈我对每次浪潮的看法,对上述每个公司 的看法,以及对其中关键人物的认识。在极度商业化的今天,科技的进步和商机是分不开的。因此,我也要提到间接影响到科技浪潮的风险投资公司,诸如 KPCB 和红杉风投 (Sequoia) 以及百年来为科技捧场的投资银行,例如高盛 (Goldman Sachs) 等等。

附上IT史记《浪潮之巅》的下载地址:

最后附上从《ARM与X86》封面图,ARM与Intel的roadmap:

ARM and X86 roadmap

Mapreduce简介

2011年4月21日 sigma 6 条评论 9,318 views

今天在Opps里和grapeot,Ouyang等人扯到了mapreduce,感觉这东西还是挺有意思的,并且和分布式系统等体系结构领域有关,我于是花了点时间去看了下(主要是看wiki以及google员工在MIT讲课的课件),在这里对mapreduce做个简要介绍。

Mapreduce是google提出的一种编程模型,该模型最早在OSDI(一个操作系统领域顶级会议) 2004上提出。其主要是用于大规模数据并行处理(如排序,索引),不过现在貌似机器学习(machine learning,ML)上用的也挺多的。其主要有两个步骤,一个是Map(可译为分发,映射),一个是reduce(可译为化简,回收,合并等),这两个概念都是从函数式语言借来的。Map和reduce的两个步骤主要工作如下:

"Map" step: The master node takes the input, partitions it up into smaller sub-problems, and distributes those to worker nodes. A worker node may do this again in turn, leading to a multi-level tree structure. The worker node processes that smaller problem, and passes the answer back to its master node.

Map阶段主要是主节点把输入划分成一些子问题,并且分发给工作节点。而工作节点有可能继续重复这一工作,直到划分够细,子问题能在规定的时间内有一个工作节点完成为止,形成一个树状结构。下一层的工作节点会将完成的计算结果传输给上一层的(主)节点。

"Reduce" step: The master node then takes the answers to all the sub-problems and combines them in some way to get the output — the answer to the problem it was originally trying to solve.

Reduce阶段把所有的问题,所有的答案按一定的方式组合化简归并,最终形成最初问题的答案并输出。

在这两个阶段中,Map阶段分配后的并行度是很高的,因此很适合一些数据处理的应用,比如说对大量网页文件进行建立索引,因为这时候可以直接把数以亿计的网页直接按数G分给各个工作节点处理(貌似google一般是以64M为单位的)。而reduce阶段的并行度相对不高,但是由于可以层层的reduce,并行度其实也很可观。

为了提高可靠性,每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔,主节点(类同Google File System中的主服务器)记录下这个节点状态为死亡,并把分配给这个节点的数据发到别的节点。

另外,可以看出,其实这个并行模型和分治法非常像,基本思想几乎一致,感觉是一个基本思想(分治)在大规模数据处理中的一个应用和具体化。

也许也正因为这个原因,mapreduce从技术上没有任何先进之处,感觉其火起来很大一部分是由于云计算泡沫的原因,因此一些传统的数据库领域的人甚至认为其是一种倒退,因为:

  1. 在大规模的数据密集应用的编程领域,它是一个巨大的倒退
  2. 它是一个非最优的实现,使用了蛮力而非索引
  3. 它一点也不新颖——代表了一种25年前已经开发得非常完善的技术
  4. 它缺乏当前DBMS基本都拥有的大多数特性
  5. 它和DBMS用户已经依赖的所有工具都不兼容  

顺便说件大傻帽grapeot碰到的傻帽事:

    求一个图的连通片个数,7M个节点70M条边,在Amazon Elastic EC2上开了16个small instance跑了4个半小时就跑完了。然后我写了个串行的版本,在自己的笔记本上跑。。。90秒。。

    这件事说明,任何事物都具有适用性,反过来说,任何事物都有存在的理由。想用万能的通用结构或者模型高效解决任何问题是不可能的,因此,多样性结构是高效的必要条件,因为应用是多样的。

不过,相对与传统的牛叉的各种数据库技术,mapreduce能活的这么好,主要原因是:传统的数据库太难用了,传统的并行编程模型也太难用了,而mapreduce简单,因此简单的,易用的往往是最好的,这也是windows能够打败linux的原因之一。而历史上,野蛮的蒙古人就用简单的暴力几乎整个地球上所谓的文明人!

最后,附一张来自google在MIT的课件上的图,来形象的描述mapreduce:

mapreduce示意图

参考:

维基:http://en.wikipedia.org/wiki/MapReduce

google lab:http://labs.google.com/papers/mapreduce.html

MIT MapReduce course:http://sites.google.com/site/mriap2008/home

另附:MapReduce: 一个巨大的倒退的链接(点前面标题)

无觅相关文章插件,快速提升流量