一、前言
AWS EC2计算实例同时提供了Intel和AMD的产品，在申请EC2实例时候，尾号带有小写a的就是AMD的，不带a的就是Intel的。如下截图，红色区域有标注。
那么，该怎么选择呢？
AWS官方介绍的产品系列如下截图。
在选择时候，AMD和Intel的实例价格有一定差异，因此这里做一个简单性能测试。
二、产品解析
1、测试前提
（1）本文以通用计算型m5实例为例，选比4xlarge，即16CPU/64GB内存，规格较大的，适合应用系统各种中间件的场景。
（2）本文不选择t系列突发实例，因此这里不研究t系列如何积攒CPU积分，如何平时不忙碌然后突发忙碌花掉积分这个话题。有兴趣可以看这里的文档对突发实例的原理描述。
（3）测试地点选AWS 海外新加坡，ap-southeast-1区域。测试时间2019年9月。
（4）本次测试主要考察CPU的整数运算能力，适合企业应用场景，不测试视频、图像渲染等领域需要的浮点预算能力。此外，不使用复杂的benchmark套件测试内存、网络、磁盘等。测试工具为软件包源直接安装，预先build好，不做build过程的调参数。
2、处理器内核与超线程
AWS上的EC2实例除个别低端特殊型号外，绝大部分实例的定义是：一个vCPU就是一个线程。通俗的说，一个虚拟机有8个vCPU，16GB内存，其实它对应的是4core，每个core有2个线程。点击这里的这篇文章有详细讲解。
在创建EC2时候，选定规格之后，其实是可以指定内核数和线程数的。当然指定的过程没有vCenter那么任性，VMware组合姿势繁多，什么几个socket几个core等。AWS的EC2配置选项的位置需要手工先选中“Specify CPU options”，就可以调整。如下截图。
以本次测试创建的m5.4xlarge型号为例，有16个vCPU。配置过程可能是如下情况：
- 默认，按照1个内核2线程配置，总vCPU数量16个
- 打开超线程，内核数设为8，1个处理器2个内核，总vCPU为16个
- 打开超线程，内核数设为6，1个处理器2个内核，总vCPU为12个
- 打开超线程，内核数设为4，1个处理器2个内核，总vCPU为8个
- 打开超线程，内核数设为2，1个处理器2个内核，总vCPU为4个
- 关闭超线程，内核数设为8，1个处理器1个内核，总vCPU为8个
- 关闭超线程，内核数设为6，1个处理器1个内核，总vCPU为6个
- 关闭超线程，内核数设为4，1个处理器1个内核，总vCPU为4个
- 关闭超线程，内核数设为2，1个处理器1个内核，总vCPU为2个
通过以上信息可以看出，CPU可以降低配置，不超过选择实例规格的4xlarge限制的上限16个vCPU即可。不过不管怎么配置，AWS计费都是按照4xlarge的规格计费。
本文测试直接选默认值，8个core，每个core 2个线程，总计16vCPU。
三、测试工具
1、安装
测试使用sysbench工具。sysbench工具可以压CPU内存、磁盘、网络、数据库等。代码在这里。
注意：AWS上的CentOS、Redhat Enterprise Linux、Amazon Linux 2默认的源不包含这个包，Ubuntu 18.04是包含的可以在线安装。如果使用Amazon Linux 2，可以使用额外的扩展源安装。命令如下。
amazon-linux-extras install epel
yum update -y
yum install sysbench安装过程如下截图。
这里需要补充一下，amazon-linux-extras 是个好东西。Amazon Linux 2 本身是基于CentOS 7的发行版，yum就能装好大部分。但少数包太老了，需要高版本的又不想build，也不想在生产环境上随意去找第三方的binary包。就算拿过来第三方的Source RPM，还要自己编译一遍，也不方便。那么用Amazon Linux，这个额外的extra包含了很多工具的多个版本，部署简单多了。这也是我开始基本上只用Amazon Linux 2的理由之一。
2、使用
Sysbench压CPU的方式是算素数，又叫分解质因数。先设定一个范围，例如1～10000，程序开始逐个计算确认是不是质数，其实就是一个个强行除法分解。然后从1到10000都算完毕了，这是一个event。然后，重复继续跑第二次，每算完一次1～10000的区间就叫一个event。
性能对比是看指定时间内，谁跑的event多，谁的性能高。或者反之，限制event次数，谁先跑完，谁快。本次测试用的是限制时间，谁跑的event多，谁性能高的方法。
测试脚本如下：
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=1 run解释如下。
- 参数 –cpu-max-prime=100000 是指定素数的范围，如果不指定默认数值是10000，这里改到100000
- 参数 –time=60 是程序跑满60秒，谁算的event多，谁的性能好。如果不指定，默认是10秒，这里改到1分钟
- 参数 –threads=1 是线程数
于是在这个脚本上，分别用线程1，2，4，8，16，32跑性能看看，且分别在Intel和AMD处理器的实例上运行。
下边开始测试。
四、测试过程
1、查看CPU信息
使用ssh登陆上去，运行lscpu命令可以看到CPU的信息。
例如采用AMD处理器的m5a.4xlarge信息如下截图。注：图中的参数BogoMIPS也是一个处理器性能标称值。
采用Intel处理器的m5.4xlarge实例的CPU信息如下截图。
2、各线程下测试
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=1 run > /var/www/html/threads-1.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=2 run > /var/www/html/threads-2.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=4 run > /var/www/html/threads-4.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=8 run > /var/www/html/threads-8.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=16 run > /var/www/html/threads-16.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=32 run > /var/www/html/threads-32.txt测试结果收集起来写入到/var/www/html/下，可以直接挂在web server上，不需要ssh登录也能看到结果。
五、小结
1、规格对比
仅从CPU规格来看，对比如下。
| 对比项目 | m5 | m5a |
| 处理器 | Platinum 8175M CPU | AMD EPYC 7571 |
| 基础频率 | 3100.886MHz | 2231.147MHz |
| 一级缓存 L1d | 32KB | 64KB |
| 一级缓存 L1i | 32KB | 32KB |
| 二级缓存 | 1024KB | 512KB |
| 三级缓存 | 33792KB | 8192KB |
| BogoMIPS | 4999.99 | 4399.34 |
从AMD的官网查询结果来看，7571是一款定制处理器，并未对外零售，只在提供给AWS等合作伙伴使用。官方的型号规格见这里。
这种定制处理器的情况还是很常见的，Apple家的Macbook Pro也是各种定制i5、i7处理器型号。尤其是i5高主频版本是零售市场见不到的。
同样经过查询，Intel的8175M也是一款定制处理器，在Intel官网ARK上并看不到这款处理器。
两款定制处理器之争，看下测试结果。
2、测试结果
以下是m5实例Intel CPU的测试结果。
这里除了可以看到总共跑了38770个Event之外，还可以看到每个Event的最大时间、最小时间、平均时间。这个数字区间约接近，浮动越小，说明处理器的调度能力越好。
总结，把两种处理器的数据汇总如下。
| 线程数 | Intel | AMD |
| 1 | 2779 | 3470 |
| 2 | 5555 | 6919 |
| 4 | 11111 | 11920 |
| 8 | 22211 | 23849 |
| 16 | 38770 | 24461 |
| 32 | 38905 | 24490 |
将上述信息转为折线图。
从以上测试数据在配合上趋势可以看出：
- 由于EC2实例默认都是开启超线程，每个内核2个线程的，因此本次测试的16vCPU实际是8内核2线程。
- 在单线程和线程数较少的情况下，AMD处理器有一定的优势。
- 当测试线程数跑到8线程时候，还是可以跑满AMD处理器的能力，AMD依然小幅领先。
- 当来到16线程时候，处理器已经没有物理Core了，是虚拟机出来的超线程，此时Intel发挥了碾压的优势，将AMD摔在身后。
- 继续施压到32线程，可以发现处理能力几乎不在上升了。这是因为处理器算上超线程就16个线程的能力，强行施压基本上就是排队，而不会有计算效能显著提升。
另外一个角度来看，存在一定可能是本次测试使用的sysbench在多线程优化上完全是按照intel来做的，并没有给AMD做任何调优。看起来可能有些不够公平。但是换一个角度，可能很多通用软件也并未给AMD做任何调优，都是从源上直接downlad binary包下来跑。这个时候，AMD处理器在多线程跑的比较高负载时候的性能劣势就体现出来了。
本次测试也不能代表全部，并且还有浮点运算场景，以及完整的benchmark还应该结合内存吞吐、磁盘IO、网络吞吐（数据中心内网）等因素，并施以一定的权重比例区评测。因此本测试只是单纯的一个方面来考察下两款处理器之间的能力。从AWS将AMD本身定价比Intel便宜10%这个来看，AMD的在不敏感不是满负载的普通企业应用场景下，还是有成本优势的，可以选择。而且使用云的一个特点就是灵活，真的负载上来了遇到性能不好，或者水平扩展，或者直接migrate到Intel处理器规格，都可以灵活的迁移。当看中成本优化时，而且资源量较多时候，10%还是一个比较客观的数字的。
全文完。