1
chenbojian 2021-03-30 21:47:32 +08:00
都小数据量了,不需要在意速度了吧
|
2
czfy 2021-03-30 21:50:11 +08:00 via Android
毕竟是封装的
复杂统计模型也不能全部都手写吧 |
3
xiaolinjia 2021-03-30 23:50:52 +08:00
上次我测试的时候,发现
n1 = np.arange(cnt, dtype=np.int_) n2 = list(range(cnt)) n1 + 2 [mem + 2 for mem in n2] 当 cnt 较小的时候,numpy 的广播方式比下面 py 原生循环还慢。之前看文档说,numpy 用的 c 循环,所以比 py 的快。把我整的有点懵。 |
4
liprais 2021-03-30 23:55:31 +08:00 via iPhone 1
你这对比的都不是一件事好么
|
5
LeeReamond 2021-03-31 12:56:09 +08:00
@xiaolinjia
https://gist.github.com/GoodManWEN/dc9372c7a0288837aa4ffd4b0ddc85f8 明显你测试有问题,我测试里长度为 100k 情况下 np 比原生快 200 倍,长度为 1k 下快 55 倍 |
6
xiaolinjia 2021-03-31 13:41:58 +08:00
@LeeReamond 行吧,具体阈值我没测清除,不过 cnt 在 15 以内 py 的列表推导快过 np 广播。
|
7
LeeReamond 2021-03-31 14:34:02 +08:00
@xiaolinjia 测了一下确实,我的阈值大概长度 25 左右时速度相等。
理论上 np 的主要开销在于 ffi,不同的优化程度 ffi 调用开销在几十到几百纳秒不等。C 语言进行这么短的计算的开销可以认为不存在,cache 不会 miss,大概几个 clock 之内搞定,可能个位数纳秒,或者 1 纳秒。 原生的话,主要在于新建和回收列表的开销,因为这部分已经高度优化了,cache 不 miss 的情况下可能几十纳秒,循环过程的开销也比较高,可能几十纳秒,加在一起得到一个合计的阈值。不过可以看出来 py 追求性能还是颇拉胯的,随着列表长度增长会有明显的开销增长,c 的话可能你长度为 1 和长度为 1000 感受不到什么区别。 |
8
tisswb 2021-04-08 16:14:46 +08:00
目前我用到的 pandas 适合做统计跟可视化等骚操作
|