justou

记 api 没多大意义, 要记概念 1) 可视化概念: 有哪些数据呈现方式. 之后换成任何库都可以直接去找有没有实现那些呈现方式. 2) 库概念: 库从上到下实现了什么概念, 每个抽象层可以做什么, 了解提供了哪些从上到下的 api, 这个可以通过文档整理一份笔记. 实际应用时就从可视化概念对应到库实现, 因为你知道整个库有哪些抽象层次, 去查 api 文档就会很有目的性, 问 AI 也能问到点子上.

很大部分是历史原因，各种类型设备的出现，都需要 C/C++ 编写能运行在之上的程序（比如驱动），C++11 标准化的 (Fixed width integer types)[https://en.cppreference.com/w/cpp/types/integer] 就是为了方便编写可移植性代码，以前的都是完全由开发者用宏来处理数据类型的差异。

@guanhui07 我一直用 AI 来辅助学习数学, 一些书上的描述或者证明不太理解的, 就把问题整理给 AI, 让它提供解释, 包括动机, 背景, 例子, 直观理解等等. 虽然很多问题 Google 也能找到, 但是需要花时间搜索整理, AI 直接总结完了, 然后我再去整理它提供信息到自己的知识体系. 其它任何学科也一样, 就当有个 AI 专家在辅助学习, 这让我感到任何学科的基础知识学习几乎没有难度, 只是自己有没有兴趣去学罢了.

@ypw 按理说应该是可行的, 只要每个线程都能在对应的设备上分配独立的 cuda context, 彼此互不影响. 后来我的应用要同时兼容 TorchScript 和 PyTorch model, 所以只能用进程了

Clion 的 clangd 性能真的差了点，小的工程还好，一个引入了 qt, torch, boost 工程, goto 经常卡半天, 语法分析和补全几乎处于半不工作状态, 即使给它内存再多也没用.

经过一些测试和查找资料，发现单个进程内，cuda 似乎无法充分利用多显卡，可能是单个进程 cuda 能利用的数据带宽有限，得一个进程一个模型对应一个显卡。

例如有 4 个显卡，主进程启动 4 个子进程，每个子进程一个推理模型，主进程源源不断地将数据一个一个 batch 的送到进程共享队列，每个推理子进程一边从队列获取数据缓存一边推理一边将结果发送回主线程汇总，这些都异步进行，主要目的是让各个显卡尽量不要空闲，以此将利用率最大化。

最开始尝试将大量输入数据均摊到各个子进程，然后等他们完成，再获取结果，发现这种方式显卡利用率不高，主要是有些进程很快完成推理，有些进程则很慢，这种方式永远是在等最慢的那个进程，而其它进程早就空闲下来了。这种方式得到的 fps 跟单个进程多个线程的差不多，而通过上面这种流水线处理方式，fps 按显卡个数倍增。

必须是那样, 利用 RAII 方式来保证一些动作得到执行
void func(){
auto socks_guard = wear_socks_guard(); // 构造时穿上袜子, 析构时脱掉袜子
auto shoes_guard = wear_shoes_guard(); // 构造时穿上鞋, 析构时脱掉鞋

// ....

// 先脱鞋
// 再脱袜子
}

windows 下有个 embed 版本的 python, 比如 https://www.python.org/ftp/python/3.10.11/python-3.10.11-embed-amd64.zip 可以把它看成一个绿色版 python(可以用 pip 在这个环境中安装管理第三方库), 相当于把 python 当成动态链接库来用, 可以随你的程序一起发布