2017总集篇及2018预告

他们说，生活要有些仪式感。从前，现在，过去了再不来。人生短暂，所以要用庄重认真的态度去对待生活里看似平淡重复的某些时刻（我想，每个时刻都这样或许会有些累）。

“仪式”会赋予某一时间段内发生的特定事件“与众不同”的意义，让短暂的生命时刻都能有自己的光辉。

由于某个契机，今天变成了一个特别的日子：

谢谢你们

好吧，它其实本来就是个特别的日子：

感谢挚友。要我说，这蛋糕有点大了，感觉吃不完

2017总集篇

《提问的智慧》是一篇译作：How To Ask Questions The Smart Way，选择它为第一篇文章大部分原因是，提醒自己，如何更好的提问、学习。但更应谨记的是——我们因何发问：

We are the explorers，来源：NASA

以下为前阶段的公众号文章列表，一共17篇，其中两篇科技真探栏目的为旧文搬运，其余则为至顶实验室与公众号同步发布，至于Spectre/Meltdown系列栏目以及Xeon D-2100处理器则是公众号独有，同时它们和《提问的智慧》一样，都是翻译文章，这些文章出现的缘由不是因为别的，而是因为它们对初中高中大学十年英语当中九年荒废度过的我是一个很好的挑战。

其中，包含“处理器评测”关键词的文章里面均包含了对微架构的较为深入的解析，这种工作亦是来源于探索，来源于一种挑战。

2018预告

以下是2018年已经准备好或者快要准备好，或者应该能准备好的几个测试方法，按心目中的重要程序排序：

一：SPEC CPU2017，准备其的原因当然是SPEC组织不再接受独立SPEC CPU2006成绩了。当然，《微评测》还会继续运行SPEC CPU2006一段时间，直到对我们的SPEC CPU2017测试的测试完毕，并达到一个“正式版”的状态，并且，更重要的是，笔者需要对当中每一个子项目都达到一定程度的了解，这并不是一件简单的工作。我们计划在半年内完成对每一个子项目的粗浅介绍，并rolling out这个测试。

SPEC CPU2006子项目介绍示例，国内所有相关的介绍皆来源于此；做这个的原因亦非其他，正是因为这是一个挑战

二：SPECvirt_sc2013，2017年的时候，笔者曾为是购买SPECvirt_sc2013还是SPEC Cloud IaaS 2016犹豫，后来觉得，直接跳过虚拟化部分测试对知识体系是没有益处的。SPECvirt_sc2013的Proto Type方案已经接近可以运行，它确实可以起到一些评估作用。但还有很多未解决的问题，我们对这个测试本身的配置的繁琐性质感到头疼，要让其能完美适应不同的Hypervisor、不同网卡的VMDq或SR-IOV特性、以及VM内vNIC的额外优化配置问题，需要做或可以做的工作感觉像是一望不到头。但如果不追求完美，我们预计几个月内可以测试完毕开始运行。

三：AS3AP OLTP，来自ANSI的ANSI SQL Standard Scalable and Portable（AS3AP）OLTP（On-Line Transaction Processing，联机事务处理）测试，这个测试笔者其实已经运行了很多年，但一直以来对其其实并不足够了解——也没能找到更了解的人。经过数千次的重复测试探索和持续研究，现在笔者觉得对其已经有了还算过得去的掌握，目前我们正在进行四路平台上的测试项目（我们使用的是基于百数台客户机群的模拟真实网络测试环境），相关的测试很快就可以出现。下一步的目标是扩展我们测试方案的覆盖范围，目前的测试方案针对CPU内核、CPU互联子系统、内存子系统、网络子系统有着极大的压力。说了你们可能不信，网络子系统在一项指标上起到了关键的作用。在合适的时候，我会将压测范围扩展到存储子系统。

四：TPC-C，来自TPC（Transaction Processing Performance Council，事务处理性能委员会）的TPC-C OLTP测试。同样是基于百数台客户机群的模拟真实网络测试环境，仍处于Test Type阶段（Test Type和前面的Proto Type都是来自EVA的术语，对应里面的作品分别是初号机和零号机），我已经运行过了很多次特定条件下的测试，但是对一些边角条件以及极限条件并未做足够的覆盖，和AS3AP不同，这个测试蕴含对存储子系统的可观压力，我尚未有很合适的存储系统，或许在Windows Server 2016 RS4或者Red Hat Enterprise Linux Server 7.5发布之后能用较低成本建立一个，并在半年内进行“RTM”版本的测试。

五：FIO（Flexible IO），这个测试已经达到了Production状态（对应二号机），并已经在现在的Intel Optane测试上得到了应用，但目前需要时间撰写文章。对于FIO方案，我觉得现在开发的可堪一用，配合原有的Iometer方案，足够应付绝大部分的设备。方案没有进一步的计划，但我计划挑战更多种类的存储系统和存储环境。

当前，我所有的测试方案都具有着很宽广的适应性，从台式机到大型四路服务器都经过了实践并具有良好的测试效率。理论上，它们用于八路及八路以上的平台也不会有问题，但笔者在2010年第一次测试四路机器——Nehalem-EX的时候也花了些时间解决了几个扩展性相关的问题。

Intel Nehalem-EX四路样机（2010），这个设备过关的时候很是麻烦了一段

类似的这些问题在八路或更多路上还存不存在？我能不能解决？我正在寻求继续挑战的机会。

顺祝各位新春快乐！

注：总集篇是动画界的一个术语，类似于阶段总结。

微评测是科学与技术的观察者