这是一个非常轻松的实验。你不需要手动写很多代码，也不需要深入阅读复杂的源码。整个实验的核心是：让 AI 帮你完成大部分工作，你来引导它、理解它的输出，并最终形成一份有内容的报告。
本实验的主题是 glibc 的内存分配器（malloc）。从 1990 年代到今天，这个分配器经历了多次重大优化。你的任务是复现这段历史，并用真实的实测数据来说明每次优化带来了多少性能提升。
完成本实验预计需要 2~3 小时。
完成实验后，你应当能够：
- 了解 glibc malloc 在不同版本间的主要架构演进（Arena、tcache、THP 等）
- 阅读真实的开源项目提交历史，理解性能优化是如何一步步演化的
- 用基准测试量化性能差异，并判断实测数据是否符合理论预期
- 产出一份结合代码分析与实测数据的技术报告
一份 Markdown 格式的报告文件，内容包括：
- 背景介绍：glibc malloc 有哪些重要的版本演化节点，每个节点做了什么优化
- 评测数据：至少覆盖 3 个不同 glibc 版本，给出测量结果
- 结果分析：数据说明了什么，与理论上的优化预期是否吻合
报告不限长度，但需要言之有物。
把以下仓库 clone 到本地：
https://github.com/Weihong-ye/glibc-upstream
这是一份完整的 glibc 上游仓库镜像，包含了从 1990 年代至今的所有提交历史。
把你 clone 下来的仓库提供给 AI（例如将仓库路径告诉支持文件系统访问的 AI Agent），请它：
- 阅读
malloc/目录下的提交历史 - 找出哪些版本引入了哪些针对性能的优化
- 按版本号整理成一份时间线
提示： 你可以告诉 AI："请阅读这个 glibc 仓库的提交历史，重点关注 malloc/ 目录，梳理出各个版本在内存分配器性能方面做了哪些优化，以版本号为骨架整理成文档。"
这一步的产出是一份版本演化文档，它将作为第三步设计实验的依据。
根据第二步梳理出的优化历史，让 AI 帮你：
- 制定评测计划：针对你找到的关键优化节点，设计能够体现性能差异的测试场景
- 实现测试：让 AI 写测试脚本或 C 程序，利用不同版本的容器镜像（不同 Ubuntu 版本内置不同 glibc）在同一台机器上对比运行
- 执行测试：运行脚本，收集数据
提示： 你可以告诉 AI："根据上面整理出的 glibc 内存分配器优化历史，帮我设计一个 Benchmark 方案来验证这些性能提升，并写出完整的测试脚本。"
拿到测试数据后：
- 如果数据符合预期（即性能确实随版本提升），让 AI 根据数据和优化历史撰写完整报告
- 如果数据不符合预期（某个版本没有体现出提升，甚至出现下降），不要跳过，这往往更有价值——让 AI 帮你分析原因，然后决定：
- 调整第三步的测试思路，换一个更能体现该优化的场景
- 或者在报告中直接分析并解释这个现象
提示： 如果数据不符合预期，可以问 AI："我测出来 glibc X.XX 并没有比 X.XX 快，按理说这个版本引入了 tcache，为什么看不出来？请帮我分析原因并建议如何调整测试方案。"
最终的报告应当由你审查并确认，确保逻辑自洽、结论有数据支撑。
- 不要吊死在一棵树上。 AI 总是做不出来不是你的问题，是那个 AI 的问题——换一个 AI 试试。
- 一个对话里一直解决不了问题，就回滚修改或开一个新对话。 上下文越长，AI 越容易在错误的方向上越走越远。
- 需要执行时间较长的任务，可以让 AI 把命令给你，自己跑。 这样不容易焦虑，也方便中途中断和恢复。
- 多和同学交流。 AI 变化很快，助教个人也经常跟不上时代，要多向会用 AI 的同学请教和学习。
| 项目 | 分值 |
|---|---|
| 报告中包含不少于 3 个 glibc 版本的评测数据 | 40 分 |
| 对至少 2 个优化点有结合代码或原理的解释 | 30 分 |
| 数据分析逻辑自洽（结论与数据一致，或对异常有合理解释） | 20 分 |
| 报告结构清晰、可读性强 | 10 分 |
（这个表格是 AI 写的，我们会结合学生们的实际情况给分，不要拘泥于这个表格）