说明:

本文为博主自己翻译,水平有限,仅供参考。

  1. 画删除线部分我也不知道咋翻译。
  2. 加粗部分为论文重点表达。
  3. 红色部分为扩展链接
  4. 浅蓝色部分为博主个人理解

概要:

互联网网页浏览已经达到了一个关键的转折点。与桌面浏览器相比,用户越来越依赖移动Web浏览器访问Internet。与此同时,过去十年中网页的复杂程度增加了十倍以上。移动浏览和无用网页的快速渗透意味着未来对高性能移动设备的需求不断增长,以确保持续的最终用户浏览体验。未能提供满足严格限制条件的网页可能会直接转化为网页放弃,或者对于电子商务网站而言,会带来巨大的收入损失。但是,移动设备有限的电池容量限制了移动网络浏览可以实现的性能程度。在本文中,我们展示了具有大/小内核的异构系统的优势,每个内核具有不同的频率,以实现高性能和高能效之间的理想折衷。通过基于最热门的5,000个网页的不同网页原语的详细表征,我们构建了估计网页加载时间和能耗的统计推断模型。我们表明,利用这些预测模型,我们可以使用理想的核心和频率配置来识别和安排网页,从而最大限度地降低能耗,同时仍然满足严格的截止限制。真实的硬件和软件评估表明,与面向性能的硬件策略相比,我们的调度方案实现了83.0%的节能,同时仅违反了4.1%的网页的截止延迟。针对更智能,由OS驱动的动态电压和频率调整方案,它可以同时实现8.6%的节能和4.0%的性能提升。

介绍:

移动网络浏览正在改变互联网流量的平衡。 最近的统计数据显示,用户现在花费50.2%的时间使用网络浏览器[1],导致移动互联网流量超过世界主要地区的桌面互联网流量[2]。 移动设备和社交网络的激增正在推动这一趋势。 同时,网络货币化(即每用户的平均收入)在移动设备上仍然比桌面设备低5倍[1]。 媒体和广告提供商正在利用这一机会,从而使移动网络浏览的速度更快。
      伴随着移动市场的临界质量,网页在过去十年中变得越来越复杂和计算密集。 例如,图1显示了过去11年中www.cnn.com的网络传输时间和内容处理时间。 我们从Internet Archive [3]存档的每年中随机选择一张图像,并测量连接到100Mb / s以太网的双核ARM Cortex-A9移动处理器。 图中的趋势线表明,从计算与网络的角度来看,网页计算强度相对增加了十倍。
      随着网页计算强度的增加,人们越来越关注网页加载时间。 最近的一项调查得出的结论是,用户倾向于放弃在某个截止延迟内没有加载的网页[4]。 电子商务网站的相关统计数据显示,网页加载延迟1秒可能导致每年250万美元的销售损失[5]。 截止延迟的硬约束意味着对高性能移动设备的需求。 但是,能源限制限制了我们在移动设备上实现桌面级计算能力。 因此,面临的挑战是确保高性能,同时最大限度地降低能耗。 由于具有较大的调度空间,具有大/小内核的异构系统均具有DVFS功能,可在性能和能量之间进行灵活的权衡.
      在本文中,我们展示了大/小异构系统通过调度实现理想性能和能量权衡的好处。 我们利用关键洞察力,不同的网页包含负载时间和能耗的强烈差异。 利用这一事实,我们提出了网页感知调度,这是一种探索网页差异的机制,并使用不同的核心和频率配置智能地调度网页,以最小化能量,同时仍满足截止约束。
      具体而言,图2显示了在1.2 GHz下加载在Cortex-A9上的六个热网页的加载时间和能耗。 我们观察到网页的差异很大。例如,www.cnn.com加载大约需要6秒钟,同时消耗8.9焦耳的能量。 相比之下,www.craigslist.org加载时间不到1秒,而仅消耗1.6焦耳的能量。 详细的表征表明,这种差异是固有的结果,网页基元的差异(例如,HTML,CSS)。 回归建模技术捕获固有的网页差异,让我们估计不同核心和频率组合下的网页加载时间和能耗。
      在估计的基础上,我们预测理想的执行网页的核心和频率,并相应地安排它们以满足最节能的截止约束。 总之,我们在本文中做出以下贡献:

  1. 我们探索用于移动网络浏览的大/小系统的能量延迟权衡,并展示潜在的好处(第4节)。
  2. 我们通过表征和量化网页原语的不同方面来确定网页差异的根本原因(第5节)。
  3. 我们表明,可以通过回归模型预测网页加载时间和能耗(第6节)。
  4. 我们将演示如何通过建议的网页感知调度有效地利用大/小系统(第7节)。

基于ARM Cortex-A9和A8处理器的合成大/小系统的测量硬件结果表明,与面向性能的硬件策略相比,网页感知调度实现了83.0%的节能,同时仅违反了 关闭延迟4.1%的网页。 针对更智能的操作系统驱动的DVFS策略,网页感知调度可实现8.6%的能源减少,同时平均将负载时间缩短4.0%。

2.移动网络浏览

我们将解释在移动Web浏览体验期间对最终用户的重要性(第2.1节)。 接下来,我们简要概述了Web浏览器的工作原理,并确定了潜在的计算强度来源(第2.2节)

2.1 移动网络浏览器体验

CA Technologies在2010年进行的一项神经学研究得出结论,糟糕的网络浏览体验可能导致“网络压力”导致用户使用竞争对手的网站或完全放弃交易[4]。 谷歌工程师测量了这种效应,称“400毫秒延迟会导致搜索量下降0.44%”[6]。 全球有超过22.7亿的互联网用户[7],这种看似微不足道的下降可以转化为大约998万不满意的用户。
      移动浏览体验最重要的标准是网页加载时间。 这是放弃网页的主要原因[5]。 统计数据显示,47%的移动网络消费者希望网页在2秒或更短的时间内加载,超过该截止延迟,每增加一秒,使用率将下降6.7%, 4秒的网页加载时间可以使网页放弃增加25%[5]。
      此外,在移动网络电子商务迅速成为进行在线销售的新手段的世界中,错过截止加载时间会对机构产生重大的财务影响[1]。 最近的一项研究得出结论认为,每天产生10万美元收入的电子商务网站每秒钟的网页负载延迟每年损失高达250万美元[5]。

2.2 Web浏览器体系结构

Web浏览器体系结构的核心是渲染引擎,它处理从服务器返回的网页文档并在屏幕上显示它们。 加载网页后,用户可以通过JavaScript动态地与网页进行交互。 在本文中,我们只关注渲染引擎,因为它是移动Web浏览体验的第一个决定性因素。 动态网页交互超出了这项工作的范围,我们将读者推荐给Sec。 8讨论JavaScript。 使用图3,我们提供了Web浏览器体系结构的概述。
      渲染引擎从解析HTML和CSS文档开始。 HTML包含通过标签组合的网页的文本和整体骨架,每个标签与零个或多个属性相关联。 在解析HTML文件的同时,呈现引擎动态地构造DOM(文档对象模型)树数据结构,其中每个节点对应于HTML标签,属性或文本的一部分。 DOM树可以被视为网页结构的抽象和简洁表示。
      CSS是CSS的补充,它通过一组样式规则确定网页的视觉样式信息,每个样式规则都有一个选择器和一组属性。 每个规则旨在选择一个或一组HTML标记来应用属性。 在解析期间,呈现引擎提取CSS规则并构造相应的数据结构。
      给定DOM树和CSS规则,样式解析模块通过构造渲染树来确定网页的样式信息(例如,颜色,字体)。 渲染树是网页的可视化表示,每个节点对应于网页中的一个可视元素。 此后,布局模块在渲染树上操作以计算每个视觉元素在屏幕上的精确坐标。 绘图模块然后遍历渲染树并调用图形库以执行网页的实际显示。

尽管Web浏览器进行了优化以改进样式分辨率,布局和绘画,但它们仍然是最耗时的组件[40]。 这些阶段的计算本身就涉及密集的树操作,难以并行化,硬件资源利用不足,能源效率低下[42,45]。
要和我前面读的那篇论文的关键路径相联系

3.实验设置

实验平台:我们使用Cortex-A9移动处理器作为核心。 所有与大核相关的实验都是在运行Ubuntu 12.04和Linux内核版本3.2.14的Pandaboard ES(rev.B1)上进行的。 它配备了市场品质的OMAP 4460片上系统(SoC),配备了在45 nm工艺节点上制造的双核A9处理器。 A9是一个复杂的无序四宽超标量核心,有八个流水线级。 它有32 KB L1 I / D高速缓存和512 KB二级缓存。 它可以在300 MHz,700 MHz,920 MHz或1.2 GHz下工作,测得的核心电压分别为0.83 V,1.01 V,1.11 V或1.27 V.
      我们选择低(呃)功率的Cortex-A8作为小核心。 在配备有封装A8核心的DM 3730 SoC(OMAP3系列)的BeagleBoardxM开发板(rev.C1)上进行小核实验。 A8处理器也是在45纳米工艺节点上制造的。 它是一个有序的双发布处理器,具有13个流水线级和32 KB I / D高速缓存以及256 KB L2高速缓存。 它可以在300 MHz,600 MHz或800 MHz下工作,测得的核心电压分别为0.94 V,1.10 V或1.26 V.
      网页:我们认为互联网上排名前5,000的网页是由www.alexa.com排名的。 这些网页涵盖了从商业到新闻,购物,搜索引擎等各种网站类别的广泛分布。 由于这些网站的很大一部分没有移动版本,为了公平比较,我们将桌面版本用于所有网页。
      加载时间度量:我们使用Mozilla Firefox 12.0的渲染引擎进行测量,消除了浏览器的引导和关闭效果。 由于我们研究个人网页,因此我们不考虑浏览器的多标签功能。 为了紧密隔离和研究每个网页的行为,我们禁用浏览器缓存以避免污染部分缓存的网页资源。 我们的测量分辨率大约为微秒。
      另外,在图2的推动下,我们只关注计算并通过下载网页并将它们映射到RAMFS来隔离网络和磁盘开销,以将整个工作集保存在内存中。 实际上,之前的工作表明缓存可以在很大程度上捕获工作集,这样网络和I / O的延迟就会大大缓冲[32]。 我们验证但由于空间限制而不包括数据。
      能量测量:我们使用位于片外稳压器模块(VRM)[8]之前的检测电阻来构建功率检测电路(图4),以测量A9的能耗。 使用NI的DAQ单元X系列6366,我们通过同时检测15mΩ的电流分流电阻上的压降以及处理器的VDD来收集功率测量值,两者的速率均为每秒200,000个样本。 我们必须在分流电阻上保持极小的压降,以保持原有的处理器电流消耗特性,因此我们使用带有INA199A1电流分流放大器的Texas Instruments INA199A1-A3EVM模块来实现50倍的增益。 我们的测量分辨率为78μV。 我们使用类似的设置来测量DM 3730 SoC中A8的功率。
      实验测量设置中的逐次运行方差可以忽略不计。 我们通过测量基准网页的10次运行的加载时间和能量差异来验证设置的可重复性。 差异在3%以内。

4.动机:能量延迟权衡

我们希望回答一个基本问题:网页加载是从大/小异构系统中获益吗?例如,处理器能否降低简单网页的频率以消耗更少的能量,但仍然遵守截止约束?最初安排在(耗能)大核心上的网页是否可以迁移到(节能)小核心而不违反截止约束?在对5,000个网页进行详细测量和分析的基础上,我们发现不同的网页需要不同的核心和频率配置,以满足延迟截止约束,同时最小化能量。这表明具有大核心和小核心的异构系统,每个都能够执行DVFS,是非常有益的。为了展示这种异构系统的优势,我们测量了Cortex-A9和A8处理器上所有5,000个热门网页的网页加载时间和能耗。我们在大核和小核上共扫描了七种配置,分别是带有四个DVFS设置的Cortex-A9和带有三个DVFS设置的A8。我们使用代表我们观察到的一般趋势的四个网页开始我们的分析,然后我们扩展我们的分析以包括所有网页的综合集。
我觉得不仅可以根据不同网页的特征指定不同的CPU频率,也可以根据不同的网页特征指定不同的核的大小
DVFS 即动态电压频率调整,动态技术则是根据芯片所运行的应用程序对计算能力的不同需要,动态调节芯片的运行频率和电压(对于同一芯片,频率越高,需要的电压也越高),从而达到节能的目的。
DVFS虽然可以能够根据不同应用程序对计算机能力的不同需求,动态调用芯片的运行频率和电压,但是没有根据网页的结构特征更加细粒度的去调用芯片运行频率和电压,因此,还是有很大的可优化空间。
      代表性分析图5显示了四个代表性网页的能量与延迟图。假设3秒作为网页负载的截止延迟[9],这四个网页具有不同的理想核心和频率配置,以满足截止,同时最小化能耗。例如,www.autoblog.com在消耗最少能量的同时满足截止延迟。一个复杂的网站,在DOM树中有4,235个节点,因此它需要大核心上的最高频率来满足截止延迟。但是,对于简单的网站,例如www.newegg.com,有3,152个DOM树节点,这个配置被过度抽取了。它只需要700 MHz的大核心。这表明某些网页可以从每个处理器核心的不同频率中获益。
      此外,一些网页可以利用大/小核之间的日程安排。如果只有大核心可,www.adobe.com最多只能以700 MHz的频率加载。相反,使用小核心,网页可以使用600 MHz加载,仍然可以满足截止延迟,但是比大核心上的700 MHz消耗的能量少75%。同样,www.baidu.com是一个搜索引擎网站,内容非常简洁,图像不到1 KB。它只需要小核心上的最低频率。
      综合分析我们将分析扩展到全套5,000个网页。图6显示了不同截止延迟的理想核心和频率配置的分布,范围从1秒到10秒,间隔为1秒。图6中的每个区域表示在相应的架构配置下加载的网页部分,具有最小的能量消耗,同时仍然满足截止延迟。我们发现了理想配置的广泛分布,表明了灵活的基线架构的优势,它将大/小核与不同频率混合在一起。
假设紧密的3秒截止延迟[9],具有固定频率的单个核心对于广泛的网页来说是不够的。具有固定频率的最佳单核是600 MHz的小核心。但是,它只能在该延迟约束内加载40.2%的网页。甚至是在不同的截止延迟下的罪恶。具有不同频率的gle核心(大或小)是不充分的。当我们考虑具有不同频率的小核心时,只有74.4%的网页可以在截止延迟内加载。但是,如果我们使用大核心来加载所有网页,那么74.4%的网页在性能与能量之间存在不理想的折衷。此外,一个简单的异构系统同时具有大核和小核,但每个都具有固定频率,这也可能导致某些网页的性能 - 能量权衡不佳。据统计,最佳单频配置在大核上为700 MHz,在小核上为600 MHz;然而,仅具有这两种设置的异构系统导致仅52.1%的网页的理想调度。
      虽然3秒是移动系统的典型截止延迟,但我们还研究了在其他截止延迟下理想配置分布的灵敏度。我们发现不同的截止需求也需要灵活的基线架构。如图6所示,在不同的截止延迟要求下,没有一个特定的配置始终如一地表现良好。例如,尽管宽松的截止点有利于小核心,但在1秒的严格约束下,87.5%的网页不是最理想的。同样地,在严格限制下表现良好的大核心在更宽松的限制下过度抽取;当截止延迟为10秒时,仅需要约3%的网页。
总之,我们发现不同的网页需要不同的理想核心和频率设置,以实现性能和能源效率之间的理想平衡。不同的截止延迟也需要不同的理想配置。因此,我们得出结论,不同的网页可以从一个多功能的异构系统中受益,该系统由大核和小核组成,每个核都能够执行DVFS。

5.网页表征

下面介绍不同网页特征带来的差异
      有效利用大/小系统的好处的关键是了解不同网页上的加载时间和能耗差异的根本原因。在本节中,我们证明了网页差异的根本原因来自结构(HTML)和样式(CSS)信息中固有的“网页差异”。
      我们挖掘了5,000个热门网页,并在微基准网页上应用了真实网页的静态配置和运行时测量的组合。静态配置文件显示,不同的网页具有截然不同的网页基元分布。运行时微基准测试表明,不同的网页基元具有显着不同的执行开销和能耗。由于空间限制,我们只显示30个最热门网页的数据;仍然,网页差异仍然是强烈可观察的。

5.1。超文本标记语言(HTML)

HTML文档由标记和属性组成,它表示为在网页呈现中起重要作用的DOM树数据结构。我们为他们分类分别为标签,属性和DOM树。
      标签在网页中,HTML标签描述了网页的基本功能。我们研究HTML标记的静态和运行时特征。在静态分析下,我们执行HTML标签使用的累积分布配置,并在图7a中显示结果。y轴表示网页中显示的标记的累积百分比。x轴以最热门标签开始,并在所有网页上向最低热门标签下降。只有10%的HTML标签(~14)占整个标签使用量的近90%,表明网页上存在强大的“标签”位置。我们推断Web开发人员习惯使用一些常见的HTML标记。
      为了更好地了解标签在不同网页中的变化情况,我们执行标签混合配置文件,类似于传统的指令混合配置文件。在图7b中,网页按从左到右的标签总数进行排序。我们做了三个重要的观察。首先,所有网页上都有一些热门标签。我们将其余部分组合成图中的“其他”类别。其次,不同网页的标签数量差异很大。例如,www.baidu.com是第五个最热门的网站,只有126个标签,而www.163.com排名第28,有4,135个标签。最后,热门标签在所有网页中并不总是均匀热门;例如,www.baidu.com没有标签,该标签几乎存在于所有其他网页中。
      我们对HTML标记进行加载时间和能量微基准测试,以量化不同HTML标记的运行时行为。我们选择可在网页中直观显示的热门标签子集。每个微基准标记都是一个简单的网页,重复一个特定的HTML标记100次,除了img微基准标记,它只加载一次185 KB的可移植网络图形(PNG)图像([10]中报告的每个网页的平均图像大小)。通过观察微基准网页和空白基线网页之间的加载时间和能耗的差异,我们计算与特定HTML标签相关的执行时间和能耗。除非另有说明,否则我们在以下表征部分中使用相同的微基准标记方法。
      来自Tbl中“标签”类别中显示的微基准测试结果。 1,我们观察不同标签的不同执行开销和能耗。例如,与简单的h3标头标签相比,用于输入字符的input标签需要5倍的执行时间。input标签比h3标签消耗的能量多6.3倍。
      HTML标记的辅助属性是用于界定标记功能并为其指定额外信息的属性。我们执行类似的静态属性配置,观察属性的数量在网页上的显着变化。在所有属性中,与布局相关的属性是最重要的。它们可以导致部分重新布局网页,引入额外的计算。图8显示了影响网页布局的属性的分布。我们观察到跨网页的广泛分布。最后10个网站使用少于100个属性来设置网页样式。因此,它们对网页渲染的干扰较小。
      为了量化不同布局相关属性对网页渲染的干扰,我们进行了微基准测试。Tbl中的“属性”类别。图1显示了结果的代表性子集。除了背景微基准测试外,我们使用一个包含5,000个1×1 HTML表的网页,没有任何属性作为基线。每个微基准标记将一个特定的布局相关属性应用于表,并重复1,000次。背景微基准测试加载影响网页布局的。
与HTML标记类似,属性也表现出不同的执行开销和能量消耗。例如,处理背景属性比处理1,000个cellspacing属性慢19倍,耗能18倍。DOM树DOM树在语义上等同于HTML文档。如第二节所述。 2.2,渲染引擎在DOM树上进行密集操作以进行样式分辨,布局等。因此,DOM树的大小是指示网页处理复杂性的强启发式。

如图9所示,就DOM树节点的数量而言,网页具有截然不同的DOM树大小。我们通过选择两个极端案例(www.huffingtonpost.co.uk和www.baidu.com)来突出显示网页DOM树大小的差异。如图所示,两个网页之间DOM树大小的差异超过1,200倍。
      我们执行微基准测试来量化DOM树大小对负载时间和能耗的影响。我们在每个微基准测试实验中改变DOM树节点的数量,并且我们将网页加载时间和能量消耗与空白基线网页进行比较。Tbl中的“DOM树节点计数”类别。图1显示了结果。微博标记显示执行时间和能量消耗随着DOM树节点的数量而增加。我们观察到DOM树大小与其渲染时间和能量消耗之间几乎呈线性关系。

我们还研究DOM树深度和DOM树中每个节点的平均扇出。但是,我们的分析表明,与DOM树大小相比,这些指标对负载时间和能耗的影响不大。
本文章已经做了很多的实验来证明了哪些因素对加载时间和能耗影响比较大。

5.2。层叠样式表(CSS)

CSS是样式分辨率和布局模块的核心。大多数现代网页都大量使用CSS来指定有关HTML标记应在网页中显示的方式和位置的规则。CSS规则使用选择器来选择HTML标记,并且可以向它们应用不同的属性,例如颜色,格式,浮动首选项等。因此,我们为选择器和属性表征CSS。
      选择器与选择器处理相关的复杂性主要来自两个方面:选择器的总数和选择器的选择模式。CSS选择器的数量是一个重要的指标,因为理论上每个CSS选择器必须与每个HTML标签匹配,以确定网页的样式信息,从而导致O的计算复杂度(#tags×#rules)。我们提供了总CSS选择器的数量,并在图10中显示结果。我们观察到网页选择器数量的广泛分布,范围从2,959到29。
      为了理解选择器数量的影响,我们执行微基准测试。每个微基准标记逐渐将选择器的数量从1,000增加到8,000。作为Tbl中的“选择器计数”类别。如图2所示,随着选择器的数量从1,000变化到8,000,相关的执行时间和能量消耗量级急剧增加。这表明选择器计数的重要性。
      此外,CSS选择器的选择模式也对选择器处理有很大影响。例如,某些模式需要遍历DOM树来识别HTML标记之间的后代关系,而其他模式则不需要[11]。图10显示了选择模式的分布。
      我们进一步对不同的选择模式进行微基准测试。每个微基准标记网页重复特定模式1,000次,并且与没有CSS规则的基线不同。Tbl中的“选择器模式”类别。 2报告结果。根据不同的模式,执行时间和能耗不同。例如,与不涉及DOM树操作的伪模式相比,需要DOM树遍历的后代模式需要8X处理时间并且消耗6X能量。
      属性:除了选择器之外,我们还会分析CSS属性用法。 图11显示了具有七个最热属性的属性分布,所有其他属性分组为“其他”。 网页中的CSS属性用法很大程度上是多样化的,没有任何明显热门的属性。 但是,不同网页的总属性数量差异很大。
      我们的CSS属性的微基准测试结果(每个属性重复1,000次)显示在Tbl的“属性”类别中。 我们观察到属性之间明显的执行时间和能耗差异

6.网页性能和能量建模

下面是关于如何建立模型来预测加载时间和能量消耗,以便进行不同核和不同CPU频率的调度
预测网页加载时间和能耗的能力对于利用大/小系统进行智能调度至关重要。在本节中,我们通过回归建模证明了这种预测的可行性。基于上一节中描述的网页特征,我们应用回归建模,捕获网页特征的不同方面及其相互作用,以预测网页加载时间和能耗(第6.1节)。我们的模型的负载时间和能量消耗的中位预测误差率分别为5.7%和6.4%(第6.2节)。

6.1 模型推导

回归模型是一组预测变量和响应之间的数学函数。在我们的上下文中,响应是网页的加载时间或加载网页时的能耗。预测变量是一组网页特征。我们还需要一些抽样观察来训练模型。线性回归是基本的回归技术,是高级回归技术的前提。因此,我们首先提供线性回归建模的基础知识。然后,我们确定模型的预测变量并获得一组采样观测值,以得出线性模型。之后,我们将描述在上一节中关于网页特征的不同见解如何使我们重新定义基本线性模型。
      线性回归建模线性回归模型将网页的加载时间和能量消耗(响应)建模为各种网页特征(预测变量)的线性组合,表述为:

y表示为预测的结果,x1,x2,x3,xp表示p个预测器,β0,β1,β2,βp表示相应的系数
最小二乘法用于通过识别最小化残差平方和(RSS)的最佳匹配β来求解回归模型[33]。
      预测器:我们首先将上一节中描述的网页原语作为模型预测器包含在内,因为它们显示出强大的层间差异,因此对加载时间和能耗有很大影响。此外,我们还必须考虑内容相关特征(如图像大小和网页总大小)的影响。 这些特征是粗粒度度量,它们独立于网页结构,但会影响渲染的加载时间和能量。 我们在Tbl中总结了这些功能。 总的来说,我们考虑了376个预测因子
      获得观察:我们需要一些抽样观察来构建回归模型。 我们在第三部分描述的实验装置获得2,500个采样观察我们在运行1.2 GHz的CortexA9处理器上同时测量网页加载时间和能耗。
      型号规格和细化我们应用各种技术来减轻过度拟合并捕获预测器响应非线性以实现高预测精度。 我们使用R [12]及其glmnet和rms包进行所有分析。
论文中也说明了他们分析的时候用到的模型,如https://www.r-project.org/
      我们考虑了相对于观测数量(2,500)的大量预测变量(376)。 众所周知,这会产生导致过度拟合的预测[33]。 我们通过消除与响应关联性较低的预测变量来缓解第一顺序。 我们通过计算每个预测变量与观察到的负载时间和能量之间的平方相关系数(ρ2)来测试预测器/响应相关强度。 图12a显示了七个最相关的预测变量。 对于加载时间和能量,我们发现DOM树节点(#nodes)的数量是最相关的网页原语,因为它启发式地捕获了网页结构的复杂性。 此外,图像大小和总网页大小也是相关的,因为它们捕获网页内容。 我们只选择ρ2大于0.01的预测变量。 这是为防止过拟合所做的措施
       我们通过修剪彼此相关的特征来进一步减少过度配置。我们测试预测器强度测试后留下的预测变量之间的相关性。相关矩阵在图12b中显示为热图。热图中点的强度与两个预测值之间的相关系数的大小成比例。树形图中分支的高度量化了这个量级。

固有相关性和强加相关性,分析,抛去冗余
      通常,我们发现两种类型的相关性:固有相关性和强加相关性。 几个HTML标签和属性在功能上共同定义,并且通常一起使用,例证了固有的相关性。 例如,<form>标签描述了网页中的表单,action属性指定了提交表单的位置。 这两个预测变量几乎彼此同步,表明冗余。 类似的例子是<a>标签和href属性,它们被定义为指定外部超文本链接。 其他一些预测因素并没有这种固有的关系,但是Web开发人员一起使用它们来描述相关信息,例如图像的宽度和高度。 例如,CSS属性的高度和宽度高度相关。 由于这个原因,后代选择器模式和类选择器模式也显示出很强的相关性。
      此外,响应和所有预测变量之间的真实关系不太可能是简单线性模型所假设的严格线性。 模拟非线性的一种有效方法是使用限制样条函数拟合数据,这些函数是分段多项式函数,但强制线性拟合超出第一个和最后一个结[33]。

6.2 模型评估

模型的构建也是逐步细化的,从刚开始的线型到非线型
      为了验证模型,除了用于推导模型的2,500个观测值外,我们还获得了2,500个观测值。 我们通过比较三种回归模型的准确性,逐步评估前面描述的各种细化技术的效果。 首先,我们评估基本线性回归(L)模型,该模型修剪不太重要的预测因子。 其次,我们用正则化(R)评估线性回归,进一步修正彼此相关的预测变量。 第三,我们使用修剪特征评估受限立方样条(RCS)模型,该模型捕获预测变量和响应之间的非线性关系。 在所有三种模型中,RCS在预测负载时间和能量方面表现最佳。 我们展示了所有三种模型的完整性评估。
      绩效模型:基本线性回归模型(L)的中值和平均误差率分别为25.8%和32.8%,表明不太理想的预测。 由于更积极的预测器修剪,基于正则化的模型(R)将中值和平均错误率分别降低到11.5%和13.6%。 限制三次样条(RCS)建模预测最佳,中位数和平均错误率仅为5.7%和7.5%,因为它能够捕获预测变量和响应之间更复杂的关系。
      我们还评估分布或预测误差。 图13a通过呈现三种建模方法的误差的累积分布示出了结果。 图中的每个(x,y)点对应于处于或低于特定错误率(x)的页面部分(y)。 由于过度拟合,L非常准确地预测了一些网页,但缺乏普遍适用于大范围网页的能力。 因此,L只能在10%的误差范围内预测20.0%的网页。 相比之下,R通过积极的修剪减轻了过度拟合,并预测44.6%的网页在10%的误差范围内。 最后,RCS进一步捕获了非线性关系,因此可以在10%误差范围内预测73.0%的网页,在20%误差范围内预测94.0%的网页。
      能量模型:与加载时间模型类似,基于RCS的模型表现最佳,中位误差率为6.4%(平均值为8.2%),R和L的中位数分别为12.3%和27.1%。 图13b显示了三种建模方法的误差累积分布。 由于前面解释的原因,RCS可以预测70%的网页在10%误差范围内(91%在20%误差范围内),分别从R和L提高41.7%和18.7%。

7. 动态网页调度

主要讲了调度的时间开销和能耗开销,时间开销主要是预测和大小核切换和CPU频率切换。
      在前面描述的预测模型的基础上,我们提出了网页感知调度。 调度程序通过智能地安排网页来实现理想的截止/能量权衡,从而充分利用大/小系统的优势(第7.1节)。 真实的硬件和软件测量表明,针对面向性能的硬件策略,网页感知调度程序实现了83.0%的节能,同时违反了截止延迟,仅增加了4.1%的网页。 与更智能的按需操作系统DVFS调度程序相比,该机制可实现额外8.6%的节能以及4.0%的性能提升(第7.2节)。

7.1 网页感知调度

调度在解析阶段(占总执行时间的<1%)期间,网页感知调度器提取网页特征,并将它们馈送到预测模型中以估计不同核心和频率配置下的网页加载时间和能量消耗。 在这些预测的基础上,调度程序然后以最小的能量消耗识别满足截止延迟的配置(如果可能的话)。 如果没有找到这样的配置,则网页被安排到具有最高频率的大核心以获得最佳性能。
      调度开销我们考虑两个主要的调度开销:预测和配置转换。 预测非常迅速(在1.2 GHz下Cortex-A9上<3毫秒)。 此外,预测与渲染引擎的解析阶段交错(怎么理解???)。 由于现代浏览器中的解析被高度优化(例如,与其他处理异步),因此预测开销是微不足道的。 根据我们的测量结果,我们假设一个5毫秒的恒定开销。
      硬件配置之间的转换涉及在大/小核之间迁移任务和/或频率缩放开销的代价。 任务迁移的主要开销源是上下文切换,即(重新)存储体系结构状态,例如寄存器文件和配置寄存器,以及预热专用L1 / L2高速缓存(假设最后一级高速缓存(LLC)之间的高速缓存一致性) 大核心和小核心)。 我们假设每个上下文切换的状态(重新)存储的持续开销为20毫秒,如ARM big.LITTLE系统所示。 对于私有缓存预热惩罚,先前的工作表明,当大核和小核的私有LLC一起启动时,性能通常会提高。 因此,我们忽略了预热惩罚。 此外,先前的工作表明任务迁移的功率开销<0.75 [46]。 因此,我们不考虑调度机制的额外能耗。
      对于频率缩放,我们假设开销为0.3毫秒。 Linux内核在CortexA9和A8系统上都使用此值。 该值考虑硬件(即,电压调节器模块切换频率)和软件开销(即,频率改变请求的特权级切换开销)。 在我们的评估中,由于我们不知道Web浏览器当前运行的配置,我们保守地考虑配置转换开销和每个调度点的频率扩展开销。

7.2 评估

节能:我们将网页感知调度机制与在异构系统上执行按需DVFS的智能合成OS调度程序进行比较。 OS调度程序根据系统利用率的简单启发式在网页加载期间缩放频率[31,49]。它对特定时段的CPU使用率进行采样,并在前一采样周期内的平均CPU使用率高于预设阈值时对其进行扩展,反之亦然。 因为没有Linux调度程序可以跨大/小内核执行异构调度,所以我们合成了这样的调度程序。通过在大核和小核上单独运行“按需”cpufreqgovernor [14]下的网页,然后选择更好的结果。
      我们将两种调度技术与基线策略进行比较,该策略始终如一地产生最佳性能。 我们通过评估所有不同核心和频率配置的性能来确定这样的基线。 图14显示了每种配置下网页加载时间的累积分布。 图中的每个(x,y)点表示在特定延迟(x)内加载的网页(y)部分。 具有峰值频率(1.2 GHz)的大核心可实现最佳整体性能。 它可以在3秒内加载96.5%的网页。 随着频率和核心能力的下降,可以在相同的截止延迟内加载更少的网页。 因此,我们选择具有峰值频率(1.2 GHz)的大核心(A9)作为高性能基线。
      我们评估了用于评估回归模型准确性的相同2,500个网页。 假设3秒的截止延迟,图15a示出了针对高性能模式的网页感知和OS调度器下的每网页节能的箱线图。 两种调度器均比高性能基线节能显着,(几何)平均值分别为83.6%和83.0%。 这是因为两个调度程序都可以将网页安排到较低功率核心或较低频率。

将我们的网页感知机既比普通的OS调度要好而且比DVFS还要好!!
      与OS调度程序相比,网页感知调度程序的节能分布更加密集,达到100%。 这表明通常网页感知调度程序实现了更高的节能效果。 图16a示出了网页感知调度器对OS调度器的perwebpage相对能量的直方图。 支持网页的调度程序可为大约80%的网页节省能源。 有几个网页被错误安排到大核心上,可以通过小核心来满足截止延迟。 与OS调度程序相比,这些网页在网页感知调度程序下消耗的能量要高得多(图16a中的> 2X)。 平均而言,与OS调度程序相比,支持网页的调度程序可将能耗降低8.6%。
      绩效影响:与性能模式相比,OS调度程序和网页感知调度程序交换性能以实现更好的节能。 我们使用违反其操作下的截止延迟的网页数量,更严格地评估他们的行为。 该数据显示在图15b中。 性能模式仅违反3.5%的网页,截止延迟为3秒,因为它始终以峰值计算能力运行。 两个软件调度程序的性能都稍差。 我们的机制,即网页感知调度程序,导致7.6%的违规,这比OS调度程序仅差0.6%。 但是,在(几何)平均值上,我们的机制加载网页比OS调度程序快4.0%。
      截止灵敏度:为了评估可变用户需求和移动设备条件下的网页感知调度程序,我们还尝试了不同的截止延迟。 例如,当最终用户在2秒时请求更快的网页加载时,该机制比OS调度程序节省7.3%的能量,同时减少4%的网页数量。 在电池节约模式下,性能不太重要且截止延迟放宽至10秒,与OS调度程序相比,网页感知调度程序实现了11.8%的节能,同时超过了0.02%网页的截止延迟 总。 我们得出结论,网页软件调度程序可以灵活地改变用户需求.
      预测准确度:调度有效性依赖于加载时间和能量预测精度。 我们通过将网页感知调度与Oracle调度程序进行比较来研究预测准确性的影响,该调度程序假定在3秒截止延迟下进行完美预测。有两种类型的误预测:过度预测会导致网页加载到更强大的配置上,这种配置比理想配置消耗更多能量,但不会导致切断违规; underprediction在较弱的配置上加载网页,消耗较少的能量但违反了截止约束。 我们的模型导致10%的过度预测和4.1%的低估。 与Oracle调度程序,网页感知调度程序相比导致4.1%的截止违规,但“节省”9.7%的能源。
      分析网页感知调度程序的优势在于其对网页特征和截止延迟的了解。 因此,它为每个网页预测并选择适当的(虽然是固定的)配置。 相反,OS调度程序的DVFS决策基于系统利用率,该系统利用率与网页特征/截止延迟没有直接关联,并且对其他系统活动敏感 因此,它可能导致次优的绩效能量权衡,甚至错过截止约束。
       例如,当在OS调度程序下加载www.newegg. com( 图5中的右上角)时,我们发现大核心上的CPU使用率在大约40%的时间内达到95%以上并且(不必要地)发生 峰值频率(即1.2 GHz)。 事实上,网页感知调度程序选择720 MHz的大核心足以满足3秒的截止延迟,与我们实验中的OS调度程序相比,实现了20%的节能。
      然而,在加载网页时扩展频率的灵活性有时允许OS调度程序利用能量的边际值,即能量的轻微增加(通过频率缩放)可以使网页恢复到可能具有的截止延迟之内。如果使用较低频率加载网页,则会错过。如果预测过低,使用了过低的CPU频率也是有不好结果的。凡是都有利弊
      例如,www.autoblog.com(图5中的左上角)在920 MHz(大核心)下加载时仅超过3秒的截止时间0.1秒,但必须在网页下使用1.2 GHz回落 - 意识到调度程序。 在1.2 GHz时,网页仅在1.8秒内加载,但比920 MHz消耗的能量多37%。 但是,根据操作系统调度程序,我们的统计数据显示,操作系统仅在大约20%的时间内将频率提升到920 MHz以上,并在2.7秒内完成负载。 与此网页以1.2 GHz运行的网页感知调度程序相比,此情况下的OS调度程序可节省20%的能源,有效地利用高边际能源价值。
      讨论:为了完整评估,我们还评估了一个集成的调度程序,它将网页感知调度程序与OS DVFS相结合。 目的是通过OS DVFS利用潜在的高边际能量值,但绑定DVFS空间以避免不必要的高(浪费能量)或低(缺少截止延迟)的频率。
      具体地,网页感知调度器首先将OS DVFS调度空间限制为两个频率:恰好满足截止约束的较低频率和仅错过约束的较高频率。 鉴于这两个频率,网页感知调度程序试图通过进一步调整在任一频率上花费的时间百分比来确保仍然可以满足截止延迟。 实际上,我们将Linux cpufreqgovernor的scaling_max_freq和scaling_min_freq分别设置为较低和较高频率。 我们设置up_threshold来控制何时提升到更高的频率[14]。 例如,对于www.autoblog.com(图5中的左上角),大核心上的OS DVFS仅在1.2 GHz和920 MHz上运行。 因为920 MHz几乎能够在截止日期前完成,只占网页的一小部分负载必须以较高的频率运行。

扩充
      图16b在3秒截止约束下示出了集成调度器对网页感知调度器的每个网页相对能量的直方图。 集成的调度程序始终优于网页感知调度程序,平均节能3.0%(高达30%)。 我们将完整的集成和详细的比较留待将来的工作。

8.相关工作

本文的实验没有涉及到JavaScript,但是LZ的考虑了
      JavaScript JavaScript在网页中很重要。但是,我们认为这是一个与网页加载密切相关但又截然不同的问题。JavaScript代码通常在加载网页后执行。谷歌建议,为了提高性能(特别是在移动浏览中),所有JavaScript处理都应推迟到网页加载完成[15]。推测性地处理JavaScript的提案[16,38,43]进一步将JavaScript与网页加载分开。此外,正如[47]中所指出的,大部分JavaScript代码要么是计算密集型的[17,18],要么是对内存管理系统的密集压力。它们需要对即时(JIT)引擎,编程模型或垃圾收集器(GC)[28,34,39]进行优化,所有这些都超出了我们的工作范围。因此,我们在本文中的重点和机制很大程度上独立于JavaScript执行及其浏览器引擎性能。

移动端由于耗电考虑,不适合超过4核的并行化。

Web浏览器性能优化当前的研究提案侧重于并行化浏览器特定任务,例如解析,CSS选择等[24,36,40,41]。虽然这种并行算法可以实现各种浏览任务的4X到80X的加速,但它们通常不能很好地扩展到超过四个内核/线程,导致不可接受的能量效率低下。因此,我们认为虽然并行化方法在桌面计算方面具有潜力,但它对于移动Web浏览不太有利。

Web性能优化的另一部分侧重于通过异步/多进程呈现,资源预取,更智能的浏览器缓存等来改进Web浏览器的执行模型[19,20,37,38,50]。我们专注于每个网页处理,这可以与整个网络浏览器架构的改进相结合。
      Web浏览器能源/功耗优化Thiagarajan等。 [48]将网络浏览器的能耗分解为粗粒度元素,如CSS和Javascript行为,并确定一些系统和应用程序级别的操作,以提高移动Web浏览的能耗。他们推荐的优化,例如重新组织JavaScript文件和删除不必要的CSS规则,是我们的网页预测和调度工作的正交和补充。其他工作分析整个智能手机的功耗/能耗[26,29,44],而我们则专注于提高移动处理器的能源效率,以满足对高性能的需求。SiChrome [25]将浏览器的关键执行映射到硬件以改进EDP,并与我们的工作正交。
      单一ISA异构调度我们的网页调度技术基于大/小内核借助DVFS,是利用单ISA异构系统优化性能与能量权衡的一个例子[35]。Nvidia的Kal-El [21]是一个单ISA异构系统,它将四个高频内核与一个低频内核集成在一起。ARM提出的big.LITTLE系统[13]包含一个高性能Cortex-A15处理器和一个低性能但极其节能的Cortex-A7处理器。如果没有big.LITTLE系统的可用性,在本文中我们使用Cortex-A9和A8来合成这样的系统,并在高性能和高能效的移动网页浏览中展示其优势。我们基于预测的调度技术类似于其他最近的异构调度提议,例如PIE [30]。但是,我们不是依靠(微)架构和系统级统计进行预测,而是使用回归建模捕获网页特征的复杂行为,并准确预测网页加载时间和能耗。
      Web浏览器工作负载表征Gutierrez等。 [32]使用11个网站执行Android浏览器的微体系结构级别表征。我们将网页而不是Web浏览器视为工作负载。此外,我们挖掘了5,000个热门网页,以更严格地识别和量化网页的固有差异,并将网页差异与网页加载时间和能量的差异相关联。Butkiewicz等人。 [27]采用类似的方法,描述不同网页的复杂性。他们构建了一个考虑服务器和网络效应的网页加载时间模型。相反,我们考虑移动网络浏览的客户端上的加载时间和能量使用,并且我们使用甚至更细粒度的预测模型在异构系统上执行网页感知调度。

9.讨论

我们看到了我们的网页广告方法的广泛未来应用。首先,Web开发人员可以使用我们的预测模型,通过改善网页加载时间来降低网页放弃率。Google提供网页性能优化技术和微博加网页,以评估不同的优化技术[22,23]。与此相辅相成,Web开发人员可以进一步依赖我们的预测模型在部署之前收集定量和细粒度的优化结果。
      其次,我们的工作是将预测和调度技术集成到具有显着改进空间的移动设备的过程中的第一步。我们可以通过更全面和全面地了解不同Web浏览器组件之间的交互来扩展我们的系统级预测方案,例如网络模块,浏览器缓存/数据库等。包括HTML5的功能也是进一步改进的主题。
      最后,我们的方法是反馈导向优化的启发式方法。未来的移动Web浏览器可以根据网页的独特特性甚至Web应用程序及其用户需求不断优化其执行。我们设想这样的浏览器将像传统的运行时系统一样,不断地协调其硬件资源以实现特定的优化目标,而不仅限于本文演示的能源效率。

10.结论

我们建议网页感知调度,以实现高性能和高能效的移动网络浏览。它是一种新的机制,可以将底层异构硬件资源动态匹配到具有多样化特征的网页。通过对网页方差的详细描述,我们应用回归建模来预测网页加载时间和能耗。这种预测模型允许调度器识别网页的理想核心和频率配置,以最小化延迟截止约束下的能量消耗。真正的硬件和软件测量表明,平均而言,网页感知调度实现了83.0%的节能,而与仅面向性能的硬件策略相比,只有4.1%的网页违反了截止延迟。与生产级OS DVFS调度程序相比,它实现了8.6%的节能和4.0%的性能提升。

此时已是凌晨1点13,有点累了,后面翻译有点粗糙,望谅解,后续会不断完善。

High-Performance and Energy-Efficient Mobile Web Browsing on Big/Little Systems相关推荐

  1. State of the Mobile Web: First Quarter, 2008

    原文地址 http://www.opera.com/mobile_report/ State of the Mobile Web: First Quarter, 2008 Welcome to the ...

  2. 让jQuery Tools Scrollable控件在Mobile Web里面支持resize功能

    让jQuery Tools Scrollable控件在Mobile Web里面支持resize功能 项目中有两份代码,一份是Main Site,一份是Mobile Site.Main Site里面主页 ...

  3. mobile web retina 下 1px 边框解决方案

    http://www.tuicool.com/articles/ZRv6bun 再谈mobile web retina 下 1px 边框解决方案 时间 2015-01-03 12:03:31  Hug ...

  4. mobile web开发遇到的问题

    移动web开发之道(Android与Iphone) 1.javascript篇 (1)使用querySelector和querySelectorAll这两个方法获取文档对象中DOM节点的引用 由于这两 ...

  5. 【论文翻译】3461 AdderSR Towards Energy Efficient Image Super-Resolution(个人粗略翻译)

    AdderSR: Towards Energy Efficient Image Super-Resolution[3461] 本文仅为根据博主个人理解的翻译,如有错误或不准确之处,敬请各位读者指出 摘 ...

  6. 关于Mobile Web App你所应该知道的

    Native App与Web App的争论从未停息过,尽管很多人在批判Web App的各种不是,但也阻止不了各种各样的Web App如雨后春笋般出现,尤其是伴随智能手机的普及而受到重视的Mobile ...

  7. Coordinate Attention for Efficient Mobile Network Design

    目录 摘要 Coordinate Attention 注意力机制 Coordinate Attention模块 坐标信息嵌入(Coordinate Information Embedding ) 坐标 ...

  8. 一个基于SAE Channel的综合应用--mobile web IM(1)

    2019独角兽企业重金招聘Python工程师标准>>> 关键词:Mobile IM, SAE Channel, JQM动态加载, 滚动刷新,设计模式,编程范式 Hi, 我是Leona ...

  9. Google Developers 认证团队推出 Mobile Web Specialist 认证

    如果您是一名网络开发者,就一定知道这是一个鱼龙混杂的市场,而您也想让自己从其他网络开发者中脱颖而出.想要展示您具备构建自适应和灵活网络应用的技能吗? Google Developers 认证团队荣幸地 ...

最新文章

  1. 皮一皮:一个戒指吃出了电视剧的感觉...
  2. PAT甲级1015 Reversible Primes :[C++题解]进制位、秦九韶算法、判质数
  3. [MATLAB学习笔记]peaks函数1013(2)
  4. 机器学习算法基础概念学习总结
  5. boost::function的用法(一)
  6. 【C/C++】值传递和址传递区别解析
  7. JavaScript通俗易懂(一)-变量提升
  8. C# vs MySql
  9. Android反编译分析工具
  10. OSPF邻接关系建立过程
  11. L1-8 估值一亿的AI核心代码 (20 分)
  12. 桌面支持--dcc打印机设置注意
  13. 一个 C盘搬家 方式.Chrome搬家到D盘
  14. 华为牛人的十年工作感悟
  15. ch4_3_5利用radon函数和iradon函数构造一个简单图像的投影并重建图像.m
  16. Flink 实战问题(五):The transaction timeout is larger than the maximum value allowed by the broker
  17. 下载Macromedia FLASHPAPER
  18. jzoj5442. 【NOIP2017提高A组冲刺11.1】荒诞
  19. ui标注android ios,IOS+ANDROID的UI切图与标注方法
  20. 网页版 连连看 html5实现

热门文章

  1. 深度专访:图标的故事
  2. Blender图解教程:新手入门练习
  3. 肖金立计算机,肖金立
  4. 关闭Mac的Microsoft AutoUpdate
  5. android 平面图app_Android App 开发技术图谱
  6. ATM机(c语言带界面)
  7. 【BeeWare安装过程】
  8. 如何安装OpenCV?OpenCV下载安装流程
  9. 作为一名程序员的对自己的编码要求
  10. 1941年电子计算机的英文名,Borden[伯顿,博登,波顿]的中文翻译及英文名意思