必须先调用 likwid_init() 初始化，否则所有 API 调用失败或崩溃；它启动运行时状态机、探测计数器、绑定线程、加载内核模块；需 root 权限并检查返回值。
LIKWID 在 C++ 中怎么初始化和读取 CPU 硬件事件
必须先调用 likwid_init()，否则所有后续 API 都会返回错误或崩溃。这个函数不是可选的“准备步骤”，而是 LIKWID 运行时状态机的启动开关——它会探测可用的硬件计数器、绑定当前线程到指定 CPU 核、加载内核模块（如需要）。
常见错误现象：likwid_markerInit() 返回 -1，likwid_getEventSetId() 返回 -1，或者读数始终为 0。八成是漏了初始化，或者初始化失败后没检查返回值。
- 初始化前确保你有 root 权限（Linux 下加载
msr和perf_event_paranoid设置需权限） - 初始化后务必检查返回值：
if (likwid_init() - 每个线程独立初始化；多线程下不要只在主线程 init 一次就完事
- 不支持跨 fork() 子进程复用——子进程需重新 init
如何用 likwid_markerStart/Stop 测一段代码的硬件事件
这是最常用也最容易出错的路径：你以为在测某段循环，结果实际测的是 marker 区域外的指令，或者被编译器优化掉了关键代码。
使用场景：想快速知道某段计算密集型逻辑的 L3 缓存未命中数、分支误预测率、IPC 等——不用改构建流程，只需加两行标记。
立即学习“C++免费学习笔记（深入）”；
- 必须用
likwid_markerStart("region_name")和likwid_markerStop("region_name")成对出现，名字要完全一致 - 标记区域内的代码不能被编译器优化掉；建议加
volatile或用asm volatile("" ::: "memory")防止重排 - marker 不自动绑定到当前 CPU；若线程迁移过，需手动调用
likwid_pinThread(getpid(), cpu_id) - 默认只收集预设事件集（如
INSTR_RETIRED:ANY,CYCLES:REF），如需自定义事件，得先调用likwid_addEventSet()并传入 event string
likwid_getEventSetId 返回 -1 怎么排查
这不是配置写错了那么简单——它意味着 LIKWID 没法把你的字符串解析成有效的硬件事件，或者目标 CPU 不支持该事件。
参数差异：x86 上事件名大小写敏感，且依赖微架构。比如 MEM_LOAD_RETIRED:L3_MISS 在 Skylake 可用，在 Zen2 上可能不存在，替换成 L3_MISS 或 DC_ACCESS 才行。
- 先运行命令行工具确认事件是否存在：
likwid-perfctr -a -g <code>list查看当前 CPU 支持的组 - 再查具体事件：
likwid-perfctr -a -g <code>FLOPS_DP-q 看它展开的实际事件字符串 - 别直接抄文档里的通用名；不同 LIKWID 版本对事件别名的支持程度不同（如
INSTR_RETIREDvsINST_RETIRED_ANY） - 如果用了
likwid_addEventSet()后仍返回 -1，说明字符串里有非法字符或空格位置不对——事件名之间用英文冒号分隔，无空格
为什么 likwid_getCounter() 总是返回 0
最常忽略的一点：marker 区域必须执行至少一次，且 likwid_markerStop() 调用后才能读数。很多人在 Stop 前就急着调 likwid_getCounter()，或者 Stop 后没调 likwid_getEventSetId() 就直接读。
性能影响：LIKWID 的 marker 模式本质是基于 perf_event_open 的采样，开销比纯 rdpmc 小，但频繁 Start/Stop（比如每轮循环都调）会显著拖慢程序——建议把 marker 包在外部大循环里，而非内部热循环中。
- 读数前必须保证：init → pin → start → 执行目标代码 → stop → getEventSetId → getCounter
-
likwid_getCounter()第二个参数是eventId，不是事件名字符串，也不是数组下标；它来自likwid_getEventSetId()的返回值 - 返回值是 long long 类型，但某些事件（如周期计数）可能溢出；LIKWID 不自动做差分，你需要自己缓存上一次值来算增量
- 如果程序跑完没看到输出，检查是否忘了调
likwid_finalize()—— 它会触发最终数据汇总和打印（命令行模式下）
硬件事件不是“开了就能读”的黑盒；LIKWID 把底层复杂性暴露给了用户，而最容易被忽略的，恰恰是那些不报错却默默失效的环节：线程绑核失败、事件名拼写偏差、marker 区域被优化、读数时机错位——这些地方一出问题，数据就全不可信。
