感觉不应该有问题，cors 没有不支持二级域名的说法，nginx 反向代理也不会替换 origin

这是语言特性，具体问题就是子 block 对父 block 中资源的处理方案，各个语言对这三点的处理不尽相同，一般的三个问题是 1 、能否感知，2 、能否读取，3 、能否修改。

就 python 来说是能感知和读取，修改的话会创建副本，所以父 block 不用担心变量被子 block 或调用乱改。可能有一些考量在，虽然目前我个人来说更喜欢闭包可以全权修改的方案。

解决方案一般是 nonlocal 或者传递指针，传递指针是指传进子 block 的是对象或者[0,]，子 block 中用 item.property += 1 或者 item[0] += 1 的方式修改。nonlocal 效率更高，不过传指针更灵活一些，性能其实倒是不太有所谓，python 列表单次寻址耗时大概是 20 纳秒左右，在绝大多数场景中这并不是值得在意的开销。

我觉得一楼对比效率的图意义不大，毕竟 hashmap 实现的上细节也很丰富，不可一概而论。看了 LZ 之前两个帖子，应该就是传统算法遇到 hash 碰撞则按链表方式保存，二级搜索采用逐个对比，lz 觉得二级搜索可以再加一层 hash ，以此类推。不过从普遍情况讲，google 开源 cityhash 已经是十多年前的事了，哈希发展到 2022 年，快速哈希算法本身效率和碰撞率都很低，普遍应用场景中碰撞本身是少数，所以二级索引中使用全文读生成二级哈希效率会比直接位对比快吗？我看不尽然，举例中使用的 md5 和 sha1 之类的成本极高的算法更不现实了，生产中也没见过这么用的。

再一个如果是从数理逻辑上针对无穷输入的情况设计普遍适用模块，逐位对比当然是永远不会出 bug 的，但是多层哈希法无法保证一定不会出现某对数据所有哈希值相同的情况，哈希算法需要人为设计是有限的，数据是无限的 ，完美看起来反倒没有现在通用方案完美。

@enchilada2020 确实，感觉活这么大心理最放不下的还是父母，最惭愧的也是父母，但自己老大不小又一事无成，也没什么能报答的，时间就这么过去了。

@qbqbqbqb
@fcfangcc
@janus77
@gfreezy
@lolizeppelin
@xuanbg 异步是为了让过程调用受网络管理，需求是 CPU 密集型任务所以使用 fork 多进程，楼上老哥说得对，我试了一下好像真的除了 fd 以外不共享任何数据，跟我记忆中有些偏差（我印象中不特意创建进程间可共享内存也有同指向发生，试了下好像除了虚拟内存表以外物理内存表也全拷贝了，完全的互不相干。。）


关于代码写完过几年看不懂的问题，因为是开源项目其实当时还写了蛮详细的注释的，只不过是用英文写的，现在看注释一大坨一大坨像看论文一样实在不想看。可能这个故事教育我们就是不要好面子写英文，外国人看不看得懂不是最重要的，自己能看懂才是。。

我觉得普通也不代表平庸吧，人在定义自己或他人的社会属性的时候，普通往往跟人掌握的社会资源挂钩。所以往往社会看一个人，看他没钱也没资源，那就是广泛意义上属于普通的那一类。比如年轻人除非是 X 二代继承了资源，否则基本上都是没什么资源的，在社会整体看这些年轻人都很普通。但是这些人里也有一些是活的与众不同的，或者活的精彩的，说他们平庸又有失偏颇了。

@LeeReamond 实用就是比如我是百度贴吧的维护者，然后我想给每个帖子一楼加个自动摘要之类的。。像简单能学到的 tfidf 似乎完全应付不了百度贴吧的数据量

@paopjian 有什么其他效果好的 /常见的摘要算法推荐吗？想做点生产能实用的到的东西。。tfidf 其实只是想当个 helloworld 跑，概念和实现啥的都挺简单的，没想到真的跑起来发现完全跑不动。。

并不很理解，同样的代码生成的字节码几乎一样，而字节码解释为机器码又几乎一样，一样在 cpu 上跑为啥会慢。。。WSL2 不比原生慢就不错了，还能快 30%我觉得可能是你测试有问题，毕竟听起来你测的是纯计算而不是 IO ，涉及到系统内核 IO 的话倒是由于系统实现不同确实有很大区别。

@murmur 不是很懂，主要 tf-idf 有个整体词频，我不输入所有贴的话怎么得到总体词频呢。你的意思是取样算出来的和整体也差不多？不过也不知道咋取样啊，比如我导入 A 板块的帖子，那用这个板块产生的词频算 B 板块的 tf 是不是就不太对了

@murmur 我筛除了大部分没有实体含义的词性。最后得到的词有三万多个。。所以按 100 万帖子算的话，整个 tfidf 的矩阵大小就是 100 万*三万，太难顶了

hashlib 是通过 ffi 调用实现的，不需要多进程，直接使用多线程即可释放 GIL ，你说不能释放 GIL 我感觉是你哪里错了。

@seakingii 到本地可调式为止，静态编译也需要安装相关依赖，这与动态语言依赖无任何区别，只会更加麻烦。你说自身提供服务可以省去 nginx ，那你开心就好，按照你的理论 uswgi 也可以省去 nginx ，甚至不需要 uwsgi 也可以省去 nginx ，甚至 mysql 也可以省了，用 sqlite 不就行了。顺带一提谢谢你的回复，block 了。

@seakingii exe 也无法规避 mysql 和 nginx ，你在说啥

个人体验上，你使用不良的设计，或者追求极限要求（比如就是不适用 string ，就要通篇&str ），那在 rust 里就容易吃瘪。反之则可以体会到 rust 相对于 c++的快感。往往越到底层奇技淫巧越少，实现也就是按部就班的实现。

@misdake 确实，我只考虑了图床需求，没考虑其他网站接受图片上传可能有各种各样的需求，感觉有点被原贴关于储存方式的讨论带跑偏了。仔细看了你的帖子似乎是 nginx+phpfpm 相关的漏洞，随着现代 nginx 被当做反代使用方式增多和 php 使用减少本身发生这个特定漏洞的情况应该很少了，所以在 2022 年的角度考虑可能就是维护图片解码库的朋友注意一些就不会有啥问题。。

@misdake 所以什么操作会引发执行脚本？解码缓冲区溢出倒是确实见过，以前 PIL 就发生过类似情况，不过为啥要解码，就算校验文件类型稍微读读文件头也就完事了。。

“效率虽然已经很高，但是仍然没有发挥多核优势”，建议重新理解 IO 密集任务的含义。IO 密集场景指的是最终性能表现受限于你的基础设施（软件基础设施，硬件基础设施），你的信息收发模块按照它的设定逻辑，总共只能处理那么多的任务，你 CPU 跑的再快，塞再多任务它也处理不了，有什么用呢？

你可以看到一些 TCP 通信框架跑分，用 C 语言写的框架每秒可以做到几十万次并发，但是 C 语言每秒可以修改 1 亿次三级缓存状态，所以为什么 CPU 跑的比单机通信跑分可以高好几个数量级，单机通信跑分最高还是只有几十万？