Valgrind / Callgrind on Dorkytiger 的小屋

Callgrind —— 指令级精确分析

Mon, 01 Jan 0001 00:00:00 +0000

一、和 perf 的区别

perf（采样）：
    每隔 N 微秒采样一次 CPU 的 PC 寄存器
    快（几乎不影响程序运行速度）
    统计结果有误差（采样丢失）

Callgrind（模拟）：
    用 Valgrind 的虚拟 CPU 模拟执行每条指令
    慢（慢 20-30 倍）
    结果精确（统计了每一条指令、每次缓存访问）

二、基本用法

# 运行 Callgrind
valgrind --tool=callgrind ./my_program

# 输出文件：callgrind.out.12345 (pid=12345)

# 查看函数排行
callgrind_annotate callgrind.out.12345

# 输出示例：
# --------------------------------------------------------------------------
# Ir (指令数)   Dr (读)    Dw (写)    L1m (L1 Miss)  L2m (L2 Miss)  function
# --------------------------------------------------------------------------
# 12,345,678    4,321,000  2,100,000  123,456        12,345         motion_search
#  8,234,567    3,100,000  1,500,000   89,012         8,901         dct_transform
#  2,345,678      900,000    400,000  234,567        23,456         memcpy
#    567,890      200,000    100,000    1,234           123         frame_copy

# 重要指标：
# Ir（Instructions）—— 总指令数，越多的函数越值得优化
# L1m / L2m —— 缓存不命中率，越高说明内存访问模式越差

# 可以清晰看到：
# motion_search 指令数最多（12M），且 L1 Miss 也高（123K）
# → 优先优化这个函数，且优化方向是改善内存访问模式

三、可视化分析

# 用 KCachegrind（GUI 工具）打开
kcachegrind callgrind.out.12345

# 可以在图形界面中看到：
# - 函数调用关系的图（谁调了谁，花费了多少指令）
# - 每个函数的指令数/缓存 Miss 数/分支预测失败数
# - 源码级别的指令开销
# - 热路径（哪个调用链最耗时）

用 Callgrind 分析你的 SPSC 队列

Mon, 01 Jan 0001 00:00:00 +0000

// 对比 SPSC Ring Buffer 和 Mutex 队列的指令级开销

#include <atomic>
#include <mutex>
#include <queue>

// SPSC 队列（你的 SimpleAsyncLogger 风格）
template<typename T>
class SPSCQueue {
    std::atomic<size_t> head_{0};
    std::atomic<size_t> tail_{0};
    T buffer_[256];

public:
    bool push(T val) {
        size_t h = head_.load(std::memory_order_relaxed);
        size_t t = tail_.load(std::memory_order_acquire);
        size_t next = (h + 1) & 255;
        if (next == t) return false;  // full
        buffer_[h] = val;
        head_.store(next, std::memory_order_release);
        return true;
    }

    bool pop(T& val) {
        size_t t = tail_.load(std::memory_order_relaxed);
        size_t h = head_.load(std::memory_order_acquire);
        if (t == h) return false;  // empty
        val = buffer_[t];
        tail_.store((t + 1) & 255, std::memory_order_release);
        return true;
    }
};

// Mutex 队列
template<typename T>
class MutexQueue {
    std::queue<T> q_;
    std::mutex mtx_;

public:
    void push(T val) {
        std::lock_guard<std::mutex> lock(mtx_);
        q_.push(val);
    }

    bool pop(T& val) {
        std::lock_guard<std::mutex> lock(mtx_);
        if (q_.empty()) return false;
        val = q_.front();
        q_.pop();
        return true;
    }
};

# 用 Callgrind 对比：
valgrind --tool=callgrind ./bench_spsc
valgrind --tool=callgrind ./bench_mutex

# callgrind_annotate 对比结果：

# SPSC Queue 的 Callgrind 输出：
# Ir: 2,100,000（每次 push 只执行大约 21 条指令）
# L1m: 1,200（缓存命中率极高，因为 head/tail 在独立缓存行）

# Mutex Queue 的 Callgrind 输出：
# Ir: 23,500,000（每次 push 约 235 条指令，多了 lock/unlock 的系统调用）
# L1m: 89,000（mutex 对象需要跨核心同步）

# SPSC 的指令数只有 Mutex 版本的 1/10。
# 面试时可以展示这个数字——"我用 Callgrind 精确验证了 SPSC 比 Mutex 快 10 倍"

Massif —— 堆内存分析

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候用

程序的 RSS（驻留内存）超出预期，想知道谁分配了这么多内存。

# 运行 Massif
valgrind --tool=massif ./my_program

# 输出文件：massif.out.12345

# 用 ms_print 生成报告
ms_print massif.out.12345

# 输出：
# ---------------------------------------------------------------------------
# Command:    ./my_program
# Massif output
# ---------------------------------------------------------------------------
#     MB
#  3.25 ┤                  ╭╮
#  2.99 ┤                  ││ ╭──╮
#  2.74 ┤                  ││ │  │
#  2.48 ┤      ╭──╮       │╰─╯  ╰──╮
#  2.23 ┤      │  │       │        │
#  1.97 ┤      │  ├───────╯        │
#  1.72 ┤  ╭───╯  │                │
#  1.46 ┤  │      │                │
#  1.21 ┤  │      │                │
#  0.95 ┤──╯      │                │
#      ─┴─────────┴────────────────
#       0      7.9       15.8      time(s)
#
# 可以看到在第 8 秒左右有一次大幅的内存分配。
# 看下面的详细信息找谁分配了这些内存：

# --------------------------------------------------------------------------
#   n    time(B)    total(B)   useful-heap(B)  extra-heap(B)  stacks(B)
# --------------------------------------------------------------------------
#  20     7,891,234   3,123,456   3,100,000       23,456       12,345
#  99.2% (3,100,000) 的堆内存分配在 process_frame 中
#  其中 80% 是在 process_frame → allocate_frame_buffer
#  说明大部分内存被帧缓冲占用了

Helgrind / DRD —— 数据竞争检测

Mon, 01 Jan 0001 00:00:00 +0000

一、Valgrind 的 TSan 替代方案

之前讲过 ThreadSanitizer 能检测数据竞争，但需要重编译。如果你有一个已经编译好的二进制（或者第三方库没源码），可以用 Helgrind 或 DRD 做运行时数据竞争检测。

# Helgrind（更详细，但更慢）
valgrind --tool=helgrind ./my_multithread_program

# DRD（更快一点，但可能漏报）
valgrind --tool=drd ./my_multithread_program

二、输出示例

#include <thread>
#include <iostream>

int counter = 0;  // 没有锁保护

void worker() {
    for (int i = 0; i < 100000; i++) {
        counter++;  // 数据竞争！
    }
}

int main() {
    std::thread t1(worker);
    std::thread t2(worker);
    t1.join();
    t2.join();
    std::cout << counter << std::endl;
    return 0;
}

valgrind --tool=drd ./race

# 输出：
# DRD: data race on address 0x601050 in object 'counter'
#   Conflicting store by thread 1 at 0x400B34: worker() race.cpp:6
#   Conflicting load by thread 2 at 0x400B38: worker() race.cpp:6
#   Allocation context: BSS section of /tmp/race

三、Helgrind vs DRD vs TSan

工具	是否需要重编译	运行速度	精确度
TSan（-fsanitize=thread）	需要	慢 5-10x	高
DRD（valgrind）	不需要	慢 20-30x	中
Helgrind（valgrind）	不需要	慢 20-30x	高

实际选择：
  如果你有源码：用 -fsanitize=thread（最快最准）
  如果你只有二进制：用 DRD 或 Helgrind
  Helgrind 的报错比 DRD 详细，但慢一点

第八阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

Callgrind（指令级分析）：
    慢 20-30x，但精确到每条指令
    告诉你"哪个函数指令数最多、Cache Miss 最高"
    可视化工具：KCachegrind

Massif（堆内存分析）：
    找到"哪个函数分配了最多内存"
    需要优化内存使用时使用

Helgrind / DRD（数据竞争检测）：
    不需要重编译的 TSan 替代方案
    适合分析第三方库或已编译好的二进制

perf vs Callgrind 怎么选？
  粗略定位热点 → perf record（快，但可能漏掉低频执行的热路径）
  精确优化 → Callgrind（慢，但告诉你完整信息）
  验证优化效果 → perf stat（只需要对比 IPC 和 Cache Miss 就行了）