1. 项目概述为什么我们需要一个更好的NVM实验平台如果你在计算机体系结构或系统软件领域做过研究尤其是在非易失性内存NVM这个方向那你一定对“仿真”和“模拟”这两个词又爱又恨。爱的是它们几乎是探索新硬件、新架构的唯一可行手段恨的是这个过程往往慢得令人抓狂。我至今还记得为了在gem5上跑一个完整的应用等上几天几夜是家常便饭而最终可能只是为了验证一个微小的优化点是否有效。这种“仿真之痛”严重拖慢了NVM相关软硬件协同设计的创新步伐。NVM比如相变内存PCM、自旋转移矩磁阻内存STT-MRAM和阻变内存RRAM它不仅仅是“断电不丢数据”那么简单。它模糊了传统内存DRAM和外存如SSD的界限带来了全新的系统设计范式。操作系统需要重新思考虚拟内存和文件系统的融合硬件架构师则要设计新的内存控制器和缓存一致性协议。但这一切创新的前提是你得有一个能快速、准确评估想法的“试验田”。现有的“试验田”主要有两类一是全系统模拟器如gem5、MARSS功能强大但速度极慢且结构复杂难以定制二是基于特定硬件的仿真方法如利用NUMA远程访问延迟或内存控制器带宽限制寄存器它们虽然快但要么灵活性差要么模型过于简化准确性存疑。这就好比你要测试一辆新车的性能前者是造一个1:1的风洞模型精度高但成本巨大后者则是用一辆旧车改装虽然快但测出来的数据可能和真车相去甚远。正是在这种背景下LEEFLightweight Emulation Framework应运而生。它的核心目标很明确在真实的商用硬件上以接近原生执行的速度高精度地仿真出NVM的各种关键行为延迟、带宽、持久性同时提供一个开放的接口让基于轨迹Trace的微架构模拟结果能够反馈并指导仿真过程。简单说LEEF试图在“全真模拟”和“快速原型”之间找到一个最佳平衡点。它不是要取代谁而是为NVM研究者提供一把更趁手、更高效的“手术刀”让我们能更快地迭代想法验证设计。2. LEEF框架的核心设计思路拆解LEEF的设计哲学可以概括为“监控-建模-注入”三步走策略并在此基础上引入了“仿真-模拟联动”的创新模式。理解这个思路是掌握LEEF精髓的关键。2.1 从“全系统模拟”到“轻量级仿真”的范式转变传统全系统模拟器如gem5采用的是“推演”模式。它从指令集架构ISA开始逐周期地模拟处理器流水线、缓存、内存控制器等所有硬件组件的行为。这种方法的优势是保真度高可以模拟任何微架构改动。但代价是巨大的性能开销模拟速度通常比真实硬件慢3到5个数量级。对于需要长时间运行真实应用如数据库、科学计算的NVM研究来说这几乎是不可接受的。LEEF则采用了“差异补偿”的仿真思路。它不模拟整个系统而是让应用直接运行在真实的DRAM硬件上。LEEF的核心任务是实时监控应用在DRAM上的运行时行为然后根据一个精确的NVM性能模型计算出如果应用跑在NVM上会多花多少时间最后通过“注入延迟”的方式让应用“感觉”自己正在一个更慢的NVM上运行。这就像给一个跑步运动员腿上绑沙袋来模拟他在泥泞路面上跑步的速度。这个思路带来了两个根本性优势速度极快应用的主体执行是在原生硬件上完成的LEEF只负责周期性地进行监控和延迟注入开销极低。平台通用不依赖特定的处理器型号或BIOS设置如PMEP所需的带宽节流寄存器只要硬件支持性能监控单元PMULEEF就能运行。2.2 双模式架构本地仿真与模拟联动LEEF并非一个单一的仿真黑盒它设计了两大工作模式以适应不同的研究需求本地仿真模式这是LEEF的基础模式。在此模式下LEEF直接监控目标应用使用内置的NVM性能模型预测性能差距并通过ptrace等机制注入延迟完成对NVM延迟、带宽和持久性行为的仿真。这个模式适合快速评估现有应用在假设的NVM硬件上的性能表现或者测试针对NVM优化的系统软件如文件系统、内存分配器。模拟联动模式这是LEEF最具创新性的部分。在此模式下LEEF不仅仅是一个仿真器更是一个真实系统与模拟器之间的桥梁。它包含一个内核级的轨迹生成器能够以极低开销捕获应用运行时的真实内存访问轨迹地址、时间戳、读/写类型。这些轨迹可以直接输入给基于轨迹的内存模拟器如DRAMsim、NVMain或Ramulator。注意这里的“轨迹”不是通过插桩或二进制翻译生成的而是通过利用页表保护位触发缺页异常在内核的缺页处理函数中记录物理地址。这种方法开销远低于动态二进制翻译且能捕获到包括操作系统活动在内的完整内存访问流。模拟器研究员可以利用这些轨迹在模拟器中自由地修改内存微架构例如调整内存控制器调度策略、改变Bank/Subarray的组织方式、模拟新型NVM的读写特性等并评估这些改动对性能指标如行缓冲命中率、内存级并行度的影响。最关键的一步来了模拟器可以将这些指标的变化例如行缓冲命中率提升了15%反馈给LEEF的运行时系统。LEEF随后会动态调整其性能模型中的相应参数使得后续的仿真能够反映出这些微架构优化带来的效果。这就形成了一个“仿真-模拟-反馈-再仿真”的闭环。研究员可以先在LEEF上快速进行软件层面的实验和调优当需要探索硬件改动时则利用轨迹驱动模拟器进行深入研究并将硬件优化的潜在收益量化后再融合回LEEF的仿真中评估软硬件协同设计的整体效果。这极大地加速了从硬件创新想法到系统级验证的流程。2.3 核心组件剖析为了实现上述设计LEEF由四个核心组件构成一个有机整体轨迹生成器位于内核空间基于BadgerTrap思想实现。通过标记进程页表项为“保留”使得每次访问受保护页面时触发缺页异常从而在异常处理程序中记录下物理地址。结合PMU监控的读写比例为每个地址打上读/写标签最终生成带时间戳的内存访问轨迹流。性能监控器这是LEEF的“眼睛”。它利用处理器上的性能监控计数器PMC同时监控核心core和末级缓存LLC之外的非核心uncore事件。关键监控指标包括末级缓存缺失次数LLC Miss内存访问次数及读/写比例行缓冲命中、缺失、空状态的比例内存级并行度相关的指标 这些实时数据是性能模型进行计算和决策的基础。仿真运行时这是LEEF的“大脑”和“手”。它负责核心的仿真逻辑分时隙Epoch管理将应用运行时间划分为等长的时间片。在每个时间片结束时汇总性能监控数据。性能差距计算根据选定的NVM性能模型计算在当前时间片内如果内存是NVM会比DRAM多花费多少时间即性能差距T_gap。延迟注入通过ptrace等机制让目标进程“睡眠”T_gap时间从而模拟NVM更慢的访问延迟。带宽限制监控每个时间片内的写入带宽如果超过设定的NVM带宽上限则通过注入额外延迟来“节流”。持久性仿真对于需要持久化保证的应用在运行时动态注入clflush缓存行刷回和mfence内存屏障指令对模拟NVM的持久化开销。可选的轨迹模拟器这是一个外部组件接收LEEF生成的轨迹进行微架构层面的模拟实验并将结果参数如β值变化、行缓冲命中率提升反馈给LEEF运行时用于更新仿真模型。3. LEEF性能模型从简单线性到综合感知性能模型是LEEF准确性的基石。一个糟糕的模型会导致仿真结果失真误导研究结论。LEEF没有采用“一刀切”的单一模型而是深入评估了多种主流模型并最终提出了一种启发式的模型选择机制。3.1 现有模型的局限性与LEEF的探索在LEEF之前NVM仿真主要依赖两种简单的性能模型线性延迟模型这是最直观的模型。它基于一个核心假设由内存访问引起的处理器停顿周期数与内存访问延迟成正比。该模型通常监控LDM_PENDING负载指令等待事件等PMU事件然后按NVM与DRAM的延迟比例缩放这个值来预测在NVM上的停顿时间。它的优点是简单、开销小。但问题在于这个“成正比”的假设过于理想化。内存子系统的带宽、应用程序的指令发射率、行缓冲的局部性都会严重影响这个比例关系。对于像libquantum这类高带宽、高并行度的应用LL模型的预测误差会非常大。带宽节流模型这类模型如PMEP通过编程内存控制器iMC中的寄存器直接限制内存通道的可用带宽。它本质上模拟的是带宽瓶颈但对访问延迟的变化不敏感。更大的问题是它严重依赖特定的硬件平台如Intel Xeon某些型号的Thermal Throttling寄存器和特殊的BIOS支持可移植性差。LEEF的论文作者通过大量实验发现没有一个单一的模型能在所有基准测试程序上都保持最高精度。例如对于cactus、dealII等应用LL模型表现最好而对于lbm、libquantum基于平均延迟的模型更准对于gemsFDTD、soplex则需要考虑行缓冲局部性的模型。3.2 LEEF的核心模型平均绿总督模型基于上述发现LEEF实现并重点推荐了平均绿总督模型。这个模型可以看作是经典“绿总督”模型的增强版它更细致地考虑了内存访问的微观行为。AGG模型的核心思想是内存停顿时间 ≈ 末级缓存缺失次数 × 平均内存访问延迟。关键在于这个“平均内存访问延迟”不是固定值而是动态计算的。平均内存访问延迟的计算 首先平均延迟是读延迟和写延迟的加权平均Lat_avg (N_r * Lat_r N_w * Lat_w) / (N_r N_w)其中N_r和N_w是通过PMU监控得到的读、写操作次数。对于读操作其延迟Lat_r进一步细分为三种情况的加权平均行缓冲命中要访问的数据就在当前打开的行缓冲中。这是最快的情况延迟基本就是数据传输时间tBurst。行缓冲空目标Bank的行缓冲是空的需要激活ACT一个新行。延迟为tRCD tCAS tBurst。行缓冲冲突行缓冲中已有数据但不是目标行需要先写回预充电PRE再激活新行。对于NVM非破坏性读取可以省去预充电步骤延迟为tRCD tCAS tBurst。实操心得tRCD行选通延迟、tCAS列地址选通延迟这些时序参数需要针对目标NVM技术进行标定。可以从器件论文或厂商数据手册中获取。例如一篇关于PCM的论文可能给出读延迟~50ns写延迟~150ns。你需要将这些值分解为tRCD、tCAS、tBurst等组件这通常需要参考DRAM的时序比例或通过微观基准测试进行拟合。AGG模型通过PMU事件如行激活次数、预充电次数来估算出行缓冲命中、空、冲突的比例从而计算出更贴近真实场景的动态平均延迟。这使得模型对应用程序访存模式的变化如空间局部性的好坏更加敏感预测精度更高。3.3 启发式模型选择算法既然没有“银弹”模型LEEF的解决方案是我不做选择我全都要然后让数据告诉我用哪个。LEEF在运行时会并行地通过PMU事件多路复用用多个候选模型LL、MA、AGG进行预测。同时它会实时收集一组应用程序的特征指标内存带宽利用率末级缓存缺失率行缓冲命中/缺失/空比率平均指令发射率这些特征构成了一个多维特征空间。LEEF内部集成一个简单的回归模型或查找表这个模型是在离线阶段通过在各种应用和配置下运行收集“哪个模型预测最准”的数据训练而成的。在线运行时LEEF根据当前监控到的特征向量快速查找或计算选择出预测误差最小的那个模型来用于当前时间片的性能差距计算。这种启发式方法虽然增加了些许复杂性但将整体预测的平均误差降到了最低。在实际部署中研究员可以根据自己常用的工作负载集重新训练这个选择器以获得更好的领域特异性精度。4. LEEF的完整实现与实操要点理解了设计思路和模型我们来看看如何将LEEF真正用起来。这里会涉及一些具体的实现细节和操作中的“坑”。4.1 环境搭建与依赖LEEF的实现主要依赖于Linux内核模块和用户空间的ptrace系统调用。其核心依赖如下硬件支持PMU的x86_64处理器Intel或AMD。需要能访问核心和非核心性能计数器。通常需要msr内核模块来访问模型特定寄存器。软件Linux内核2.6.32及以上。需要内核头文件来编译模块。用户空间工具如perf或likwid可用于初步验证PMU事件是否可用。权限部分操作如安装内核模块、访问/dev/cpu/*/msr需要root权限。搭建步骤简述获取代码从论文作者提供的仓库获取LEEF源码。编译内核模块进入kernel/目录make。这会产生leef_trace.ko轨迹生成器和leef_pmu.ko性能监控辅助模块。加载模块sudo insmod leef_trace.kosudo insmod leef_pmu.ko。编译用户空间工具进入user/目录编译主控制程序leef_ctl和延迟注入工具。配置NVM参数编辑配置文件设定目标NVM的时序参数如读/写延迟、带宽上限、持久性模型如每X次写操作后刷一次缓存以及仿真模式本地/联动。4.2 延迟与带宽的仿真实现这是LEEF运行时最核心的循环。其伪代码逻辑如下while (application_is_running) { // 1. 开始一个新的时间片 (Epoch) start_epoch(); // 2. 重置PMU计数器开始监控 reset_pmu_counters(); enable_counters(); // 3. 让应用自由运行一个Epoch的时间 sleep(epoch_interval); // 例如 10ms // 4. 停止监控读取PMU数据 disable_counters(); read_pmu_data(llc_miss, rb_hit_rate, read_cnt, write_cnt, ...); // 5. 性能模型计算 // 5.1 根据特征选择模型 (LL, MA, AGG) model_t chosen_model heuristic_select_model(rb_hit_rate, bandwidth_util, ...); // 5.2 计算在DRAM上本Epoch的内存耗时 T_dram T_dram chosen_model.calculate_memory_time(llc_miss, rb_hit_rate, ...); // 5.3 计算如果在NVM上内存耗时 T_nvm T_nvm chosen_model.calculate_memory_time(llc_miss, rb_hit_rate, ..., nvm_latency_params); // 5.4 计算性能差距 T_gap T_nvm - T_dram // 6. 带宽限制检查与调整 measured_bw write_cnt * cache_line_size / epoch_interval; if (measured_bw target_nvm_bw) { T_gap (measured_bw - target_nvm_bw) / target_nvm_bw * epoch_interval * penalty_factor; } // 7. 持久性开销注入如果启用 if (persistence_enabled) { num_persist_injections write_cnt / writes_per_persistence; T_gap num_persist_injections * (clflush_latency mfence_latency); // 通过ptrace实际注入clflush和mfence指令 inject_persistence_operations(target_pid); } // 8. 注入总延迟 if (T_gap 0) { // 关键需要减去本Epoch内监控和计算带来的开销T_overhead T_inject T_gap - T_overhead; if (T_inject 0) { stall_target_process(target_pid, T_inject); // 使用ptrace或定时器暂停进程 } } // 9. 记录日志循环继续 log_epoch_data(T_gap, chosen_model, ...); }重要提示epoch_interval时间片长度的选择是一个权衡。太短如1ms会导致频繁的上下文切换和PMU读取开销T_overhead占比过大甚至可能超过T_gap导致无法准确注入延迟。太长如100ms则会导致仿真粒度太粗无法捕捉应用阶段的快速变化。论文中通常使用10ms左右这是一个经验值需要在你的具体平台上进行校准。4.3 持久性仿真的“陷阱”与技巧NVM的持久性是其区别于DRAM的核心特性之一但也是仿真中最棘手的部分。LEEF采用运行时动态注入clflush和mfence指令来模拟。实现机制指令注入LEEF通过ptrace(PTRACE_POKETEXT, ...)将目标进程内存中特定位置的指令临时替换为clflush和mfence的机器码然后让进程执行之后再恢复原指令。注入策略最简单的策略是每隔固定的写操作次数如每50次写注入一次持久化操作。更精细的策略可以尝试在缓存行被逐出或时间片结束时注入但这需要更复杂的监控。实操中必须注意的坑性能扭曲频繁的clflush会清空整个缓存行不仅影响目标地址还可能误伤同一缓存行上的其他数据导致比真实NVM更差的性能。mfence是全局内存屏障会序列化所有内存操作开销巨大。这可能导致你对持久化开销的估计过于悲观。正确性挑战动态注入指令难以完美模拟编译时插入的持久化原语。例如编译器可能对持久化区域进行特殊对齐优化而运行时注入无法知晓这些信息。建议对于严肃的持久化内存编程研究如研究PMDK库最好还是直接使用支持持久化指令如Intel的CLWB、PCOMMIT的模拟器或者在真实NVM硬件如Intel Optane DC Persistent Memory上进行测试。LEEF的持久性仿真更适合用于快速评估持久化操作的大致开销对整体应用性能的影响比例而不是验证持久化程序的正确性。4.4 模拟联动模式的操作流程这是LEEF的进阶用法用于软硬件协同设计研究。生成轨迹使用leef_ctl启动目标应用并开启轨迹生成模式。LEEF内核模块会开始记录内存访问流到文件。运行模拟将生成的轨迹文件喂给修改过的NVMain或DRAMsim模拟器。在模拟器中你可以修改内存控制器策略、尝试不同的Bank映射算法、模拟新型NVM的异步读写时序等。分析输出模拟器会输出详细的统计信息如行缓冲命中率变化ΔRHP、内存级并行度提升ΔMLP、平均延迟变化等。参数反馈编写一个脚本从模拟器输出中提取关键参数变化例如行缓冲命中率从60%提升到了70%。更新仿真在LEEF的配置文件中调整AGG模型中的行缓冲命中率参数或者定义一个“加速因子”β例如β 1.1 表示模拟器的优化带来了10%的内存子系统性能提升。然后用更新后的模型重新运行LEEF仿真观察应用整体性能的改善情况。这个过程使得硬件架构师和系统软件开发者可以在一个统一的、高效的框架内进行迭代硬件想法先在模拟器上快速验证其对微观指标的影响然后立即评估这个硬件改进对上层真实应用的整体收益。5. 案例研究在LEEF上探索内存微架构优化论文中用两个具体的案例展示了LEEF模拟联动模式的威力。这里我们深入解读一下并补充一些实操视角。5.1 案例一RowClone技术仿真背景memcpy或fork()时的写时复制Copy-on-Write会导致大量数据在内存内部搬运消耗大量带宽和能量。RowClone是一种硬件优化通过在内存控制器中增加新的命令利用DRAM内部的行缓冲直接在内存阵列内部完成批量数据拷贝无需经过处理器和内存通道。如何在LEEF上研究量化需求首先需要知道在你的目标应用中有多少内存流量是来自拷贝操作LEEF的轨迹生成器可以帮忙。你可以在轨迹中识别出连续的、源地址和目标地址有固定偏移的读-写对来近似统计拷贝操作的比例即FTMC拷贝流量占比。模拟器实验将轨迹输入支持RowClone模型的模拟器如修改版的Ramulator。模拟器可以模拟两种RowClone模式FPM同一子阵列内快速页拷贝和PSM跨子阵列的DMA式拷贝。模拟器会输出这两种模式分别能减少多少内存控制器命令、降低多少延迟。反馈与仿真假设模拟器结果显示FPM模式能将拷贝操作的延迟降低为原来的30%。你可以在LEEF的性能模型中将识别出的拷贝操作的内存访问延迟乘以一个0.3的因子。然后重新运行LEEF仿真看看应用整体获得了多少加速。LEEF的优势传统的模拟器研究受限于速度只能模拟很小的数据量如128MB。而LEEF可以轻松处理GB级别的真实应用如数据库、大型科学计算从而发现当数据规模极大、超出缓存时RowClone带来的收益是否会饱和或变化。5.2 案例二SALP技术仿真背景SALP子阵列级并行旨在挖掘DRAM Bank内部多个子阵列之间的并行性以缓解行缓冲冲突带来的性能损失。SALP-1, SALP-2, MASA是三种不同的子阵列管理机制。如何在LEEF上研究获取参数你无法直接在LEEF上实现SALP的硬件电路。但可以从已发表的使用模拟器研究SALP的论文中如论文引用[30]获取关键的参数变化表格。这些表格通常会告诉你在启用SALP-1/2/MASA后行激活延迟tRCD、预充电延迟tRP等关键时序参数会如何变化以及行缓冲命中率预计会提升多少。集成到模型将获取到的参数直接更新到LEEF的AGG性能模型中。例如将tRCD减少20%将行缓冲命中率的初始估计值提高15%。仿真评估用修改后的模型重新仿真一系列基准测试程序。你得到的不再是硬件模拟器输出的IPC每周期指令数而是真实应用在真实处理器上如果内存采用了SALP技术其端到端的运行时间会如何变化。这个结果对于评估一项硬件改进的最终系统级价值至关重要。个人体会这两个案例清晰地展示了LEEF的定位——它不是用来做晶体管级或电路级仿真的那是SPICE或Verilog模拟器的活儿。LEEF是做系统级影响评估。它回答的问题是“假设我们有了这么一项酷炫的硬件技术参数已知我们日常用的软件操作系统、数据库、应用到底能跑快多少” 这种从微观参数到宏观性能的桥梁作用正是系统研究者所需要的。6. 常见问题、局限性与未来展望尽管LEEF设计精巧但在实际使用中你可能会遇到一些问题和挑战。6.1 精度与开销的权衡问题时间片Epoch设置多长合适设置太短监控和注入开销占比大影响仿真准确性设置太长无法捕捉应用阶段的快速变化仿真粒度变粗。排查与调优基准测试先在不注入任何延迟的情况下运行LEEF测量不同Epoch长度下的监控开销T_overhead。选择一个T_overhead远小于典型T_gap例如小于10%的Epoch长度作为起点。敏感性分析用同一个应用使用不同的Epoch长度如1ms, 5ms, 10ms, 50ms进行仿真对比结果差异。如果结果差异很小说明应用对粒度不敏感可以选择较长的Epoch来降低开销。自适应Epoch可以实现一个简单的自适应算法当监测到应用内存访问模式稳定时延长Epoch当监测到模式剧烈变化如进入新阶段时自动缩短Epoch。6.2 多核与并发应用的挑战问题LEEF论文主要评估了单线程应用。在多核环境下共享资源如最后一级缓存、内存控制器的竞争会极大地影响性能。简单的每个核心独立监控和延迟注入无法准确模拟共享资源争用带来的非线性性能衰减。解决思路协同监控需要监控系统级的共享资源争用指标如LLC未命中率、内存控制器队列长度、行缓冲冲突等。全局协调的延迟注入不能孤立地给每个进程/线程注入延迟。需要一个中央协调器根据全局资源竞争情况动态调整每个核心的延迟注入量。这非常复杂接近一个资源调度问题。当前建议对于多核研究可以先将应用绑定到单个核心或单个NUMA节点上运行以规避复杂的竞争问题。对于必须研究多核交互的场景LEEF可能需要与能模拟缓存一致性协议和内存控制器仲裁的模拟器进行更深度的耦合。6.3 模型泛化能力与标定问题AGG模型中的时序参数tRCD,tCAS,tBurst以及行缓冲命中率等参数严重依赖于具体的NVM器件特性和工作负载。如何为一种新型NVM如FeRAM标定这些参数实操流程获取底层参数从器件物理学论文或原型芯片测试报告中获取基本的读/写延迟、带宽、耐久性等参数。微观基准测试拟合编写一组指针追逐pointer chasing、顺序/随机访问等微观基准测试程序。在LEEF中设置不同的时序参数组合运行这些基准测试将结果与已发表的、在同一或类似NVM硬件上运行的微观基准测试结果进行对比。通过迭代调整找到一组能使LEEF仿真结果与真实硬件测试结果最匹配的时序参数。这个过程本质上是模型标定。持续验证用一组独立的、更复杂的基准测试程序如SPEC CPU来验证标定后的模型是否依然有效。6.4 与真实硬件的对比验证这是所有仿真/模拟研究最终的“试金石”。随着Intel Optane DC Persistent Memory等商用NVM产品的出现现在有了进行对比验证的可能。方法在配备真实NVM硬件的系统上运行你的目标应用记录其真实性能。然后在另一台只有DRAM的类似系统上使用LEEF并按照真实NVM的参数进行配置仿真运行同一个应用。对比两者的性能指标如运行时间、IPC、内存带宽。预期与局限你可能会发现LEEF的仿真结果在趋势上是正确的例如应用A在NVM上比DRAM慢2倍LEEF预测是1.8倍但绝对数值存在偏差。这些偏差可能来自1) LEEF性能模型的误差2) 真实NVM的复杂行为如写延迟的不均匀性、功耗限制导致的性能波动未被模型捕获3) 持久化开销仿真的不精确。这种对比是完善LEEF模型的最佳途径。LEEF作为一个学术研究框架其最大价值在于提供了一个灵活、高效的探索平台。它可能无法给出商业级精度答案但它能让你在几天甚至几小时内完成在传统全系统模拟器上需要数月才能完成的探索性实验快速验证想法的可行性。在NVM软硬件生态尚未完全成熟的今天这种快速迭代的能力对于研究者来说其意义远胜于绝对的精度。它让大胆的架构创新和系统设计有了一个可以快速试错的沙盒。