近日，相关部门官网发出了几则通知，针对国产计算机和操作系统的采购向社会公开征求意见。采购需求标准包括了“便携式计算机”、“一体式计算机”、“通用服务器”、“工作站”、“台式计算机”这五类，如果对《采购需求标准（征求意见稿）》有意见，可以发送邮件提出意见。
个人觉得《采购需求标准（征求意见稿）》总体上是比较完善的，但一些具体细节方面还有些含糊，主要是关于CPU性能部分，表述中有一些知识错误。
CPU的核心数和主频不是体现CPU性能的依据，比如Intel的8核Atom处理器的性能不如Intel的4核酷睿低压低频版笔记本/平板CPU。因此建议加上对CPU的性能测试的明确的测试成绩，以实测结果体现CPU的性能水平。
如果不以实测成绩为准，就免不了出现滥竽充数的情况，比如某些国产CPU的实际性能和Intel的8核Atom处理器基本一样，但如果只看核数和频率却超过了10代酷睿i3-10100的水平。
台式机CPU对单核性能的要求比较高，应把CPU单核性能作为重要的指标。
服务器CPU对性能的要求更加具体，更应该明确标注各种性能测试的成绩。
性能应该包含整数、浮点通用性能测试、浮点运算性能测试、事务处理能力测试、访存性能测试。
整数、浮点通用性能测试建议使用业界主流的SPEC CPU 2006和2017。
通用性能测试的环境应与用户实际的系统环境一致，而不是性能测试专用环境，原因如下：
a. 性能测试专用的软件环境（如定向优化的操作系统和编译器以及第三方优化库等）不会被用于实际的软件开发和生产环境，而且即使在软件开发和生产环境中使用，也不能取得在性能测试中表现出的性能提升。在专用环境中的测试成绩不能体现出用户实际获得的CPU性能；
b. 性能测试专用的硬件环境（如强化散热、锁定CPU频率、使用未被量产产品支持的内存规格等）不会被用于用户实际的使用场景，体现的不是用户能获得的CPU性能；
c. 性能测试的软件环境应使用国产操作系统、GCC或LLVM编译器、编译时不链接操作系统本身未提供的库，若使用了非GNU发布的库也应加以标注。性能测试须包含单线程和多线程并行性能。
浮点运算性能测试建议使用Linpack。
允许厂商对测试环境、编译参数、测试参数进行调优，以获得最值测试成绩。
事务处理能力测试建议使用UnixBench。
性能测试的软件环境应使用国产操作系统、GCC或LLVM编译器，使用测试工具默认的编译参数。性能测试须包含单线程和多线程并行性能。
访存性能测试建议使用stream。
允许通过调整编译参数获得较优的测试成绩。测试应包含单线程和多线程并行的访存性能。
不应该只要求满载时的笔记本电脑外壳温度，还应该加上满载测试的时长，比如半小时。否则仅CPU仅满载一秒钟显然不会使整机温度明显升高，CPU满载时间过长也极有可能使整机温度超过标准。
应规定CPU在满载的时限内性能下降的幅度。因CPU通常会因温度升高而降低频率，如果为了使温度达标而故意把频率降至极低，那么CPU性能也会极低，没有实用价值。
《采购需求标准（征求意见稿）》对当前国产CPU所使用的各种CPU架构一视同仁，这是值得商榷的。
比如ARM架构，目前没有任何国内企业获得ARMv9架构授权，虽然国内企业可以依托ARMv8发展自主软件生态，但随着时间推移，基于ARMv8的处理器会逐步失去了在公开市场与进口或国产ARM新势力的ARM（V9）处理器（比如阿里的倚天710）竞争的能力。
因为ARMv9兼容ARMv8，所以国产的ARMv8处理器所谓的“自主软件生态”就只是ARMv9软件生态的子集，ARMv9处理器能兼容国产ARMv8处理器的所有软件，但反之则不行。基于ARMv8建立“自主软件生态”是在帮助进口的ARM处理器完善桌面和服务器生态，是在帮助它们打造阻拦国产ARM处理器进入公开市场的盾牌。
国内自主的LoongArch和SW64架构更应该被明确支持，也更有发展潜力，希望《采购需求标准》能明确地表示对自主架构的支持。
