AWS 出了 ARM 架构的云服务

[kljsandjb]

https://www.cnbc.com/2018/11/26/aws-launches-arm-based-server-chips.html

[likuku]

官方消息页：
https://aws.amazon.com/cn/blogs/aws/new-ec2-instances-a1-powered-by-arm-based-aws-graviton-processors/

[echo1937]

云服务的这个体量，真的是能改变业界的格局，希望 arm 架构在服务器市场也能走好啊。

[likuku]

@echo1937 省电，便宜，在微服务 /server less 时代，动态使用大量小强一样的 arm 虫群，也是可以得了……对上下游厂商和消费者都很有好处吧。

性能嘛，也不用太过担心…如今主流手机（非旗舰）性能已经超越 3 年前 mac 笔电了。

[likuku]

自己家用 arm 树莓派也算好几年了，个人觉得除了性能弱，用起来和 x86 机器完全没差别（ debian ）

[echo1937]

@likuku #4 树莓派的性能太弱啦

[leafleave]

对于架梯子这种小服务 arm 足够了，希望能便宜点

[zn]

@likuku 手机和 PC 性能还是差得挺远的。

[datou]

@likuku 你莫不是被苹果忽悠瘸了....

苹果说的是 2018 款 iPad Pro 的性能超越了部分笔记本电脑

并没有说 iPhone

[likuku]

@leafleave 上面我贴的 aws 官网页面有价格表，然而并没有觉得更便宜... Orz

[likuku]

@zn @datou 请看清我 #3 的回复吧。我也并没有说是 iphone，也没说是 ipad pro，我也说明是 “ 3 年前 mac 笔电”

友人自己对评测软件结果的感概罢了。

[Showfom]

@likuku 感觉这个性能只是苹果给自己的自慰吧

[zn]

@likuku 我看的很清楚， [如今主流手机（非旗舰）性能已经超越 3 年前 mac 笔电了] ，我给你看看三年前的 mac 笔电是什么水平：

3 年前的 Mac 笔电的电池容量：6500mah * 11.4v = 74.1Wh ，全功率运行大约能支持一个小时，峰值功率将近 70W。
如今主流手机电池容量约 4000mah * 3.7v = 14Wh，全功率运行也是大约能支持一个小时，峰值功率 14W。

70/14=5 倍的功率差距，这不是差不多，这是远远甩开的概念。

就算 ARM 能耗性能比高出一倍，那还是有 2.5 倍的性能差距。


以上讨论仅针对手机和笔记本，仅讨论 CPU 性能（ GPU 就更加不要比了）。

[tsui]

@zn 笼统这么算没什么价值，来个实际 use case 2 分钟 4k -> 1080p
iPhone XS: 40 秒左右
2012 MBP: 接近 12 分钟
2015 MBP: 3 分钟

[yexm0]

又见拿 arm 去跟 x86 比的。。。

[zn]

@likuku 又特意去查了一下，结论如下：

A11 仿生的单线程性能约等于 i3 低压版 CPU 的性能。
至于别的手机？被 A11 压在身下动弹不得呢。。。。

[zn]

@tsui 你这个比较才没什么价值。这种视频处理都有专用硬件加速处理器来处理的，CPU 只是辅助。

而且，都是 1080p，里面道道很多的，大约有二三十个参数可以控制输出质量，而编码质量是直接影响编码速度的。

[tsui]

@zn 呵呵哒，小学算数估算功耗 10 年前的 Dell 笔记本性能更强，当年那些可都是 150W 的电源适配器

实际使用上 MacBook 的 m3 性能完全过得去，再说你以为 MacBook 现在的 i5 是真 i5 么

[zn]

@tsui 呵呵哒，相同制程下，性能还真和能耗大致成正比。

[zn]

@tsui 哦，补充一下， [A11 仿生的单线程性能约等于 i3 低压版 CPU 的性能] ，看好我说的是什么：低压版 CPU，低压版，低压版。

然后呢，MacBook 上的 i5 就是低压版 i5。

[txydhr]

@zn lol

[txydhr]

@yexm0 不，是苹果先比的

[yksoft1]

@tsui 硬压打软压就算了。

[laxenade]

aws 现在越来越随性了，都已经推出真·云服务 ground station。

[likuku]

对比 CPU RAM 相近 EC2 产品的价格，当前 ARM 实例并无明显优势，US East 相近规格最便宜是 t3.small，
只能希望未来 ARM 上架足够多，批量上去后能降价吧。

US East (N. Virginia)

Instance Name: a1.medium
vCPUs: 1
ECU: NA
RAM: 2 GiB
EBS Bandwidth: Up to 3.5 Gbps
Network Bandwidth: Up to 10 Gbps
On-Demand Price/Hour :$0.0255

Instance Name: t3.small
vCPUs: 2
ECU: Variable
RAM: 2 GiB
EBS Only
On-Demand Price/Hour : $0.0208

Instance Name: t2.small
vCPUs: 1
ECU: Variable
RAM: 2 GiB
EBS Only
On-Demand Price/Hour : $0.023

[bp0604]

树莓派目前还不怎么好用, arm 有太多的东西与 x86 不兼容

[kzfile]

那么问题来了,什么类型的应用不适合跑在 arm 上呢?
什么类型的应用根本跑不在 arm 上呢?

[phithon]

aws 的没用过，正在用另一家的 ARM 架构的 vps，最直观的感觉是编译东西慢了很多（虽然是 4 核 2G，但没有我其他 1 核 1G 的快）。因为跑得是个人应用，消耗不大，所以暂时没感觉到其他的问题。

[kljsandjb]

@likuku #24 价格确实不便宜，没券烧根本不会想着去尝试😂

[jonsun30]

@phithon 哪家的？ Scaleway ？

[likuku]

#28 @kljsandjb 临时测个东西什么也还好，按秒计费，手勤快点，测完立马删机器，花销也尚可。

[kljsandjb]

@likuku #30 确实是这样，不过家里放了俩树莓派，一个 32bit 一个 64bit，用腾讯云学生机做了 frp 也够平时学习用了，可能我需求也没那么多😄

[likuku]

@phithon #27 可惜当前 aws 价格表里，这些新的 arm 实例还没有 ECU 的信息参考(可以当作实际算力指数)

[likuku]

@kljsandjb #31 树莓派 64bit 系统支持的软件包覆盖 32bit 够高了么？我竟然才知道 64bit 系统已经可用了... Orz

[kljsandjb]

@likuku #33 64 内核自己编译一下是可以的～也不算特别麻烦

[kljsandjb]

@likuku #33 软件包覆盖不敢说，这个也许我用的不算多吧，就正常 gnu 组件对我就够了，其他的其实也多多少少有了

[kljsandjb]

@likuku #33 今天开了一个 aws 的 arm 服务器，64bit ubuntu，可以试试先😂

[zn]

@likuku 亚马逊敢上这种服务器，说明性能肯定是达到基础要求的，这种用来做服务器的 CPU，也肯定不是手机上用那种弱鸡 CPU。

[zn]

@txydhr 很想知道你笑什么，愿闻高见。

[likuku]

@kljsandjb #34 #35 查了一阵资料，发觉当前即便在 pi3B+ 上跑完整的纯 arm64 系统 (内核与所有软件) 效能并没有明显提高，放弃，安于已经用很久的 32bit 系统和软件了，不折腾了。

[kljsandjb]

@likuku #39 是的，受限于硬件，我不过是有其他用途罢了，不建议折腾😂

[likuku]

@zn 可能我需求低吧，当前主流手机 CPU 我已经满足了，aws 这回弄出这个定制 arm 应该是不会差到哪，

假若继续保持 arm 的节能优势，那么给 aws 降低成本就相当可观了。

[kljsandjb]

https://i.loli.net/2018/11/28/5bfe77700890b.png 补张图

[zn]

@likuku 手机 CPU 和服务器 CPU 考虑的问题完全不一样，所以性能差异那不是一般大，其实没什么可比性的。硬要比的话，顶级手机 CPU 和顶级服务器 CPU 性能差距可能差一百倍是有的。

[likuku]

@kljsandjb #42 你这个是用啥测的？能不能再跑个 unixbench ？哪个区域的？谢谢！

我等会去同区开台接近的 x86 机器也测下，好做个对比。

[likuku]

@kljsandjb #42 补，ubuntu 是 aws 官方的镜像么？

[kljsandjb]

@likuku
1. wget -qO- bench.sh | bash
2. 回头我测一下
3. us-west
4. 是官方镜像

[phithon]

@jonsun30 是的

[kljsandjb]

@likuku

error: snap "unixbench" is not available on stable for this architecture
(arm64) but exists on other architectures (amd64, armhf, i386).

暂时测不起来

[txydhr]

@zn 笑苹果这理论牛逼

[zn]

@txydhr 本质上都是计算，所以肯定是可以量化的，可以量化那自然就可以比较。

当然了，直接比不好比，毕竟架构不一样。

但是可以把浮点性能，定点性能等指标单独拿出来比比较，然后各项指标做加权，得出一个综合性能，就可以比了。

这个应该没什么可争的吧？需要争论的是各项指标的权重，这个争议会比较大。

[likuku]

@kljsandjb 额... 好吧，我先研究下如何用 gromacs 这个 分子动力学模拟软件 来做测试，看到有人拿它作性能参考。

树莓派上 rasbian 9 的 apt 源是可以直接装 gromacs 的。

[likuku]

@kljsandjb #48 补，

想法来源:
树莓派官方 32bit 系统和 Pi64 系统性能测试 - weixin_38412284 的博客 - CSDN 博客 : https://blog.csdn.net/weixin_38412284/article/details/79900850

gromacs 的 Regression Tests 说明：
Regression Tests - Gromacs : http://www.gromacs.org/Developer_Zone/Programming_Guide/Regression_Tests?highlight=regression+test

[likuku]

@kljsandjb #48 apt 源里的完全没用的，不要浪费时间。我还是在已有的测试机 debian 9 按官方文档源码编译中...

Installation guide — GROMACS 2018 documentation : http://manual.gromacs.org/documentation/2018/install-guide/index.html

然后，看到这篇，这里的 make check 步骤正式可以拿来当基准测试的:
阿就操場啊~: 安裝 GROMACS-5.1.2 在 Ubuntu Gnome : https://2formosa.blogspot.com/2016/05/linuxgromacs-512.html

[zhuang]

简单说，计算密集型的应用场景，在软件配套跟得上的情况下，用 arm 比 x86 要更合适，网络 DPDK 相关的也可以考虑，IO 密集型还是 x86 更好。

所谓的软件配套一方面是指 arm64 二进制源，这方面最近一两年进步非常大，不是大问题。重点在于 arm 架构是弱一致的内存模型，有指令集支持的计算效能非常高，基于 c 的编译代码优化也尚可，但依赖 jit 或者是优化尚不到位的 golang 等效率就很低，虚拟化涉及内存模型所以效率也很低。

现阶段 arm/x86 的主要区分并非指令集和效能，而是平台和生命周期。关于 arm/x86 的细节对比我会再开帖子详细说明。

[whileFalse]

@zhuang 同样优化到位的计算场景，核心数相同下 arm 能比 x86 性能好吗？抑或只是 arm 便宜靠堆核心压制 x86 ？

[kevinhwang]

如果价格能做的更低就好了。
梯子和内网穿透都需要公网 ip 却不占用太多资源，arm 性能足够。
非常看好 arm 集群，期待后续的推广。

[tempdban]

@zhuang 老哥，dpdk 也是 io 密集的

[mengzhuo]

@zhuang Go 优化不到位我严重不同意啊，Cloudflare、arm 中国那波大牛们写了这么多优化你都没体会到？

x86 还是胜在各种软硬件优化，流水线也比公版 arm 深也多，自然比 arm 快，arm 需要到 v8.3 上 SVE 加上软件优化估计能和同频率 x86 拼一把，不过 x86 和 ppc64 也是垃圾（狗头

绝大部分人接触的中低端 IT 从来都是农村包围城市，跟当年 intel 战胜 IBM 一样，历史总是相似的，所以大家等着 arm 或者更便宜的 riscv 占领市场吧。

[bsidb]

现在 Phoronix 已经放出了[Benchmark 的结果]( https://www.phoronix.com/scan.php?page=article&item=ec2-graviton-performance&num=1)，同时对比了 x86 的几款处理器的性能。

[qping]

@kljsandjb #42 兄弟，这是啥管理界面？

[kljsandjb]

@qping #60 就命令行啊，运行一下脚本就这个样子

[zhuang]

@tempdban 主要是 arm 平台 IO 外设缺少统一的接口，IO 设备要么用不上，能用上的情况下 DPDK 软件支持还是到位的。

@mengzhuo 这里说的优化是从 go 编译到 arm 二进制的过程，相比 gcc/clang 的优化不到位，当然近一年来的进步很明显了，但是考虑到 arm 平台的多样性，有没有针对特定处理器的优化会导致结果差别很大。优化的重点是 SIMD 方面，arm 和 x86 在内存模型上有先天差异，缓存读取 x86 只要一条指令，而 arm 需要几条，所以针对 arm 特定架构利用 SIMD 的优势会成倍影响运行效率。

[mengzhuo]

@zhuang 主流 AES-GCM，sha1，sha2，CRC32，MD5 没优化好？张口就来 Go 优化不到位，好歹给个 benchmark，要不然我很受伤。
arm 平台是多样，但服务器领域是基本没差，除了三星这朵大小核都偷工减料的奇葩。
而且 armv8 都有 Neon，不知道你特定处理器优化是几个意思（是想说指定架构优化?）
-----------
v 站大牛太多，不敢多说了

[zhuang]

@mengzhuo

1. Go crypto arm64 今年四月份才有补丁使用 AES 硬件指令，八月底随 Go 1.11 发布。

2. Go arm64 的短板在于 Go 编译器没有 auto vectorization 特性，非特殊优化的计算任务极大概率没有用到 SIMD 相关指令。

3. NEON FP 是非标准的 IEEE 浮点实现，可能会损失精度，包括 gcc aarch64 在内，启用 NEON 都是 opt in 行为。ARM 官方库 Ne10 并没有 Go 版本。

4. 特定处理器优化可参考 gcc 针对 ThunderX 的修正，调整寄存器使用和缓存对齐等等涉及硬件实现的参数，能够带来超过 10% 的性能影响。绝大多数 arm soc 都是在其商业寿命周期结束之后才获得开源软件支持的。

5. 好好说话。

[mengzhuo]

@zhuang

1. 不知道你回这个什么意思……这我当然知道啊，arm64 aeshash 也是我 5 月份加上去的。再说 Go 才 9 岁，armv8 也才出来 7 年，要不是今年 arm 中国为了支持更多语言工具链，明年都还用不上。

2. 自动向量化应该是 SSA 的工作，Go 的 x86 实现也没有这个，但绝大部分针对[]byte 的并行已经用了 NEON 优化方案（看 internal/bytealg ），位操作（ xor，and ）现在是 Go 官方人手不够 review，我 10 月份已经提交最后版本了。

3. 没有实际用过，但是看手册《 ARMv8-A Architecture Reference Manual 》 A1.4.4 章 里面说是支持 IEEE754 了。

4. 10%？有 ref 我看看么？访问对齐，优化好流水线，超过 1k 的 prefecth 是基本优化操作，我测下来差不多有这样的提升，跟 CPU 无关。
https://mzh.io/golang-aeshash-arm64
搜 PRFM 看 benchmark

5. 三星的问题么？ https://go-review.googlesource.com/c/go/+/147377
我还是那句话，看完代码再来说，别提“大概率”这事，我们做了这么多优化，不是你一句话说没就没的。