双芯记-3

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 双芯记(A Tale of Two Chips)

  1. 双芯记(A Tale of Two Chips)
  2. 双芯记-2
  3. 双芯记-3

* 塞翁失马:Transmeta昙花一现

时间来到九十年代中期,这时的RISC阵容已经认识到要击败x86,仅仅在一纸SPEC性能结果上领先并无意义,最大的障碍来自软件部分-正如John Hennessy戏言:软件就是x86代码(”Everyone want to running x86 code, Because that’s all what software was”)。所以兼容x86代码成为RISC设计者的主要目标之一,比如DEC的FX!32项目,IBM传说中的PowerPC615项目,Sun的SoftWindows等,而日后在市场上产生重大影响的则是另外一家神秘的初创公司。
这时,当年和Patterson一起撰写RISC论文的Dave Diztel已经辗转来到Sun领导SPARC的开发。Sun也在内部开展了一个研究项目,就是分析在Sparc处理器上采用Emulation等技术运行x86代码到底能达到什么性能。这一研究得出的结论却不乐观-要高效运行x86代码,现有的RISC架构有许多天生的限制。于是Diztel等决定创办一个新的公司,从头开始设计硬件,专门针对x86代码的emulation优化架构,所以Transmeta在1995年成立。
但是,Transmeta初期的融资并不顺利,尤其是向风险资本推销Transmeta的核心技术“动态二进制翻译”时,这样一个艰涩的学术名词根本吸引不起注意,于是经过多次头脑风暴,技术团队决定将这一技术命名为“变形虫”(Amoeba),这一次,在没有任何实质技术改变的基础上,却引起了风险资本的兴趣并成功完成资金募集。这和王靖雯改名王菲一个道理-一个好的艺名不可或缺,由此看来,技术圈和娱乐圈有时还是非常相像的。
历经五年的研发,这个引起广泛关注(大神Linus也位于阵中)但又保持神秘的初创公司Transmeta终于在2000年初揭开面纱,发布了第一代产品,实际内部已经经过两代开发,其中的低功耗和动态二进制翻译实现x86兼容两项技术惊艳全场,在同等频率的情况下,二进制翻译带来的性能损失仅25%,面积略微增加(包括集成北桥功能等),而功耗仅为Intel移动处理器的三分之一,简直就是太美好了而不能让人相信。而此时的整个Intel正沉浸于和AMD的频率竞赛-这一极端策略的后果就是Pentium 4,但巨人的反应迅速而有效,在以色列启动专为移动市场优化的Pentium M的设计同时,六个月之后就推出了一系列重新打造的移动处理器,但主要提高来自说明书,例如使用duty cycle仅为20%的测试程序得出来的平均功耗来取代往常的TDP标称处理器功耗,将根据电源是否来自电池而简单调节处理器两种工作电压的“动态”SpeedStep技术来等同于根据负载真正动态调节电压和频率的LongRun等等,当然还有杀手锏-降价。
可惜的是,Transmeta在关键时刻犯下了一个致命错误,在将制造工艺向130nm演进时,在由IBM转向TSMC的过程中出现问题,导致数个月的产品供应断档,错失宝贵市场机会窗。虽然借科技股泡沫成功登录Nasdaq,但终究无可奈何花落去,在2009年,耗费12年时间,6亿美金和无数人心血的公司的最后物理资产-包含所有软件和硬件设计代码的数台服务器-被黯然拍卖。虽然最终失败,但Transmeta这一精彩一击给后来者留下了许多值得借鉴之处:
1,商业上,证明了Intel的地位也并非不可动摇的,但面对这样的对手时,仅仅一记重拳只会唤醒对手,需要的是一系列的组合拳;而且对于一个初创公司来说,几乎没有犯错的机会。
2,法律上,在没有架构授权的基础上实现兼容是一个可以解决的问题,而且Transmeta首先发起了对Intel的专利诉讼,并最终获的$250M的赔偿。
3,技术上,将动态二进制翻译和动态压频调节带上了一个新的高度。
而经历过这一次战斗,为移动计算而设的以色列团队开始崭露头角,Intel最终也在笔记本市场建立了强大的迅驰品牌。而Ditzel本人,现今则已披上Intel军装,官拜架构集团VP。

参考资料:
1,“A 25 year Perspective on Binary Translation”, David Diztel演讲,UWTV
2,“Transmeta’s Magic Show”, IEEE Spectrum
3,Microprocessor Report系列报告
4,Wikipedia相关条目

(2个打分, 平均:5.00 / 5)

雁过留声

“双芯记-3”有23个回复

  1. James 于 2010-11-12 7:14 上午

    Transmeta 最后卖给谁了?

  2. spike 于 2010-11-12 8:10 上午

    嗯,其实王菲才是王菲的真名,王靖雯是曾经的艺名。。。
    这个系列第二篇跟第一篇隔得好久啊

  3. 删吧 于 2010-11-12 3:02 下午

    intel 另一个david是实际的掌门人.

  4. 看客 于 2010-11-12 11:32 下午

    工艺发展到一定程度以后,CISC和RISC之间的那点区别早已经不重要,X86多出那点复杂度需要的晶体管开销不算什么了。Transmeta从一开始就注定只能走低功耗路线,不可能去强求性能。但Transmeta搞低功耗却选择了X86,追求性能却选择了二进制翻译的优化。这种技术路线在市场上能成功才奇怪了。

    回想当初安腾那场豪赌,我的直觉二进制翻译来优化性能比设计安腾的编译器还困难。

    其实决定市场是否成功的重要因素是把应用吃透,瞄准应用做技术,最近GPU在高性能计算领域的成功值得思考。

  5. 陈怀临 于 2010-11-12 11:45 下午

    今天我与几个老外争论cache的设计。我提出:cache要application和OS都能控制,而非经典的pseudo-LRU。老外基本上没听懂。比较郁闷。感觉对系统的理解比我差了N个level。。。

  6. 沙加 于 2010-11-13 5:59 上午

    5.陈怀临 于 2010-11-12 11:45 下午
    今天我与几个老外争论cache的设计。我提出:cache要application和OS都能控制,而非经典的pseudo-LRU。老外基本上没听懂。比较郁闷。感觉对系统的理解比我差了N个level。。。
    ————————————
    首席的观点,上次的多核峰会上也听过了。最近经常在想一个问题:将来的kernel会越做越薄,很多功能会由硬件来代劳,而有些原本需要kernel来控制的东西,也许会由应用层来代劳。但是这样一来,我们这些做kernel的还能干啥?只有转行做芯片去了

  7. ether 于 2010-11-13 7:01 上午

    Transmeta 这种协同设计虚拟机其实挺好玩的~看看能不能把Transmeta底下测vliw改成动态重构的FPGA~

  8. James 于 2010-11-13 8:22 上午

    :-) 首席的观点有点类似与 exokernel了(提出已经15年多了). 就是 kernel 要小, 然后 app 要有机制 去控制 底层的 如cache 一样的东西. 这样才能做出来 app-优化的 系统. 这样的系统设计 对于特定应用系统很有帮助.

    其实旧的酒在新的环境下同样会发出醇香. 虚拟化已经证明了这一点.

  9. 陈怀临 于 2010-11-13 10:44 上午

    Transmeta可惜了。首席刚入硅谷时,接过一个noon-sun的活,给人写网卡驱动,玩uboot等。。。。moon-light:晚上去打二分工;noon-sun:中午出去干活兼职。 旁边就是Transmeta. 没事就看见Linus在那里晃。。。

  10. 删吧 于 2010-11-13 10:49 上午

    cache这东西,没有具体应用,空谈无用。
    noon-sun: 中午还能出去干活??驾校教练?

  11. 删吧 于 2010-11-13 10:51 上午

    看看这几年所有设计过的cache,千奇百怪,跟经典的教科书上的相差大了。

  12. 陈怀临 于 2010-11-13 1:09 下午

    Page Coloring为什么进不了Kernel Tree。本质原因就是:App,OS,CPU的显示分割。 Linus一句在多SET/Associative的cache情况下,性能提高不明显,Page Coloring就被枪毙了。。。

    我觉得系统软件在多核的冲击下,到了turn point了。。。

    当然,做OS的startup没啥意思。不挣大钱。。。

  13. 理客 于 2010-11-13 1:36 下午

    在cache比较小的情况下,意义不大,因为不得不控制太复杂就不美了,效果也会大打折扣,我想这是之前业界许多大拿研究后的结论:开放cache给APP太复杂,性价比的价值不够大。至少在2005年前的商用CPU,其cache的size都太小
    如果cache比较大,就简单粗暴一点,划一块指令cache和一块数据cache给APP专用,其他的系统用,当然之间的通讯和管理还要定义一下,这里的前提是cache要够用,否则也缺少商用价值,如果系统能提供这样的功能,我看会有一些人喜欢,做CPU cache DIY的乐趣
    所以确实需要与时俱进,谁能在90年代想象10年后一个小小smart phone比当年的一台PC还要强几倍,而此时整个APP的和软硬件系统的变化,更是对得起跨世纪的时间。所以无论是旧酒还是首席的新瓶,在十二五期间都可能startup

  14. KISS 于 2010-11-13 5:39 下午

    Transmeta的专利在Intellectual Venture Funding手中,芯片和软件就不知道被谁买走了,要是Nvidia就有意思了。

    我也同意首席turn point的观点,以前的软件,不用做太多性能优化工作,只需要等几个月下一代频率更快,Cache更大的处理器芯片就出来了,而现在这条路到头了。

    首席要给软件开发者提供配制替换算法的功能,这个要求有点变态啊。。。:) 系统性能分析能作到这个粒度。估计性能提升极其有限,工作量又巨大。不过很多处理器一直有cacheline lock等功能,不知道软件开发实际应用的多不多。

  15. liang 于 2010-11-13 8:15 下午

    transmeta 内核是128 way vliw core,不是传统意义的superscale risc,不要老是risc,cisc

  16. liang 于 2010-11-13 8:22 下午

    Transmeta的核心技术“动态二进制翻译”是否是
    x86指令到tranmeta vliw 指令的编译器,做vliw
    core 易,vliw编译器难

  17. xycfwrj 于 2011-02-05 9:21 上午

    我做过不少dsp代码优化,关于cache,我也觉得让app参与控制会效率更高。
    最极端的情形如overlay,把cache当l1用,事先就知道要把哪些内容放入l1。
    反正如果我的critical section里的Loop如果cpu占用率非常可观,而每次Loop取数又基本上全是miss(这种情况其实很常见)。这种情况touch的效果都不会太好,相反把cache当l1 ram用,而事先用dma把数据搬入l1,效率一般会高好几倍。
    另外,代码在load某个数的时候,其实一般情况很早就知道数的地址了,完全可以提前放到cache里。

  18. cloud 于 2011-02-06 6:43 上午

    目前有一些简单的cache应用。比如intel有一些api可以在代码中预取指令到cache。不过感觉对编程的要求更高了,一旦用不好可能反而效果会更差。

  19. Lucifer 于 2011-02-06 8:16 上午

    intel是有手动prefetch的指令

  20. KISS 于 2011-02-06 5:32 下午

    所以DSP也叫“Destroy Software Programmable”。。。

    请教下网络大虾,PowerPC的那堆cache控制指令在应用开发中使用多么(lock和touch等等)?

  21. xycfwrj 于 2011-02-11 7:35 上午

    ti c6000 dsp可以通过写寄存器实现cache freeze,touch是通过汇编实现(就是产生一系列cache miss pipelined,相比没有pipeline的cache miss消耗更少的cycle数)。
    cache freeze我用得非常少,touch用得也不太多,效果不是很好。

  22. bend,or 于 2012-05-06 6:03 上午

    伤心记–一部上弯曲看文章看到烂尾的血泪史

  23. bend,or 于 2012-05-07 4:59 上午

    抱歉,本来想幽他一默,仿照双城记总结一些在tektalk上看到的没有完结的系列,可惜功力不够,又怕贻笑大方,罢了。双芯记系列很是吸引,作者起了个大纲,文笔细腻,却没有完成,可惜可惜。类似的还有楼上19楼 Lucifer 的大作:英特尔Sandy Bridge 处理器分析测试系列,应该还没完结,都搜索不到下文了,哈哈。