从功耗角度理解的性能优化

简介: 通常的性能优化都会以在规定时间范围内完成的逻辑运算为目标,但是有趣的是我们发现也许追求相同目标下的减少额外功耗是我们真正的方向,性能仅仅是产物而非目标,为此我们提出性能的公式: 信息有效密度/处理所需数据量需要的功耗,该公式表明我们需要提升信息有效密度,同时减少数据处理功耗,这样才能帮助我们最终提升性能。 提升有效信息密度: 文章 Deep learning has a size prob

通常的性能优化都会以在规定时间范围内完成的逻辑运算为目标,但是有趣的是我们发现也许追求相同目标下的减少额外功耗是我们真正的方向,性能仅仅是产物而非目标,为此我们提出性能的公式: 信息有效密度/处理所需数据量需要的功耗,该公式表明我们需要提升信息有效密度,同时减少数据处理功耗,这样才能帮助我们最终提升性能。

提升有效信息密度:
文章 Deep learning has a size problem
中,作者看到当前为了准确性,深度学习模型参数不断扩张甚至达到83亿,该模型导致需要使用512块 NVIDA V00 GPU计算9.2天,用于训练该模型的能源量是美国人平均年能源消耗量的3倍以上以上,因此作者提出了“I couldn’t help but ask myself: is deep learning going in the right direction?", 同时作者发现当前很多深度学习模型在优化模型使用更少的数据(也就是提升有效信息密度),得到几乎相同的准确率,同时提升效率,最后作者的结论是“Shifting from state-of-the-art accuracy to state-of-the-art efficiency”

减少数据处理功耗:
虽然摩尔定律仍然持续,但是RC延迟得到的优化很少,因此从内存取8个字节到计算单元需要1000pj, 而计算单元运行需要10pj,根据性能公式我们需要做3件事:1. 相同结果下减少数据访问量(也就是提升有效信息密度),2. 减少存储单元与计算单元的距离,减少功耗,3. 增大处理单元的并行度,减少数据在计算和存储单元的乒乓过程,减少功耗。上述2. ,3.两个方法也是都被FPGA或者GPU,CPU所使用,也是他们优化的方向,比如内嵌内存,增大缓存,甚至 processor in memory,并且增大计算向量宽度. 虽然我们没有提到性能提升,但是性能的改善已经很明显,前者减少延迟,后者增加吞吐,最终数据处理能力在加快.

深入背后的原因发现,所有优化工作都应该围绕减少运行过程中状态的变化(信息擦除产生功耗 = K W T,K是玻尔兹曼系数,W为需要擦除的bit数,T是环境开尔文温度),也就是减少功耗(提升信息密度也是为了减少bit的翻转),其包括OS上下文切换,OS页面缓存缺失,CPU跳转指令预测失败,CPU缓存缺失,CPU执行通道冲突等,如果用1,0分别代表缓存命中和缺失,有0101和0011两种情况,我们应该会选择后者,甚至应会选择0001,因为前者有三种变化,后者只有一种变化, ISCA 论文《A Case for MLP-Aware Cache Replacement》就完整的描述了这个过程,他努力去获取连续缺失或者连续命中的场景。即使我们关注的是性能,但这个却是结果,而不是行动的原因,反之仅仅考虑速度(例如CPU 频率),那就会落入intel P4的结局,也就是频率虽然快,但是单位时间内可输出的逻辑运算确很低。

当前很热的量子计算机具有超强的计算能力,然而真正推动他前进的是可逆计算(从计算输出可以知道输入,无状态改变,例如“非”运算就是典型的可逆计算)导致量子计算机超低的功耗。所以真正推动性能优化前进是提升信息密度,减少处理数据产生的功耗,最终减少由于状态变换产生的额外功耗,这是一只看不见的手,推动我们前行。

目录
相关文章
|
SQL 存储 关系型数据库
对线面试官 - 如何理解MySQL的索引覆盖和索引下推
索引下推是MySQL 5.6引入的优化,允许部分WHERE条件在索引中处理,减少回表次数。例如,对于索引(zipcode, lastname, firstname),查询`WHERE zipcode='95054' AND lastname LIKE '%etrunia%'`时,索引下推先过滤zipcode,然后在索引中应用lastname条件,降低回表需求。索引下推可在EXPLAIN的`Using index condition`中看到。
1755 0
对线面试官 - 如何理解MySQL的索引覆盖和索引下推
|
网络协议 网络架构
计算机网络期末复习——计算大题(一)
计算机网络期末复习——计算大题(一)
1216 0
计算机网络期末复习——计算大题(一)
|
关系型数据库 MySQL 索引
【MySQL】当前读、快照读、MVCC
【MySQL】当前读、快照读、MVCC当前读:  select...lock in share mode (共享读锁)  select...for update  update , delete , insert   当前读, 读取的是最新版本, 并且对读取的记录加锁, 阻塞其他事务同时改动相同记录,避免出现安全问题。
13158 0
|
10月前
|
Java API 微服务
Java 21 与 Spring Boot 3.2 微服务开发从入门到精通实操指南
《Java 21与Spring Boot 3.2微服务开发实践》摘要: 本文基于Java 21和Spring Boot 3.2最新特性,通过完整代码示例展示了微服务开发全流程。主要内容包括:1) 使用Spring Initializr初始化项目,集成Web、JPA、H2等组件;2) 配置虚拟线程支持高并发;3) 采用记录类优化DTO设计;4) 实现JPA Repository与Stream API数据访问;5) 服务层整合虚拟线程异步处理和结构化并发;6) 构建RESTful API并使用Springdoc生成文档。文中特别演示了虚拟线程配置(@Async)和StructuredTaskSco
1109 0
|
存储 Java 编译器
🔍深入Android底层,揭秘JVM与ART的奥秘,性能优化新视角!🔬
【7月更文挑战第28天】在Android开发中,掌握底层机制至关重要。从Dalvik到ART, Android通过采用AOT编译在应用安装时预编译字节码至机器码,显著提升了执行效率。ART还优化了垃圾回收,减少内存占用及停顿。为了优化性能,可减少DEX文件数量、优化代码结构利用内联等技术、合理管理内存避免泄漏,并使用ART提供的调试工具。
504 7
|
机器学习/深度学习 安全 TensorFlow
OpenCV的发展历史
【7月更文挑战第27天】OpenCV的发展历史。
667 3
|
存储 消息中间件 容灾
阿里IM技术分享(八):深度解密钉钉即时消息服务DTIM的技术设计
本文是国内企业IM的事实王者钉钉首次对外深度解密其即时消息服务(即DingTalk IM,简称DTIM)的技术设计实践。
2040 0
阿里IM技术分享(八):深度解密钉钉即时消息服务DTIM的技术设计
|
存储 编译器 C语言
【C语言】指针大小知多少 ?一场探寻C语言深处的冒险 !
在C语言中,指针的大小(即指针变量占用的内存大小)是由计算机的体系结构(例如32位还是64位)和编译器决定的。
1682 9
|
算法 安全 关系型数据库
深度|庖丁解InnoDB之Buffer Pool
聚焦在Buffer Pool的本职功能上,从其提供的接口、内存组织方式、Page获取、刷脏等方面进行介绍
105501 90
|
Ubuntu 关系型数据库 Linux
在Ubuntu 16.04上安装和使用PostgreSQL的方法
在Ubuntu 16.04上安装和使用PostgreSQL的方法
385 0