- 主题:python是不是落伍了，跑东西挺慢
性能问题当然是有的，但python还有另一个好处，就是可以很容易的把热点代码替换成高性能实现。
当然，综合来说比不过全部是c/c++/rust实现，
但很多时候也没这个必要，毕竟不是谁写的东西都是linux kernel级的东西的
【 在 pixYY 的大作中提到: 】
: Python的优势是代码的快速简易开发
: 对于目前的硬件，大多数需求场景下性能不是问题
: 要想跑的快，去玩玩要取代 C++ 的 Rust 吧
: ...................
--
FROM 180.158.52.*
你是在windows下吧？
linux下不会这样的。
【 在 hongyan2022 的大作中提到: 】
: 刚刚 我的JUPYTER NOTEBOOK 出问题了 工作了几天后 变的非常慢... 我还重启了
: 后来 找出原因了 因为我存近万个小文件 我把每个独立任务的细节都存下来了单独存下来 以便日后查证分析...
: 好象也就7千多文件
: ...................
--
FROM 180.158.52.*
cython，numba都很容易。
【 在 xeagle 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 请教一下, 这具体是怎么做的?
--
FROM 180.158.52.*
苹果我不熟，但按理说应该不至于这样
【 在 hongyan2022 的大作中提到: 】
: 正是我吃惊的地方 在苹果机上 三年新的公司机器 英的U
: python 3.10.6
:
--
FROM 180.158.52.*
cv2和numpy底层会release gil，不需要特别的去研究怎么多核。你直接开thread就行。
至于前面那个过滤聚合的。如果是用python的itertools里面的groupby，filter等等实现的，那qps上去妥妥的热点代码啊。在高负载场景下，python就不能用来做任何数据处理，只能用来做代码粘合。
你这个场景是非常典型的可以用cython/numba进行热点优化的例子。
【 在 CKevin 的大作中提到: 】
: 用numpy啊，numpy也被我当作python技术体系的一部分了，没特别提。。。
: 算法倒也不是特指各种矩阵运算，如果单纯只剩下numpy了，倒确实也不慢了哈哈
: 举两个例子
: ...................
--
修改:lvsoft FROM 180.158.52.*
FROM 180.158.52.*
做个简单测试：
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.*
这个有啥好玩的？这个就是个redist工具。
我在考虑玩下openai的triton，热点代码直接jit到gpu里面去，而且还没有cuda依赖。
这玩意才是未来。
【 在 hgoldfish 的大作中提到: 】
: 奢侈博最近有玩 nuitka 吗？作者全职搞这个了。
:
--
FROM 180.158.50.*
你是说怎么找到热点代码还是说替换掉热点代码？
怎么找热点代码这个太容易了吧，多的是profile工具，从内存到cpu时间到执行次数都可以给你分析的很好了。
替换掉热点代码是个语言的实现问题，而python现实上演化成了胶水语言，那当然是有优势的，干的就是这种活。
【 在 xeagle 的大作中提到: 】
: 其实我想问的是，找到python中的热点代码，和其他语言比是否有优势
: 发自「今日水木 on iOS」
--
FROM 180.158.50.*
py不是专门为数学计算设计的语言，如果你单论矩阵计算代码的简洁程度，那自然是不如的。
不过差距很小，我不认为有值得一提的区别。
【 在 Findest 的大作中提到: 】
: ，代码的简洁度，速度没比过
--
FROM 180.158.50.*
这根本就不是单纯的找出热点的问题啊。
任何孤立的点拿出来都无所谓有没有优势的说法啊。
所有语言还都是等价的，本质都没啥区别呢。
我要说的就是找到热点并完成局部优化这种开发模式是py的优势领域，其他语言可以模仿，但收益小很多。
比如，假设用python和java实现的同一个应用的开发，
py的场景：1人日完成开发，1人日找出热点，1人日完成热点的替换。
java的场景：7人日完成开发，不需要找热点，或者说找出了热点也不方便替换（JNI反而会损失性能）。
如果说你认为py 1人日，java 7人日过分了，那我们换成c/c++也行。然后你会发现c/c++找热点更难，或者找出来之后也更难替换。
【 在 xeagle 的大作中提到: 】
: 我关心的是找到热点。
: 所以说对于找到热点，只是靠工具，python本身并没有什么优势吧
:
: ...................
--
FROM 180.158.50.*