系统与数据库2016vcl.ece.ucdavis.edu
一款 32nm 的 1000 处理器阵列
A 32nm 1000-Processor Array
进阶 · 约 60 分钟读完前置知识：计算机体系结构、多核/众核架构基础、VLSI 工艺基础
导读
这篇论文（UC Davis 的 KiloCore 项目）展示了在 32nm 工艺下集成 1000 个独立处理器核心的芯片阵列，每个核心可独立运行并关断以实现极高能效。评论者指出其面向整数运算和流式处理场景，能效表现优异但缺乏与 GPU 的直接对比。
HN 关注点：千核芯片的实际能效、与 GPU 的对比，以及如何为这种大规模并行架构编程、其内存带宽瓶颈等现实问题。
HN 评论精选
这几条评论里：质疑 2 补充 2
补充补充与 GPU 的能效对比：千核芯片能效高约 5 倍，但 GPU 追求的是性价比
论文竟然没和 GPU 对比，我来补一下。论文似乎只谈整数运算（提到 ALU 而非 FPU），而我下面的 GPU 数据是单精度浮点，所以是苹果比橘子。现代 14-16nm GPU（如 Tesla P100 或 RX 480）在 200-300W 下每秒约 5-10 万亿次运算，约 30 pJ/op。也就是说 GPU 能效比它低约 5 倍，作者做得不错。不过 GPU 优化的不是绝对能效，而是性价比。
mrb查看英文原文
It is surprising the paper makes no comparisons with GPUs. So I will do it. For starters it looks like they are talking about integer operations (I only skimmed the paper and it mentions an ALU, not an FPU), whereas my GPU numbers below are single precision floating point numbers. So it is apples vs oranges. So, a modern 14-16nm GPU like the Tesla P100 or RX 480 does about 5 to 10 trillion ops/sec at 200-300 W, and approximately 30 pJ/op. So GPUs are about 5x less power efficient. The paper authors did a good job. However GPUs are not optimized for absolute power efficiency, but mostly for performance per $.
质疑质疑编程模型：放弃缓存一致性后如何编程是个大问题
这种芯片到底怎么编程？这方面有什么进展？缓存一致性似乎很难放弃——连 CPU-GPU 缓存一致性都正在成为标配，连 ARM 都在提供。
willvarfar查看英文原文
So how do you program such a beast? What progress is being made on that front? Cache coherency seems really hard to give up on, and even CPU-GPU cache coherency is becoming the expected norm, with even ARM delivering it.
补充补充历史先例：2007 年的 Ambric 芯片早已实现数百核并商用
这让我想起 2007 年 Ambric 的 am2045，有 336 个核心。他们把 40 颗装进一台 X 光机，总共 13000 个核心。
imtringued查看英文原文
This reminds me of the Ambric am2045 with 336 cores from 2007. They put 40 of these into an X-Ray machine for a total of 13,000 cores. https://en.wikipedia.org/wiki/Ambric http://www.embeddedinsights.com/epd/Diagrams/nethra-am2045.jpg
质疑指出核心局限：千核芯片只适合流式处理，内存带宽严重不足
Venray Technology 是我见过的唯一看似可用于通用大规模计算的高 CPU 密度设计，但他们的退出策略（卖给 DRAM 厂商套现）没成。很多这种多核芯片单颗做不了太多事，只适合加密、数据包路由、视频流处理等流式算法。它们的内存带宽也远不如 GPU，无法给这么多处理单元各自喂数据。有人考虑过内存需求吗？
white-flame查看英文原文
I think that http://venraytechnology.com/ is the only high CPU density design I've seen that seems useful for general purpose, large-footprint computing, but their launch model (sell to a DRAM manufacturer and cash out) didn't go anywhere. So many of these tons-of-cores chips can't really do much per chip, and are only suited for streaming algorithms like encryption, data packet routing, video stream processing, etc. They also have nowhere near the memory bandwidth to compare to GPUs, or to feed those many processing units with unique data per unit. Would somebody please think of the memory requirements? :-P (or Venray, please seek investment and start pushing your designs yourself)
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2016Hacker News 讨论帖148 分 · 104 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选