2019年10月14日月曜日

marisa-trie で BMI2 の PDEP 命令を使えるようにしました

簡潔ビットベクトルの select に BMI2 の PDEP 命令を使うと実装を単純化できる上に高速化できるという情報を見つけたので marisa-trie (https://github.com/s-yata/marisa-trie) に組み込んで試してみました.

PDEP を使うのは, 64-bit 整数まで絞り込んだ後になります.
marisa-trie での該当箇所は以下の通りです.(MSVC 向けの部分はカットしました.)
unit から i+1 番目の 1 になっているビットの位置を求めています.(bit_id はただのオフセットなので気にしなくて OK です.)

std::size_t select_bit(std::size_t i, std::size_t bit_id, UInt64 unit) {
  return bit_id + ::__builtin_ctzll(_pdep_u64(1ULL << i, unit));
}

select は lookup や reverse_lookup の中で特に重い処理なので,結構効果がありました.
以下, marisa-benchmark に日本語 Wikipedia のタイトル一覧(順序そのまま)を入力したときの出力を貼っておきます.
実行環境の CPU は Core i7 6800K 3.4GHz です.

まずは PDEP を使わないバイナリです.

$ make clean && autoreconf && ./configure --enable-bmi && make
...
$ tools/marisa-benchmark -p jawiki-20191001-all-titles-in-ns0
Number of tries: 1 - 5
TAIL mode: Text mode
Node order: Descending weight order
Cache level: Normal cache
Number of keys: 1887667
Total length: 40976550
------+----------+--------+--------+--------+--------+--------
#tries       size    build   lookup  reverse   prefix  predict
                                      lookup   search   search
          [bytes]    [K/s]    [K/s]    [K/s]    [K/s]    [K/s]
------+----------+--------+--------+--------+--------+--------
     1   16224608  1446.04  3608.77  3206.54  3152.50        -
     2   11877920  1169.76  2051.87  1898.60  1977.19        -
     3   11008584  1158.67  1699.86  1695.10  1708.77        -
     4   10692624  1151.92  1685.07  1632.11  1644.95        -
     5   10557664  1155.25  1661.06  1597.17  1618.07        -
------+----------+--------+--------+--------+--------+--------

次に PDEP を使うバイナリです.

$ make clean && ./configure --enable-native-code && make
...

$ tools/marisa-benchmark -p jawiki-20191001-all-titles-in-ns0
...
------+----------+--------+--------+--------+--------+--------
#tries       size    build   lookup  reverse   prefix  predict
                                      lookup   search   search
          [bytes]    [K/s]    [K/s]    [K/s]    [K/s]    [K/s]
------+----------+--------+--------+--------+--------+--------
     1   16224608  1418.83  4134.11  3956.39  3858.28        -
     2   11877920  1220.01  2357.28  2276.49  2279.57        -
     3   11008584  1164.50  2037.00  1978.51  1985.62        -
     4   10692624  1158.25  1915.64  1929.95  1909.70        -
     5   10557664  1159.29  1916.36  1902.57  1872.88        -
------+----------+--------+--------+--------+--------+--------

PDEP を使わない場合と比べて PDEP を使う場合は, lookup が 14-20% の高速化, reverse_lookup が 17-23% の高速化となりました.

2018年11月17日土曜日

古いプロジェクトのメンテナンス

古くなったプロジェクトのメンテナンスをおこないました.

変更したところは大体こんな感じです.
  • 新しいコンパイラで出るようになった警告が出ないように修正しました.
  • ドキュメントのリンク先がなくなっているリンクを更新しました.
  • バージョンが上がったソフトウェアとの組み合わせを試しました.
  • Markdown のインデントを修正しました.

2018年11月16日金曜日

アーカイブの公開方法を変更

日本語ウェブコーパス 2010 (NWC 2010) の移動が完了したため, HTML アーカイブとテキストアーカイブの公開方法を変更しました.

https://www.s-yata.jp/corpus/nwc2010/htmls/
https://www.s-yata.jp/corpus/nwc2010/texts/

以前は AWS Account Number を教えてもらい,こちらで EBS スナップショットのアクセス権限を設定していました.
この方法だと,利用者は AWS アカウントが必要な上,手元にダウンロードするまでの手順がとても面倒という問題がありました.

今回, EBS スナップショットに入れていたデータを S3 に移動したので,アーカイブが欲しいという連絡をもらったとき,こちらで公開の設定をおこなえば,利用者は単純にダウンロードするだけになります.

2018年11月15日木曜日

日本語ウェブコーパス 2010 の移動


日本語ウェブコーパス 2010 (NWC 2010)  は,当時もっとも安かった米国東部(バージニア北部,us-east-1)リージョンで作成した後,これまで同リージョンに置きっぱなしになっていました.
現状, us-east-1 にこだわる理由は特にないので,東京リージョンに移動することにします.

それから,サイズの大きいアーカイブは EBS スナップショットにしていたのですが,コスト面で s3 の方が優れていると判明したので,すべて s3 に移行しようと思います.
稀にリクエストがある程度のアーカイブであれば, Glacier にすることでコストを削減できるはずです.

GitHub Pages でサイトを作成してみた

GitHub Pages でサイトを作成してみました.
https://www.s-yata.jp/

旧サイトの中身を持ってきただけなので,新しいことは特にありません.
これで問題がなければ,旧サイトをホストしているサーバは解約できます.

追記:
http://s-yata.jp/ へのアクセスは http://www.s-yata.jp/ にリダイレクトされることを確認しました.
旧サイトのコンテンツに対するブックマークなども有効なはずです.
ただ,ウェブサービスについてはサーバをなくしたいので廃止してしまいました.

2018年11月13日火曜日

GitHub Pages をお試し中

ウェブサーバの管理をきちんとやるのは大変なので, GitHub Pages でウェブサイトを公開する方が良いのではないかと試しています.

GitHub Pages の使い方は GitHub の Help (https://help.github.com/categories/github-pages-basics/, https://help.github.com/categories/customizing-github-pages/) に詳しく書いてあります.
既に HTML ファイルが手元にあれば,リポジトリの設定で GitHub Pages を有効にして, push するだけで公開完了します.

ウェブサイトの生成には Jekyll が使われているため, Front Matter 付きの Markdown ファイルを push すれば, HTML に変換されたものが見えるようになります.
_config.yml を追加してテーマを変更したりプラグインを追加したりすることもできます.

2018年10月16日火曜日

Code prettifier の使い方

https://github.com/google/code-prettify の使い方をメモしておきます.

「テーマ - HTML の編集」で <script> タグを <b:skin> の前に追加した後,「テーマ - レイアウト - 上級者向け - CSS を追加」でスタイルを追加しました.
<script> を入れるべき場所はテーマで変わりそうな気がします.

上記の設定だけではモバイル版には反映されません.
「テーマ - モバイル - 設定」で「カスタム」を選択すれば反映されました.