mojavy.com

組み込み用プログラミング言語のパフォーマンス比較

Tue, 21 Apr 2015 01:10:40 JST

組み込み用のプログラミング言語といえばLuaがよく使われるけど、最近はmrubyやsquirrelもあって選択肢が広がってきた感があるのでどういう特徴があるのかを知るためにベンチマークをやってみた。

今回対象にしたのは以下。

Lua - v5.1
LuaJIT - v2.0.2
squirrel - v3.0.7
V8 - v3.30
mruby - v1.1.0
ecl (Embeddable Common-Lisp) - v15.3.7

ここでのベンチマークは言語自体のスピードの比較ではなく、どちらかというと組み込む際に必要なオーバーヘッドやホスト言語側での処理にかかる部分に重点を置いた。

ベンチマークの処理では、関数呼出し比較用のecho関数と、テーブル操作比較用のinvert関数を組み込み言語側に実装して、それを繰り返し呼び出すようにした。

また、なるべく公平になるように、組み込み言語側の関数は初期化時にグローバルスコープ(組み込み言語側のグローバルスコープ)に登録しておき、すべて同じインターフェースから呼ぶようにした。

使用したコードは以下。そのうち別の言語とか追加するかもしれない。

https://github.com/taksatou/embench

結果

echo 100000 回実行

invert 100000 回実行

https://gist.github.com/taksatou/8de85bbfe79548864cf5#file-result-md

備考

control は同等の処理をホスト言語側で実装したもの
LuaJITはLD_PRELOADで切り替えた
eclはechoが遅くてやるきを失ったのでinvertのほうは省略

所感

Luaがパフォーマンスと組み込みやすさの点でやはり一番使いやすい。LuaJITをつかうとさらに数割速くなる。
squirrelは言語機能的にはluaのスーパーセットという感じで、パフォーマンスもluaと同じ程度。ただしドキュメントはあまりない。
V8はマルチスレッド環境や大規模なものには向いてるかもしれない。組み込みはちょっとめんどくさい。
mrubyはechoだと意外と健闘しているがテーブル操作は速くない。組み込みはLuaと同じくらい簡単。
eclにはもうちょっとがんばってほしい。組み込み方法に問題があるのかもしれない。

Phabricatorを使ったワークフローについて

Mon, 02 Mar 2015 20:55:43 JST

最近 Phabricator を使ったワークフローを試しています。FacebookやDropboxをはじめとして海外では割と良く使われているようですが、あまり国内には情報がないようなのでまとめておきます。

Phabricatorでできること

Phabricatorはコードレビューがメイン機能のようですが、それに留まらずソフトウェアの開発で必要なものがワンストップでまとまったプロジェクト管理ツールになっています。

メニューのネーミングが独特でとっつきづらいですが、主に以下のような機能があります。

Differential: pre push型のコードレビュー
Audit: post push型のコードレビュー
Maniphest: タスクとバグの管理
Diffusion: リポジトリの管理
Harald: commitやタスクの更新イベントにフックして起動する処理の管理
Phriction: Wiki

また、arcanist というコマンドラインから操作するためのツールも別途提供されており、開発のワークフローも含めた統合が意図されているようです。

セットアップ

docker環境があるなら docker run yesnault/docker-phabricator ですぐ試せます。

https://registry.hub.docker.com/u/yesnault/docker-phabricator/

ただし、上記dockerfileから構築したコンテナはデフォルトだとメールは外部に送信できない設定になっています。admin以外のユーザ登録ではメールアドレス認証が必要なので、docker exec -it bash でコンテナに入ってメール設定を適宜修正して下さい。

dockerを使わずに普通にインストールする場合は https://secure.phabricator.com/book/phabricator/article/installation_guide/ を参照してください。

起動直後は色々設定を聞かれますが、特につまるようなところはないので省略します。

Phabricatorでのコードレビュー

pre-push型のコードレビュー (Differential)

pre-push型のコードレビューは、フロー的にはGithubでのPull Requestに似ていますが、レビュー対象のcommitをpushするのではなく、パッチを送る点が異なります。Phabricatorでは以下のようなフローで作業することになります。

コードを修正した人(author)は、レビュワー(reviewer)を指定して変更内容をDifferentialに登録する
reviewerは通知を受けてレビューをする
reviwerがacceptしたら、authorはupstreamにpushする

diffをPhabricatorにコピペして登録することもできますが、基本的にはarcanist経由で作業することになります。

PhabricatorのUser GuideにはDifferentialの良さが長々と書かれてますが、実際のところ、長所として挙げられている項目はどれもPull Requestベースでも達成できます。ただ、Defferentialとarcanistを使えば簡単にレビュー依頼が投げられるので、開発者が自発的に適切な粒度でレビュー依頼する助けにはなりそうです。

post-push型のコードレビュー (Audit)

Differentialではレビューが完了するまでpushを待つ必要がありますが、Auditはレビューを待たずにpushしてその後にレビューを実施するための機能です。

例えば、急いでリリースする必要がある場合でも、Auditを用いてあとからレビューすることができます。このときに問題が見つかればProblem Commitsというフラグをたてておいてタスクに積む、というような使い方になるようです。

Haraldという機能を使えば特定の条件に合致するcommit(例えば変更が大きい、Differentialでレビューされていない、等)があった場合は自動的にAuditを生成させることもできます。

Auditをpull requestのように使うこともできますが、推奨はされていないようです。

所感

もし開発管理のためにredmineやjiraをつかっているのであればPhabricatorは良い代替になりそうです。開発者向けに特化してる分、プロジェクトのタスクやバグ管理がソースコードとうまく統合されていて、ダッシュボードも柔軟にカスタマイズできます。githubのissueに不満を感じている人もPhabricatorのワークフローは試してみる価値があると思います。

レビューツール単体としてみると、(Differentialをつかうなら)開発者にarcanistの導入をしてもらう必要がある分、Pull Requestの手軽さに比べるとやや煩雑に感じました。既にPull Requestベースの開発が定着していて、単によりよいレビューツールを探しているのであればGerrit 等のほうが導入しやすいかもしれません。

その他

https://showoff.phab.io/ でデモPhabricatorが使えるので一通り試せます。
デフォルトではかなりの頻度でリポジトリに対してポーリングしに行きます。負荷をかけ過ぎないように注意が必要です。
Phabricator自体もそれなりの性能のマシンが必要です。環境によってはworker数を減らしたりmysqlのメモリサイズを調整しておく必要があります。

参考

C++のdreaded diamondについて

Wed, 09 Jul 2014 21:56:32 JST

以下のようなダイアモンド継承をしたときに発生する問題のことをdreaded diamondと呼ぶらしい。

    Base
    /  \
   D1  D2
    \  /
     D3

例えば以下のようなクラスではアップキャストをするときやBaseクラスのメンバにアクセスするときに曖昧性が生じる。

class Base {
public:
    int data;
    virtual ~Base() {}
};

class D1 : public Base {
public:
    virtual ~D1() {}
};

class D2 : public Base {
public:
    virtual ~D2() {}
};

class D3 : public D1, public D2 {
public:
    virtual ~D3() {}
};

以下のようなコードをコンパイルしようとしてもエラーになる。

void f1() {
    D3 d3;
    Base &base = d3;
    d3.data = 123;
}

      ambiguous conversion from derived class 'D3' to base class 'Base':
    class D3 -> class D1 -> class Base
    class D3 -> class D2 -> class Base
    Base &base = d3;
                 ^~

      non-static member 'data' found in multiple base-class subobjects of type 'Base':
    class D3 -> class D1 -> class Base
    class D3 -> class D2 -> class Base
    d3.data = 123;
       ^

これを回避するためには明示的に中継するクラスを指定してやる必要がある。

void f2() {
    D3 d3;
    Base &base = dynamic_cast<D1&>(d3);
    d3.D1::data = 123;
    d3.D2::data = 456;

    cout << d3.D1::data << ',' << d3.D2::data << endl;  // => 123,456
}

でも普通は継承元にそれぞれの別々の親を持つのではなく、共通の1つだけを持っていてほしい。それを解決するには仮想継承を使う。

class D1 : public virtual Base { /* 省略 */ };
class D2 : public virtual Base { /* 省略 */ };
class D3 : public D1, public D2 { /* 省略 */ };

このようにすればBaseクラスのインスタンスは1つだけになって曖昧性が解消される。

void f3() {
    D3 d3;
    Base &base = d3;
    d3.data = 123;

    cout << d3.D1::data << ',' << d3.D2::data << endl;  // => 123,123
}

pthreadの取り消しポイント(cancellation point)についてのメモ

Tue, 18 Mar 2014 21:41:12 JST

cancellation pointsとは、スレッドのキャンセル種別がdeferredのときに、そこに到達したときにはじめて実際にそのスレッドのキャンセル要求が処理されるような関数のこと。

POSIX.1では、基本的にはブロックするような関数がcancellation pointsであることが要求されている。

参考

malloc+memsetとcallocの違いについて

Wed, 05 Mar 2014 21:25:23 JST

mallocとcallocの違いは、表面的には引数の数とcallocは確保した領域を0で初期化するという点くらいですが、以下のコードを大きなnで実行すると、今時のOSだとmalloc + memsetのほうが大幅に遅くなる可能性があります。

void *p = malloc(n * sizeof(type));
memset(p, 0, n * sizeof(type));

void *p = calloc(n, sizeof(type));

カーネルはセキュリティ上の理由からメモリを0で初期化してからユーザプロセスに渡します。

しかし、仮想メモリをサポートしたシステムでは、実際にそのメモリに書き込みが発生するまでカーネルはread onlyな領域を複数プロセスで共有させることができるため、既に初期化してあるページであればこの処理を省略できる場合があります。

brkで拡張した領域は0で初期化されているので、callocは新規確保した領域は初期化を省略することができ、結果的にcallocを実行したタイミングでは初期化が実際にはほとんど発生しない、ということがありえます。

一方memsetの場合は実際にメモリへの書込みが発生する上、ページの共有もできなくなるためswapする可能性もあります。

ちなみに、(カーネルではなく)calloc自身が0初期化する処理と、memsetの処理は微妙に違います。なぜなら、memsetは対象の領域がアラインされているかどうかについての情報なしに処理する必要があるので、境界部分は1byteずつやるしかありません。

じゃあmemsetのほうが遅いのかというと、コンパイラによってはアラインされていることを推測できる場合もあったり、callocはライブラリ関数なので移植性のために最適化しにくかったりするので、結局のところ微妙です。

参考： http://stackoverflow.com/questions/2688466/why-mallocmemset-is-slower-than-calloc

スレッドプールの実装方法について

Mon, 03 Mar 2014 20:58:58 JST

スレッドプール(thread pool)を実装するには、暇なときはthreadを寝かせておいて必要なときに起こす、というイベント通知の仕組みが必要になる。 UnixでC/C++で実装するときはpthreadの条件変数を使うのが普通だと思われるが、適当なファイルディスクリプタをopenしておいてread等でブロックさせる方法でも実装できそう。

どのようなやり方が一般的なのか、いくつか有名どころのOSSの実装を調べてみた。

libuvの場合

https://github.com/joyent/libuv

単純にpthread_cond_waitをつかっている ¹

static void worker(void* arg) {
  struct uv__work* w;
  QUEUE* q;

  (void) arg;

  for (;;) {
    uv_mutex_lock(&mutex);

    while (QUEUE_EMPTY(&wq))
      uv_cond_wait(&cond, &mutex);

    q = QUEUE_HEAD(&wq);

    if (q == &exit_message)
      uv_cond_signal(&cond);
    else {
      QUEUE_REMOVE(q);
      QUEUE_INIT(q);  /* Signal uv_cancel() that the work req is
                             executing. */
    }

    uv_mutex_unlock(&mutex);

    if (q == &exit_message)
      break;

    w = QUEUE_DATA(q, struct uv__work, wq);
    w->work(w);

    uv_mutex_lock(&w->loop->wq_mutex);
    w->work = NULL;  /* Signal uv_cancel() that the work req is done
                        executing. */
    QUEUE_INSERT_TAIL(&w->loop->wq, &w->wq);
    uv_async_send(&w->loop->wq_async);
    uv_mutex_unlock(&w->loop->wq_mutex);
  }
}

Boost.Asioの場合

http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio.html

Boost.Asioにスレッドプールそのものは提供されてないが以下のようにして簡単に実装することができる

#include 
#include 
#include 

int main ( int argc, char* argv[] ) {
    asio::io_service io_service;
    asio::io_service::work work(io_service);

    std::vector<std::thread> threadPool;

    for(size_t t = 0; t < std::thread::hardware_concurrency(); t++){
        threadPool.push_back(thread(std::bind(&asio::io_service::run, &io_service)));
    }

    io_service.post(std::bind(an_expensive_calculation, 42));
    io_service.post(std::bind(a_long_running_task, 123));

    //Do some things with the main thread

    io_service.stop();
    for(std::thread& t : threadPool) {
        t.join();
    }
}

http://stackoverflow.com/questions/14265676/using-boostasio-thread-pool-for-general-purpose-tasks

長くなるのでコードは省略するが、io_service::postするとunixの場合は最終的にはtask_io_service::wake_one_idle_thread_and_unlockからpthread_cond_signalが呼ばれる。

memcachedの場合

https://github.com/memcached/memcached

libeventのイベント通知機能を利用して実装している。それぞれのthread初期化の際にpipeをつくって、そのfdをlibeventに渡す。 ² libevent内部でそのfdをepollなりkqueueなりでブロックして待つ。

//
// memcached.c
//
typedef struct {
    pthread_t thread_id;        /* unique ID of this thread */
    struct event_base *base;    /* libevent handle this thread uses */
    struct event notify_event;  /* listen event for notify pipe */
    int notify_receive_fd;      /* receiving end of notify pipe */
    int notify_send_fd;         /* sending end of notify pipe */
    struct thread_stats stats;  /* Stats generated by this thread */
    struct conn_queue *new_conn_queue; /* queue of new connections to handle */
    cache_t *suffix_cache;      /* suffix cache */
    uint8_t item_lock_type;     /* use fine-grained or global item lock */
} LIBEVENT_THREAD;

//
// thread.c
//
void thread_init(int nthreads, struct event_base *main_base) {
//
// 中略
//
    threads = calloc(nthreads, sizeof(LIBEVENT_THREAD));
//
// さらに中略
//
    for (i = 0; i < nthreads; i++) {
        int fds[2];
        if (pipe(fds)) {
            perror("Can't create notify pipe");
            exit(1);
        }

        threads[i].notify_receive_fd = fds[0];
        threads[i].notify_send_fd = fds[1];

        setup_thread(&threads[i]);
        /* Reserve three fds for the libevent base, and two for the pipe */
        stats.reserved_fds += 5;
    }

    /* Create threads after we've done all the libevent setup. */
    for (i = 0; i < nthreads; i++) {
        create_worker(worker_libevent, &threads[i]);
    }

    /* Wait for all the threads to set themselves up before returning. */
    pthread_mutex_lock(&init_lock);
    wait_for_thread_registration(nthreads);
    pthread_mutex_unlock(&init_lock);
}

pthread_cond_waitの実装

脱線するが、pthread_cond_waitがどのようにsleepにはいってるのか気になったので調べた。

https://sourceware.org/git/?p=glibc.git;a=tree;f=nptl;hb=HEAD

pthread_cond_waitのソースコードはglibcのnptl以下にある。 __pthread_cond_waitがlll_futex_waitを呼んでおり、これは以下のように実装されている。(以下はx86_64のもの)

#define lll_futex_wait(futex, val, private) \
  lll_futex_timed_wait(futex, val, NULL, private)

#define lll_futex_timed_wait(futex, val, timeout, private) \
  ({                                         \
    register const struct timespec *__to __asm ("r10") = timeout;          \
    int __status;                                \
    register __typeof (val) _val __asm ("edx") = (val);                \
    __asm __volatile ("syscall"                            \
             : "=a" (__status)                         \
             : "0" (SYS_futex), "D" (futex),                 \
           "S" (__lll_private_flag (FUTEX_WAIT, private)),         \
           "d" (_val), "r" (__to)                    \
             : "memory", "cc", "r11", "cx");                 \
    __status;                                    \
  })

上記アセンブラは大体以下のような意味³

futex(futex, FUTEX_WAIT, val, timeout, NULL, 0);  // 便宜上、上記コードの引数の変数名をそのままつかっているが、
                                                  // 1つめのfutexはシステムコールのfutexで、
                                                  // 2つめは引数のpthread_cond_tの__futexメンバ変数のアドレス

futex() システムコールは、指定したアドレスの値が変更されるのをプログラムが待つ手段や特定のアドレスに対して待機中のプロセスを wake (起床) させる手段を提供する

futex(2) http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/futex.2.html

とのこと。

まとめ

pthread_cond_waitをつかったもののほうが普通は高速なはず
memcachedのようなやりかただとユーザプロセス側でスレッドプール管理のための排他制御がほとんど不要になるので多少実装が簡単か

pthread_cond_waitはunixの場合。windowsの場合はpSleepConditionVariableCS、これが使えない場合は疑似的に同様の動作をするようなラッパを定義している。 ↩
memcachedでは使用してないが、libeventはシグナルを通知する際もfdをつかう。Boost.Asioもシグナル通知はpipeを経由する。 ↩
厳密には違う。 ↩

オーバーフローしにくい組み合わせの数の計算方法

Thu, 17 Oct 2013 21:13:58 JST

Cで組み合わせの数を計算するときに定義通り計算するとすぐにオーバーフローしてしまう。例えば以下のような実装だと、程度でも結果がおかしくなってしまう。

#include 

using namespace std;

uint64_t fac(uint64_t n) {
    if (n > 1)
        return n * fac(n-1);
    else
        return 1;
}

uint64_t combinations(uint64_t n, uint64_t k) {
    return fac(n) / (fac(k) * fac(n-k));
}

int main(int argc, char *argv[]) {
    cout << combinations(5, 3) << endl; // => 10
    cout << combinations(10, 5) << endl; // => 252
    cout << combinations(20, 10) << endl; // => 184756
    cout << combinations(30, 15) << endl; // => 0 !?
    return 0;
}

とりあえず素因数分解してやれば解決するのでいままでそうしてたのだけど、もっとかっこいい方法がないものかと思って探してみたらKnuth先生の本で以下のようなアルゴリズムが紹介されているらしい。¹ これはかっこいい。

uint64_t combinations2(uint64_t n, uint64_t k) {
    uint64_t r = 1;
    for (uint64_t d = 1; d <= k; ++d) {
        r *= n--;
        r /= d;
    }
    return r;
}

int main(int argc, char *argv[]) {
    cout << combinations2(30, 15) << endl; // => 155117520
    cout << combinations2(60, 30) << endl; // => 118264581564861424

    cout << combinations2(64, 32) << endl; // これはオーバーフローする
    return 0;
}

結果の値が範囲内ならオーバーフローしないのか、というとそういうわけではないけどナイーブな実装に比べるとずっと計算できる範囲が広いので、値のレンジがあらかじめわかっているのであればこれで十分ですね。

http://stackoverflow.com/questions/1838368/calculating-the-amount-of-combinations 残念ながらvol2は手元にはない ↩

C言語でtuple

Wed, 10 Jul 2013 21:02:39 JST

Cをつかってるとtupleっぽいものがあれば便利なのに、と思うときが時々あります。

別にtupleなんてなくても

typedef struct {
   char *s;
   int *i;
} tuple;

のようにして構造体をつかえばいいのですが、必要になるたびにこれをするのはちょっとめんどくさいですよね。

というわけで色々試行錯誤してみたところ、以下のようにしてunionの配列にするというのがそこそこ便利だったので紹介します。

以下は使用例です。

#include 

typedef union {
    void *p;
    char *s;
    int i;
    char c;
} tuple_u;
typedef tuple_u tuple[2];

int main(int argc, char *argv[]) {
    tuple t = { { .s = "hoge" }, { .i = 123 } };

    printf("%s, %d\n", t[0].s, t[1].i);
    return 0;
}

C99のdesignated initializerをつかえば初期化もまあそこそこ書きやすいし、型の組み合わせもある程度柔軟にできます。

C++ではなくあえてCをつかうような人の多くは独自のコンテナライブラリのようなものをもってると思いますが、上記のようなtupleがあれば便利な場面は結構あるのではないかと思います。

The P Convention

Sun, 24 Feb 2013 14:42:00 JST

Lispには'p'という接尾辞がつく名前の関数があるが、この'p'はpredicateのこと。

The -P Convention

ところが、HaskellやOCamlにも'p'という接尾辞がつく関数があって、そちらはprimeの意味で使うらしい。シングルクオート(ダッシュ)記号は英語だとprimeというので、例えばfoo'という名前の関数はfooという名前のヘルパー関数的なもの、ということになる。

“foop”: a naming convention? It's a helper recursive function for “foo”; what does the suffix “p” mean?

ちなみに、OCamlだとシングルクオートが識別子につかえるのでfoo'という名前の関数も結構あるらしい。

まぎらわしい、かと思ったけど使う文脈が違うし意外とそうでもないか。