1
likuku 2018-11-28 11:12:33 +08:00 via iPhone
|
2
echo1937 2018-11-28 11:20:19 +08:00 1
云服务的这个体量,真的是能改变业界的格局,希望 arm 架构在服务器市场也能走好啊。
|
3
likuku 2018-11-28 11:24:53 +08:00 via iPhone
@echo1937 省电,便宜,在微服务 /server less 时代,动态使用大量小强一样的 arm 虫群,也是可以得了……对上下游厂商和消费者都很有好处吧。
性能嘛,也不用太过担心…如今主流手机(非旗舰)性能已经超越 3 年前 mac 笔电了。 |
4
likuku 2018-11-28 11:29:05 +08:00 via iPhone
自己家用 arm 树莓派也算好几年了,个人觉得除了性能弱,用起来和 x86 机器完全没差别( debian )
|
6
leafleave 2018-11-28 12:09:34 +08:00 via iPhone 1
对于架梯子这种小服务 arm 足够了,希望能便宜点
|
8
datou 2018-11-28 12:27:20 +08:00
|
10
likuku 2018-11-28 12:33:17 +08:00
|
12
zn 2018-11-28 13:05:22 +08:00
@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 就更加不要比了)。 |
13
tsui 2018-11-28 13:11:07 +08:00
|
14
yexm0 2018-11-28 13:11:22 +08:00 via Android
又见拿 arm 去跟 x86 比的。。。
|
15
zn 2018-11-28 13:14:57 +08:00
|
16
zn 2018-11-28 13:19:50 +08:00
@tsui 你这个比较才没什么价值。这种视频处理都有专用硬件加速处理器来处理的,CPU 只是辅助。
而且,都是 1080p,里面道道很多的,大约有二三十个参数可以控制输出质量,而编码质量是直接影响编码速度的。 |
17
tsui 2018-11-28 13:27:01 +08:00
@zn 呵呵哒,小学算数估算功耗 10 年前的 Dell 笔记本性能更强,当年那些可都是 150W 的电源适配器
实际使用上 MacBook 的 m3 性能完全过得去,再说你以为 MacBook 现在的 i5 是真 i5 么 |
19
zn 2018-11-28 13:51:13 +08:00
@tsui 哦,补充一下, [A11 仿生的单线程性能约等于 i3 低压版 CPU 的性能] ,看好我说的是什么:低压版 CPU,低压版,低压版。
然后呢,MacBook 上的 i5 就是低压版 i5。 |
23
laxenade 2018-11-28 15:06:14 +08:00 via Android
aws 现在越来越随性了,都已经推出真·云服务 ground station。
|
24
likuku 2018-11-28 15:07:33 +08:00
对比 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 |
25
bp0604 2018-11-28 15:13:04 +08:00
树莓派目前还不怎么好用, arm 有太多的东西与 x86 不兼容
|
26
kzfile 2018-11-28 15:13:04 +08:00
那么问题来了,什么类型的应用不适合跑在 arm 上呢?
什么类型的应用根本跑不在 arm 上呢? |
27
phithon 2018-11-28 17:13:20 +08:00
aws 的没用过,正在用另一家的 ARM 架构的 vps,最直观的感觉是编译东西慢了很多(虽然是 4 核 2G,但没有我其他 1 核 1G 的快)。因为跑得是个人应用,消耗不大,所以暂时没感觉到其他的问题。
|
31
kljsandjb OP @likuku #30 确实是这样,不过家里放了俩树莓派,一个 32bit 一个 64bit,用腾讯云学生机做了 frp 也够平时学习用了,可能我需求也没那么多😄
|
32
likuku 2018-11-28 18:26:22 +08:00
@phithon #27 可惜当前 aws 价格表里,这些新的 arm 实例还没有 ECU 的信息参考(可以当作实际算力指数)
|
33
likuku 2018-11-28 18:28:28 +08:00
@kljsandjb #31 树莓派 64bit 系统支持的软件包覆盖 32bit 够高了么?我竟然才知道 64bit 系统已经可用了... Orz
|
35
kljsandjb OP @likuku #33 软件包覆盖不敢说,这个也许我用的不算多吧,就正常 gnu 组件对我就够了,其他的其实也多多少少有了
|
36
kljsandjb OP @likuku #33 今天开了一个 aws 的 arm 服务器,64bit ubuntu,可以试试先😂
|
37
zn 2018-11-28 18:53:24 +08:00 via iPhone
@likuku 亚马逊敢上这种服务器,说明性能肯定是达到基础要求的,这种用来做服务器的 CPU,也肯定不是手机上用那种弱鸡 CPU。
|
39
likuku 2018-11-28 18:57:53 +08:00
@kljsandjb #34 #35 查了一阵资料,发觉当前即便在 pi3B+ 上跑完整的纯 arm64 系统 (内核与所有软件) 效能并没有明显提高,放弃,安于已经用很久的 32bit 系统和软件了,不折腾了。
|
41
likuku 2018-11-28 19:04:37 +08:00
|
42
kljsandjb OP |
43
zn 2018-11-28 19:21:43 +08:00 via iPhone
@likuku 手机 CPU 和服务器 CPU 考虑的问题完全不一样,所以性能差异那不是一般大,其实没什么可比性的。硬要比的话,顶级手机 CPU 和顶级服务器 CPU 性能差距可能差一百倍是有的。
|
44
likuku 2018-11-28 19:57:45 +08:00
|
46
kljsandjb OP |
48
kljsandjb OP @likuku
error: snap "unixbench" is not available on stable for this architecture (arm64) but exists on other architectures (amd64, armhf, i386). 暂时测不起来 |
50
zn 2018-11-28 20:29:08 +08:00 via iPhone
@txydhr 本质上都是计算,所以肯定是可以量化的,可以量化那自然就可以比较。
当然了,直接比不好比,毕竟架构不一样。 但是可以把浮点性能,定点性能等指标单独拿出来比比较,然后各项指标做加权,得出一个综合性能,就可以比了。 这个应该没什么可争的吧?需要争论的是各项指标的权重,这个争议会比较大。 |
51
likuku 2018-11-28 20:34:45 +08:00
@kljsandjb 额... 好吧,我先研究下如何用 gromacs 这个 分子动力学模拟软件 来做测试,看到有人拿它作性能参考。
树莓派上 rasbian 9 的 apt 源是可以直接装 gromacs 的。 |
52
likuku 2018-11-28 20:36:28 +08:00 1
@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 |
53
likuku 2018-11-28 21:20:10 +08:00
@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 |
54
zhuang 2018-11-28 21:58:52 +08:00 1
简单说,计算密集型的应用场景,在软件配套跟得上的情况下,用 arm 比 x86 要更合适,网络 DPDK 相关的也可以考虑,IO 密集型还是 x86 更好。
所谓的软件配套一方面是指 arm64 二进制源,这方面最近一两年进步非常大,不是大问题。重点在于 arm 架构是弱一致的内存模型,有指令集支持的计算效能非常高,基于 c 的编译代码优化也尚可,但依赖 jit 或者是优化尚不到位的 golang 等效率就很低,虚拟化涉及内存模型所以效率也很低。 现阶段 arm/x86 的主要区分并非指令集和效能,而是平台和生命周期。关于 arm/x86 的细节对比我会再开帖子详细说明。 |
55
whileFalse 2018-11-28 22:43:58 +08:00
@zhuang 同样优化到位的计算场景,核心数相同下 arm 能比 x86 性能好吗?抑或只是 arm 便宜靠堆核心压制 x86 ?
|
56
kevinhwang 2018-11-28 22:48:26 +08:00 via Android
如果价格能做的更低就好了。
梯子和内网穿透都需要公网 ip 却不占用太多资源,arm 性能足够。 非常看好 arm 集群,期待后续的推广。 |
58
mengzhuo 2018-11-29 10:28:48 +08:00
@zhuang Go 优化不到位我严重不同意啊,Cloudflare、arm 中国那波大牛们写了这么多优化你都没体会到?
x86 还是胜在各种软硬件优化,流水线也比公版 arm 深也多,自然比 arm 快,arm 需要到 v8.3 上 SVE 加上软件优化估计能和同频率 x86 拼一把,不过 x86 和 ppc64 也是垃圾(狗头 绝大部分人接触的中低端 IT 从来都是农村包围城市,跟当年 intel 战胜 IBM 一样,历史总是相似的,所以大家等着 arm 或者更便宜的 riscv 占领市场吧。 |
59
bsidb 2018-11-29 10:49:14 +08:00
现在 Phoronix 已经放出了[Benchmark 的结果]( https://www.phoronix.com/scan.php?page=article&item=ec2-graviton-performance&num=1),同时对比了 x86 的几款处理器的性能。
|
62
zhuang 2018-11-29 11:30:56 +08:00
|
63
mengzhuo 2018-11-29 14:19:17 +08:00
@zhuang 主流 AES-GCM,sha1,sha2,CRC32,MD5 没优化好?张口就来 Go 优化不到位,好歹给个 benchmark,要不然我很受伤。
arm 平台是多样,但服务器领域是基本没差,除了三星这朵大小核都偷工减料的奇葩。 而且 armv8 都有 Neon,不知道你特定处理器优化是几个意思(是想说指定架构优化?) ----------- v 站大牛太多,不敢多说了 |
64
zhuang 2018-12-02 16:32:27 +08:00
@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. 好好说话。 |
65
mengzhuo 2018-12-02 20:28:51 +08:00
@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 我还是那句话,看完代码再来说,别提“大概率”这事,我们做了这么多优化,不是你一句话说没就没的。 |