请选择 进入手机版 | 继续访问电脑版
Mozilla

火狐社区

登录    注册

用新浪微博连接 QQ互联

进入量子纪元——Firefox为什么又变快了?未来如何更快?

yingliu Mozilla员工 发表于 2017-12-27 11:20:27 | 显示全部楼层 [复制链接]
8 5447
本帖最后由 yingliu 于 2017-12-27 11:23 编辑

有人已经注意到火狐浏览器又变快了。

Sara Soueidan 的推特上关于火狐浏览器试运行版变快的消息:


过去七个月里,我们不断地把浏览器引擎里一些重要部分尽快换掉,并在火狐里引入了 Rust 语言和 Servo 引擎组件。此外,我们还对代码基进行了一次性能突击大检查,寻找各种性能问题,无论是明显还是不明显的。

这个项目我们就称之为量子(Quantum)项目,而新生的火狐浏览器量子版(Firefox Quantum)将在明天第一次全面发行。

喷射发动机的正投影图:


但这并不意味着我们的工作已经完成了,未来的火狐将会变得比如今速度更快,响应更迅速。

那么,我们看看怎么样使火狐又能快起来,还有哪些方面可以使它变得更快吧。

用粗粒并行运算技术(coarse-grained parallelism)打基础

过去十年里电脑硬件改变了许多。要让浏览器速度更快,我们就需要利用这些硬件的变化。

我们不是第一个这样做的。Chrome 浏览器刚问世时速度就比火狐更快,反应也更快。原因之一就是 Chrome 的工程师那时就看到了硬件正在发生的变化,并开始更好地利用新型硬件。

Chrome 浏览器展望粗粒并行运算技术的未来:


以前有一种新型的 CPU 越来越普遍。这种 CPU 拥有多个核,所以能够同时并行处理多个任务,而任务之间互不干扰。

当然这也会造成一些麻烦。并行运算可能会带来一些细微的差错,很难发现也很难纠正。比如,如果双核需要给内存中的一个数字加一,不特别小心处理的话,一个核很可能把另一个核的操作结果覆盖掉。

双核竞速图:


要避免这类差错,有一个相当直接的方法:只要保证正在进行的两部分不用共享内存就行了。把程序分割成比较大的几个任务,任务之间用不着太多配合,这就是粗粒并行运算技术。

这种粗粒部分浏览器里很容易就能找到,如每个浏览器标签都各有各的工作要做。另外还有网页周围的那个东西——浏览器边框,也可以分开处理。

这样做,每个页面都能以自己的速度同步运行,而不会互相妨碍。即使某个后台标签有一个脚本运行时间很长,也不会阻碍当前标签的任务。

Chrome 的工程师预见到了这种机遇,我们也是。但实现这一步,我们走过的路更曲折些,因为我们已有的代码基需要经过计划、想好如何进行分割后才能利用好多核技术。

Firefox 浏览器展望粗粒并行运算技术的未来:


虽然花了不少时间,但是我们还是做到了。通过电解(Electrolysis)项目,我们最终将默认运行模式改为多进程模式,并对所有用户都有效。而量子项目以及其它几个项目则进一步改善了粗粒并行运算技术的应用。

粗粒并行运算技术时间表,包括首个量子版本之前的电解项目、量子合成器(Quantum Compositor)项目以及之后的量子文档对象模型(Quantum DOM)项目:


电解(Electrolysis)项目

电解项目为量子项目打下了根基。它首次采用了一种多进程架构,和 Chrome 当年采用的类似。因为这个变动相当大,引入的过程很缓慢。我们从2016年开始,先在小组用户范围内进行测试,到2017年中期才初次向所有 Firefox 用户推出。

量子合成器(Quantum Compositor)项目

GPU进程:


量子合成器项目将合成器移到了它自己的进程上,其最大的好处就是使火狐更稳定。独立的进程就意味着即使显卡驱动崩溃,Firefox 也不会整个崩溃。不但如此,这个独立的进程也使火狐反应更快。

量子文档对象模型(Quantum DOM)项目

即便每个内容窗口都被分配到不同的核上,并且都拥有独立的主线程,每个主线程仍然有很多任务要完成。有些任务要比别的任务更重要,如响应按键的任务比垃圾回收任务重要。靠量子文档对象模型项目,我们找出办法设定这些任务的优先级别,这让火狐反应更迅速。这项任务的大部分已经落实了,但我们还打算利用一种名叫占先调度(pre-emptive scheduling)的技术,把这项任务进行得更深入些。

依靠细粒并行运算技术(fine-grained parallelism)充分发挥硬件功能

然而为未来考虑,我们要做的还不止是粗粒并行运算。

Firefox 展望细粒并行运算技术的未来:


粗粒并行能更好地利用硬件,但并不能充分利用硬件。把网页分配给不同的核处理时,有些核并没有什么任务可处理,所以只能闲置在那里。与此同时,因为一个网页一个核,所以打开单个新网页所花的时间并不比单核 CPU 少。

内容窗口分配到不同的核上:


单个新网页加载时最好能够动用所有的核去处理,这样加载才能完成得更快。

但粗粒并行技术无法把一个核的任务再分割出来给另外的核,因为这种技术的任务之间没有界限。

有了细粒并行技术,我们可以把大的任务分成小的任务单元,然后发送到不同的核上去。比如,在 Pinterest 网站上可以把各种收藏项目分开,然后给不同的核处理。

细粒分割各核任务:


这样做不仅能像粗粒并行一样帮助减少延迟,还能提高纯速度。因为加载任务由所有的核共同承担,网页加载得更快。核的数量越增加,网页加载就越快,有多少核就有多快。

我们之前看到了这一点,意识到它是未来的趋势,但并不完全清楚该怎么做。因为要快速运用细粒并行技术,一般都需要在核之间共享内存。但那样就会造成刚才提过的数据竞速问题

但我们也明白浏览器必然要经过这个改变,所以我们开始投入资源进行调查。我们创作了一个避免数据竞速的新语言 Rust,然后又创作了一个浏览器引擎 Servo,能充分利用这种细粒并行运算技术。通过调查,我们证明了这是行得通的,而且实际上可能速度更快、差错更少。

细粒并行运算技术时间表,包括量子初版前进行的量子 CSS (Quantum CSS) 项目和量子渲染(Quantum Render)项目,以及之后可能进行的其它项目:


量子 CSS (Quantum CSS 又名 Stylo) 项目

完工的核从活太多的核那里偷活干:


有了 Stylo 功能,就可以利用所有的 CPU 核全面并行运算 CSS 样式。Stylo 功能用了一种叫偷活(work stealing)的技术,高效地把工作分配给不同的核,使所有的核都有活干。有了这个技术,实际时间就等于 CSS 样式运算所需时间除以 CPU 核的数量,所以速度直线上升。

量子渲染(Quantum Render, 以 WebRender 渲染器为重点)项目

图中四个不同线程,包括处于主线程和合成器线程之间的后台渲染(Render Backend)线程。后台渲染线程将显示列表转成批量的成像函数调用:


硬件还有一个高度并行化的部分是 GPU。GPU 有几百或几千个核。当然要保证这些核尽量满负荷工作,有很多方面要计划。那就是 WebRender 渲染器的作用

WebRender 渲染器将会在 2018 年得到落实,到时新式的 GPU 将会发挥作用。与此同时,我们还从另一个角度解决了这个问题。高级分层(Advanced Layers)项目修改火狐现有的层系统,使之支持批量渲染。这优化了火狐目前的 GPU 使用模式,效果即刻显现。

还有呢???

我们还考虑了渲染通道有哪些其它部分可以从这种细粒并行运算技术中获益。在接下来的几个月里,我们会更仔细地研究,看还有哪里可以用到这些技术。

争取不断提速,永不减速

这些大的架构变动是我们之前已经想好要实施的。除此之外,我们一不注意,就有一些性能方面的差错混进了代码基里。

于是,我们量子项目又创建了一个分部来修复差错,基本上就是一个浏览器性能突击检查队,发现问题、部署人手、进行修复。

量子流(Quantum Flow)项目时间表,上升斜弧:


量子流(Quantum Flow)项目

担任此次突击任务的就是量子流项目团队。他们把注意力集中在某些非常特定且重要的用例上,而不是集中在某个子系统的整体性能上。比如加载社交媒体新闻在火狐上的反应速度比其它浏览器慢,他们整队合作分析出原因。

量子流项目给我们带来了许多性能方面的巨大提升。在这个过程中,我们也开发了几个工具,建立了几个流程,将来寻找追踪此类问题就变得更容易。

那现在量子流项目怎么样了?

这个项目每次都只锁定一个关键用例,再集中处理。我们采用的这个流程非常成功,以后准备把它化为工作流程的常规部分。为了做到这一点,我们正在完善各种工具,这样就不必再等专家突击搜寻问题了,而可以让整个组织中来自各部门的更多的工程师都可以发现问题。

但这种措施有一个问题,一个用例优化的同时可能会另一个用例就无法优化。为了防止这种事发生,我们新加了许多追踪信息,包括改进持续集成自动运行性能测试,用遥测技术追踪用户体验,以及差错内部的回归管理。这样,我们希望火狐量子能不断变得更好。

明天只是开始

对我们这些 Mozilla 的人来说,明天(原文发于11月13日,11月14日是 Firefox Quantum 发布的日子)是个重要的日子。为了让火狐提速,我们在过去一年里一直在努力奋斗。但那也只是个开始。

在接下来的一年里,我们会继续使性能方面有新的提高,希望能再与大家分享!

要试用 Firefox 浏览器,可以去下载 Firefox Quantum 发行版开发者专用版,保证用到最新版本。

关于作者

Lin Clark
Lin 是 Mozilla 开发者事务(Developer Relations)团队的工程师。她用 JavaScript,WebAssembly,Rust,和 Servo 进行了一些修补工作,并为代码画了漫画。
code-cartoons.com
更多 Lin Clark 写的文章

本文转载自:众成翻译
译者:chaussen
审校:betsey
链接:http://www.zcfy.cc/article/4648

原文

评分

参与人数 3声望 +8 收起 理由
FFsaber + 2 很给力!
挽尊小优优 + 2 666
德亮Leslie + 4 淡定

查看全部评分

萧先森 社区新人
发表于 2017-12-27 14:52:59 | 显示全部楼层
速度提升上去了又怎么样呢?现在css好多都不支持。希望改进,兼容性做到谷歌浏览器哪有就好了,否则只能建议用户使用谷歌跟IE,版本越新css兼容性越差
隐元 老狐狸
发表于 2017-12-28 06:38:47 | 显示全部楼层
mozilla的新科技层出不穷!
FlamingFox 老狐狸
发表于 2017-12-28 20:59:03 | 显示全部楼层
萧先森 发表于 2017-12-27 14:52
速度提升上去了又怎么样呢?现在css好多都不支持。希望改进,兼容性做到谷歌浏览器哪有就好了,否则只能建 ...

说的有理,光有速度是不够的。除了你所说的这些外,新版的火狐还要拥有极强的安全防护能力,否则,这个新版的火狐又要回到原来的发展老路了。
stain 小狐狸
发表于 2017-12-28 21:29:05 | 显示全部楼层
引擎图挺有创意的
310971373 狐狸精
发表于 2017-12-29 09:18:14 | 显示全部楼层
量子时代要来喽,吼吼吼 ~~
挽尊小优优 狐狸仔
发表于 2018-1-5 04:33:59 | 显示全部楼层
不会画漫画的工程师不是好程序员(
Say花火 社区新人
发表于 2018-1-22 13:46:47 | 显示全部楼层
那个双核竞速图有人能解释一下么
Say花火 社区新人
发表于 2018-1-22 16:20:08 | 显示全部楼层
为什么是覆盖而不是再加一,所谓错误是不是说这个过程重复造成了资源浪费啊
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表