YAPC::Asia Tokyo 2013に行ってきた

blogに書くまでがYAPCです。

ってことで、9/20, 21に慶應義塾大学日吉キャンパスで開催されたYAPC::Asia Tokyo 2013に行ってきました。

今年も個人スポンサーとして参加です。個人スポンサー用のTシャツがイケてるので満足です。

以下、ざっくりとした感想など。

1日目

2日目

  • 今年の本命トークこれからのPerlプロダクトのかたちは、期待通り素晴らしかった
  • 昼食は浜虎
  • 午後はPerl入学式 In YAPC::Asiaにサポーターとして参加
  • 個人的ベストLTはまかまかさん
  • 後夜祭は狭くて暑かったけど、同じテーブルになったdannさんと色々話せてよかった

YAPC::Asia\(^o^)/

懇親会や後夜祭でも何人かにつつかれたMinillaのModule::Build::XSUtilサポートのpull-reqも送って、ブログの書いたのでようやく今年のYAPC::Asiaが終わりですかね。

Module::Build::Pluggable::XSUtil と Minilla の相性が悪いので Module::Build::XSUtil 作りました

Minillaを使い始めたのですが、MinillaとModule::Build::Plaggableは共にModule::Build::subclass()を使用していて、Module::Build::subclass()は多重に使えないという制約のため一緒には使えません。

XSモジュールではModule::Build::Pluggable::XSUtilを使っていたため、Minillaでも同等のことを行うためのモジュール Module::Build::XSUtil を作りました。

GitHub
MetaCPAN

Minilla専用というわけではなく、素のBuild.PLでも使えます。
なお、オプションの名前はModule::Buildの流儀に近いかたちにアレンジしています。

use strict;
use warnings;
use Module::Build::XSUtil;

my $builder = Module::Build::XSUtil->new(
    dist_name            => 'Your-XS-Module',
    license              => 'perl',
    dist_author          => 'Your Name <yourname@example.com>',
    dist_version_from    => 'lib/Your/XS/Module',
    generate_ppport_h    => 'lib/Your/XS/ppport.h',
    generate_xs_helper_h => 'lib/Your/XS/xshelper.h',
    needs_compiler_c99   => 1,
);
$builder->create_build_script();

Minillaと共に使う際は、minil.tomlに以下の記述を行います。

[build]
build_class = "builder::MyBuilder"
[no_index]
directory = ['t', 'xt', 'inc', 'share', 'eg', 'examples', 'author', 'builder']

そして、以下のような builder/MyBuilder.pm を作成します。

package builder::MyBuilder;
use strict;
use warnings FATAL => 'all';
use 5.008005;
use base 'Module::Build::XSUtil';

sub new {
    my ( $class, %args ) = @_;
    my $self = $class->SUPER::new(
        %args,
        generate_ppport_h     => 'path/to/ppport.h',
        generate_xs_helper_h => 'lib/Your/XS/xshelper.h',
        needs_compiler_c99   => 1,
    );
    return $self;
}

1;

最後に、

$ minil build

で Build.PL を生成すればMinillaでModule::Build::XSUtilを使用できるようになります。

素のBuild.PLを使っている場合は自動的にModule::Build::XSUtilがconfigure_requiresに追加されますが、Minillaの場合はcpanfileに以下のような記述を追加してください。

on 'configure' => sub{
    requires 'Module::Build::XSUtil' => '>=0.02';
};

なお、拙作の Algorithm::HyperLogLogDigest::SpookyHashは既にModule::Build::XSUtilを使うバージョンをリリース済みです。

Digest::MurmurHash3::PurePerl released!

MurmurHash3をpure perlで計算する。Digest::MurmurHash3::PurePerlCPANにリリースしました。

もともと、Algorithm::HyperLogLog::PP用に作っていた murmur32( ) に murmur128() を加えて、独立したモジュールとしました。
CPANTestersでもいまのところ問題が無いようなので、Algorithm::HyperLogLogのmurmur32の実装も、Digest::MurmurHash3::PurePerlに切り替えました。

参考までに、他のpure perlハッシュ関数(128-bit)と共にベンチマーク結果を以下に貼っておきます。

           Rate     sha     md5 murmur3
sha       808/s      --    -92%    -92%
md5     10000/s   1138%      --     -2%
murmur3 10204/s   1163%      2%      --

Hachioji.pm #29 に行ってきた

6/15に開催された Hachioji.pm #29 に行って来ました。

今回のLTテーマは「ホスティング」でした。

自分のLT

いつものごとくテーマ無視で、Digest::MurmurHash3::PurePerl(metacpan, github)を作ったときの、C言語からPure Perlへの移植に関する話をしました。

スライド

LT

以下、他の参加者のLTのメモです。

@akira1908jpさん
  • 転職
@__papix__さん
@ytnobodyさん
@xtetsujiさん
@ichigotakeさん
  • Acme大全、Webアプリケーションの作り方を母校に献本した
@ks0608さん
@equinox79さん
  • Pyazoを参考にS3に画像を投稿するアプリケーションを作った
@uzullaさん
  • Pyazoを改良
    • Dancerを使ったGyazo互換サーバ
    • Gifzoに対応
      • Gifzoクライアントでデスクトップを録画してアップロード
      • アップロード先はdefaultsを変更(Mac)
  • VPS

簡潔ビットベクトルライブラリを書いてみた

簡潔データ構造の勉強がてら、各種簡潔データ構造の核となる簡潔ビットベクトルを扱うC++ライブラリを書いてみました。

GitHub - hideo55/cpp-HSDS: Succinct Data Structure Library Collection.Includes bit-vector/wavelet-matrix/trie.

簡潔データ構造とは?

簡潔データ構造とは、データ構造を最適に近いサイズで保存しつつ、インデックスを利用して高速な操作を実現するデータ構造のことです。

簡潔ビットベクトルとは?

完備辞書(Fully Indexable Dictionary, FID)とも呼ばれます*1
簡潔ビットベクトルはビットベクトルに対する簡潔データ構造で、ビットベクトルに対して以下の操作が可能なデータ構造のことを指します。

  • access(i): ビットベクトルのi番目の値を返す
  • rank(i): 先頭からi番目までの1(または0)の数を返す
  • select(i): i番目に出現する1(または0)の位置を返す

簡潔ビットベクトルは他の簡潔データ構造の基礎となるものなので、簡潔ビットベクトルの性能が簡潔データ構造の性能を左右します。

作ったライブラリについて

marisa-trie における rank/select の実装 - やた@はてな日記

この辺を見て作ったので、rank辞書、select辞書も持ち方などmarisa-trieの簡潔ビットベクトルと似た実装になっています。
大きな違いは以下の通りです。

CMake

ビルドツールとしてAutotoolsではなくCMakeを使用しています。

64-bit整数を使用

marisa-trieの簡潔ビットベクトルでは32-bit 環境における性能の劣化を防ぐために64-bit 整数を使用してしませんが、自分で使う環境は64-bit環境なので64bit整数を使っています。

std::vectorを使用

marisa-trieの簡潔ビットベクトルでは独自のベクトル型コンテナクラスを使っていますが、HSDSで必要とする機能にはstd::vectorで十分だったため、std::vectorを使っています。

値のセット方法

marisa-trieでは、値のセットはpush_back()で末尾に追加する形になりますが、HSDSではset()によって任意の位置に値をセットできます。

mmap非対応

marisa-trieはmapper()というインタフェースでファイルに保存した簡潔ビットベクトルにmmapによるアクセスができるようになっていますが、HSDSは現在は対応していません。

使用方法

インストール
$ git clone git://github.com/hideo55/cpp-HSDS.git
$ cd cpp-HSDS
$ cmake .
$ make && make install
コード
#include "hsds/bit-vector.hpp"

using namespace hsds;

void main(){
    BitVector bv;
    bv.set(0, true);
    bv.set(100, true);

    bv.build();

    uint64_t pos = bv.select1(0)// 0;
    pos = bv.select1(1)// 100;
    pos = bv.select0(0)// 1;
}
ビルド
$ g++ foo.cpp -o foo -lhsds-bitvector

APIに関しては、以下のDoxygenで生成されたドキュメントを参照下さい。
APIドキュメント

ベンチマーク

ux-trie、marisa-trieと共にベンチマークを行った結果は以下にまとめてあります。

簡潔ビットベクトル-ベンチマーク結果

HSDSとmarisa-trieのrank、selectはほぼ同等の速度でした。getはmarisa-trieが桁違いに速いですが、marisa-trieこれはデバッグビルド以外では引数のチェックをしないようになっているためで、HSDSでも引数チェックをコメントアウトして試してみたところ、marisa-trieと同等の速度になりました。

Doxygenで生成したドキュメントをGitHub Pagesで手軽に公開する方法

以前にもやったのにやり方忘れて調べ直したので、メモっときます。

gh-pagesブランチを作成

以下のコマンドでgh-pagesブランチを作成します。

$ git checkout --orphan gh-pages

--orphanオプションで空の一切履歴のないブランチができます。

以前は以下のようなことをやっていたのですが、だいぶ楽になりました。

$ git symbolic-ref HEAD refs/heads/gh-pages
$ rm .git/index
$ git clean -fdx

Creating Project Pages using the command line - GitHub Help

gh-pagesをGitHubにpush

空のブランチだとpush出来ないので適当なファイルをコミットしてからpushします。

$ echo "My GitHub Page" > index.html
$ git add index.html
$ git commit -a -m "First pages commit"
$ git push origin gh-pages

gh-pagesをsubmoduleにする

masterブランチに戻って、gh-pagesブランチをsubmoduleにします。
ここではdocsというサブディレクトリをしていしています。

$ git co master
$ git submodule add -b gh-pages `git remote -v|grep origin|head -n 1|awk '{print$2}'` docs

doxygenでドキュメントを生成

doxygenの設定(デフォルトではDoxyfile)のHTML_OUTPUTで docs/ を指定して、ドキュメントを生成します。

$ doxygen
$ cd docs
$ git add .
$ git ci -m 'Updated docs'
$ git push origin gh-pages
$ cd ..
$ git add docs/
$ git ci -m 'Updated docs'

このコマンドは適当に自動化しておけばいいと思います。

CMakeでSSEが使えるか調べる

CMakeで、その環境でSSE命令が使えるかどうかを調べるモジュールを作りました。ベースはこれですが、マクロ化、SSE4.2対応、-msse4.1やーmsse4.2を使えないgcc 4.3未満の場合の対応を追加してます。

あとは、CMakeLists.txtで以下のようにすればOKです。

INCLUDE(FindSSE)
FindSSE ()
IF(SSE4_2_FOUND)
    SET(SSE_DEFINITIONS -DUSE_SSE4_2 -msse4.2)
ENDIF(SSE4_2_FOUND)