如果不是一定要用虚拟机的话， lxc 和 nvidia-docker 都可以。我们公司的开发机是把 nvidia-docker 当虚拟机用，我们实验室是用 lxc 。但问题也是很明显，宿主机的显卡驱动如果崩了的话，全部都崩了。我们在公司里面就经常遇到这种情况，就跟传染病一样，一堆进程都变成 D 了，只能重启。

显卡的虚拟化现在还是未知数，无论是软件还是硬件都还没做好准备。要么如楼上所说用 PCI Passthrough ，要么就像我们一样只做隔离。

我差点都忘了昨天晚上在 V2EX 上发了这么个帖子了……

刚刚关于这个问题写了篇长文，各位有兴趣的话可以去看看：
我的博客： https://abcdabcd987.com/qrcode-login/
或者知乎： https://www.zhihu.com/question/46822051/answer/126854559

楼主是安徽大学的？

127.0.0.1

前天入了块二手 GTX 660 Ti
跑同样的小计算达到 TITAN X 一半的速度
感觉好开心

@billlee 我觉得还是有意义的，新开一个 worker ，把计算任务丢进去，发挥多核优势？

@caizixian 原来是这样。不过这也不一定是 ToLower 的问题，也有可能是在原串上做匹配触发了某些条件使得字符串匹配变快了。

刚刚看了下 Strings.ToLower 的代码，发现可能确实 ToLower 会存在性能问题。他是直接用了个 map ，然后 mapper function 还要往下递归两三层。在这种情况下，编译器优化再厉害也是不如手写个 for 来得快的。

https://hg.python.org/cpython/file/2.7/Objects/stringlib/fastsearch.h

Python 用了一个跑的比较快的匹配算法，所以表现起来比 golang 好一些

https://golang.org/src/strings/strings_amd64.go?s=521:550#L3

这里可以看到 go 实现的是 Rabin-Karp algorithm 。假设文本长度为 n ，单个关键字长度为 m ，那么 Rabin-Karp 的方法最坏复杂度是 O(nm)，不过一般情况下是 O(n+m)。假设你这里有 w 个关键字，那么总的复杂度是 O(w*(n+m))。

如果关键字多并且文本比较长的话，改用 AC 自动机，复杂度就降到了 O(n + w*m)

“需要进行大小写不区别的子串检测”

瓶颈不在与 ToLower ，而在于子串识别的算法。子串识别有两个很基本的算法：

Multiple text with single pattern: KMP Algorithm
Multiple text with multiple pattern: Aho-Corasick algorithm （ AC 自动机）

我的有时候会听到电流声……

虚拟机跑一个无 GUI 的 Linux （比如 Ubuntu Server)
然后 ssh 进去用

题外话：能不能下载是一回事，下载之后传播的风险大不大是另外一回事。如果像电影那样加上了厉害的数字水印的话，你就算是拿着录像机去录，他一样能把水印的信息读出来，然后封号就很容易了。

Core Java, Volume I--Fundamentals (10th Edition)
Core Java, Volume II--Advanced Features (9th Edition) 第 10 版还没出来

所以有哪些更技术向的地方呢？

上海移动收到

@lcj2class 你这个例子里面没有提现到变量提升的问题吧？另外我觉得变量提升应该只是 JavaScript 的处理方法而已

这个事情和闭包其实没关系。

在 C 和 C++ 里面要实现这样的功能，必须先在前面把两个函数都给声明了，否则 is_even 会找不到 is_odd 。他们之所以这么做，是因为早期存储能力十分有限，所以编译器尽量做到一趟编译。既然是一趟编译，你就不可能知道在 is_even 之后还有 is_odd 。所以说 C 和 C++ 要实现这样的功能必须得写前向的声明。

后来计算机的存储能力和计算能力都大大加强了，把整个程序存到内存中是轻轻松松的事情，把源程序以不同的形式遍历好几遍也没有任何压力了，所以多趟编译器就流行了。在多趟编译器里面，完全可以第一遍把所有函数的名字和类型扫到符号表里面，于是在第二遍再扫到 is_even 的时候就知道了其实 is_odd 在这个程序里面是有的。 C/C++ 因为历史包袱所以还是保留了前向声明，但是新的语言比如 python ，就不再需要这样麻烦的语法了。