最適化するのに相応しいサブルーチンのみ最適化できるように，optimizer::hotspotというモジュールを考えてみた。まだCPANクオリティではないのでgithubのみ。

• http://github.com/gfx/Perl-optimizer-hotspot

仕組みとしては，PL_peeppをフックして，生成されるサブルーチンの頭にホットスポット計測のためのopcode*1を仕込み，そのopcodeが一定数呼ばれると，最適化器*2を起動するというものだ。

最適化の基本は，いまのところ特定パターンをもつ構文木を高速な一つのノードに置き換えるというもの。少し実装してみたところ，以下のような結果となった。

benchmarks/arbit.pl

# 's' represents 'single-threaded'
$ sperl -Mblib benchmarks/arbit.pl
Perl/5.10.1 on i686-linux
           Rate     plain optimized
plain     489/s        --      -39%
optimized 797/s       63%        --

以上，Perlを63%高速化することができた。

.

.

.

もちろん，これで済むほど話は簡単ではない。このベンチマークは恣意的なもので，ベンチマークスクリプトは非常に不自然なコードである。もう少しまともなbenchmark/math.plを実行すると，効果は誤差の範囲内でしかないことがわかる。

ホットスポットを検出して最適化器を起動する，というところまではいいが，そこから先の最適化についてはもう少しいい方法を考えないと使い物にならないのではないかと思う。

特定パターンを検出する方法は，まずパターンの検出が大変すぎるし，この調子でパターンを増やしたとしても所詮ヒューリスティクスによる小手先の最適化にすぎず，アプリケーションレベルで+10%達成できれば御の字だろう。

ということを考えると，プロファイラでボトルネックを探してその部分をXS化するほうがずっと簡単だ。

Perlコアの最適化をまとめておく。

まず，opcodeの最適化を主に行っているのは，op.cのPerl_peep()である。ただし，これは最適化以外の処理，たとえばuse strict 'subs'の下でベアワードに対して致命的エラーを投げる，なども行っている。

さて，Perl_peep()の最適化はだいたい以下の3パターンである。

• 不要なopcodeを削除
  • opcodeを構築する際につかわれる，op_stubやop_nullなどのスタブノード
  • op_scalar*1など，実質的な意味を持たないopcode
• よくあるopcodeパターンを一つにまとめる
  • "reverse sort LIST"において，op_sortの逆順ソートビットを立ててop_reverseを消す*2
  • $arrary[10]などの定数添え字が小さな定数の場合，op_aelemfastに変換してopcodeに添え字を埋め込む
• データに細工を施す
  • $hash{foo}などの定数キーをShared SVに変換する

このうち，頻出するopcodeパターンを一つにまとめる方法は実装も試験も容易であり，いろいろ試してもいいかもしれない。その場合，「頻出するopcodeパターン」を探すようなプロファイラをまず書く必要があるだろう。

また，現状の最適化器は本格的なコンパイラが行うようなアグレッシブなコード書き換えは行っていないので，それを考慮すると試せることはまだ沢山あるように思う。

元ネタ：Perl基礎文法最速マスター(id:perlcodesample)

XSを始めるための手順といくつかの要素の解説です。C言語をある程度知っている人でも，これを読んだだけでXSの基礎をマスターしてXSを書くことができるようにはなっていません。リファレンスでもありません。

XSとは，狭義ではPerlでエクステンションを書くためのマクロ言語の名前ですが，広義ではエクステンションを書くための技術の総称です。ここでは，広義のXSを俯瞰します。

XSはいろいろと特殊なのでテンプレは無視で行きます。

目次：

1. h2xsで空のディストリビューションを作る
2. XSファイルの構成
3. スレッドコンテキスト
4. SVファミリ
5. GCとスコープ
6. さらなる学習のために

h2xsで空のディストリビューションを作る

以下のコマンドで空のXSディストリビューションを作ることができます。

h2xs -A -b 5.8.1 -n Foo::Bar

ディストリビューションを作るためのモジュールはModule::Starter, Module::Setupなどもありますが，最初はh2xsで十分でしょう。なによりインストールの必要がありません。

ディストリビューションを作ったら，その中のディレクトリに移動してとりあえずビルドしてみます。

cd Foo-Bar
perl Makefile.PL
make && make test

これがうまくいかなければコンパイラをセットアップする必要がありますが，省略します。WindowsならStrawberry PerlやCygwinを使うのがお勧めです。

次の節に進む前に，XSファイルの先頭，Perlのヘッダファイルをインクルードする前に，"#define PERL_NO_GET_CONTEXT"という行を追加しておきましょう。これはスレッドコンテキストと関係があるのですが，とりあえずオマジナイと考えてかまいません。また，XSセクションには"PROTOTYPES: DISABLE"という行を加えておきましょう。この行がないとXSUBに自動的にプロトタイプがついてしまい，予想外の挙動を招くことになります。

XSファイルの構成

一つのXSファイルはCセクションとXSセクションに分かれています。CセクションはC言語そのもので，モジュールのユーザーからは見えません。XSセクションでXSUBを書き，これはモジュールのユーザーから見えます。

たとえば，以下のようになります。

#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include "ppport.h"

=pod

C section

=cut

MODULE = Foo::Bar		PACKAGE = Foo::Bar	

PROTOTYPES: DISABLE	

=pod

XS section

=cut

void
hello()
CODE:
{
    PerlIO_stdoutf("Hello, world!\n");
}

これは，以下のコマンドで実行できます。

make
perl -Mblib -MFoo::Bar -e 'Foo::Bar::hello()'

なお，上の例が示すように，セクションにかかわらず任意の場所にPODを書くことができます*1。

スレッドコンテキスト

Cセクションにいろいろ書くつもりがなければ，この節の内容は特に必要ありません。

スレッドコンテキストとは，Perlインタプリタレベルでのグローバル変数を持っている構造体で，ほとんどすべてのPerlAPIの最初の引数として渡すものです。ただし，ほとんどすべてのPerlAPIは，このことを意識しなくてすむようにマクロでラップしてあります。

このことを意識しなければならないのは，Cセクションに関数を書くときです。

このとき，自分の関数についても，PerlAPI と同じように最初の引数にスレッドコンテキスト渡すようにしないと，その関数の内部でPerlAPIが使えません。

スレッドコンテキストの宣言にはpTHX*2/pTHX_*3を使います。API の呼出には aTHX/aTHX_ を使います。

/* in C section */
static void
hello(pTHX) {
    PerlIO_stdoutf("Hello, world!\n");
}

/* IV: Integer Value */
static void
increment(pTHX_ SV* const sv) {
    sv_inc(sv); /* 実際には Perl_sv_inc(aTHX_ sv) に展開される */
}

MODULE = Foo::Bar		PACKAGE = Foo::Bar	

void
hello()
CODE:
{
    hello(aTHX);
}

void
increment(SV* sv)
CODE:
{
    increment(aTHX_ sv);
}

特定のプロトタイプが必要なコールバックなどではスレッドコンテキストを受け取れないことがありますが，その場合は関数の最初で dTHX; 宣言をすることにより，スレッドコンテキストを定義することができます。

SVファミリ

Perlのデータは，CレベルではSV*(スカラー)，AV*(配列)，HV*(ハッシュ)などで表現されますが，これらすべてはSV*の派生クラスと考えられます。つまり，SvTYPE() や SvREFCNT_inc()/SvREFCNT_dec() などのAPIは，その引数としてどのSVファミリでも受け取れるようになっています。以後，単にSVと書くときは，SVファミリのことと考えてください。

SVファミリを操作するためのAPIの数は多いので紹介はしませんが，一般に，スカラー値であれば sv_*4/Sv*5 というプレフィクスを持ち，同様に配列では av_/Av，ハッシュでは hv_/Hv というプレフィクスを持つので，ソースコードを読むときには頭に入れておくといいでしょう。

なお，SVファミリの具体的な挙動については，perldoc perlapiを参照してください。

GCとスコープ

Perlはリファレンスカウントベースのガベージコレクション機構を持っています。また，スコープと揮発性(mortality)という概念で，XSレベルでもリファレンスカウントの管理を自動化できるようになっています。

XSにおけるスコープは，Perlレベルでのスコープと同じです。これは，ENTER; SAVETMPS; というマクロで開き，FREETMPS; LEAVE; というマクロで閉じます*6。

そして，このスコープの中であるSVを揮発性にすると，そのSVのリファレンスカウントは，そのスコープを抜けるときに一つ減ります*7。この処理はスコープの中で例外が起きたときでもきちんと行われるので，手動でリファレンスカウントを減らすよりも安全です。SVを揮発性にするには，sv_2mortal()を使います。初めから揮発性のSVがほしいときは，sv_newmortal()が，SVの揮発性コピーがほしいときはsv_mortalcopy()を使います。

/* in C section */
static void
foo(pTHX) {
    SV* sv;
    ENTER;
    SAVETMPS;

    sv = sv_newmortal();
    sv_setpvs(sv, "Hello, world!\n");
    PerlIO_stdoutf("%"SVf, sv); /* -> "Hello, world!" */

    FREETMPS;
    LEAVE;
    /* ここでsvはすでに解放されている */
}

SvREFCNT_inc()とSvREFCNT_dec()でリファレンスカウントを手動で操作することもできますが，慣れないうちは手動で操作する代わりにsv_mortalcopy()とスコープメカニズムを使ったほうが安全です。

なお，すべてのXSUBは呼び出されるときにスコープで囲まれます。また，XSUBからの戻り値は揮発性のSVでなければならないという呼出規約があります*8。したがって，XSUBからSVを直接返す時は，必ずsv_2mortal()で揮発性にしましょう。

sv_2mortal()を掛けすぎると，Perlインタプリタが「不正にSVの解放が行われた」と文句を言ってくれますが，メモリリークについてはインタプリタは文句を言いません。したがって，不安だったらsv_2mortal()するように習慣づけておくと安全です。

さらなる学習のために

以上，XSを俯瞰しましたが，実際にXSを一から書くのは大変です。いくつかのXSモジュールを実際に読んでみたり，改造してみたり*9することをお勧めします。

Scalar-List-UtilsのXSセクションは比較的理解しやすいのではないかと思います*10。

また，Perl自身のソースコードは，その時の最新の PerlAPI *11に則って書かれているため，最良の教科書です。sv.c，av.c，pp_hot.c，universal.c は比較的読みやすく，重要性も高いのでお勧めです。細かな挙動について知るためにはPerlのソースコードを参照するしかないことも少なくなく，XSを書くならPerlソースコードを手元に置いておくのは必須といえます。

See also:

• perlxstut(ja) - XS のチュートリアル
• perlxs(ja) - XS のリファレンス
• perlapi(ja) - PerlAPI のリファレンス
• perlguts - Perl の内部構造(データ編)
• perlhack - Perl の内部構造(インタプリタ編)
• perlclib - Cライブラリの代替API

Enjoy XS!

プログラミングについての雑記(id:perlcodesample)

プログラミングが上達するコツは簡単なプログラミングをできるだけたくさん書いて実行することです。本やインターネットを読むだけではプログラミングは上達しません。読むのは3割、書くのが7割ぐらいになるとちょうど良いのではないかと思います。もしプログラムの意味がわからない場合は丸写ししてプログラムの動きをみてください。たくさん書いているうちに次第にわかってくるようになります。

前半には異論はありません。しかし，意味がわからないまま丸写しすること，いわゆる「写経」は一般に薦められてますが，私はあまり効果がないんじゃないかと思ってます。というより，面白くないから続かないんじゃないでしょうか。しかも，何も新しいことを生み出さないじゃないですか，写経って。しかも，最近の書籍だと大抵実行可能なサンプルコードが付いてますから，写経が終わっても達成感がありません。

私はむしろ，あるコードを別の言語の等価コードに移植することが上達への近道だと思っています。元のコードの言語に精通している必要は必ずしもなく，移植先の言語とともに初心者レベルで構いません。いずれにせよ，移植するためにはコードの中身を理解する必要に迫られますから。移植は写経よりも面白い，というのもいいですね。

アルゴリズムのテキストから好きなアルゴリズムを選び，それを学習したい言語で実装する，というのも同じパターンです。

"Perl Best Practices" recommends to use "return;"*1 to return nothing, but it might be wrong in some cases. If you use this idiom for those functions which are expected to return a scalar value, e.g. searching functions, the user of those functions will be surprised at what they return in list context, an empty list - note that many functions and all the methods evaluate their arguments in list context. You'd better to use "return undef;" for such scalar functions.

『Perlベストプラクティス』は名著だが，中には奨励できないプラクティスもある。「無効値を示すためには"return;"を使用せよ」というのもその一つだ。"return;"を使うと，そのサブルーチンはリストコンテキストでは空リストを返すのだが，下記のコードのように，スカラーを返すべきサブルーチンで空リストを返すと予想外の振る舞いをとることがある。このようなことを避けるため，スカラー値を返すべきサブルーチンでは，"return;"ではなく"return undef;"を使ったほうがよい。

sub search_something {
    my($arg) = @_;
    # search_something...
    if(defined $found){
        return $found;
    }
    return; # XXX: you'd better to "return undef;"
}

# ...

# you'll get what you want, but ...
my $something = search_something($source);

# you won't get what you want here.
# @_ for doit() is (-foo => $opt), not (undef, -foo => $opt).
$obj->doit(search_something($source), -option=> $optval);

# you have to use the "scalar" operator in such a case.
$obj->doit(scalar search_something($source), ...);