gLM
1.0.0
GLM基于GPU的语言模型是NGRAM语言模型实现，该模型实现将ARPA文件作为输入，对其进行二进制并批次查询。有关设计和实施的更多详细信息，请参见本文，该论文在ACL 2016上发布。
git clone https://github.com/XapaJIaMnu/gLM.git
cd gLM
mkdir release_build
cd release_build
cmake ..
make -j4
make test # Requires CUDA for GPU testing-DBUILDTYPE=debug用-o0和-g构建-DCOMPUTE_VER设置硬件的计算版本。默认值为52。如果编译错误的计算版本，它将不会产生正确的分数！！！在此处查看GPU的计算版本。如果make test不会失败任何GPU测试，则意味着您的计算版本是正确的。-DBAD_HOST这应该有助于建立在旧的Ubuntu系统（例如12.04和14.04）上。除非构建困难，否则不要使用它。-DPYTHON_INCLUDE_DIR定义了python库的路径，例如/usr/include/python2.7/pyconfig.h or /usr/include/python3.6m/pyconfig include/python3.6m/pyconfig，并启用构建Python组件。-DPYTHON_VER设置为默认为2.7，如果要构建具有不同版本的Python组件，请将其设置为所需的版本。除非设置-DPYTHON_INCLUDE_DIR ，否则它将没有效果。/usr/incude ），则应为--DYAMLCPP_DIR 。 cd path_to_glm/release_build/bin
./binarize_v2 path_to_arpa_file output_path [btree_node_size]btree_node_size应该是一个奇数。我个人发现31条效果最好，但是您应该进行实验。该数字可能会随不同大小的ARPA文件和不同的GPU而变化
在批处理设置中基准GLM进行：
cd path_to_glm/release_build/bin
./batch_query_v2 path_to_binary_lm path_to_text_file [gpuDeviceID] [add_begin_end_markers]这将计算文本文件的困惑。如果设置了GPudeViceID ，它将告诉代码的GPU部分将在特定的GPU上执行。您可以使用nvidia_smi命令检查系统上的可用GPU。如果要设置0是安全默认值。如果add_begin_end_markers设置为0，则句子的开始和句子的结尾（<s>和</s>）不会包围每个句子。
所以...一切都开始正确运行。 A（初步）基准对单线探测Kenlm（Titan X vs Core i7 4720HQ）
| LM | ngram查询每秒 | 型号信息 |
|---|---|---|
| 肯尔姆 | 10 274 237 | 3.3G，88720517 ngrams |
| Glm | 65 459 102 | 3.3G，88720517 ngrams |
多线程基准，相同的GPU与2x Intel（R）Xeon（R）CPU E5-2680 0 @ 2.70GHz
| LM | ngram查询每秒 | 型号信息 |
|---|---|---|
| Kenlm 1线程 | 8 310 761 | 3.3G，88720517 ngrams |
| Kenlm 2线程 | 15 823 376 | 3.3G，88720517 ngrams |
| Kenlm 4线程 | 27 201 337 | 3.3G，88720517 ngrams |
| Kenlm 8线程 | 43 336 444 | 3.3G，88720517 ngrams |
| Kenlm 16线程 | 49 218 076 | 3.3G，88720517 ngrams |
| Kenlm 32线 | 119 539 677 | 3.3G，88720517 ngrams |
| Glm | 65 459 102 | 3.3G，88720517 ngrams |
调度问题可能会导致16个线程案例的性能较低。 GLM相对于硬件的成本，其性能提高了2倍。 （GPU $ 1000，CPU $ 3500）
