记 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 当成动态链接库来用, 可以随你的程序一起发布

排队凑个热闹, 感谢 lz 的翻译工作

@oneKnow 发现 Obsidian 支持 vim ，准备弃 Typora 了...

@mepwang 让我想起了我的入门语言 Fortran ，数组在内存中列连续。出了学校再也没用过了，现在语言内置的并行计算功能越来越完善了
https://coarrays.sourceforge.io/doc.html
https://github.com/tkoenig1/coarray-tutorial/blob/main/tutorial.md

https://stackoverflow.com/questions/26389981/serialize-a-python-function-with-dependencies
可能 dill 可以做, 我先试试看好使不好使

@xgdgsc 感谢提供这个新思路.

@xsen 的确以前没怎么接触网络编程, 所以了解到 zmq 后才一拍脑门: 这东西不仅可以让软件解耦成更加容易开发和维护的独立模块, 还直接导致硬件也跟着解耦了, 比如给一批老旧的硬件系统新增加速卡(GPU/TPU)计算服务, 不用去动原有的硬件结构, 甚至可能无法动, 只需要一根网线牵出来连到新买的加速卡服务器上, 旧系统上原有的软件也不需要太多的更改, 只需要调用新开发的接口程序, 把数据发送到加速卡上计算就行了.

@ysc3839 是的, 就是一个 C ABI 的 DLL 将整个 python 虚拟机隐藏在下面, 这样上层应用不论是 C++ C#还是其它什么实现都能用了. Cython 主要在 cdef public 的函数中对 C++传过来的指针进行数据转换然后再直接调用 python 函数. 既然已经到 C ABI 层次了, 可能 pybind11 与 Cython 区别不大了, 主要是我对 Cython 熟悉一点, 其实开发中最麻烦的还是 debug 问题, 两边无法直接联动.

@xsen @xgdgsc
改用 zmq 替换嵌入 python 虚拟机具体一点的想法是这样的:
还是一个 C ABI 的 DLL, 假设有图像处理和视频(几秒的视频)处理功能用 python 来实现, start_image_service, start_video_service 分别启动对应的 python 脚本在后台等待请求, process_image(void* image, ...), process_video(void* video, ...)将数据发送过去, 等待处理结果; python 接收到对应的字节后对其解码成适合自己的数据结构, 处理后发送回去.

不过随着应用的通信变得复杂, 这种方式可能会变得不可控, 看来大家说的 gprc 才是正确选择; 对延迟要求还是挺高的, 所以进程间通信越快越好.

其实我主要是想了解下 zmq 底层实现的一些思想, 也就是上面关于 ZeroMQ 的 1,2,3 个问题.

另外，根据 f(x)在某点 c 的二阶导判断极大极小值:
f''(c)>0, concave up, minimum
f''(c)<0, concave down, maximum

我经常按照以下方式来理解记忆：
f''(c)
v v 形状 concave up, v 的尖尖儿上极小值
0

f''(c)
^ ^形状 concave down, ^的尖尖儿上极大值
0
虽然简单推导下就能得出，但以上形象记忆非常适合脑筋急转弯 XD

∪ (上凹 concave up=convex, eg. y=x^2), ∩ (下凹 concave down)

做了个简易 demo, 所有依赖都在里面, CLion 可以直接打开工程. 其它开发环境可能要用里面的 CMakeLists.txt 生成工程文件 https://drive.google.com/file/d/1OElQ6j8LwA-A2A45G2OROepqywmvh3Hn/view?usp=sharing

"hello"的类型是 const char[6], 作为数组相加吗? 如果可以的话,
const char[2] + const char[3]怎么加?
const int[4] + const int[4]怎么加?

char, short, int, long 等都是 integral, 除了数值能表示的范围, 没啥特殊

这样可以
using std::operator""s;
auto s = "hello"s + "world";