@lujjjh 哈希只能是概率性不冲突啊，虽然概率小，但是不能保证程序**一定**正确不是么？

楼主没有讲可以概率性正确，你这就加上这个条件，这不好。

@ZhangZisu 但其实哈希表用平方探测不是只要两倍内存就基本能保证性能么。。而且两倍的是哈希表节点而不是字符串。用上 StringPool + string_view 咱觉得基本就是最好的方案了。

@Phishion 咱多少觉得，楼主有种 XY Problem 的感觉。到底什么场景下 400MB 的表都会 concern ？是不是和多进程有关？ Linux fork 的话，因为内存使用是 COW 的，所以可以主进程创建完整个表，然后子进程就不用创建第二份了。

那如果是设备内存太小，或者本身楼主要处理的不是 400MB 而是 40GB 这种场景，那可能就需要使用 disk-backend 的数据结构了。比如 B-Tree 。

@ZhangZisu 我觉得楼主这个需求，trie 树不太好用。因为楼主的字符串是真随机，trie 树每层都会分出一堆节点，基本是个满 K 叉树，比一个大哈希表用更多内存

@Phishion https://developers.digitalocean.com/libraries/

楼主估计说的是这里，Official API 只有 Go 和 Ruby，其他的是社区提供的。

但是，这难道不能说明其他语言社区比同时期 Go/Ruby 好很多，所以官方都不用动手就有 Binding 了吗 。。。。

也许版本不对标错了的话，你可以再看看

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

唯一不带的好像是 TensorFlow，你自己随便装一个

@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 原语就行。