毕竟能招到宝马谁想要桑塔纳 hhh

不会点原理的话 95% 的代码工作能胜任，但是出点奇怪的 bug 就搞不定了。

总之如果只看名词不看实际（实现方式），各种语言、框架的并发就是大坑，不同概念层出不穷，会让楼主混乱的。

如果楼主不想继续纠结这么多乱七八糟的概念，建议左转 Go 语言。那边的 Goroutine 中的同步代码 = Event Loop + 协程（相当于 Python/JS 手动 async/await ） + 线程池。实际上完全解决了楼主你书里面看到的问题，但是其实你书上的概念一个都套不上去，因为它直接从 vm 层面给你扬了这些概念（笑

虽然你像我这么分析还是能对应到你书上概念的

... 然后书上说的不错，但是没有告诉你的是什么叫“时间太长阻塞”。

实际上你看到的 “每个事件处理都用线程池里的线程去处理” 太泛泛了。具体而言，一般我们都是把 CPU 时间开销大的逻辑丢进线程池然后 await 的。比如算一个 PageRank 分数之类的（笑）。

上面的仁兄提到了 Actor model 。我很感动居然还有人知道这玩意儿，但实际上这玩意儿写普通的业务逻辑不如 async await 高效。举个例子，如果你要读数据库，在多线程 Actor model 下你要怎么做？难不成直接同步阻塞等数据库结果？那不好意思，在大部分语言（ C++/Java/Python ）中，你又阻塞了一个线程池。纯粹的 Actor model 要求你业务代码把数据库请求 send 给 DBActor ，DBActor 应该是一个负载均衡，后面接着一串多线程的 DBActors 。然后 DBActors 阻塞读写，出来结果再 reply 到业务 Actor 。总之纯粹的 Actor model 写业务代码挺麻烦的。

但是 Actor model 上限很高的，是屠龙刀。它能保证每个 actor 同时只有一个线程在跑，直接保证所有数据的线程安全。这种屠龙刀就不该用来写普通的业务代码。
----

综上所述其实 async / await 写业务代码其实很舒服的，在大部分语言中你不会喜欢其他模式的。

除了 Go 语言。

Go 语言是个工程妥协性非常强的语言，为了解决普通程序员不那么高明这一“人力 BUG”，它做了一些在我看来很丑陋的（但是确实能解决不那么博闻强识的程序员写出来的代码问题）选择。比如它会自动把同步的等待代码直接切出来控制权，强行在 Go vm 层面自动地把同步代码给打断等待。相当于你写了同步等待的网络 /文件 IO ，它自动翻译成 async await 了。这个确实屌，不得不承认，虽然在我看起来很丑陋——

这意味着程序员并不能 100% 控制 Go 语言的实现，你写个比如 PageRank 的算法可能比不上 C++，因为有一堆你不知道它会干嘛的额外动作。

当然，我这么评价 Go 语言，是因为我从线程池、Event loop （ select epoll ）、Actor model （ Akka 或者我自己 C++ 手撸的）、callback 之类的东西我都用过。C++、Python 、Scala 、JS 我都写过不少项目。嘛，没那么博闻强识的程序员确实 Go 语言包办更舒服。

其实吧，业务代码没那么多 CPU 时间很长的片段的。一般都是直接写一点数据处理，await 数据库 /文件 IO 。

好处实在太大了。因为在线程池模式下，无论是数据库还是文件 IO 都会阻塞一个线程，也就是说就算你业务逻辑再简单，也会耗尽线程而无法提高并发。现在直接 async ，阻碍你并发的只有后端数据库和网络的速度。网络速度可以随意 100MB/s ，数据库可以集群（提供更快的读、更慢的写），这样就非常 nice 。

虽然楼主说的确实有道理，不过我个人确实不需要呼吸灯这种玩意儿。。。

毕竟电脑上该登陆的都登陆了。微信是肯定会打开的，那么大部分消息也就不会没看到了。

鲜榨果汁 = 饮料，没必要考虑它的营养价值，毕竟它也不剩啥营养价值了。

从饮料角度，你老婆是对的。

哦最大最小堆也挺好，可以处理在线情况。

换个几号吧，如果你的全数组长度是 M ，用最小堆找最大的前 N 个元素，那么时间复杂度就是 O(M log N)。
反之用最大堆可以找最小的 N 个元素。

快速选择，做一半的快速排序，期望复杂度 O(n)

先做一次快速排序，若轴枢元素是第 K 大。

* 如果 K < N 则对右侧做 N-K 的快速划分。
* 如果 K > N 则对左侧做 N 的快速划分。

df[column].rolling(window_size).rank(pct=True)

https://pandas.pydata.org/docs/reference/api/pandas.core.window.rolling.Rolling.rank.html

这种结论一般都是构造法证明。

首先图灵机是什么有清晰的定义。然后就是怎么用 sigmoid + rnn 表达任意给定的图灵机了。

随便搜一下可得：

Turing Completeness of Bounded-Precision Recurrent Neural Networks
https://openreview.net/forum?id=IWJ9jvXAoVQ

这篇 2021 年的 poster 说，前人的工作需要假定无穷精度的 RNN 才能表达任意图灵机。现在他们可以用有限精度 RNN 来表达了（可喜可贺

1. 坚果云的 WebDav 我印象中用 Joplin 容易冲突。不知道 Obsidian 怎么样，但我想这可能是 WebDav 的固有缺陷 —— 依赖客户端的冲突解决能力。

2. 所以我会更倾向于使用自带客户端的同步盘。其实按道理坚果云自己的同步盘效果还可以，冲突解决也还行。直接把 Obsidian 的 Vault 塞进去就行了。

3. 我自己用的是 Seafile 自建网盘，用的 Seafile 的同步客户端。

@mcone az 。我联通，当年支付宝健康码经常加载不了，我就换微信了

北京健康宝内部的扫码才能显示健康码。

我认为正常写法更好

@nthhdy “ 引入运动预测等机制，即使无损也能一定程度上提高压缩比。”

呃，真的存在无损运动预测压缩算法嘛