@HowardMei 抽象建模不需要实分析，你哪里听来的。实分析是测度论的先修，测度论是概率论的严格化。你不需要了解测度论，已经能算概率的很多问题了。就好像实分析是微积分的严格化，你不需要实分析，工程里面算微积分已经绰绰有余了。

@xu33 微积分是必须的，否则你根本入不了门。另外 狄拉克δ函数 这个知识点你最好了解一下，因为大部分离散概率分布（求和形式）都可以用 δ函数 转换成一个连续的概率密度，然后用积分来表示。这样子就统一了，也就不需要区分离散和连续分布了。

你们都怀疑 cpu 和网卡。但是我根据楼主的描述，怀疑主板的 IO 总线。
- - - -

@yingfengi @flyz 首先 iperf 的结果排除了硬盘问题。
其次网卡的型号明朗，我觉得这么便宜的部件应该不会出问题。
再次 cpu 在所有测试中都没满负载。
那么只剩下主板的 IO 总线了。

想当年我用树莓派，IO 总线太渣，无论接什么设备，都无法突破 4MB/s。

mac 写 Linux 跑

用卷积呗，构造一个播放按钮的 kernel。

楼主你真的学过数据结构和算法么？
- - - -

上哈希表，妥妥的。

看看文件句柄数量是不是超过了当前进程的限制数量。

https://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/

- - - -

每写一行打开一次文件不是好的 practice。请用 logging 模块。

我觉得，博客是给别人看的…… 给别人看的东西还要让别人敲命令，这对用户不友好。

苦海无边，回头是岸。

if not os.path.exists(os.path.split(dst)[0]): os.makedirs(os.path.split(dst)[0])

@sunthink 对的事情就坚持去做呗。人生没有那么多时间去迷惘。当然，你要问我个人的偏好，我不喜欢前端。

你所厌恶的不是卖卡、打电话还是做前端。

你所厌恶的是机械性的重复劳动。

而造成你只能机械性重复劳动的重要原因，是你从一家不知名的 211 毕业这个履历。

而你的这个客观条件其实是在你人生更早阶段的经历的结果。
- - - -

当然，以上不是在打击楼主积极性，而是在分析你的条件和你的愿望之间的客观矛盾。

所以你现在无论换什么，不管它是前端还是后端，还是别的什么工作，都会有这个壁垒存在。

你要么抓住一个固定的方向去提升你在这个页内的能力和人脉，重新奋斗几年填平你以前的坑，要么你就只能不断地换各种重复的机械性劳动，然后很快产生厌恶，离开。

怎么做，楼主你看着办呗。

大哥，每个人的手感都不一样好哇？别老乱代表

看看基类是不是重载了 __new__ 或者有 metaclass

我怎么觉得维度对不上啊？ index: [?, 10]，但是 result [?, 1000]，怎么对的？

@noqwerty 我记得 asyncio 有方法用多进程，不过现在的 api 都很基础很难用。所以你这需求用 python 其实挺麻烦的。

@Miksztowi GIL 的存在导致文件读取的每个原子操作，线程切换的开销增大。而 shutil.copyfileobj，那是个 Python 循环，所以是不可能高效的。aiofiles 那东西在很多平台上面是多线程实现的，你可以 check 一下它的源代码。

基于这个原因，可以认为楼主的程序上多线程没救，所以 asyncio 就没有救（如果多线程有救，asyncio 还是可以用的）。而因为多线程无法使用，CPU 密集型的 unzip 就没法被 asyncio 搞定。这才导出了我的结论，unzip 是 cpu 密集型，不适合 asyncio。

至于 select、epoll 这类 I/O 复用，我觉得可以认为它们是非阻塞模型，因为它们避免了多线程模式下的 while { read } 县线程等待，和 callback 效果等同。我觉得并不一定 callback 才可以被认为是非阻塞，只要看是否达到同样的效果就可以了。

@noqwerty asyncio 主要针对网络通讯的并行化，用的是非阻塞模型。关键词可以搜索 select, epoll，了解更多非阻塞模型的事情。