OSDI 2018有哪些让人眼前一亮的文章？
理解“眼前一亮”的维度：
在深入介绍论文之前，我们先明确一下“眼前一亮”可能包含哪些方面：
颠覆性创新： 提出了一种全新的设计或实现方法，彻底改变了我们对某个问题的看法或解决方式。
解决长期存在的难题： 攻克了系统领域多年未决的棘手问题，提供了有效且优雅的解决方案。
实用性与性能突破： 实现了显著的性能提升或显著降低了资源开销，使其在实际应用中具有巨大价值。
安全性增强： 在操作系统安全方面取得了重大进展，提供了更强大的防护机制。
跨领域融合： 将系统设计与机器学习、硬件加速等其他前沿领域巧妙结合，产生了新的火花。
优雅的设计和简洁的实现： 以一种出人意料的简洁和优雅的方式解决了复杂问题。
基于这些维度，以下是 OSDI 2018 中几篇我认为“眼前一亮”的文章，我会尽量详细地介绍它们的技术细节和影响力：
1. “Faunus: Building a Scalable, Distributed, and FaultTolerant Graph Processing System”
亮点： 这篇文章的亮点在于它对大规模、分布式、容错图处理系统的设计和实现，尤其是在性能、可扩展性和容错性方面的权衡和创新。
详细介绍：
问题背景： 图计算在社交网络分析、推荐系统、知识图谱等领域至关重要。然而，处理大规模图（数十亿节点和边）在分布式环境中面临着巨大的挑战，包括数据 partitioning、通信开销、节点故障等。现有的许多图处理系统往往在性能或容错性上有所妥协。
Faunus 的设计哲学： Faunus 旨在提供一个高性能、可扩展且无需人工干预就能处理节点故障的图处理系统。它的核心思想是“Active Partitioning”。
核心技术 Active Partitioning:
动态数据分布： 传统的分布式图处理系统通常采用静态 partitioning，即图的顶点及其邻居被分配到固定的节点上。当图的结构发生变化或负载不均衡时，性能会急剧下降，且迁移数据代价很高。Faunus 的 Active Partitioning 允许顶点动态地迁移到更适合计算的节点上。
“VertexCentric” + “EdgeCentric” 的混合模型： Faunus 不仅支持传统的 Vertexcentric 模型（如 Pregel），还引入了 Edgecentric 的概念，允许边的属性和计算也得到更好的管理，尤其是在处理稀疏图或需要跨边信息时。
容错机制： Faunus 通过增量式 checkpointing 和 distributed logging 来实现高效的容错。当一个节点发生故障时，它只需要从最近的 checkpoint 和日志中恢复少量最近的状态，而不是整个图的状态。这种增量式恢复大大缩短了故障恢复时间，使其能够承受更频繁的节点故障。
内存管理与优化： Faunus 采用了一种“offheap”的内存管理策略，允许图数据存储在JVM堆外，从而避免了垃圾回收对图计算性能的影响，并能管理远超内存容量的图数据。
API 设计： Faunus 提供了一个简洁而强大的 API，允许开发者以相对容易的方式表达图计算逻辑，同时系统会在底层处理分布、容错和性能优化。
为什么眼前一亮：
解决了“大图”的棘手问题： 在那个年代，处理PB级别甚至EB级别的图数据并保证高性能和容错性是一个非常困难的任务。Faunus 的 Active Partitioning 提供了解决这个问题的有效途径。
容错的优雅： 增量式 checkpointing 和 logging 的结合，使得系统在节点故障发生时能够快速、无缝地恢复，这对于大型集群环境至关重要。
性能的显著提升： 相较于当时的一些主流图处理系统，Faunus 在许多基准测试中展现出了显著的性能优势。
2. “MetalOS: A HardwareAssisted Security Kernel for Transient Execution Attacks”
亮点： 这篇文章的亮点在于其开创性的硬件辅助安全设计，专门应对 Spectre 和 Meltdown 等瞬态执行（Transient Execution）攻击。
详细介绍：
问题背景： Spectre 和 Meltdown 等漏洞利用了现代处理器的推测执行（Speculative Execution）机制，在执行过程中秘密地泄露信息，绕过了传统的内存访问控制。这些攻击对现有操作系统的安全性构成了严重威胁，修复方案往往带来巨大的性能损失。
MetalOS 的核心思想： MetalOS 不仅仅是一个软件层面的修复，它深度集成硬件能力来解决这个问题。它引入了一个精简的安全内核 (Security Kernel)，并设计了与硬件协同工作的机制，以隔离和保护敏感代码的执行。
核心技术：
硬件隔离的“安全区域” (Secure Enclaves): MetalOS 允许应用程序在处理器上创建一个硬件隔离的“安全区域”。这些区域的内存访问受到严格的硬件控制，即使在推测执行期间，也无法访问到区域外的敏感数据。
推测执行防护的硬件支持： MetalOS 鼓励或强制将关键的、敏感的代码（如密码学函数、密钥管理代码）运行在这些安全区域中。硬件层面会提供机制来阻止或限制推测执行在这些区域中进行跨边界的数据访问。
安全内核的职责： MetalOS 的安全内核非常精简，主要负责：
创建和管理安全区域： 协调硬件来划分和配置安全区域。
安全地加载代码： 确保只有经过验证和授权的代码才能被加载到安全区域中执行。
处理安全事件和异常： 当推测执行可能导致越界访问时，安全内核会介入并处理，阻止信息泄露。
与应用程序的接口： 提供安全的 API，让应用程序能够调用安全区域内的功能。
硬件特性利用： MetalOS 需要依赖特定的硬件特性（如一些处理器可能提供的内存隔离和控制指令），并将其抽象出来供软件使用。
性能考量： 为了最小化性能开销，MetalOS 极力避免了对所有代码进行隔离。它只将最关键的、最敏感的代码放在硬件保护的安全区域中，从而将性能影响控制在可接受的范围内。
为什么眼前一亮：
“硬件+软件”的协同防御： 这是它最突出的亮点。在 Spectre/Meltdown 出现后，很多工作都集中在软件层面的缓解措施，而 MetalOS 展示了一种更根本的解决方案，通过硬件来提供安全保障。
对瞬态执行攻击的“根本性”解决： 通过硬件隔离和受控的推测执行，MetalOS 在理论上提供了一个比纯软件修复更强大的防御机制。
安全边界的重新定义： 它重新思考了操作系统和硬件之间的安全边界，将一部分安全关键功能下沉到硬件层面实现。
对未来安全设计的启示： MetalOS 的设计理念对未来操作系统和处理器安全设计产生了深远影响，推动了对硬件辅助安全技术的关注和研究。
3. “No.Wait: A New Approach to NonVolatile Memory Systems”
亮点： 这篇文章的亮点在于其提出的全新内存管理和数据持久化方法，以极低的延迟和高吞吐量利用了非易失性内存 (NVM) 的特性。
详细介绍：
问题背景： 非易失性内存 (NVM)，如 3D XPoint (Optane)，结合了 DRAM 的速度和 NAND Flash 的持久性。然而，如何有效地利用 NVM 的这些特性，并提供与 DRAM 相似的低延迟访问，是一个巨大的挑战。传统的持久化机制（如日志记录）往往引入了显著的延迟。
No.Wait 的核心思想： No.Wait 旨在实现“无等待” (No Wait) 的 NVM 访问，即数据写入 NVM 后，应用程序可以立即返回，无需等待持久化操作完成，同时保证了数据的正确性。它通过一种巧妙的基于日志结构 (LogStructured) 和版本控制 (Version Control) 的方法来实现这一点。
核心技术：
日志结构化的 NVM 管理： No.Wait 将 NVM 组织成一个日志结构。所有数据的修改都被写成新的日志条目，并追加到日志的末尾。这种追加式写入非常高效，避免了原地更新的开销和碎片化问题。
版本化数据结构 (Versioned Data Structures): No.Wait 使用版本化的数据结构来管理内存中的数据副本。当一个数据项被修改时，会在内存中创建一个新的版本，并将其指针指向新的数据。
“FenceLess” 的持久化： 这是 No.Wait 的核心创新之一。当应用程序写入数据时，它只需将数据写入内存缓冲区，然后将指向新版本的指针写入 NVM 日志。系统在后台异步地将内存中的最新版本刷写到 NVM 中。关键在于，应用程序可以认为数据已经持久化，即使它还没实际写入到 NVM 的最终位置。
原子性和一致性保证： No.Wait 使用“事务” (Transactions) 来保证数据的一致性。每个修改操作都被封装在一个事务中。当事务提交时，它会将其修改的日志条目写入 NVM，并更新数据结构的指针。即使在写入日志的中间发生崩溃，系统可以通过回放日志来恢复到事务提交前的状态，或者在成功提交后恢复到新状态，而不会丢失任何已确认的修改。
垃圾回收 (Garbage Collection): 随着日志的不断增长，需要进行垃圾回收来释放旧的数据版本。No.Wait 使用一种高效的后台 GC 机制来清理不再被任何活动版本引用的旧数据。
直接的 NVM 访问： No.Wait 绕过了传统的块设备 I/O 栈，允许应用程序直接通过内存地址访问 NVM，从而获得更高的性能。
为什么眼前一亮：
彻底解决了 NVM 延迟问题： No.Wait 的“无等待”设计有效地解决了 NVM 写入延迟过高的问题，使其能够提供接近 DRAM 的性能体验。
优雅的持久化模型： 通过版本化数据结构和日志结构化的管理，它提供了一种简单而强大的持久化模型，易于应用程序开发和理解。
高吞吐量和可扩展性： 日志结构和异步刷写的设计使其能够轻松处理高并发的写操作。
对未来存储系统的启示： No.Wait 的方法为如何设计利用新一代持久化内存提供了重要的范例，对数据库、文件系统等领域都产生了深远影响。
4. “Unikernel Cloud: Deploying and Managing Unikernels in the Cloud”
亮点： 这篇文章的亮点在于它提供了一个完整、可用的框架和系统，使得在云环境中部署和管理 Unikernel 成为可能，并且展示了其实际的优势。
详细介绍：
问题背景： Unikernel 是一种特殊的操作系统，它将应用层代码和必要的内核功能打包成一个独立的、可执行的镜像。相比于传统的虚拟机或容器，Unikernel 具有极小的攻击面、更快的启动速度和更少的资源开销。然而，在实际的云环境中部署和管理 Unikernel 面临许多挑战，包括镜像构建、网络配置、存储集成、安全策略、以及与现有云管理工具的兼容性。
Unikernel Cloud 的核心目标： 构建一个端到端的解决方案，使开发者能够轻松地构建、部署和运行 Unikernel，并充分利用云平台的优势。
核心技术：
通用的 Unikernel 构建框架： 提供一个统一的、可扩展的框架，支持多种编程语言（如 C, Go, Rust）和多种 Unikernel 运行时（如 MirageOS, OSv, IncludeOS）。该框架自动化了从源代码到可部署 Unikernel 镜像的构建过程。
与云平台（如 OpenStack）的深度集成： Unikernel Cloud 的一个关键部分是它能够与现有的 IaaS 平台（如 OpenStack）无缝集成。它将 Unikernel 镜像作为自定义的虚拟机镜像来处理，并能够利用云平台提供的网络、存储、安全组等功能。
自动化镜像管理： 提供工具来管理 Unikernel 镜像的生命周期，包括版本控制、分发、更新等。
网络和存储的抽象： 提供一套抽象的接口，允许 Unikernel 在云环境中以标准化的方式访问网络和存储资源，而无需关心底层云平台的具体实现细节。
安全和隔离的强化： 虽然 Unikernel 本身就具有良好的安全特性，Unikernel Cloud 还进一步利用云平台的隔离机制（如虚拟机隔离）来提供多层安全防护。
性能和效率的展示： 通过大量的实验和案例研究，证明了 Unikernel 在云环境中的实际优势，例如极快的启动时间（秒级甚至毫秒级），显著的内存和 CPU 占用率降低，以及更小的安全攻击面。
为什么眼前一亮：
“理论变现实”的典范： Unikernel 的概念并非全新，但将其“落地”并使其在复杂的云环境中变得易于使用是巨大的挑战。Unikernel Cloud 提供了一个真正可用的解决方案。
解决了大规模部署的瓶颈： 通过与云平台的集成和自动化工具，它极大地降低了部署和管理 Unikernel 的门槛，使得其在生产环境中成为一个可行的选择。
突出了 Unikernel 的实际价值： 这项工作通过实际案例，清晰地展示了 Unikernel 在提高效率、安全性和响应速度方面的巨大潜力，尤其是在微服务和 Serverless 计算等场景下。
对云原生和容器生态的补充： 在容器技术蓬勃发展的背景下，Unikernel Cloud 提供了一种不同的、更轻量级、更安全的应用部署范式，与现有的生态系统形成了互补。
总结：
OSDI 2018 呈现了许多令人兴奋的系统研究成果。上述这几篇文章只是其中的一小部分代表，它们在各自的领域都做出了重要的贡献，通过创新的设计、解决实际难题或开辟新的研究方向，真正地“眼前一亮”。这些论文也反映了当时系统领域的一些热门趋势，如硬件辅助安全、新存储技术利用、以及对云原生和大规模分布式系统复杂性的深入探索。
网友意见
OSDI'18 preview
从现在放出来的文章标题和作者信息来看，不吹不黑，Microsoft是最让人眼前一亮的，参与了大会47篇文章中的13篇的工作。MIT拿下了其中的5篇，是所有大学里面最多的，其中Frans一人就贡献了4篇Orz。Madison和UW也各有3篇入账。
至于文章，OSDI涵盖的方面太大了，亮不亮很主观的。并且对于在这局游戏中的研究人员来说，往往越熟悉的领域越不觉得有亮眼的工作。（此处应该有捂脸表情）
在大的文章分类的感受上，我感觉OSDI的文章还是一如既往很关注系统质量相关的研究，因为现在的软硬件系统越来越复杂。错误分析、debug、形式化验证、安全等相关topic还是非常的火热，超过1/3的文章属于这个内容。另外一个发现就是，今年面向应用的计算系统相关的文章较往年似乎多了一些，特别是机器学习相关系统研究，在今年的OSDI上迎来了一个爆发。
下面按照我的个(zhi)人(shi)喜(ju)好(xian)给出一个今年OSDI文章导读。
Understanding Failures
第一篇文章应该是跟Ryan之前发表在HotOS’17上的Gray Failure一脉相承的工作，可以在大型复杂的系统中捕捉到不易被发现的错误，从而进行相应的处理避免更严重的错误发生。Ryan师从Yuanyuan Zhou老师，在复杂系统分析和研究上有很深造诣，毕业后在MSR当过postdoc，现在是JHU的AP。据CX说这是一篇质量很高的工作，很期待！
第二篇文章REPT，微软资深抓bug团队出品。在成熟的广泛使用的系统中找bug，其对于工业界的意义也是毋庸置疑，找出来一两个都是巨大的贡献。去年他们团队在SOSP上也有一篇分析和加速复现Concurrency Bug的文章，感觉这篇OSDI文章应该也是一篇实战催生的扎实工作。
第三篇和第四篇failure analysis的文章分别来自UT Austin和University of Waterloo，目前找不到额外的信息。
Operating Systems
这个section的topic叫OSs，从这个名字看起来就已经包罗万象了。
第一篇文章LegoOS，一个为resource disaggregation设计的全新OS。Yiying Zhang的实验室最近在System领域的顶会上表现很强势，去年的SOSP上他们的工作LITE，做了一个kernel-level RDMA support，保持RDMA的低延迟高性能的同时提供一个高层次的抽象从而可以更好的构建基于RDMA的应用。感觉应该是名字起的不是那么好，不是很好搜索到，虽然是在github上开源，但是关注的人并不多。这里给个传送门。 LegoOS这个名字就起得非常好，容易搜索而且非常形象。一作是我的本科同班同学，单老板颜值高身材棒性格赞特别帅（点赞爆照？？）。在我看来，resource disaggregation是所有构建应用的人的梦想，即透明地使用data-center内所有的资源，将其当作一台大电脑，不需要去考虑server boundary，resource locality等。如今，随着网卡技术的飞速发展，数据中心内部网络延迟，特别是rack内部的延迟已经非常可观，很多人做梦都想在某种程度上将其变成现实，而这也是近年一个研究的热点。OSDI'16上伯克利的文章就讨论了实现resource disaggregation所需要的网络，SOSP'17上还有一个Workshop on Resource Disaggregation。
第二篇文章出自MIT，标题就说明了一切，探讨了用高级语言编写POSIX kernel的好处和代价，非常的有意思。很期待这个高级编程语言是什么，python?（哈哈哈哈哈哈哈哈哈哈）
=====
经评论区大神指出是Frans大神用Go写的。Go有大厂推再加上还有k8s这样的killer app，现在已经在系统圈子占据相当的地位了。
第三篇文章出自UT-Austin和VMware，从Reconfigurable判断应该是FPGA相关的工作。
第四篇是来自CMU的关于checkpointing的文章。在一个异步执行的系统中，做checkpointing的标准做法是Chandy-Lamport algorithm。Flink就采用这个算法来做到exactly-once这个feature。很好奇这篇文章的Adaptive和Dynamic所对应的方法。
Scheduling
Arachne是斯坦福John Ousterhout带队出品的一个user-level thread lib，现在可以看到一个预览版，对于KV store有显著的加速效果，可以减少超过10x（卧槽！）的tail latency。很难想象在这种经典的问题，没有GPU没有FPGA，就是普通的CPU内存，还能有这么显著的突破，感觉是黑科技！
第二篇文章和第三篇文章目前还找不到任何相关信息，分别是UW-Madison和University of Michigan做的工作。
第四篇文章RobinHood的一作是CMU的一个Postdoc，之前在NSDI'17上发表了AdaptSize，一个用ML方法优化CDN缓存的工作，带来的性能提升非常的显著，让我印象深刻。而RobinHood这篇文章的idea从他的NSDI poster也可以得窥一二。
Data
第一个工作Noria，来自MIT，相关的短文在网上可以找到，只不过system换了个名字，主要的idea是说通过streaming和暂存一些状态，从而加速query。
第二个工作来自上交的IPADS实验室，海波老师是真的强，年年有SOSP和OSDI。这篇文章的idea从名字上判断是把transaction进行解耦分类，然后对不同类型应用不同的优化从而达到整体最优。一作Xingda Wei是做分布式transaction的高手，在这个topic上有SOSP，ATC和OSDI三篇高水平的工作了，很强！
======
感谢评论区大神指出这个工作是按照OCC协议的阶段解耦，按阶段行为、硬件特性来选择适合的primitive
第三篇文章还是UW-Madison的工作，不过可以在Mosharaf教授的博文中得窥一二，主要的idea是根据当前data-center的resource的状态来改变query plan。
第四个文章是CMU，Microsoft和ETH合作的文章，在ArXiv上有预览版。主要是说在Video上运行CNN做Object detection非常消耗计算资源，而他们提出一种低代价低精度的CNN检测方法，并且配合高精度的CNN校验，并基于此设计了一个系统。这个idea其实很直观而且获得的资源节省性能提升也是可以预期的，主要是这一系统设计方法到底有多通用，以及这里面是否需要新的系统设计方法的支持，这些都需要仔细阅读他们的文章。
Verification
第一篇文章是Xi Wang大神的工作，跟他之前的OSDI'16的工作Push-Button Verification和SOSP'17的工作Hyperkernel一脉相承。第二篇和第三篇的工作是Xi Wang大神的老师Frans Kaashoek和Nickolai Zeldovich的工作。而最后一篇的工作来自于Microsoft Research。我对这种形式化验证的方法了解颇浅，这里就不班门弄斧了。
Reliability
FuzzyLog是一个放宽一致性限制的log系统，不严格要求total-ordered，允许partially-ordered的更新和存储，很好奇这会给application端带来什么新的好处和机会。代码已经开源在github。
Maelstrom是facebook做的一个数据中心级别的容灾系统，目前还找不到额外的资料，不过感觉还是很值得一看的。
第三个工作还是UW-Madison出品的工作，探讨分布式系统上fault-tolerance的经典问题。
第四个工作关注的是可复现性的问题，从现在的摘要看来，他们关注的问题是：同样的程序在同样的机器上反复执行有可能会有不同的性能（interesting...）。这篇文章分析了一个10个月之久的超大trace来分析这种variance的原因，值得关注。
File Systems
第一篇文章Pocket是斯坦福和IBM合作打造的一个弹性分布式数据存储系统。这里可以看到预览版的文章和slides，值得一读。
第二篇文章是Facebook的工作，现在还没有相关的信息。
第三篇文章是来自华科的工作，应该是华科的第一篇OSDI工作，恭喜恭喜！这个工作是提出一个在NVM上全新设计高性能Hash结构，针对写入操作做特别优化，按照作者的github判断，这个工作应该也会在近期开源。他们团队的工作最近在NVM上的工作取得了很大的突破，在今年的MICRO和OSDI上都有斩获。
第四个工作FlashShare是好多不同学校的韩国人合作的SSD上的存储优化工作。
Debugging
这个章节的工作都不太熟悉，略过。
Machine learning
深度学习毫无疑问是当下系统届最为关注的应用之一，在上一届OSDI上面，Google发表了Tensorflow，宣告了以data-flow为抽象的通用的深度学习框架的到来。2年过去了，无论是学术界还是工业界，很多人都在思考，深度学习系统的设计是否适合当前深度学习算法应用的发展，深度学习基础架构是否已经到了终极形态，深度学习迈向实用和广泛部署还有什么挑战等问题。去年SOSP上相关的文章几乎没有，沉寂许久之后，今年Deep learning system卷土重来。在这个machine learning section里面，一共录取了4篇文章：Ray, TVM, Gandiva, PRETZEL, 分别讨论了深度学习系统应用的四个重要的问题： 1. 针对新型深度学习应用的系统设计 2. 深度学习程序在异构硬件上全自动编译器设计 3. 深度学习计算平台的设计 4. 深度学习模型服务部署上的优化
其中Ray是伯克利打造的分布式执行框架，从ArXiv预览版的文章看来，重点用于支持强化学习这类新型的重要机器学习应用。其设计的重点是将worker无状态化，并且配合高效的分布式调度器来提升整个系统的throughput。
TVM是陈天奇大神打造的全自动深度学习编译器，希望能支持异构硬件上的自动代码生成和优化。在我看来，这是深度学习走向实用和异构硬件飞速发展的今天非常实用的一个问题，也是非常具有挑战性的一个问题，如何把传统的编译技术和全新的应用、异构的硬件特性做一个好的抽象整合，非常考验系统设计的能力。知乎上的讨论都比较多，这里我就不赘述了。
Gandiva是我们通过对于微软内部深度学习训练平台的观察和思考，从而提出的全新的深度学习平台调度系统。深度学习任务对比以往big-data任务的本质不同在于其是一个feedback-driven的过程，用户往往为了一个特定的目标做着模型结构或者参数的搜索，而达到这个目标通常需要一系列的任务。于是，优化其中的某个任务并完成它，有的时候显得并不是那么的重要，而为用户提供early feedback则往往能加速搜索的过程。另外一方面，深度学习的发展使得不同计算任务间在资源需求和使用上呈现heterogenity，很难在一开始为一个任务找到最佳位置。不同于传统集群调度器把一个job或者task当作黑盒，仅在到达的时候做调度，我们利用了深度学习任务的周期性特性，通过观察和获取运行时的任务特性和数据来进行内省的反复调度，从而可以显著降低深度学习整个pipeline的时间，并且提升整个GPU集群的资源利用率。在Gandiva中，我们引入了对于计算资源的over-subscription并且提供了一系列全新的调度机制：suspend-resume, packing, time-slicing, migration, grow-shrink等等，从而做到了26%的集群资源利用率提升和10倍以上的AutoML加速。
PRETZEL是Seoul National University，Politecnico di Milano和Microsoft联合打造的Serving系统，从题目上判断应该是通过引入机器学习相关的特性来提升Serving系统本身的性能。
Networking
Splinter是犹他大学的一篇文章，关注Multi-tenant下存储的优化。
第二篇文章来自KAIST，是一篇Neural network for system的工作，这一系列的工作之前发表在HotNets'17上，分析了在CDN中引入DNN有什么潜在的机会和挑战，相信这篇OSDI文章就是对于这一问题的回答，非常值得期待。DL for system/networking也是最近讨论很多的一个焦点的话题，越来越多的文章证明DL可以在Job scheduling, congestion control上做到比传统的rule-based要好的结果，但是也开始有一些反对的声音，指出DL也有不佳的表现，并且因为DL是个黑盒，基本无从得知其原因。可解释性其实是DL的根本性问题，整个ML届还在为之努力，但是因为这样就完全放弃DL算法为系统和网络带来的好处在我看来是不对的，取而代之的应该是更好的系统抽象设计和方法，使得DL fail的时候可以被检测和处理，做到fail safety。
第三个工作Floem是伯克利，UW， UT-Austin多校合作的一个工作，在gitlab上开源，其描述是“Floem is a language, compiler, and runtime for NIC-accelerated network applications.”，感觉是希望打造一个统一的软件栈来构建支持SmartNIC的网络应用。
Security
扫了一眼这个章节四个工作的标题，最吸引我的是第一篇文章Graviton，这是微软出品的Confidential Accelerators，旨在GPU上提供可信执行环境的工作，大致的idea可以从这个slides里面窥得一二。GPU能够提供高效的计算性能，现在变得越来越重要，但是GPU的设计之初就缺乏可信原语，这给很多的攻击带来了可乘之机。这篇文章希望能提供安全性的支持，并且尽量不损害GPU的使用性能。这是一个全新的问题，而且由于这个工作是微软而不是英伟达做的，没法有硬件或者驱动的支持，应该是一个纯软件的设计。我很好奇其系统的接口抽象和设计细节。
Graphs and Data
这一章节包含了传统的big-data system，graph system，和streaming system，总计有4篇文章入选，其中两篇关于graph mining。
ASAP利用了近似计算来加速graph mining。Graph mining和query approximation都是数据库领域近些年很火的topic，很多时候用户并不需要精确值也渐渐成为了大家的共识，很期待它们能给系统设计带来全新的insight。
RStream把graph mining做到单机上面，利用了关系代数的方法。感觉是一个crazy idea，反正我是没想出来怎么能做到，非常期待这篇文章。
第三篇工作是来自ETH的streaming system，应该和NSDI'18文章SnailTrail一脉相承的，我挺喜欢他们组做的文章，两个字，扎实。
最后一篇工作Flare是针对Spark在中等规模数据处理场景下做优化，由斯坦福和普渡联合完成（仿佛有什么不对？）。文章的投稿版本已经公开。作为大数据基础设施的标准之一，Spark在工业界里面可谓必不可少，而针对Spark的性能分析的文章从未停止过。早在15年，Kay的NSDI文章指出IO或者说commmunication并不是瓶颈所在，一时让人大跌眼镜。Flare这篇文章也指出Spark在处理中等规模数据上的性能问题，这其实跟Frank McSherry在COST文章中关于Efficiency和Scalability的讨论相呼应。从系统设计的角度来说，不同的系统设计的时候往往有潜在的关于应用场景和底层依赖的assumption，不可能适用于所有的情况，而深入的思考系统设计的局限性所在，往往是优化之道乃至有破旧立新的机会。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有