作者Muscovy (三分熟的闹钟)
看板Soft_Job
标题Re: [讨论] Python 3.10将加入Switch-Case语句
时间Sun Mar 28 00:20:24 2021
※ 引述《Muscovy (三分熟的闹钟)》之铭言：
一回神竟然引发这些有趣的讨论.
来稍微介绍一下我的工作背景: 我是在上市公司做高效能运算的单位主管.
算什麽无聊东西就不要问了, 不过特别强调, 不是博弈或者加密货币. :D
我的一个 block 通常会吃掉 100%~500% CPU, 生命期介於 2~48 hours.
执行阶段占用记忆体大概是 20GB~30GB 之间, 偶尔会用到 memory map.
再长的话不敢做, 会分段跑, 因为 windows 会当. XD
（MacOS 稳定一百倍, 但是公司不配发, 所以... ）
因此, 我想我比绝大部分的人更在意「运算效能的问题」.
在我的例子里面, 每个回圈执行的时间不会低於三十分钟.
所以这些 iteration 本身的 overhead 不是问题, 因为都是毫秒级.
但是如果你关心效能的话, 拆出一堆 for-loop 才是正确的写法.
因为这种写法「对於效能」最大的好处是平行化.
怎麽平行化? 几个 for-loop 就拆几只程式跑啊, 简单得很.
接下来讲的就比较难一点.
加速最重要的其实是 cache utilization.
其次是 pipeline utilization.
这种 instruction level optimization, 很重要.
我给各位一个大概的概念...
cache utilization 做得最好与最差, 执行效率大约 x50~x100 倍.
pipeline utilization 的话, 几层 pipeline 就是几倍.
反观你的 CPU 辛辛苦苦买到 12 核心, 全占满大约加速 4~5 倍.
把 12 核通通算到过热它还会降频跑, 又更慢了, 你看多废.
然後 instruction level optimization 的部分.
教科书一开始就会说:
1.) data layout & access pattern 很重要.
2.) 回圈里面不要放 branch.
因为 principle 1.) 顾 cache, principle 2.) 顾 pipeline.
当然 python 本身很难做到这件事.
不过你可以去找 hardware accelerated library.
最知名的就是 tensorflow + GPGPU.
tensorflow 这咚咚不只能做 AI, 它也是高效能的线代运算核心.
一样, 为了顾效能, 你也会把自己搞成这种写法. XD
: --
: 推 neo5277: 好像是满好玩的 关心值 不知道会不会比较有效果
: → Murasaki0110: 变成5次for好在哪里
: → alihue: 第二种其实 eig 会被 scan 五次？效能不是比较差吗
不只会 scan, 实务上甚至有可能花 10 秒重建一个超大矩阵.
但是多这 10 秒, 反而可以让你提前几十分钟结束运算.
: 推 drajan: “pythonic”
"pythonian," 来战! 哈哈哈.
: 推 noahleft: 第二种以维护角度比较容易, 第一种当条件混入各种可能後
: → noahleft: 会很难知道甚麽时候会跑到哪个条件
: → noahleft: 只要考虑到有情形是多个条件都能成立时,第一种写法就是
: → noahleft: 看执行顺序,而第二种写法会变成喂进来的资料都是符合条
: → noahleft: 见的
是的, 尤其是你看到一堆论文, 每篇都要实作才知道有没有唬烂.
你会发现不太可能用 for-loop 内嵌一堆 if-else 去做这件事.
因为本质上你是在重建数学家的工作, 你的程式码要越接近数学形式越好.
然後做久了会发现, 一行数学式对一个 for-loop 最直观. XD
: → hsnuyi: 又是一个不考虑CPU如何branch的人
: → WunoW: NO 你先if排除不符合的条件更直观也有更好的效能
: → WunoW: 我知道你是想遵循单一职责原则，但这不是定律
: → WunoW: 一个回圈做多个判断没有不行 你判断式提取为函式就好
: 推 alihue: 楼上说到一个重点...if的位置在某些情况可以大幅改善效能
: → WunoW: 你去看pandas的源码吧 一个for loop里面包山包海的code一堆
: → alihue: 例如在回圈的一开始就筛掉大部分 case 并 continue
: 推 MoonCode: 先写的简单好懂比效能重要 推推
: 推 jack0204: 楼上说的这叫early return，写可读性高的程式常用到
我上面讲的都不是学术界里的象牙塔, 仅供写论文之类的.
是道道地地发生在产业中的每日工作.
跟我的运算类似的产业叫做 ADAS, 他们也在写类似的写法.
光是一边能无脑拆, 另一边因为内嵌 if 不能无脑拆...
不能拆的那边就准备被一堆 AWS 做翻.
或者俗气一点, 毕竟是 soft JOB.
如果年纪轻轻就已经知道上面那些小诀窍, 面试进联发科的机率很高哦.
够俗气吧, 但挺有用的.
所以你知道的, 为了效能, 你更应该写一堆 for-loop.
这绝对不是异端学说. XD
--
新诗练习：新鲜。踩破初春里的狗大便；不经意的沧桑，满溢着嫩黄的喜悦。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.248.47.50 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1616862026.A.F6D.html
1F：推 yislin: 推解释详细 03/28 00:31
2F：推 x9060000456: 推 03/28 00:32
3F：→ yislin: 好奇请教一下，如果舍弃 for loop，改成将 subarray 传递 03/28 00:37
4F：→ yislin: 至 function，而後再回传，如此一来在优化上是否更好做？ 03/28 00:37
5F：→ yislin: 再多问些，如果再加上 map 呢 03/28 00:40
6F：推 alihue: 如果你前提是每个 for-loop 拆出程式分开跑当然效能好 03/28 00:42
7F：→ Muscovy: @yislin, 你给的条件对我来说比较像是维护性的问题. 03/28 00:43
8F：→ alihue: ，但前篇文章前提是同支程式。 03/28 00:43
9F：→ alihue: 此外并不是讲职称就能把你的话直接变成正解，技术要合理 03/28 00:43
10F：→ alihue: 才能。 03/28 00:43
11F：→ Muscovy: 维护性也蛮重要的, 一味优化的结构很恐怖, 隔天就看不懂. 03/28 00:43
12F：→ alihue: 我并没有要反驳说这篇哪个做法是错的，因为 03/28 00:43
13F：→ alihue: 这篇又多加了几个前提，那解法又更不同。 03/28 00:44
14F：→ Muscovy: @alihue, 其实我只是「从效能的观点」来说... XD 03/28 00:44
15F：→ alihue: 我自己也在每天几千 QPS 的系统工作，但我不会认为我是正 03/28 00:45
16F：→ alihue: 解 03/28 00:45
17F：→ Muscovy: 从维护性来说, 我的经验也告诉我, for + if 少用为妙. 03/28 00:45
18F：→ Muscovy: 因为出错的时候真的很难 debug, 尤其一群猴子合作的情况 03/28 00:46
19F：→ Muscovy: 对, 我就是说我们的团队... XD 03/28 00:46
20F：→ paimin: 我们都直接买64 core的给大家跑 优化有空再做就好了 03/28 01:17
21F：推 taipoo: 推 03/28 01:39
22F：→ handsomeLin: 如果要拆来跑的话当然是拆开for loop跟preprocessing 03/28 10:53
23F：→ handsomeLin: 的概念是一样意思，但是这样跟用不用if在for loop里s 03/28 10:53
24F：→ handsomeLin: cope就完全不同了 03/28 10:53
25F：→ Murasaki0110: 没平行的时候硬要这样写就是慢啊 03/28 10:59
26F：→ Murasaki0110: 你前提是平行那也没讨论if的必要 03/28 11:01
27F：嘘 majohnsha: 台湾主管真敢讲 说自己团队是猴子 03/28 12:27
28F：→ majohnsha: 真好奇哪家上市公司 03/28 12:28
29F：→ recorriendo: 看起来你的loop顺序不影响结果 那直接做data paralle 03/28 13:33
30F：→ recorriendo: l 有几个entry就拆成几个job 不是更快？ 03/28 13:33
31F：推 j0958322080: 搞不好人家只是谦虚而已 03/28 18:13
32F：→ Muscovy: 不是谦虚! 而是... 薪水用乡民的眼光看, 真的是香蕉等级 03/29 00:49
33F：→ Muscovy: data parallelism 是其中的部分考量而已. 03/29 00:52
34F：→ Muscovy: 而且运算量大的时候, 常见的拆法也不能用. 03/29 00:53
35F：→ Muscovy: 因为通常也会伴随 bandwidth 的问题. 03/29 00:55
36F：→ Muscovy: bandwith 「不足」... 漏写. 03/29 00:55
37F：→ Muscovy: bandwidth........一直打错. 03/29 00:56
38F：推 vi000246: 同意越接近数学越好维护 03/29 11:54
39F：→ shooter555: 指令集的问题就变成要看指令集提供哪些运算了 看可以 03/29 12:47
40F：→ shooter555: 一次运算几个byte 再来拆loop 毕竟很多余数特例 03/29 12:48
41F：→ shooter555: 不过讲到这个就要完全舍弃可维护性了 在加速部份 03/29 12:51
42F：→ shooter555: 每个回圈运行的时间不低於三十分钟 那的确可以舍弃掉 03/29 12:59
43F：→ shooter555: 展开的时间了 03/29 12:59
44F：→ shooter555: 但如果这个function是不到一毫秒执行一次可能会有差 03/29 13:01
45F：→ shooter555: 平行化也不是这麽好用 毕竟还要考虑到race condition 03/29 13:06
46F：→ shooter555: 三十分钟这麽长的确可以拆几个thread来跑 但必须确保 03/29 13:08
47F：→ shooter555: 些来的资源不共用 或要另外lock 03/29 13:08
48F：推 ShenJing: 推解释，有所收获 03/30 01:18
49F：→ loggan: 有问有人知道内文提到的教科书是？ 03/30 11:43
50F：推 s0914714: 如果那麽在意效能应该是不要用(原生的)Python 03/30 17:25
51F：推 kqalea: 我认同，看看VPP DPDK 05/05 10:50
52F：→ kqalea: 我更觉得 LLVM Backend 是更好更理想的解法 05/05 10:51