技术写作与文档2011walkingrandomly.com
如何写出《GPU 太棒了》这类论文
How to write a "GPUs are Awesome" paper
导读
这篇博客借一个刻意简化的 GPU 基准，讨论如何写（以及如何不写）“GPU 很棒”式论文：如果只做一次简单运算又把数据全传回 CPU，GPU 当然不占优。对写作者的价值在于：技术论证要选有代表性的案例、交代优化与数据传输条件，并警惕用糟糕的基准得出大结论。
可以直接用的写作要点
- 01
用能代表真实工作负载的例子支撑结论，别拿“对一亿个数求正弦”这类过于简单的基准当普遍证据。
- 02
写性能对比时交代优化程度和数据搬运成本，否则容易把“没优化好”误写成“技术本身不行”。
- 03
先说明适用条件（计算量、数据传输比例、内存层级），再下“快/慢”的判断。
- 04
引用更全面的反方分析（如 Intel 的“Debunking the 100X GPU vs. CPU myth”），让论证更可信。
HN 评论精选
基准不公平：GPU 优势需要优化和数据驻留；不愿投入优化就别用 GPU。
这有点不公平。我用一块便宜的旧 NVIDIA 显卡，相比工作时相当强的 Xeon，获得了约 30 倍加速。关键区别是 OpenCL kernel 远不止“算个正弦”；数据上了 GPU 后，应尽量多做计算再搬回。GPU 有不同种类的内存，只对数组每个值求正弦没有高效利用内存（没用上类似 GPU L2 缓存的东西；CPU 缓存是否也解释了 CPU 上的加速？）。所以这会是 IO 受限——测试只是在比较到 CPU 和到 GPU 的内存传输，得到相似数字。最公允的说法是：如果不愿投入精力理解如何最佳使用 GPU，就别碰它。（顺便，除非需要 64 位浮点或受 PCI 插槽限制，买普通显卡比买新款顶级 Fermi 计算卡更合理；我们从旧显卡换到 C2050 只多 20% 加速，相比离开 CPU 的 30 倍微不足道；NVIDIA 对昂贵卡的支持很差，所以 OpenCL 值得多花功夫，图个安心可以换别家。）
andrewcooke查看英文原文
hmmm. this is a little unfair. i've got around a factor of 30 speedup using a cheap GPU (some old nvidia card i had in my machine) compared to a fairly meaty xeon at work. the important difference is that the kernel (written in opencl) was much more than just "taking the sine". once the data are on the gpu you don't want to move them back until you've done as much work as possible. and there are different "kinds" of memory on the gpu. simply taking the sine of every value in an array is not using that memory efficiently (you're not using the equivalent of the gpu's L2 cache (and is cpu cache explaining the increased speed on the cpu?)). so this would be io limited - all the test is doing is comparing memory transfer to the cpu with memory transfer to the gpu, and coming up with similar numbers. i guess the fairest thing you can say is that if you're not going to put the effort into understanding how best to use gpus, leave them alone. (incidentally, unless you need 64bit fp, or are really limited by pci slots, it makes much more sense to buy commodity graphics cards rather than the new top-end fermi made-for-compute cards - for us switching from an "old" graphics card to a c2050 gave an extra 20% speedup, iirc, which is peanuts compared to the factor of 30 from moving off the cpu; also, nvidia support for the expensive cards sucks, so opencl is worth the extra effort for the peace of mind that you can try something else)
计算量与数据传输的比例决定 GPU 是否更快；统一内存架构未来会解决这类问题。
如果对 1 亿个数每个只做一次数学运算，然后把它们全读回 CPU，GPU 当然更慢。但如果每个数要做 1000 或 10000 次运算，最后只取回约 100 万个数的小结果，GPU 会远超 CPU。最终答案在 AMD Fusion 路线图几步之后：GPU 像当年的浮点单元一样成为协处理器，与 CPU 同 die、统一内存和缓存；该架构实现后这些问题会消失。
modeless查看英文原文
If you're only doing one mathematical operation on each of the 100 million numbers and then you need to read them all back to the CPU, of course the GPU will be slower. However, if you need to do 1,000 or 10,000 mathematical operations each on 100 million numbers, and then get back a smaller answer of maybe a million numbers, then the GPU is going to blow the CPU away. The ultimate answer to this post is a couple of steps down the AMD Fusion roadmap, where the GPU is a coprocessor like floating point units were back in the day. The GPU and CPU will be on the same die with unified memory and caches. When that architecture is fully realized, these problems will go away.
例子不公，应参考 Intel 更全面的分析。
有趣的博客，但例子不公平。Intel 做过更全面的分析：“Debunking the 100X GPU vs. CPU myth”（http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.2755&rep=rep1&type=pdf）。
kyky查看英文原文
Amusing blog, but an unfair example. Intel did a more extensive analysis of this issue in "Debunking the 100X GPU vs. CPU myth" [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.2755&rep=rep1&type=pdf]
论点有效但案例不具代表性；数据驻留和避免传输是首要优化。
文章提到的所有点都成立。然而，对 1 亿个数求正弦虽简单，却不很有代表性；在 kernel 调用之间尽量把数据留在 GPU 内存、避免传输，是 GPGPU 程序首先要考虑的优化之一。
mynegation查看英文原文
All points touched in the article are valid. However, calculating sine of 100M numbers is simple but not very representative case for GPGPU programs. Leaving data in GPU memory as long as possible between kernel invocations and avoiding transfers is one of the first optimizations that must be considered.
同类还值得读
编写更好文档的框架
A Framework for Writing Better Documentation
这是 Divio 的文档写作框架，把技术文档按「读者的目标」分成四类：教程（学习导向）、操作指南（问题导向）、参考（信息导向）、解释（理解导向）。
技术写作与文档2021 · 637 分 · 76 评4 条写作要点编辑精选写好一份设计文档
Writing a good design document
这篇 HN 帖子标题为《Writing a good design document》，主题是如何写好一份设计文档；对写作者来说，它值得作为技术写作和结构化说明文的参照。
技术写作与文档2025 · 581 分 · 147 评3 条写作要点编辑精选技术写作课程
Technical Writing Courses
这是 Google 官方免费技术写作课程（两门），讲受众定义、主动语态、短句、文档结构等基础方法。
技术写作与文档2020 · 571 分 · 73 评4 条写作要点编辑精选写出更好的错误信息
Write better error messages
这篇帖子讨论如何写出更好的错误信息，评论补充了开发者场景下的具体做法和真实反面案例。
技术写作与文档2022 · 566 分 · 253 评4 条写作要点编辑精选写一本技术书的经济账
The Economics of Writing a Technical Book
一位技术书作者拆解写书的真实经济账：版税收入往往远低于投入的时间成本。
技术写作与文档2018 · 519 分 · 149 评4 条写作要点编辑精选