@zxCoder 还有 graph_tool，滑稽~

你可以看看我这个版本适合不：

https://hub.docker.com/layers/129864161/haowenxu/ml-runtime2/gpu-cuda10.1-cudnn7-py3.6-torch1.7.1/

Python 3.6 CUDA 10.1 CUDNN 7 PyTorch 1.7.1 带 graph-tool

@zxCoder 虚拟机也基本不行，你只能 Ubuntu 。

微信可以考虑 https://deepin-wine.i-m.dev/

@3dwelcome 钱不重要，ummm 那是你自己没有遇到真的想要却因为缺少条件而要不了的东西。在我看来，物质欲望和精神欲望，两手都要抓两手都要硬。

而且说起精神欲望，我就打个比方，我喜欢我博士读的学科，但我不喜欢科研（圈子）。我不喜欢做一些 incremental 的工作，为了发论文而调整研究方向，哪怕这一生做不出什么有用的突破，那是我的兴趣。但是这样是混不了学术界的，没人给你经费，没有学生会冒着无法毕业的风险跟你做。

如果我自己有钱，自己给自己发科研经费，就没这些问题了不是么。

1. 世界上大部分人都是庸人，而且大部分人这样过反而是最容易的过法。
2. 你不想做庸人，也就是说，你想做 1% 不到的那种人。
3. 世界上但凡要做 1% 不到的那种人，都不容易。
4. 只有足够强才有任性的资本。
----

所以问题只有一个原因，你不够强。你现在如果有一千万现金加北京一套无贷款的学区房，我想你就不会想着只能老实带孩子上班看周围人脸色的问题了。

《叶公好龙》

1. Windows 别想了。本体用 TensorFlow / PyTorch 可能会有各种奇怪的问题，因为你这真的是小众平台很少有搞学术这么做的，碰到问题不好解决。而 WSL/WSL2/虚拟机都是不可能用 CUDA 的，无解。
2. Linux 下用 Docker 启动 CUDA + TensorFlow 是可能的。我在实验室这么干了好几年了，不然我们实验室那么多人用服务器，每个人环境都不同，我得管死。

cow 正解。

> 更进一步，可以分别给出以上 9 项指标的得分，使我可以知道该商品为什么被分类为差。
说不定行，需要 representation learning，但这肯定是研究话题了。

@neoblackcap 所以 “搞成 Java 那样是挺好的，JIT 性能提上去，C 扩展完全可以不用” 那就不是 Python 了。Python 最大的价值就在于搞成现在这样，可以无缝衔接各种 C/C++。高兴了我就把算法用 C++ 写一下，pybind11 直接嵌入 FastAPI 多好。。。

@sagaxu All right，你说的大概是一堆用户要请求服务器的场景吧。Okay Okay，可以算 CPU 密集型。

我脑子里面 CPU 密集型的第一反应是跑一个 PageRank，跑一个 CNN 之类的……那点 IO 开销和模型本身比简直可以忽略不计，多进程是最好的选项。因而，Python GIL 在这种任务面前根本不是事情。

所以到底为啥人闲的蛋疼要用 Python 做 CPU 密集型的 Web 服务器啊，这不是找虐么。多学一门语言和生态不就好了。。。

@neoblackcap 不过份。参考上面这段，我认为 Python 在 CPU 密集型的 Web 服务器领域就毫无价值，而在科学计算 / 机器学习 / 数据处理方面才有价值。因此外部代码才是 Python 的重点，用 FastAPI 直接快速上线 PyTorch 模型或者包装一下手写的 C++ 模型，不香吗？在 C++ 里面写个 RestAPI 那是找虐啊！

所以同样的，优化掉 GIL 去适应 Web Application，为啥要找这方面虐呢？老老实实学习 Java / Go 不好吗？

我承认我太菜，写不来 bash，所以我用 python

@sagaxu 呃，我和你理解的 CPU 密集型是不是有点不一样。。。CPU 密集型，我理解就该多少核开多少线程，工作全部入队列，一个结果计算好就发出去。。。这种专门后台大量计算的场景吗？ GIL 在 CPU 密集型，直接开多进程不就可以了。。。。

好吧我理解你的意思了，这种情况下你还想用多线程那 python 就没辙了。但是话说回来，这种场景多进程超好写啊。反而是 IO 密集型，当你的 IO 再上一个台阶，要用到多核多线程 + 每个线程 event loop，那搁多进程反而就有开销了。。。


@LeeReamond 对，我个人觉得，这是 GIL 非常重要的一点，对 C/C++ 扩展至关重要。其他什么引用计数、Python 内部解释器的各种乱七八糟问题，我觉着只要钱到位肯定都能给你搞出来。只有这一点，真的是牵扯到扔掉半壁江山的事情了。。。为了兼容性可能 python 会很有顾虑。你看 pypy 不是很多 C 扩展就不能用吗。


@neoblackcap ummm 我说的 vm 是相对于 c/c++ 原生代码的。你看 python byte code 不也是一种 vm 吗，有了这个 vm，python 才能做 tracing gc 啊。对 c/c++ native code，python 是真的 tracing 不起来啊。

而且最基础的引用计数可以不枷锁实现，比如 c++ std::shared_ptr，用 atomic 原语就行。

@junkun 引用计数我看不是大问题，但是 PyList_Append 这种操作可不是原子操作。随便一个线程切换就会让搞到一半的 Append 停下来，另一个线程操作同样的 List，然后就炸了。

@sagaxu 这无所谓的啦，这种用词我不太在意的。这楼一直在说加锁的事情，那并发（单线程）不用加，但是 1C1T 并行（多线程）就得加。而且你得和他解释为啥 1C1T 这也算并行，有些人还觉得 1T1C 同一时间只有一个线程在跑，不算并行嘞。

所以我都不在意这些用词了。就怕半桶水只知道这种用词，而不知道背后到底具体是什么场景。

@sagaxu 现代操作系统是时间片复用的并行操作系统。也就是说你一个线程比如 PyList_Append 做了一半，操作系统可能就会把这个线程停下来，换另一个线程去执行。因此 1C1T 也有并行，也要加锁。P.S. 这种停下来靠 CPU 硬件中断信号。

@Jirajine yysy qs，解决 GIL 只能靠砍掉 C 模块，拥抱 JIT/VM 。但那就不是 Cython 应该做的事情了。

@neoblackcap @LeeReamond

比如：

https://zhuanlan.zhihu.com/p/192974017

pybind11，C++ 与 python 互相调用的一个库。

你 C++ 可以有自己的 pthread 线程，甚至用上 uvloop 来做事件驱动，然后控制权可能又进入 python，然后又重新回到 c++。在 C++ 里面如果有多个 pthread native 线程，根本不归 python 管，同时去访问 PyList_Append，这就是 Python 无与伦比的自由度，也是它作为胶水语言的优势，但是也造成了 GIL 尾大不掉。

@LeeReamond 或者你可以实现自己的一套引用计数（仿照 C++ std::shared_ptr，直接在你的 struct XXXObject 内部嵌入一个 Py_Object*，在你自己的引用计数清零的时候去调用 python api 清理掉这个 python 对象）。

换句话说，Python 变成了 API，C++ 才是本体。。。从 C/C++ 代码角度看就是这样。