编译器控制技术降低缺失率

❶ 关于c++定义PI，后运算结果精度缺失。

这是编译器的优化
想要得到精确的小数点后位数控制
头文件 #include<iomanip>
然后输出时
cout << fixed << setprecision(n) << num;
n是要保留的小数位数

❷ pcm编译器系统实验过程中发现的问题

1. 点到点PCM多路电话通信原理
脉冲编码调制(PCM)技术与增量调制(ΔM)技术已经在数字通信系统中得到广泛应用。当信道噪声比较小时一般用PCM，否则一般用ΔM。目前速率在155MB以下的准同步数字系列(PDH)中，国际上存在A解和μ律两种PCM编译码标准系列，在155MB以上的同步数字系列(SDH)中，将这两个系列统一起来，在同一个等级上两个系列的码速率相同。而ΔM在国际上无统一标准，但它在通信环境比较恶劣时显示了巨大的优越性。
点到点PCM多路电话通信原理可用图9-1表示。对于基带通信系统，广义信道包括传输媒质、收滤波器、发滤波器等。对于频带系统，广义信道包括传输媒质、调制器、解调器、发滤波器、收滤波器等。
本实验模块可以传输两路话音信号。采用TP3057编译器，它包括了图9-1中的收、发低通滤波器及PCM编译码器。编码器输入信号可以是本实验模块内部产生的正弦信号，也可以是外部信号源的正弦信号或电话信号。本实验模块中不含电话机和混合电路，广义信道是理想的，即将复接器输出的PCM信号直接送给分接器。
2. PCM编译码模块原理
本模块的原理方框图图9-2所示，电原理图如图9-3所示（见附录），模块内部使用+5V和-5V电压，其中-5V电压由-12V电源经7905变换得到。
图9-2 PCM编译码原理方框图
该模块上有以下测试点和输入点：
• BS PCM基群时钟信号(位同步信号)测试点
• SL0 PCM基群第0个时隙同步信号
• SLA 信号A的抽样信号及时隙同步信号测试点
• SLB 信号B的抽样信号及时隙同步信号测试点
• SRB 信号B译码输出信号测试点
• STA 输入到编码器A的信号测试点
• SRA 信号A译码输出信号测试点
• STB 输入到编码器B的信号测试点
• PCM PCM基群信号测试点
• PCM-A 信号A编码结果测试点
• PCM-B 信号B编码结果测试点
• STA-IN 外部音频信号A输入点
• STB-IN 外部音频信号B输入点
本模块上有三个开关K5、K6和K8，K5、K6用来选择两个编码器的输入信号，开关手柄处于左边(STA-IN、STB-IN)时选择外部信号、处于右边(STA-S、STB-S)时选择模块内部音频正弦信号。K8用来选择SLB信号为时隙同步信号SL1、SL2、SL5、SL7中的某一个。
图9-2各单元与电路板上元器件之间的对应关系如下：
•晶振 U75：非门74LS04；CRY1：4096KHz晶体
•分频器1 U78:A：U78:D：触发器74LS74；U79：计数器74LS193
•分频器2 U80：计数器74LS193；U78:B：U78:D：触发器74LS74
•抽样信号产生器 U81：单稳74LS123；U76：移位寄存器74LS164
•PCM编译码器A U82：PCM编译码集成电路TP3057（CD22357）
•PCM编译码器B U83：PCM编译码集成电路TP3057（CD22357）
•帧同步信号产生器 U77：8位数据产生器74HC151；U86:A：与门7408
•正弦信号源A U87：运放UA741
•正弦信号源B U88：运放UA741
•复接器 U85：或门74LS32
晶振、分频器1、分频器2及抽样信号（时隙同步信号）产生器构成一个定时器，为两个PCM编译码器提供2.048MHz的时钟信号和8KHz的时隙同步信号。在实际通信系统中，译码器的时钟信号(即位同步信号)及时隙同步信号(即帧同步信号)应从接收到的数据流中提取，方法如实验五及实验六所述。此处将同步器产生的时钟信号及时隙同步信号直接送给译码器。
由于时钟频率为2.048MHz，抽样信号频率为8KHz，故PCM-A及PCM-B的码速率都是2.048MB，一帧中有32个时隙，其中1个时隙为PCM编码数据，另外31个时隙都是空时隙。
PCM信号码速率也是2.048MB，一帧中的32个时隙中有29个是空时隙，第0时隙为帧同步码(×1110010)时隙，第2时隙为信号A的时隙，第1(或第5、或第7 —由开关K8控制)时隙为信号B的时隙。
本实验产生的PCM信号类似于PCM基群信号，但第16个时隙没有信令信号，第0时隙中的信号与PCM基群的第0时隙的信号也不完全相同。
由于两个PCM编译码器用同一个时钟信号，因而可以对它们进行同步复接(即不需要进行码速调整)。又由于两个编码器输出数据处于不同时隙，故可对PCM-A和PCM-B进行线或。本模块中用或门74LS32对PCM-A、PCM-B及帧同步信号进行复接。在译码之前，不需要对PCM进行分接处理，译码器的时隙同步信号实际上起到了对信号分路的作用。
3. TP3057简介
本模块的核心器件是A律PCM编译码集成电路TP3057，它是CMOS工艺制造的专用大规模集成电路，片内带有输出输入话路滤波器，其引脚及内部框图如图9-4、图9-5所示。引脚功能如下：
图9-4 TP3057引脚图
(1) V一 接-5V电源。
(2) GND 接地。
(3) VFRO 接收部分滤波器模拟信号输出端。
(4) V+ 接+5V电源。
(5) FSR 接收部分帧同信号输入端，此信号为8KHz脉冲序列。
(6) DR 接收部分PCM码流输入端。
(7) BCLKR/CLKSEL 接收部分位时钟(同步)信号输入端，此信号将PCM码流在FSR上升沿后逐位移入DR端。位时钟可以为64KHz到2.048MHz的任意频率，或者输入逻辑“1”或“0”电平器以选择1.536MHz、1.544MHz或2.048MHz用作同步模式的主时钟，此时发时钟信号BCLKX同时作为发时钟和收时钟。
(8) MCLKR/PDN 接收部分主时钟信号输入端，此信号频率必须为1.536MHz、1.544MHz或2.048MHz。可以和MCLKX异步，但是同步工作时可达到最佳状态。当此端接低电平时，所有的内部定时信号都选择MCLKX信号，当此端接高电平时，器件处于省电状态。
(9) MCLKX 发送部分主时钟信号输入端，此信号频率必须为1.536MHz、1.544MHz或2.048MHz。可以和MCLKR异步，但是同步工作时可达到最佳状态。
(10) BCLKX 发送部分位时钟输入端，此信号将PCM码流在FSX信号上升沿后逐位移出DX端，频率可以为64KHz到2.04MHz的任意频率，但必须与MCLKX同步。
图9-5 TP3057内部方框图
(11) DX 发送部分PCM码流三态门输出端。
(12) FSX 发送部分帧同步信号输入端，此信号为8KHz脉冲序列。
(13) TSX 漏极开路输出端，在编码时隙输出低电平。
(14) GSX 发送部分增益调整信号输入端。
(15) VFXi- 发送部分放大器反向输入端。
(16) VFXi＋ 发送部分放大器正向输入端。
TP3057由发送和接收两部分组成，其功能简述如下。
发送部分：
包括可调增益放大器、抗混淆滤波器、低通滤波器、高通滤波器、压缩A/D转换器。抗混淆滤波器对采样频率提供30dB以上的衰减从而避免了任何片外滤波器的加入。低通滤波器是5阶的、时钟频率为128MHz。高通滤波器是3阶的、时钟频率为32KHz。高通滤波器的输出信号送给阶梯波产生器(采样频率为8KHz)。阶梯波产生器、逐次逼近寄存器（S•A•R）、比较器以及符号比特提取单元等4个部分共同组成一个压缩式A/D转换器。S•A•R输出的并行码经并/串转换后成PCM信号。参考信号源提供各种精确的基准电压，允许编码输入电压最大幅度为5VP-P。
发帧同步信号FSX为采样信号。每个采样脉冲都使编码器进行两项工作：在8比特位同步信号BCLKX的作用下，将采样值进行8位编码并存入逐次逼近寄存器；将前一采样值的编码结果通过输出端DX输出。在8比特位同步信号以后，DX端处于高阻状态。
接收部分：
包括扩张D/A转换器和低通滤波器。低通滤波器符合AT&T D3/D4标准和CCITT建议。D/A转换器由串/并变换、D/A寄存器组成、D/A阶梯波形成等部分构成。在收帧同步脉冲FSR上升沿及其之后的8个位同步脉冲BCLKR作用下，8比特PCM数据进入接收数据寄存器(即D/A寄存器)，D/A阶梯波单元对8比特PCM数据进行D/A变换并保持变换后的信号形成阶梯波信号。此信号被送到时钟频率为128KHz的开关电容低通滤波器，此低通滤波器对阶梯波进行平滑滤波并对孔径失真(sinx)/x进行补尝。
在通信工程中，主要用动态范围和频率特性来说明PCM编译码器的性能。
动态范围的定义是译码器输出信噪比大于25dB时允许编码器输入信号幅度的变化范围。PCM编译码器的动态范围应大于图9-6所示的CCITT建议框架（样板值）。
当编码器输入信号幅度超过其动态范围时，出现过载噪声，故编码输入信号幅度过大时量化信噪比急剧下降。TP3057编译码系统不过载输入信号的最大幅度为5VP-P。
由于采用对数压扩技术，PCM编译码系统可以改善小信号的量化信噪比，TP3057采用A律13折线对信号进行压扩。当信号处于某一段落时，量化噪声不变(因在此段落内对信号进行均匀量化)，因此在同一段落内量化信噪比随信号幅度减小而下降。13折线压扩特性曲线将正负信号各分为8段，第1段信号最小，第8段信号最大。当信号处于第一、二段时，量化噪声不随信号幅度变化，因此当信号太小时，量化信噪比会小于25dB，这就是动态范围的下限。TP3057编译码系统动态范围内的输入信号最小幅度约为0.025Vp-p。
常用1KHz的正弦信号作为输入信号来测量PCM编译码器的动态范围。
图9-6 PCM编译码系统动态范围样板值
语音信号的抽样信号频率为8KHz，为了不发生频谱混叠，常将语音信号经截止频率为3.4KHz的低通滤波器处理后再进行A/D处理。语音信号的最低频率一般为300Hz。TP3057编码器的低通滤波器和高通滤波器决定了编译码系统的频率特性，当输入信号频率超过这两个滤波器的频率范围时，译码输出信号幅度迅速下降。这就是PCM编译码系统频率特性的含义。
四、实验步骤
1. 熟悉PCM编译码单元工作原理，开关K9接通8KHz(置为1000状态)，开关K8置为SL1(或SL5、SL7)，开关K5、K6分别置于STA-S、STB-S端，接通实验箱电源。
2. 用示波器观察STA、STB，调节电位器R19(对应STA)、R20(对应STB)，使正弦信号STA、STB波形不失真(峰峰值小于5V)。
3. 用示波器观察PCM编码输出信号。
示波器CH1接SL0，（调整示波器扫描周期以显示至少两个SL0脉冲，从而可以观察完整的一帧信号）CH2分别接SLA、PCM-A、SLB、PCM-B以及PCM，观察编码后的数据所处时隙位置与时隙同步信号的关系以及PCM信号的帧结构（注意：本实验的帧结构中有29个时隙是空时隙，SL0、SLA及SLB的脉冲宽度等于一个时隙宽度）。
开关K8分别接通SL1、SL2、SL5、SL7，观察PCM基群帧结构的变化情况。
4. 用示波器观察PCM译码输出信号
示波器的CH1接STA，CH2接SRA，观察这两个信号波形是否相同(有相位差)。
5. 用示波器定性观察PCM编译码器的动态范围。
开关K5置于STA-IN端，将低失真低频信号发生器输出的1KHz正弦信号从STA-IN输入到TP3057(U82)编码器。示波器的CH1接STA（编码输入），CH2接SRA（译码输出）。将信号幅度分别调至大于5VP-P、等于5VP-P，观察过载和满载时的译码输出波形。再将信号幅度分别衰减10dB、20dB、30dB、40dB、45dB、50dB，观察译码输出波形(当衰减45dB以上时，译码输出信号波形上叠加有较明显的噪声)。
也可以用本模块上的正弦信号源来观察PCM编译码系统的过载噪声(只要将STA-S或STB-S信号幅度调至5VP-P以上即可)，但必须用专门的信号源才能较方便地观察到动态范围。

❸ Swift语言@特性

Swift语言有各种各样缺乏（或没有）文档记录的特性（attribute）放在那里等着被使用。让我们一起看看其中的一些特性：

@inline

这个特性为编译器提供了内联提示。有效的取值是__always和never。除非我认为必须要用这两个值，否则就不会使用它（特别是__always）。到目前为止与其相关的规则还不是很明确，在有限的测试下，它可以正常地工作，但还要视具体情况而定。

进一步的解释：尽管底层虚拟机（Low Level Virtual Machine, LLVM）有强制内联的概念，但我们目前还不知道这个@inline特性是否与其直接映射，也不知道是否存在大小方面的限制，但这将会导致编译器忽略这一点而跳过内联。理论上说应该是这样的，但我不保证一定是。

注意（当优化设置关闭时）在调试模式下的构建将忽略@inline。

@transparent

我最初并未将这个特性列出来。该特性会导致编译器在管道（pipeline）中更早地将函数内联。它用于 “像+(Int, Int)这样非常原始的函数”，而“不应该用于独立函数” 。

甚至在没有优化设置的调试模式下@transparent特性函数就会被内联，所以在调用“1+1”这样的函数的时候并不会特别慢。另外这个特性与@inline（__always）非常类似。

@availability

这个特性可以用来标识某些函数只在某些平台或版本上可用。第一个参数是平台，可以用星号（＊）代表一切可用，还可以是iOS或OS X。因为如果需要针对不同的平台，就要指定多个@availability属性。

如果需要表示该函数在某个给定的平台完全不可用时，可以将第二个参数置为unavailable。此外，还可以用introced，deprecated和obsoleted来指定一个或是多个版本的组合：obsoleted意味着该项已经删除，deprecated仅仅表示如果使用就会给予警告。最后你可以设置message的值，如果该项被使用了就由编译器输出。下面是一些例子：

@noreturn

正如该特性所描述的那样：编译器可以假定这个函数是一个永远循环运行的起点，例如while true { }，或者假定是函数abort或者exit进程的情况。

评论者Marco Masser指出，如果调用另一个被标志为@noreturn的函数，那么编译器会忽略掉当前函数中缺失的返回值（missing return values），因为编译器理解程序的控制流。

@asmname

该属性给出了函数、方法或属性实现的符号名称。如果你已经知道对应的函数参数及其类型，那么就可以直接调用Swift的内部标准库函数，甚至不用头文件，也可以方便地调用C语言编写的函数：

@unsafe_no_objc_tagged_pointer

上面这个仍然是个谜，但我猜测它是在告诉Swift与Objective-C联系的时候不要使用 tagged pointer 。

@semantics

这又是另一个谜。参数看起来像是array.mutate_unknown或array.init这样的字符串数组。想必这是要告诉编译器（或静态分析器）函数是如何工作的。

@discardableResult
swift正常的方法如果有返回值的话,调用的时候必须有一个接收方,否则的话编译器会报一个警告,如果在方法前加上 @discardableResult 不处理的时候就不会有警告了。也可以用一个通配符接收方法返回值,可以达到同样的目的

结论

谁还需要乏味老套的@objc和@autoclosure呢？还是算了吧！

❹ 了解什么叫做jit compiling，与传统的编译技术有何不同

java 应用程序的性能经常成为开发社区中的讨论热点。因为该语言的设计初衷是使用解释的方式支持应用程序的可移植性目标，早期
Java 运行时所提供的性能级别远低于 C 和
C++
之类的编译语言。尽管这些语言可以提供更高的性能，但是生成的代码只能在有限的几种系统上执行。在过去的十年中，Java
运行时供应商开发了一些复杂的动态编译器，通常称作即时（Just-in-time，JIT）编译器。程序运行时，JIT
编译器选择将最频繁执行的方法编译成本地代码。运行时才进行本地代码编译而不是在程序运行前进行编译（用 C 或
C++ 编写的程序正好属于后一情形），保证了可移植性的需求。有些 JIT 编译器甚至不使用解释程序就能编译所有的代码，但是这些编译器仍然通过在程序执行时进行一些操作来保持 Java 应用程序的可移植性。
由于动态编译技术的多项改进，在很多应用程序中，现代的 JIT 编译器可以产生与 C 或 C++
静态编译相当的应用程序性能。但是，仍然有很多软件开发人员认为 —— 基于经验或者传闻 ——
动态编译可能严重干扰程序操作，因为编译器必须与应用程序共享 CPU。一些开发人员强烈呼吁对 Java
代码进行静态编译，并且坚信那样可以解决性能问题。对于某些应用程序和执行环境而言，这种观点是正确的，静态编译可以极大地提高 Java
性能，或者说它是惟一的实用选择。但是，静态地编译 Java 应用程序在获得高性能的同时也带来了很多复杂性。一般的
Java 开发人员可能并没有充分地感受到 JIT 动态编译器的优点。

本文考察了 Java 语言静态编译和动态编译所涉及的一些问题，重点介绍了实时 (RT) 系统。简要描述了 Java
语言解释程序的操作原理并说明了现代 JIT 编译器执行本地代码编译的优缺点。介绍了 IBM 在 WebSphere Real Time 中发布的
AOT 编译技术和它的一些优缺点。然后比较了这两种编译策略并指出了几种比较适合使用 AOT
编译的应用程序领域和执行环境。要点在于这两种编译技术并不互斥：即使在使用这两种技术最为有效的各种应用程序中，它们也分别存在一些影响应用程序的优缺
点。

执行 Java 程序

Java 程序最初是通过 Java SDK 的 javac程序编译成本地的与平台无关的格式（类文件）。可将此格式看作 Java
平台，因为它定义了执行 Java 程序所需的所有信息。Java 程序执行引擎，也称作 Java 运行时环境（JRE），包含了为特定的本地平台实现
Java 平台的虚拟机。例如，基于 Linux 的 Intel x86 平台、Sun Solaris 平台和 AIX 操作系统上运行的 IBM
System p 平台，每个平台都拥有一个 JRE。这些 JRE 实现实现了所有的本地支持，从而可以正确执行为
Java 平台编写的程序。

事实上，操作数堆栈的大小有实际限制，但是编程人员极少编写超出该限制的方法。JVM 提供了安全性检查，对那些创建出此类方法的编程人员进行通知。

Java 平台程序表示的一个重要部分是字节码序列，它描述了 Java
类中每个方法所执行的操作。字节码使用一个理论上无限大的操作数堆栈来描述计算。这个基于堆栈的程序表示提供了平台无关性，因为它不依赖任何特定本地平台
的 CPU 中可用寄存器的数目。可在操作数堆栈上执行的操作的定义都独立于所有本地处理器的指令集。Java
虚拟机（JVM）规范定义了这些字节码的执行（参见 参考资料）。执行 Java 程序时，用于任何特定本地平台的任何 JRE 都必须遵守 JVM
规范中列出的规则。

因为基于堆栈的本地平台很少（Intel X87 浮点数协处理器是一个明显的例外），所以大多数本地平台不能直接执行 Java 字节码。为了解决这个问题，早期的 JRE 通过解释字节码来执行 Java 程序。即 JVM 在一个循环中重复操作：

◆获取待执行的下一个字节码；

◆解码；

◆从操作数堆栈获取所需的操作数；

◆按照 JVM 规范执行操作；

◆将结果写回堆栈。

这种方法的优点是其简单性：JRE 开发人员只需编写代码来处理每种字节码即可。并且因为用于描述操作的字节码少于 255 个，所以实现的成本比较低。当然，缺点是性能：这是一个早期造成很多人对 Java 平台不满的问题，尽管拥有很多其他优点。

解决与 C 或 C++ 之类的语言之间的性能差距意味着，使用不会牺牲可移植性的方式开发用于 Java 平台的本地代码编译。

编译 Java 代码

尽管传闻中 Java 编程的 “一次编写，随处运行”
的口号可能并非在所有情况下都严格成立，但是对于大量的应用程序来说情况确实如此。另一方面，本地编译本质上是特定于平台的。那么 Java
平台如何在不牺牲平台无关性的情况下实现本地编译的性能？答案就是使用 JIT 编译器进行动态编译，这种方法已经使用了十年（参见图 1）：

图 1. JIT 编译器

使用 JIT 编译器时，Java
程序按每次编译一个方法的形式进行编译，因为它们在本地处理器指令中执行以获得更高的性能。此过程将生成方法的一个内部表示，该表示与字节码不同但是其级
别要高于目标处理器的本地指令。（IBM JIT
编译器使用一个表达式树序列表示方法的操作。）编译器执行一系列优化以提高质量和效率，最后执行一个代码生成步骤将优化后的内部表示转换成目标处理器的本
地指令。生成的代码依赖运行时环境来执行一些活动，比如确保类型转换的合法性或者对不能在代码中直接执行的某些类型的对象进行分配。JIT
编译器操作的编译线程与应用程序线程是分开的，因此应用程序不需要等待编译的执行。

图 1 中还描述了用于观察执行程序行为的分析框架，通过周期性地对线程取样找出频繁执行的方法。该框架还为专门进行分析的方法提供了工具，用来存储程序的此次执行中可能不会改变的动态值。

因为这个 JIT 编译过程在程序执行时发生，所以能够保持平台无关性：发布的仍然是中立的 Java 平台代码。C 和 C++ 之类的语言缺乏这种优点，因为它们在程序执行前进行本地编译；发布给（本地平台）执行环境的是本地代码。

挑战

尽管通过 JIT 编译保持了平台无关性，但是付出了一定代价。因为在程序执行时进行编译，所以编译代码的时间将计入程序的执行时间。任何编写过大型 C 或 C++ 程序的人都知道，编译过程往往较慢。

为了克服这个缺点，现代的 JIT
编译器使用了下面两种方法的任意一种（某些情况下同时使用了这两种方法）。第一种方法是：编译所有的代码，但是不执行任何耗时多的分析和转换，因此可以快
速生成代码。由于生成代码的速度很快，因此尽管可以明显观察到编译带来的开销，但是这很容易就被反复执行本地代码所带来的性能改善所掩盖。第二种方法是：
将编译资源只分配给少量的频繁执行的方法（通常称作热方法）。低编译开销更容易被反复执行热代码带来的性能优势掩盖。很多应用程序只执行少量的热方法，因
此这种方法有效地实现了编译性能成本的最小化。

动态编译器的一个主要的复杂性在于权衡了解编译代码的预期获益使方法的执行对整个程序的性能起多大作用。一个极端的例子是，程序执行后，您非常清楚哪些方
法对于这个特定的执行的性能贡献最大，但是编译这些方法毫无用处，因为程序已经完成。而在另一个极端，程序执行前无法得知哪些方法重要，但是每种方法的潜
在受益都最大化了。大多数动态编译器的操作介于这两个极端之间，方法是权衡了解方法预期获益的重要程度。

Java 语言需要动态加载类这一事实对 Java
编译器的设计有着重要的影响。如果待编译代码引用的其他类还没有加载怎么办？比如一个方法需要读取某个尚未加载的类的静态字段值。Java
语言要求第一次执行类引用时加载这个类并将其解析到当前的 JVM
中。直到第一次执行时才解析引用，这意味着没有地址可供从中加载该静态字段。编译器如何处理这种可能性？编译器生成一些代码，用于在没有加载类时加载并解
析类。类一旦被解析，就会以一种线程安全的方式修改原始代码位置以便直接访问静态字段的地址，因为此时已获知该地址。

IBM JIT
编译器中进行了大量的努力以便使用安全而有效率的代码补丁技术，因此在解析类之后，执行的本地代码只加载字段的值，就像编译时已经解析了字段一样。另外一
种方法是生成一些代码，用于在查明字段的位置以前一直检查是否已经解析字段，然后加载该值。对于那些由未解析变成已解析并被频繁访问的字段来说，这种简单
的过程可能带来严重的性能问题。

动态编译的优点

动态地编译 Java 程序有一些重要的优点，甚至能够比静态编译语言更好地生成代码，现代的 JIT 编译器常常向生成的代码中插入挂钩以收集有关程序行为的信息，以便如果要选择方法进行重编译，就可以更好地优化动态行为。

关于此方法的一个很好的例子是收集一个特定 array操作的长度。如果发现每次执行操作时该长度基本不变，则可以为最频繁使用的

array长度生成专门的代码，或者可以调用调整为该长度的代码序列。由于内存系统和指令集设计的特性，用于复制内存的最佳通用例程的执行速度通
常比用于复制特定长度的代码慢。例如，复制 8
个字节的对齐的数据可能需要一到两条指令直接复制，相比之下，使用可以处理任意字节数和任意对齐方式的一般复制循环可能需要 10 条指令来复制同样的 8

个字节。但是，即使此类专门的代码是为某个特定的长度生成的，生成的代码也必须正确地执行其他长度的复制。生成代码只是为了使常见长度的操作执行得更快，
因此平均下来，性能得到了改进。此类优化对大多数静态编译语言通常不实用，因为所有可能的执行中长度恒定的操作比一个特定程序执行中长度恒定的操作要少得
多。

此类优化的另一个重要的例子是基于类层次结构的优化。例如，一个虚方法调用需要查看接收方对象的类调用，以便找出哪个实际目标实现了接收方对象的虚方法。
研究表明：大多数虚调用只有一个目标对应于所有的接收方对象，而 JIT
编译器可以为直接调用生成比虚调用更有效率的代码。通过分析代码编译后类层次结构的状态，JIT
编译器可以为虚调用找到一个目标方法，并且生成直接调用目标方法的代码而不是执行较慢的虚调用。当然，如果类层次结构发生变化，并且出现另外的目标方法，
则 JIT
编译器可以更正最初生成的代码以便执行虚调用。在实践中，很少需要作出这些更正。另外，由于可能需要作出此类更正，因此静态地执行这种优化非常麻烦。

因为动态编译器通常只是集中编译少量的热方法，所以可以执行更主动的分析来生成更好的代码，使编译的回报更高。事实上，大部分现代的
JIT
编译器也支持重编译被认为是热方法的方法。可以使用静态编译器（不太强调编译时间）中常见的非常主动的优化来分析和转换这些频繁执行的方法，以便生成更好
的代码并获得更高的性能。

这些改进及其他一些类似的改进所产生的综合效果是：对于大量的 Java 应用程序来说，动态编译已经弥补了与 C 和 C++ 之类语言的静态本地编译性能之间的差距，在某些情况下，甚至超过了后者的性能。

缺点

但是，动态编译确实具有一些缺点，这些缺点使它在某些情况下算不上一个理想的解决方案。例如，因为识别频繁执行的方法以及编译这些方法需要时间，所以应用
程序通常要经历一个准备过程，在这个过程中性能无法达到其最高值。在这个准备过程中出现性能问题有几个原因。首先，大量的初始编译可能直接影响应用程序的
启动时间。不仅这些编译延迟了应用程序达到稳定状态的时间（想象 Web
服务器经
历一个初始阶段后才能够执行实际有用的工作），而且在准备阶段中频繁执行的方法可能对应用程序的稳定状态的性能所起的作用也不大。如果 JIT
编译会延迟启动又不能显着改善应用程序的长期性能，则执行这种编译就非常浪费。虽然所有的现代 JVM
都执行调优来减轻启动延迟，但是并非在所有情况下都能够完全解决这个问题。

其次，有些应用程序完全不能忍受动态编译带来的延迟。如 GUI 接口之类交互式应用程序就是这样的例子。在这种情况下，编译活动可能对用户使用造成不利影响，同时又不能显着地改善应用程序的性能。

最后，用于实时环境并具有严格的任务时限的应用程序可能无法忍受编译的不确定性性能影响或动态编译器本身的内存开销。

因此，虽然 JIT 编译技术已经能够提供与静态语言性能相当（甚至更好）的性能水平，但是动态编译并不适合于某些应用程序。在这些情况下，Java 代码的提前（Ahead-of-time，AOT）编译可能是合适的解决方案。

AOT Java 编译

大致说来，Java 语言本地编译应该是为传统语言（如 C++ 或
Fortran）而开发的编译技术的一个简单应用。不幸的是，Java 语言本身的动态特性带来了额外的复杂性，影响了 Java
程序静态编译代码的质量。但是基本思想仍然是相同的：在程序执行前生成 Java 方法的本地代码，以便在程序运行时直接使用本地代码。目的在于避免
JIT 编译器的运行时性能消耗或内存消耗，或者避免解释程序的早期性能开销。

挑战

动态类加载是动态 JIT 编译器面临的一个挑战，也是 AOT
编译的一个更重要的问题。只有在执行代码引用类的时候才加载该类。因为是在程序执行前进行 AOT
编译的，所以编译器无法预测加载了哪些类。就是说编译器无法获知任何静态字段的地址、任何对象的任何实例字段的偏移量或任何调用的实际目标，甚至对直接调
用（非虚调用）也是如此。在执行代码时，如果证明对任何这类信息的预测是错误的，这意味着代码是错误的并且还牺牲了 Java 的一致性。

因为代码可以在任何环境中执行，所以类文件可能与代码编译时不同。例如，一个 JVM
实例可能从磁盘的某个特定位置加载类，而后面一个实例可能从不同的位置甚至网络加载该类。设想一个正在进行 bug
修复的开发环境：类文件的内容可能随不同的应用程序的执行而变化。此外，Java 代码可能在程序执行前根本不存在：比如 Java
反射服务通常在运行时生成新类来支持程序的行为。

缺少关于静态、字段、类和方法的信息意味着严重限制了 Java 编译器中优化框架的大部分功能。内联可能是静态或动态编译器应用的最重要的优化，但是由于编译器无法获知调用的目标方法，因此无法再使用这种优化。

内联

内联是一种用于在运行时生成代码避免程序开始和结束时开销的技术，方法是将函数的调用代码插入到调用方的函数中。但是内联最大的益处可能是优化方可见的代码的范围扩大了，从而能够生成更高质量的代码。下面是一个内联前的代码示例：

int foo() { int x=2, y=3; return bar(x,y); }final int bar(int a, int b) { return a+b; }

如果编译器可以证明这个 bar就是 foo()中调用的那个方法，则 bar中的代码可以取代 foo()中对
bar()的调用。这时，bar()方法是 final类型，因此肯定是 foo()中调用的那个方法。甚至在一些虚调用例子中，动态 JIT
编译器通常能够推测性地内联目标方法的代码，并且在绝大多数情况下能够正确使用。编译器将生成以下代码：

int foo() { int x=2, y=3; return x+y; }

在这个例子中，简化前名为值传播的优化可以生成直接返回
5的代码。如果不使用内联，则不能执行这种优化，产生的性能就会低很多。如果没有解析
bar()方法（例如静态编译），则不能执行这种优化，而代码必须执行虚调用。运行时，实际调用的可能是另外一个执行两个数字相乘而不是相加的
bar方法。所以不能在 Java 程序的静态编译期间直接使用内联。

AOT
代码因此必须在没有解析每个静态、字段、类和方法引用的情况下生成。执行时，每个这些引用必须利用当前运行时环境的正确值进行更新。这个过程可能直接影响
第一次执行的性能，因为在第一次执行时将解析所有引用。当然，后续执行将从修补代码中获益，从而可以更直接地引用实例、静态字段或方法目标。

另外，为 Java 方法生成的本地代码通常需要使用仅在单个 JVM 实例中使用的值。例如，代码必须调用 JVM
运行时中的某些运行时例程来执行特定操作，如查找未解析的方法或分配内存。这些运行时例程的地址可能在每次将 JVM 加载到内存时变化。因此 AOT
编译代码需要绑定到 JVM 的当前执行环境中，然后才能执行。其他的例子有字符串的地址和常量池入口的内部位置。

在 WebSphere Real Time 中，AOT 本地代码编译通过 jxeinajar工具（参见图 2）来执行。该工具对 JAR 文件中所有类的所有方法应用本地代码编译，也可以选择性地对需要的方法应用本地代码编译。结果被存储到名为 Java eXEcutable (JXE) 的内部格式中，但是也可轻松地存储到任意的持久性容器中。

您可能认为对所有的代码进行静态编译是最好的方法，因为可以在运行时执行最大数量的本地代码。但是此处可以作出一些权衡。编译的方法越多，代码占用的内存
就越多。编译后的本地代码大概比字节码大 10 倍：本地代码本身的密度比字节码小，而且必须包含代码的附加元数据，以便将代码绑定到 JVM
中，并且在出现异常或请求堆栈跟踪时正确执行代码。构成普通 Java 应用程序的 JAR
文件通常包含许多很少执行的方法。编译这些方法会消耗内存却没有什么预期收益。相关的内存消耗包括以下过程：将代码存储到磁盘上、从磁盘取出代码并装入
JVM，以及将代码绑定到 JVM。除非多次执行代码，否则这些代价不能由本地代码相对解释的性能优势来弥补。

图 2. jxeinajar

跟大小问题相违背的一个事实是：在编译过的方法和解释过的方法之间进行的调用（即编译过的方法调用解释过的方法，或者相反）可能比这两类方法各自内部之间
进行的调用所需的开销大。动态编译器通过最终编译所有由 JIT
编译代码频繁调用的那些解释过的方法来减少这项开销，但是如果不使用动态编译器，则这项开销就不可避免。因此如果是选择性地编译方法，则必须谨慎操作以使
从已编译方法到未编译方法的转换最小化。为了在所有可能的执行中都避免这个问题而选择正确的方法会非常困难。
优点
虽然 AOT 编译代码具有上述的缺点和挑战，但是提前编译 Java 程序可以提高性能，尤其是在不能将动态编译器作为有效解决方案的环境中。

可以通过谨慎地使用 AOT 编译代码加快应用程序启动，因为虽然这种代码通常比 JIT
编译代码慢，但是却比解释代码快很多倍。此外，因为加载和绑定 AOT
编译代码的时间通常比检测和动态编译一个重要方法的时间少，所以能够在程序执行的早期达到那样的性能。类似地，交互式应用程序可以很快地从本地代码中获
益，无需使用引起较差响应能力的动态编译。

RT 应用程序也能从 AOT 编译代码中获得重要的收益：更具确定性的性能超过了解释的性能。WebSphere Real Time
使用的动态 JIT 编译器针对在 RT 系统中的使用进行了专门的调整。使编译线程以低于 RT
任务的优先级操作，并且作出了调整以避免生成带有严重的不确定性性能影响的代码。但是，在一些 RT 环境中，出现 JIT
编译器是不可接受的。此类环境通常需要最严格的时限管理控制。在这些例子中，AOT
编译代码可以提供比解释过的代码更好的原始性能，又不会影响现有的确定性。消除 JIT
编译线程甚至消除了启动更高优先级 RT 任务时发生的线程抢占所带来的性能影响。

优缺点统计

动态（JIT）编译器支持平台中立性，并通过利用应用程序执行的动态行为和关于加载的类及其层次结构的信息来生成高质量的代码。但是
JIT
编译器具有一个有限的编译时预算，而且会影响程序的运行时性能。另一方面，静态（AOT）编译器则牺牲了平台无关性和代码质量，因为它们不能利用程序的动
态行为，也不具有关于加载的类或类层次结构的信息。AOT 编译拥有有效无限制的编译时预算，因为 AOT
编译时间不会影响运行时性能，但是在实践中开发人员不会长期等待静态编译步骤的完成。

表 1 总结了本文讨论的 Java 语言动态和静态编译器的一些特性：

表 1. 比较编译技术

两种技术都需要谨慎选择编译的方法以实现最高的性能。对动态编译器而言，编译器自身作出决策，而对于静态编译器，由开发人员作出选择。让
JIT 编译器选择编译的方法是不是优点很难说，取决于编译器在给定情形中推断能力的好坏。在大多数情况下，我们认为这是一种优点。

因为它们可以最好地优化运行中的程序，所以 JIT 编译器在提供稳定状态性能方面更胜一筹，而这一点在大量的生产 Java
系统中最为重要。静态编译可以产生最佳的交互式性能，因为没有运行时编译行为来影响用户预期的响应时间。通过调整动态编译器可以在某种程度上解决启动和确
定性性能问题，但是静态编译在需要时可提供最快的启动速度和最高级别的确定性。表 2 在四种不同的执行环境中对这两种编译技术进行了比较：

表 2. 使用这些技术的最佳环境

图 3 展示了启动性能和稳定状态性能的总体趋势：

图 3. AOT 和 JIT 的性能对比

使用 JIT 编译器的初始阶段性能很低，因为要首先解释方法。随着编译方法的增多及 JIT
执行编译所需时间的缩短，性能曲线逐渐升高最后达到性能峰值。另一方面，AOT 编译代码启动时的性能比解释的性能高很多，但是无法达到 JIT
编译器所能达到的最高性能。将静态代码绑定到 JVM 实例中会产生一些开销，因此开始时的性能比稳定状态的性能值低，但是能够比使用 JIT
编译器更快地达到稳定状态的性能水平。

没有一种本地代码编译技术能够适合所有的 Java
执行环境。某种技术所擅长的通常正是其他技术的弱项。出于这个原因，需要同时使用这两种编译技术以满足 Java
应用程序开发人员的要求。事实上，可以结合使用静态和动态编译以便提供最大可能的性能提升 —— 但是必须具备平台无关性，它是 Java
语言的主要卖点，因此不成问题。

结束语

本文探讨了 Java 语言本地代码编译的问题，主要介绍了 JIT 编译器形式的动态编译和静态 AOT 编译，比较了二者的优缺点。

虽然动态编译器在过去的十年里实现了极大的成熟，使大量的各种 Java 应用程序可以赶上或超过静态编译语言（如 C++ 或
Fortran）所能够达到的性能。但是动态编译在某些类型的应用程序和执行环境中仍然不太合适。虽然 AOT
编译号称动态编译缺点的万能解决方案，但是由于 Java 语言本身的动态特性，它也面临着提供本地编译全部潜能的挑战。

这两种技术都不能解决 Java 执行环境中本地代码编译的所有需求，但是反过来又可以在最有效的地方作为工具使用。这两种技术可以相互补充。能够恰当地使用这两种编译模型的运行时系统可以使很大范围内的应用程序开发环境中的开发人员和用户受益。

❺ C语言中使用inline函数会降低cache命中率么

inline vs. __forceinline

MS Visual C++, 以及其它几种编译器，提供了一个非标准的用于控制函数内嵌（inline）的关键字，作为对标准关键字inline的补充。为什么要添加这个非标准关键字呢？先让我们来看看inline的一些局限，决定一个声明为inline的函数是否真的进行嵌入，完全取决于编译器的判断。因此inline只是一个建议，在一些情况下，比如在一些内嵌函数中包含有循环或是这个函数体太大了，那么即使这个函数声明为inline，编译器也将拒绝这个函数的嵌入。

与此相反，非标准关键字__forceinline 将忽略编译器的判断并强迫编译器去嵌入一个它本该拒绝嵌入的函数。我不太肯定使用这个关键字的意义，它可能会使可执行文件变得臃肿并降低cache的命中率。幸运的是，在一些极端条件下，编译器可能不接受__forceinline的任何请求。所以，一般情况下最好是使用标准的inline，inline是可移植的并且让编译器去做出“正确的选择”。
__forceinline 只应在下列条件全为真的情况下使用：inline不被编译器接受；你的代码不需要向其它平台进行移植；并且你能肯定嵌入这个函数会提高性能。

❻ 如何减少C++编写程序的CPU使用率

优化是一个非常大的主题，本文并不是去深入探讨性能分析理论，算法的效率，况且我也没有这个能力。我只是想把一些可以简单的应用到你的C++代码中的优化技术总结在这里，这样，当你遇到几种不同的编程策略的时候，就可以对每种策略的性能进行一个大概的估计。这也是本文的目的之所在。

一. 优化之前

在进行优化之前，我们首先应该做的是发现我们代码的瓶颈（bottleneck）在哪里。然而当你做这件事情的时候切忌从一个debug- version进行推断，因为debug-version中包含了许多额外的代码。一个debug-version可执行体要比release- version大出40%。那些额外的代码都是用来支持调试的，比如说符号的查找。大多数实现都为debug-version和release- version提供了不同的operator new以及库函数。而且，一个release-version的执行体可能已经通过多种途径进行了优化，包括不必要的临时对象的消除，循环展开，把对象移入寄存器，内联等等。

另外，我们要把调试和优化区分开来，它们是在完成不同的任务。 debug-version 是用来追捕bugs以及检查程序是否有逻辑上的问题。release-version则是用来做一些性能上的调整以及进行优化。

下面就让我们来看看有哪些代码优化技术吧：

二. 声明的放置

程序中变量和对象的声明放在什么位置将会对性能产生显着影响。同样，对postfix和prefix运算符的选择也会影响性能。这一部分我们集中讨论四个问题：初始化v.s 赋值，在程序确实要使用的地方放置声明，构造函数的初始化列表，prefix v.s postfix运算符。

（1）请使用初始化而不是赋值

在C语言中只允许在一个函数体的开头进行变量的声明，然而在C++中声明可以出现在程序的任何位置。这样做的目的是希望把对象的声明拖延到确实要使用它的时候再进行。这样做可以有两个好处：1. 确保了对象在它被使用前不会被程序的其他部分恶意修改。如果对象在开头就被声明然而却在20行以后才被使用的话，就不能做这样的保证。2. 使我们有机会通过用初始化取代赋值来达到性能的提升，从前声明只能放在开头，然而往往开始的时候我们还没有获得我们想要的值，因此初始化所带来的好处就无法被应用。但是现在我们可以在我们获得了想要的值的时候直接进行初始化，从而省去了一步。注意，或许对于基本类型来说，初始化和赋值之间可能不会有什么差异，但是对于用户定义的类型来说，二者就会带来显着的不同，因为赋值会多进行一次函数调用----operator =。因此当我们在赋值和初始化之间进行选择的话，初始化应该是我们的首选。

（2）把声明放在合适的位置上

在一些场合，通过移动声明到合适的位置所带来的性能提升应该引起我们足够的重视。例如：

bool is_C_Needed();
void use()
{
C c1;
if (is_C_Needed() == false)
{
return; //c1 was not needed
}
//use c1 here
return;
}

上面这段代码中对象c1即使在有可能不使用它的情况下也会被创建，这样我们就会为它付出不必要的花费，有可能你会说一个对象c1能浪费多少时间，但是如果是这种情况呢：C c1[1000];我想就不是说浪费就浪费了。但是我们可以通过移动声明c1的位置来改变这种情况：

void use()
{
if (is_C_Needed() == false)
{
return; //c1 was not needed
}
C c1; //moved from the block's beginning
//use c1 here
return;
}

怎么样，程序的性能是不是已经得到很大的改善了呢？因此请仔细分析你的代码，把声明放在合适的位置上，它所带来的好处是你难以想象的。

（3） 初始化列表

我们都知道，初始化列表一般是用来初始化const或者reference数据成员。但是由于他自身的性质，我们可以通过使用初始化列表来实现性能的提升。我们先来看一段程序：

class Person
{
private:
C c_1;
C c_2;
public:
Person(const C& c1, const C& c2 ): c_1(c1), c_2(c2) {}
};

当然构造函数我们也可以这样写：

Person::Person(const C& c1, const C& c2)
{
c_1 = c1;
c_2 = c2;
}

那么究竟二者会带来什么样的性能差异呢，要想搞清楚这个问题，我们首先要搞清楚二者是如何执行的，先来看初始化列表：数据成员的声明操作都是在构造函数执行之前就完成了，在构造函数中往往完成的只是赋值操作，然而初始化列表直接是在数据成员声明的时候就进行了初始化，因此它只执行了一次 constructor。再来看在构造函数中赋值的情况：首先，在构造函数执行前会通过default constructor创建数据成员，然后在构造函数中通过operator =进行赋值。因此它就比初始化列表多进行了一次函数调用。性能差异就出来了。但是请注意，如果你的数据成员都是基本类型的话，那么为了程序的可读性就不要使用初始化列表了，因为编译器对两者产生的汇编代码是相同的。

（4）postfix VS prefix 运算符

prefix运算符++和—比它的postfix版本效率更高，因为当postfix运算符被使用的时候，会需要一个临时对象来保存改变以前的值。对于基本类型，编译器会消除这一份额外的拷贝，但是对于用户定义类型，这似乎是不可能的。因此请你尽可能使用prefix运算符

三. 内联函数

内联函数既能够去除函数调用所带来的效率负担又能够保留一般函数的优点。然而，内联函数并不是万能药，在一些情况下，它甚至能够降低程序的性能。因此在使用的时候应该慎重。

1．我们先来看看内联函数给我们带来的好处：从一个用户的角度来看，内联函数看起来和普通函数一样，它可以有参数和返回值，也可以有自己的作用域，然而它却不会引入一般函数调用所带来的负担。另外，它可以比宏更安全更容易调试。

当然有一点应该意识到，inline specifier仅仅是对编译器的建议，编译器有权利忽略这个建议。那么编译器是如何决定函数内联与否呢？一般情况下关键性因素包括函数体的大小，是否有局部对象被声明，函数的复杂性等等。

2．那么如果一个函数被声明为inline但是却没有被内联将会发生什么呢？理论上，当编译器拒绝内联一个函数的时候，那个函数会像普通函数一样被对待，但是还会出现一些其他的问题。例如下面这段代码：

// filename Time.h
#include
#include
using namespace std;
class Time
{
public:
inline void Show() { for (int i = 0; i<10; i++) cout< };

因为成员函数Time::Show()包括一个局部变量和一个for循环，所以编译器一般拒绝inline，并且把它当作一个普通的成员函数。但是这个包含类声明的头文件会被单独的#include进各个独立的编译单元中：

// filename f1.cpp
#include "Time.hj"
void f1()
{
Time t1;
t1.Show();
}

// filename f2.cpp
#include "Time.h"
void f2()
{
Time t2;
t2.Show();
}
结果编译器为这个程序生成了两个相同成员函数的拷贝：

void f1();
void f2();
int main()
{
f1();
f2();
return 0;
}

当程序被链接的时候，linker将会面对两个相同的Time::Show()拷贝，于是函数重定义的连接错误发生。但是老一些的C++实现对付这种情况的办法是通过把一个un-inlined函数当作static来处理。因此每一份函数拷贝仅仅在自己的编译单元中可见，这样链接错误就解决了，但是在程序中却会留下多份函数拷贝。在这种情况下，程序的性能不但没有提升，反而增加了编译和链接时间以及最终可执行体的大小。

但是幸运的是，新的C++标准中关于un-inlined函数的说法已经改变。一个符合标准C++实现应该只生成一份函数拷贝。然而，要想所有的编译器都支持这一点可能还需要很长时间。

另外关于内联函数还有两个更令人头疼的问题。第一个问题是该如何进行维护。一个函数开始的时候可能以内联的形式出现，但是随着系统的扩展，函数体可能要求添加额外的功能，结果内联函数就变得不太可能，因此需要把inline specifier去除以及把函数体放到一个单独的源文件中。另一个问题是当内联函数被应用在代码库的时候产生。当内联函数改变的时候，用户必须重新编译他们的代码以反映这种改变。然而对于一个非内联函数，用户仅仅需要重新链接就可以了。

这里想要说的是，内联函数并不是一个增强性能的灵丹妙药。只有当函数非常短小的时候它才能得到我们想要的效果，但是如果函数并不是很短而且在很多地方都被调用的话，那么将会使得可执行体的体积增大。最令人烦恼的还是当编译器拒绝内联的时候。在老的实现中，结果很不尽人意，虽然在新的实现中有很大的改善，但是仍然还是不那么完善的。一些编译器能够足够的聪明来指出哪些函数可以内联哪些不能，但是，大多数编译器就不那么聪明了，因此这就需要我们的经验来判断。如果内联函数不能增强行能，就避免使用它.