[转帖]使用GCC编译器实测兆芯KX-U6780A的SPEC CPU2006成绩

使用,gcc,编译器,实测,kx,u6780a,spec,cpu2006,成绩 · 浏览次数 : 0

小编点评

**测试报告** **KX-U6780A使用GCC/Linux测试SPEC CPU2006整数单任务(int_speed_base&peak)性能的测试报告** **测试报告** **KX-U6780A使用GCC/Linux测试SPEC CPU2006整数多任务(int_rate_base&peak)性能的测试报告** **测试报告** **测试结果** | 测试项 | 单任务 (int_speed_base&peak) | 多任务 (int_rate_base&peak) | |---|---|---| | 整数单任务 (int_speed_base&peak) | 83.2 | 86.7 | | 整数多任务 (int_rate_base&peak) | 83.2 | 86.7 | **测试报告** **测试结论** KX-U6780A在单任务和多任务下具有相同的性能。

正文

 
https://baijiahao.baidu.com/s?id=1722775453962904303

 


兆芯KX-U6780A是一款8核2.7GHz的使用x86/AMD64指令集(架构)的国产CPU,于2019年发布。兆芯于2013年成立,不久之后就使用VIA的CPU成品成功申请了“核高基”重大专项,获得“核高基”和上海国资委共70亿人民币投资。它的CPU初始技术是从VIA(台湾威盛)购买,而VIA的CPU都由位于美国的子公司Centaur(半人马)设计。VIA去年(2021)11月把Centaur的CPU设计团队卖给了Intel,但在此之前,2020年10月时就已经再次向兆芯转移设计资料,以2.57亿美元的价格把“部分芯片产品相关技术、数据等知识产权(不含专利权)”卖给了兆芯。

在VIA淡出CPU市场后,Centaur就处于半死不活的状态,可以说是兆芯帮VIA养活了Centaur。可是一回头VIA就一女二嫁,先把花兆芯的钱完成的最新设计高价卖给兆芯,再把设计团队卖给了Intel。除了为了让兆芯有资格设计x86/AMD64的CPU而必须保留的合资者身份之外,在CPU研发层面已经从国产x86的伟大事业中彻底脱身,实在不当人子。

 

因合作关系发生重大变化,兆芯使用全新核心的CPU从2020年开始就一直推迟,可能要到2024年才能发布产品。在使用新核心的产品问世之前,兆芯只有KX-U6780A是能拿得出手的桌面处理器。

官网介绍KX-U6780A在3.0GHz时,使用ICC(Intel C/C++/Fortrant)编译器在Linux测试SPEC CPU2006的“单任务”int(整数通用性能)成绩是29.2,浮点成绩是38,但未说明是base测试还是peak测试,但据推测兆芯官网上公布的成绩都是peak成绩。

ICC编译器对SPEC CPU2006的部分测试项目和类似的科学计算类程序有专门的优化,特别是对编号为462的测试子项优化水平令其它编译器望尘莫及,但对其它测试子项和普通应用程序的优化水平则达不到相同的程度。又因为ICC对常规应用程序的编译不是很友好,也仅支持x86/AMD64架构,所以各种操作系统和应用软件甚少使用ICC编译器编译。在Windows下C/C++编写的应用软件以使用MSVC和GCC编译器为主,在Linux系统下,各种Linux发行版和应用软件,普遍使用的是GCC编译器。也就是说使用GCC编译器测试的SPEC CPU2006时,最能反映CPU在实际系统和软件环境中的性能水平,而不仅仅是跑分的水平。特别是在跨架构对比CPU性能时,比如ARM与x86/AMD64进行对比时,尽量使用相同的编译器是很重要的条件。因此我打算使用GCC编译器实测KX-U6780A在Linux系统下的通用性能表现,也就是测试整数性能。因精力有限,浮点性能暂不测试,只把测出的整数性能与其它的一些CPU进行横向对比。

 

在开始测试之前,我先在SPEC官网找了一些同样使用ICC编译器的CPU测试成绩作为参考,看看KX-U6780A的水平如何。事实上在任何的整机宣传资料中都没有见过3.0GHz的KX-U6780A,最高只见到2.7GHz的,我买到的也是2.7GHz的产品。当然3.0GHz的KX-U6780A肯定存在,因为有它的测试成绩,那么此处也使用3.0GHz时的成绩进行对比:

 

上表中的int表示整数,fp表示浮点,speed是单任务,rate是多任务。可以看出,KX-U6780A在核心数量、内存性能、操作系统性能、编译器版本都明显占优的情况下,“单任务”整数(通用性能)略超Q9650,浮点性能也更胜一筹,但与2015年发布的i5-6400(4核无超线程)相比,KX-U6780A的单任务性能不到i5-6400的一半,即使用8核对比4核,多任务性能也有明显差距。单任务浮点性能仅约i5-6400的44%,多任务浮点性能也远弱于4核的i5-6400。KX-U6780A的浮点性能本次不实测,以后有空再说。

之所以强调“单任务”而非“单核”,是因为SPEC CPU2006的部分测试项目可以通过开启编译器“自动并行化”支持,使单个测试任务在多个CPU核心上并行运行,从而提高总成绩。上面的测试都是开启了“自动并行化”之后的测试成绩,KX-U6780A是8个核心,与4个核的CPU进行对比时天然具有优势条件。

绝大多数桌面应用软件仅在处理少部分任务时会使用多线程,对常规的应用软件通过编译器开启“自动并行化”也是没有效果的,大多数时间的运行状况由CPU单核性能决定。因此下面进行int_base测试时我不会开启“自动并行化”,但进行int_peak测试时我会对编号462的单项开启“自动并行化”,通常“自动并行化”也只会对编号462的单项有效。我测试用的KX-U6780A主频是2.7GHz,因为买不到官方测试使用的3.0GHz版本。具体测试环境如下:

 

首先看看使用GCC的各种编译优化参数来编译SPEC CPU 2006的整数(通用性能)测试集时,KX-U6780A的单任务int_base性能如何。这里的单任务是没有开启“自动并行化”的,也就是纯粹的单核心成绩。下表中没有列出我测试过的所有参数组合,仅仅是一小部分有代表性的测试结果。

 

可以看出在使用单一的优化参数时,成绩最好的是-O2,一些在印象中大概率对性能有益的参数,在加上后反而会使总成绩降低。经过反复调整参数,最后还是以-O2为基础配置参数组合,测试得到的成绩最好。

-fno-strict-aliasing这个参数也比较有意思,它本身不属于性能优化参数,主是要用于解决某些c/c++代码与编译器的兼容性问题的,但是加上它之后测试成绩明显降低。仔细对比发现当使用-fno-strict-aliasing参数后,大部分测试项目成绩明显降低,而有几个项目的成绩反而提升了一些。base测试时要求所有测试项目配置的编译“优化参数”必须一致,但因为这个参数不属于“性能优化”参数,所以我就给有提升的项目单独用上了。

反复调优之后得到的int_base成绩也仅仅15.6分,int_peak成绩有17.5分,也比较低。这样的成绩与ICC测试得到的成绩差距很大,但却是合理的,因为这是模拟的普通用户环境的性能表现,而不单单为了跑分。可以把几款CPU的ICC和GCC测试成绩进行对比,看看KX-U6780A的ICC和GCC成绩比例是否与它们差不多:

把KX-U6780A的测试成绩与我实测过的其它CPU对比,则有下面的图表:

 

上图中除了龙芯3A5000的int_peak成绩之外,其它都是本人实测的结果。把不同CPU的单核成绩折算到相同频率后的结果,可以代表CPU的核心设计水平。从上图可见兆芯与飞腾的CPU核心设计水平是一个梯队,龙芯CPU的核心设计水平则与Intel数年前的产品相当。实际上Intel直到11代酷睿,每GHz的性能也提升不大,但是它的CPU最高频率已经突破了5GHz。国产CPU因为设计团队与代工厂的生产工艺缺乏磨合,后端设计技术和经验积累不足,尚没有任何的量产产品突破3GHz的频率。

假设当前国产CPU的运行频率也都能达到5GHz,那么龙芯的CPU单核性能会与Intel/AMD的产品接近,而兆芯和飞腾的CPU单核性能则只有Intel/AMD的一半。在当前国产CPU的运行频率都只有Intel/AMD最高端产品的一半,龙芯的CPU单核性能也就接近Intel/AMD最高单核性能的一半,而兆芯和飞腾则只有1/4。因此兆芯和飞腾不约而同地通过增加核心数量来弥补单核性能的不足,毕竟增加核心数量要比提高单核性能容易许多。

CPU的多核性能不是单核性能的简单累加,受cache同步、内存访问等影响,核心数量越多,在多核并行时的平均单核性能就越低。我再测试了8个核心的KX-U6780A多核(多任务)整数性能,在测完单核后测多核就简单了,只需要运行测试工具时指定并行运行的实例数量,实例数量通常与CPU核心数量相同。测试得到的int_rate_base成绩为83.2,int_rate_peak成绩为86.7。这个成绩比飞腾的8核D2000略低,但高于4核的龙芯3A5000。

 

兆芯KX-U6780A的单核测试成绩比飞腾D2000略好,多核并行时成绩又比D2000低一些,说明它的多核互联效率可能要比D2000差一些。以int_base的单核和多核成绩计算多核并行效率如下:

 

虽然看起来龙芯3A5000的多核并行效率最高,但这并不绝对,因为3A5000只有4个核,另两款CPU都是8核。在测试KX-U6780A多任务成绩时,8核满负载时整机功耗在100W左右,整机中无独显,除主板/CPU/风扇之外,仅两根内存和一个nvme硬盘。在进行相同的测试时,飞腾D2000和龙芯3A5000的整机功耗都是60W左右,而这3款CPU的制程、频率、和全CPU性能都是相差无几的。

 

再回头看看兆芯KX-U6780A在int_base测试中的各子项成绩,可以看出兆芯KX-U6780A与另外两款国产CPU细致的性能区别:

 

可以看到在大部分测试项目中,KX-U6780A都和D2000差距微小,只有429.mcf和462.libquantum这两项有较大差距,才使总成绩高于D2000。

我的测试成绩肯定没有达到最优,但自信在相同的测试环境下,无论如何调整编译优化参数,成绩提升的幅度也不会超过10%,大概率连5%都超不过。如果有人认为我的测试环境和编译参数等存在问题,欢迎指正,但拒绝没有依凭、信口开河的指责。除了有权威机构作保的官方或半官方的公开成绩之外,我认为所有的“个人测试”都应试公开相关的软硬件环境、配置参数、以及完整的测试报告。无论测试成绩是高还是低,如果连公开编译参数让其他人复现都不敢,那么这样的“个人测试”就经不起推敲。经不起推敲的“个人测试”成绩我见过不少,有关于龙芯的,也有关于飞腾的,还有关于兆芯的,区别只是测某种CPU的成绩都极差,测其它CPU的成绩都极好罢了。那些测试的共同点是都不提供测试用的编译参数,也不贴出测试报告的截图,甚至有人在测试FT-2000/4时,宁可拿着手机拍摄“测试过程”,也要“保密”配置信息和测试报告。掩耳盗铃、自欺欺人,只会令消费者对所有的国产CPU都失去信心!

对于以个人身份进行的测试,我认为只有公开透明,可以让他人复现测试过程和结果,才能避免争议,经得起推敲。下面贴上我的测试报告:

KX-U6780A使用GCC/Linux测试SPEC CPU2006整数单任务(int_speed_base&peak)性能的测试报告(点击或用新标签页打开图片放大):

 

KX-U6780A使用GCC/Linux测试SPEC CPU2006整数多任务(int_rate_base&peak)性能的测试报告(点击或用新标签页打开图片放大):

 

如果上面的测试报告截图看不清,那么可以留言或私信写上电子邮箱,我给你发测试报告的原文件。

与[转帖]使用GCC编译器实测兆芯KX-U6780A的SPEC CPU2006成绩相似的内容:

[转帖]使用GCC编译器实测兆芯KX-U6780A的SPEC CPU2006成绩

https://baijiahao.baidu.com/s?id=1722775453962904303 兆芯KX-U6780A是一款8核2.7GHz的使用x86/AMD64指令集(架构)的国产CPU,于2019年发布。兆芯于2013年成立,不久之后就使用VIA的CPU成品成功申请了“核高基”重大专

[转帖]spec2017 安装和使用

https://zhuanlan.zhihu.com/p/534205632 SPEC成立于1988年,SPEC基准广泛用于评估计算机系统的性能。SPEC CPU套件通过测量几个程序(例如编译器GCC,化学程序游戏和天气程序WRF)的运行时间来测试CPU性能。 安装编译器 运行speccpu2017

[转帖]GCC 编译及编译选项

俗话说:'工欲善其事,必先利其器',一直在工作中使用GNU C编译器(以下简称GCC),这里对GCC的一些警告选项细致的分析,并列举几个简单的例子[注1]供分析参考。 1、 -Wall集合警告选项我们平时可能大多数情况只使用-Wall编译警告选项,实际上-Wall选项是一系列警告编译选项的集合。下面

[转帖]Linux性能优化(十二)——CPU性能调优

Linux性能优化(十二)——CPU性能调优 https://blog.51cto.com/u_9291927/2594259 一、应用程序优化 (1)编译器优化。适当开启编译器优化选项,在编译阶段提升性能。gcc提供优化选项-On会自动对应用程序的代码进行优化。(2)算法优化。使用复杂度更低的算法

[转帖]Linux下的两个环境变量:LIBRARY_PATH和LD_LIBRARY_PATH使用

1.LIBRARY_PATH和LD_LIBRARY_PATH是Linux下的两个环境变量,二者的含义和作用分别如下: LIBRARY_PATH环境变量用于在程序编译期间查找动态链接库时指定查找共享库的路径,例如,指定gcc编译需要用到的动态链接库的目录。设置方法如下(其中,LIBDIR1和LIBDI

[转帖]--build=arm-linux

今天在arm上用configure生成makefile时报错:configure: error: cannot guess build type; you must specify one 问题: 不能确定编译的操作系统 解决: 在gcc编译中我们使用 ./configure --build=编译平

[转帖]CentOS7/完美升级gcc版本方法

https://zhuanlan.zhihu.com/p/535657060 在某些应用场景中,需要特定的gcc版本支持,但是轻易不要去编译gcc、不要去编译gcc、不要去编译gcc,我这里推荐使用红帽提供的开发工具包来管理gcc版本,这样做的好处是随时切换版本,并且可以并存多个版本,不破坏原有gc

[转帖]CentOS7完美升级gcc版本方法

https://blog.whsir.com/post-4975.html 在某些应用场景中,需要特定的gcc版本支持,但是轻易不要去编译gcc、不要去编译gcc、不要去编译gcc,我这里推荐使用红帽提供的开发工具包来管理gcc版本,这样做的好处是随时切换版本,并且可以并存多个版本,不破坏原有gcc

[转帖]redis-cluster-proxy安装使用尝试

https://www.cnblogs.com/gered/p/15210509.html 【1】gcc 4.9+安装 【2】redis-cluster-proxy 介绍与安装 下载安装: 配置文件: 启动 【3】连接核验 【4】故障转移 【4.0】查看集群状态 【4.1】集群挂一个主库的影响 【4

[转帖]Linux make: g++: Command not found

https://www.cnblogs.com/kerrycode/p/4748606.html Linux使用make命令时遇到“make: g++: Command not found”,这个主要是没有安装gcc-c++.x86_64,如下所示 [root@localhost nethogs]#