编程与软件工程catb.org编辑精选
失落的 C 结构体打包艺术
The Lost Art of C Structure Packing
2014 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Eric S. Raymond 关于 C 结构体内存布局与打包的经典文章：解释编译器为何在成员之间插入填充字节、如何通过调整成员顺序等方式减少浪费，并讨论对齐、可移植性与位域等问题。文章把 C 结构体在内存中的实际形态讲得很清楚，是理解底层布局和性能优化的入门材料。
为什么经久不衰：内存对齐与填充是 C 语言底层性能和可移植性的永恒问题，文章规则清晰，评论区又补充了现代 CPU 缓存行、非对齐访问等新变化，因此今天仍值得读。
HN 评论精选
现代结构打包的主要价值是减少缓存未命中，且 Intel i7 后非对齐访问代价大幅降低，优化假设已经改变。
现在我做结构体和位打包几乎不假思索，因为这是旧习惯。正如文章所说，如今仍习惯性仔细优化结构体布局的人，多是像我一样长期写底层和高性能代码的人，大多数程序员对此无感。今天做这件事的理由和十年前不同，规则也因处理器变化而改变。补充两点：今天优化结构打包的主要原因是减少缓存行缺失；缓存行缺失很昂贵，所以让代码多做一些工作来减少缓存行填充，很多情况下是净性能收益，最优结构打包基本是“免费”减少缓存缺失的方式。在现代 Intel 微架构上，对齐对性能的影响比过去小得多；从 i7 开始，非对齐内存访问成本大约与对齐访问相同，这彻底改变了结构布局优化的假设，因此可以非常紧凑地打包内存，而不必付出传统上那种严重性能代价。“最优”结构打包取决于架构，原始 C 结构规则部分是为了可移植性。
jandrewrogers查看英文原文
I do optimal structure (and bit) packing without much thought because it is an old habit. As the article states, I have noticed that the only other people that do habitual careful structure optimization these days have been doing low-level and high-performance code as long as I have. Most programmers are oblivious to it. The reasons you would do it today are different than a decade ago and the rules have changed because the processors have changed. To add two clarifying points to the original article: - The main reason to do optimal structure packing today is to reduce cache line misses. Because cache line misses are so expensive it is a big net performance gain in many cases to have the code do a little more work if it reduces cache line fills; optimal structure packing is basically a "free" way of minimizing cache misses. - On modern Intel microarchitectures, alignment matters much less for performance than it used to. One of the big changes starting with the i7 is that unaligned memory accesses have approximately the same cost as aligned memory accesses. This is a pretty radical change to the optimization assumptions for structure layout. Consequently, it is possible to do very tight memory packing without the severe performance penalty traditionally implied. What constitutes "optimal" structure packing is architecture dependent. The original C structure rules were designed in part to allow the structures to be portable above all else. If you design highly optimized structures for a Haswell processor, code may run much more slowly or create a CPU exception and crash on other architectures, so keep these tradeoffs in mind. The article is discussing basic structure packing which typically has easily predictable behavior almost anywhere C compiles.
用两个分离数组替代结构体数组，可以消除填充浪费。
一个没被提到的技巧是拆解结构体。假设一个结构体里有指针和字符，而且有巨大的该结构体数组；如果你不想付填充税，可以重构代码，改用两个数组分别存指针和字符，并在函数间传递它们。
anatoly查看英文原文
One trick that's not mentioned is unbundling the struct. Suppose you have a struct with a pointer and a character in it, and a huge array of those structs. If you resent the padding tax, refactor your code to use and pass around two arrays instead, one of pointers and the other of chars.
列式布局（struct of arrays）利于打包、SIMD、压缩和多线程。
有时“结构体数组”不如“数组的结构体”有益：它利于打包、启用 SIMD，通常也提升持久化速度。数据库领域称之为“列存储”。稍微抽象后，还可以做逐列压缩，这在普通结构体上很难。我在 Picasa（基本是内存数据库）学到：如果在 RAM 中存大量数据，有时应把数据结构更像数据库来想，采用拷贝进出而非引用；多线程情况下，这种做法会意外带来更多并行度和速度。
herf查看英文原文
In some cases you can benefit by "struct of arrays" instead of "array of structs". This benefits packing, enables SIMD, and usually improves persistence speed too. Database people call this a "column store". So if you abstract it a little you can do per-column compression that is really hard to do with vanilla structs. One thing I learned with Picasa (which is basically an in-memory database): if you're storing a lot of data in RAM, sometimes you should think of the data structures more as a database (with copy in/out, rather than reference). In multithreaded cases, this kind of approach unexpectedly gets you more parallelism and speed.
位域布局不可移植，编译器可重排且不保证大小和顺序。
这篇文章信息丰富，但有一个例外：C 标准对位域如何实现规定含糊，编译器可以随意重排它们；你不保证能获得高效打包、位置顺序或大小。
Dav3xor查看英文原文
Decent article full of good information. One exception -- the C standard is vague on how bitfields are implemented and the compiler can rearrange them in any way it pleases. You are not guaranteed efficient packing, placement order, or size.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选