有上亿的词算词频怎么算比较快

Trie Tree 可能会快一点，但你要用 C++ 来极限优化，不然反而比 hash 更慢。

cpu 不是问题, 分成好多个小文件并发的去算呗.

比如，如果都是英文字母，不需要区分大小写，那你的符号表就只有 26 个字符。为了速度可以取 32 。

既然长度都在 1~5 之间，那你用三层 Trie tree 就能有效压缩深度。每一层是 1024 个格子，取格子只要位移操作不用乘法。相当于分层快速哈希，而且必然没有冲突了。

上述操作必须用指针在那里魔法计算。。。不要用 STL 容器。不然速度还是提不上去

@ipwx 都是中文，trie 树应该作用不大。

一个字符 3 字节，一个单词 10 个字符，10 亿字符串也不到 30g 。。。我觉得字典够用

可以参考一下 kenlm 的实现

是 MapReduce 的意思吗 ?

@abujj 不会。。。

@nulIptr 是够用但是太慢

这不是 MapReduce 的第一课吗，赶快学学

首先排除 C 以外的其他语言，因为其他垃圾太慢了。其次就是算法和数据结构了，这个嘛，就要看个人发挥了。

map reduce

Mapper
Reducer
哈哈

单机 MapReduce 有啥用

中文字就六七千个，怎么搞成上亿的词典？ NLP 里面语言模型一般也就几万字，还包括很多重复的呢。
如果就是这几千字组成的词语 /短语也算入词典的话，用沙发的方法是不是有帮助？

大部分都是重复的，其实字典就可以了

@pengtdyd 这是什么爆论，先且不说 C/Cpp/zig/Rust 等一票原生语言本身没有额外开销，性能完全取决于具体代码。C 语言在性能方面也是具有一些劣势的：
1. 糟糕的标准库和依赖管理，很多 real world application 由于开发者为省事选择简单而非最优化的算法与实现导致性能损失。而像 Rust 这样提供方便的依赖管理，成熟且经过深度优化（复杂算法、simd 等）的库被广泛使用。
2. 手动资源管理外加宽松约束，导致的心智负担使程序员倾向于防御性编程和不必要的复制，外加理论上对编译器优化的限制。
3. 极大规模和复杂度的应用中 Java 等具有 JIT 的语言性能吞吐量等表现要好于 AOT 语言。（并且复杂度庞大的应用根本不可能由低级语言编写）
4. 开发成本过高。比如绝大多数 C 编写的网络服务并发性能肯定是不如 go 的，因为后者自带，前者除了 nginx 这种谁会去费劲优化。

直接用语言自带的哈希表就够了