不知道这么多说python不慢，或者不在乎慢不慢的，是不是都搞数据挖掘或者机器学习
的。。。我是写业务的，每天的工作除了正经的工程设计，就是帮助那些写算法的研究
他们的python服务为什么慢，能优化的给优化，不能优化的接手过来用c或go重写。。。



【 在 life2018 的大作中提到: 】
: zz
--
FROM 114.251.196.*

用numpy啊，numpy也被我当作python技术体系的一部分了，没特别提。。。

算法倒也不是特指各种矩阵运算，如果单纯只剩下numpy了，倒确实也不慢了哈哈

举两个例子

对于一个id X，RPC得到很多结果，对这些结果做各种过滤、排序、筛选、聚合（其中不
涉及numpy），得到一些新的结果，将新的结果保存到存储。

这个QPS上去后，服务极占CPU和内存，最后改成golang了

通过一部分流程，拿到一堆图片，对每张图片过cv2和numpy，执行一些筛选。这个计算
筛选太耗时了（不是慢，是耗时，这不怨python，计算量太大了）。研究了好久，受限
于GIL，加上我自己也不会cv2和numpy怎么上多核，最后改成了c opencv加blas，用pth
read开多核算，快多了


【 在 hgoldfish 的大作中提到: 】
: 算法研究员居然用 python 来写算法？
: 他们直接 for 循环用不 numpy 吗？
--
FROM 114.251.196.*

你是说，比如

def calc(image):

  # cv2 and np here

  return data

st1 = time.time()

thrs = [threading.Thread(target=calc, args=(x,) for x in images]

[w.start() for w in thrs]

st2 = time.time()

这样子，会放GIL么？这和我们线上观察到现象不一致啊，线上观察，还是单核、近似串
行跑的；观察最终st2-st1效果，还不如不开线程暴力for串行的快。。。


【 在 lvsoft 的大作中提到: 】
: cv2和numpy底层会release gil，不需要特别的去研究怎么多核。你直接开thread就行。
: 至于前面那个过滤聚合的。如果是用python的itertools里面的groupby，filter等等实现的，那qps上去妥妥的热点代码啊。在高负载场景下，python就不能用来做任何数据处理，只能用来做代码粘合。
: 你这个场景是非常典型的可以用cython/numba进行热点优化的例子。
: ...................
--
FROM 114.251.196.*

这倒是。。。而且实际上，我如果要开发新服务，没有特殊需要时也依然会首选python
搞~。。


【 在 roy 的大作中提到: 】
:         你这帖不正好说明了python的优点吗
:         非计算机背景的领域专家也能比较容易的写出能干活的程序
--
FROM 114.251.196.*

做个简单测试：
In [16]: def calc():
    ...:     frame = np.random.randint(0, 256, (2160, 3840, 3)).astype(np.uint8)
    ...:     kernel = np.ones((31,31), np.uint8)
    ...:     cv2.erode(frame, kernel, iterations=10)
    ...:

In [17]: %timeit calc()
195 ms ± 1.69 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

然后16线程执行下：
In [18]: def multi_thread():
   ...:     thres = [threading.Thread(target=calc) for _ in range(16)]
   ...:     [x.start() for x in thres]
   ...:     [x.join() for x in thres]
   ...:

In [19]: %timeit multi_thread()
1.37 s ± 18.3 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

同时跑的时候看了下cpu占用率是240%左右。
有点奇怪。加速了，但这个加速比不太对。

再测试下多进程的情况：
In [21]: def multi_proc():
    ...:     thres = [multiprocessing.Process(target=calc) for _ in range(16)]
    ...:     [x.start() for x in thres]
    ...:     [x.join() for x in thres]
    ...:

In [22]: %timeit multi_proc()
614 ms ± 20.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

好多了但还是有3倍差距，我这是16核cpu，感觉差距不应该有这么大...

anyway，opencv release gil的行为看来没有我想的那么乐观。

【 在 CKevin 的大作中提到: 】
: 你是说，比如
: def calc(image):
:   # cv2 and np here
: ...................
[upload=1][/upload]
--
修改:lvsoft FROM 180.158.52.*
FROM 180.158.52.*