【计算机架构】程序指令计数 | 功耗计算 | 电力功耗 | 安德尔定律(Amdahl‘s Law)

简介: 【计算机架构】程序指令计数 | 功耗计算 | 电力功耗 | 安德尔定律(Amdahl‘s Law)

 


0x00 程序的指令计数

程序的指令计数(Instruction Count)由程序本身、ISA(指令集架构)和编译器决定。这表示一个程序中包含的指令数量受到程序编写方式、计算机体系结构和编译器的影响。

每条指令的平均周期数(Average cycles per instruction,CPI)是由CPU硬件决定的。不同的指令可能需要不同的时钟周期数来执行,因此平均CPI受指令混合(instruction mix)的影响。

指令混合是指程序中不同类型的指令的比例。某些指令可能需要更多的时钟周期来执行,而其他指令可能需要较少的周期。平均CPI是这些不同指令的CPI的加权平均,其中权重由它们在指令混合中的相对频率决定。我们可以用以下公式来计算:

举个例子:

计算机 A: 周期时间 = 250ps,CPI = 2.0 • 计算机 B: 周期时间 = 500ps,CPI = 1.2 • 相同的ISA • 哪台计算机更快,快多少?

更多细节:如果不同指令类别需要不同的周期数,那么:

加权平均 CPI 为:

其中, 属于相对频率 (Relative frequency) 。

因此,对于性能计算,我们可以把公式总结如下:

单处理器性能:

0x01 功耗计算

对于 CMOS 芯片,传统的主要能耗在于开关晶体管,称为动态功耗。

对于移动设备,能量更好的度量标准:

对于固定任务,减慢时钟频率(切换频率)可以减小功耗,但不能减小能耗。

电容负载取决于连接到输出的晶体管数量和技术,技术决定了电线和晶体管的电容。

降低电压有助于减小功耗和能耗,因此从 5V 降至 1V。

为了节省能量和动态功耗,大多数CPU现在会关闭不活动模块的时钟(例如浮点运算单元)。

举个例子:假设电压减小15%导致频率减小15%,对动态功耗的影响如何?

我们根据公式:

现在,我们有一个 15% 的电压减小,这意味着新的电压将是原电压的0.85倍,而频率也减小了15%,即新频率是原频率的 0.85 倍。将这些值代入公式中:

现在,我们可以计算新动态功耗与原动态功耗之间的比例:

容量项和 1/2 会在分子和分母中互相抵消,所以:

新的动态功耗 / 原动态功耗 =

新的动态功耗 / 原动态功耗 = 0.614125

所以,通过减小电压15%并导致频率减小 15%,动态功耗减小到原来的约 61.41%。

0x02 电力功耗(Power consumtion)

因为即使晶体管关闭时,漏电流仍然会流动,所以静态功耗也变得重要。

在晶体管尺寸更小的处理器中,漏电流增加。即使关闭了晶体管,增加晶体管的数量也会增加功耗。在2006年,漏电目标为总功耗的25%;高性能设计为40%。非常低功耗系统甚至会降低非活动模块的门电压以控制漏电带来的损失。

在做出设计折衷决策时,通常应该优先考虑常见情况而非不太常见的情况。例如,如果在计算机系统中指令提取和解码单元的使用频率高于乘法器,那么应该首先对前者进行优化。又如,如果一个数据库服务器每个处理器都有50个磁盘,那么存储可靠性可能比系统可靠性更重要,因此应首先对其进行优化。

通常,常见情况比不太常见情况更为简单,而且可以更快地完成。这意味着可以通过优化常见情况来提高性能,即使这可能会对不太常见的情况产生一些影响。举例来说,当将两个数字相加时,溢出的情况非常罕见,因此通过优化不发生溢出的常见情况来提高性能可能更为有效。这种方式可能会减慢处理溢出的速度,但整体性能会因为优化常见情况而得到改进。在评估常见情况以及通过加速常见情况来提高性能时,我们需要考虑到 安德尔定律

0x03 安德尔定律(Amdahl's Law)

Amdahl's Law(安德尔定律)是一项关于计算机性能优化的重要原则,由计算机科学家 Gene Amdahl 于 1967 年提出。该定律强调了在优化计算系统时需要关注性能的瓶颈,特别是涉及并行计算的情况。

安德尔定律的核心思想是,当你尝试提高一个系统中某个部分的性能时,性能提升会受到系统中其他部分的限制,尤其是在多处理器或多核系统中。这意味着无论你花多少时间和资源来提高一个部分的性能,整个系统的性能提升会受到那个部分的限制。

最佳期望:

举个例子:新的 CPU 速度快了 10 倍,服务器受 I/O 限制,因此 60% 的时间用于等待I/O操作。

显然,人类天性倾向于被速度提高 10 倍所吸引,而忽视了只是提高了 1.6 倍的现实。


📌 [ 笔者 ]   王亦优
📃 [ 更新 ]   2022.
❌ [ 勘误 ]   /* 暂无 */
📜 [ 声明 ]   由于作者水平有限,本文有错误和不准确之处在所难免,
              本人也很想知道这些错误,恳望读者批评指正!

📜 参考资料 

C++reference[EB/OL]. []. http://www.cplusplus.com/reference/.

Microsoft. MSDN(Microsoft Developer Network)[EB/OL]. []. .

百度百科[EB/OL]. []. https://baike.baidu.com/.

比特科技. C++[EB/OL]. 2021[2021.8.31]. 

相关文章
|
26天前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
70 1
|
1月前
|
运维 监控 Serverless
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
30 1
|
2月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
59 3
|
2月前
|
存储 固态存储 安全
阿里云服务器X86计算架构解析与X86计算架构云服务器收费价格参考
阿里云服务器架构分为X86计算、Arm计算、高性能计算等多种架构,其中X86计算是用户选择最多的一种架构,本文将深入探讨阿里云X86计算架构的云服务器,包括其技术特性、适用场景、性能优势以及最新价格情况。
|
2月前
|
编解码 弹性计算 应用服务中间件
阿里云服务器Arm计算架构解析:Arm计算架构云服务器租用收费标准价格参考
阿里云服务器架构分为X86计算、Arm计算、高性能计算等多种架构,其中Arm计算架构以其低功耗、高效率的特点受到广泛关注。本文将深入解析阿里云Arm计算架构云服务器的技术特点、适用场景以及包年包月与按量付费的收费标准与最新活动价格情况,以供选择参考。
|
2月前
|
运维 Serverless 数据处理
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现出显著优势,包括加速研发交付、降低成本、零运维成本、高效资源利用、自动扩展、实时数据处理及快速原型开发,为高并发、动态需求场景提供高效解决方案。
55 1
|
2月前
|
运维 Serverless 数据处理
Serverless架构在图像处理等计算密集型应用中展现出显著优势
【10月更文挑战第6天】Serverless架构在图像处理等计算密集型应用中展现出显著优势,包括加速研发交付、成本效益、零运维成本、高效资源利用、自动扩展能力、实时数据处理及快速原型开发,为高并发、动态需求场景提供高效、灵活的解决方案。
47 4
|
16天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
14天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
15天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
33 1
服务架构的演进:从单体到微服务的探索之旅