＜Windowsネタ＞Windows Subsystem for Linux はマルチスレッド対応なのか

Bash はマルチスレッド対応？

Windows で bash が使えるようになってから久しい。 実は mac で事足りていたのであんまり使ったことがなかった。 今回、mac の調子が悪く、新しいものを購入する予算もないので（ピアノ買ったしね・・・）やむを得ず windows マシンで開発することにした。

きっかけは、新しいマシンでいつもやっている rbenv のインストールを行っていたときにCPUファンが周りだし ふとタスクマネージャーを覗いてみると、CPUのクロック数がターボ・ブースト状態（※１）になっていた。

今時のCPUは全コアを高クロックで動作させるのは熱や消費電力の問題があるようで、基本的に限界のクロック数で動いてはいない。 （詳しくはダークシリコン問題等で検索してほしい）

さて、そんなことよりターボ・ブーストがかかっているということは シングルスレッド で限界までCPUを食い尽くしていると見たわけだが これは、rbenv がシングルスレッドの設計なのか、 そもそも、bash.exe (しいては、Windows Subsystem for Linuxは)マルチスレッドに対応しているのかを知りたくなったので実験してみた。

※１シングルスレッドの性能を上げるために熱に余裕があればオーバークロックする機能

• 6700k の定格は 4GHz だが 4.16GHz にブーストされている

• おなじみの rbenv のインストール中

Windows Subsystem for Linux のアーキテクチャ

Windows Subsystem for Linux とタイプするのが面倒になってきたので、以下：WSFL と書く。 WSFLのアーキテクチャは、検索すると沢山でてくるが要約すると システムコールレベルのエミュレーション であるようだ。

よくUbuntuのVMが動作していると思われているがそうではないらしい。（私も誤解していた）

上記の図は簡略図だが、簡潔に書くと Bash.exe が サービスを通じて、WSFL(lxcore.sys等があるようだ) を呼び出し 生成された Linux instance(インスタンス) 内の各Linuxアプリケーションを呼び出しているようだ。 あとは、普通のLinuxと同じく init->bash(シェル)->アプリケーション の順に動作しているよう。 ちなみに、アプリケーションが呼び出したシステムコール類は WSFLを経由して、最終的に Windows APIとして呼ばれる。

また インスタンスはユーザーごとに作成されるようだ。

(上記は筆者の解釈なので誤りがあればご指摘ください）

マルチスレッド対応の計測

で・・・

今回は最終的に Linux instance 内のアプリケーションのマルチスレッドがネイティブのWindowsでマルチスレッドとして動作するかを検証してみたい。

ネイティブのCPUをフルに使っていると判断するのはタスクマネージャーの各スレッド（ここではHTTのスレッド、コアを区別しない）をほぼ使い果たしていたら マルチスレッドに対応している　ということにしたいと思う。

テスト

シングルスレッド

シングルスレッドのテストからしてみる。 なんの面白みもない普通の無限ループである。

/* single.c */
#include <stdio.h>

int main()
{
        printf("強制終了しないとおわらないよ♪");
        while(1);
}

gcc single.c -o single.out
./single.out

結果

• 対象のCPUは 8スレッドなので 1/8スレッド=12.5% になるはずだが、他のプロセスも動作しているので若干それよりは高い

• こちらでは、 single.out が 13% と (ほぼ 1/8 スレッド) 専有している

マルチスレッド

pthread をつかった、こちらも特に面白みのないコード。 CPUのスレッド分（今回は８スレッド）生成し、無限ループするだけ。

/* multi.c */
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

#define CPU_MAX_THREAD  8

void* task(void *p);

int main()
{
                pthread_t threads[CPU_MAX_THREAD];
                int iret[CPU_MAX_THREAD], ii[CPU_MAX_THREAD];
                for(int i=0; i<CPU_MAX_THREAD; i++) {
                        ii[i] = i;
                        iret[i] = pthread_create(&threads[i], NULL, task, (void*)&ii[i]);
                        pthread_detach(threads[i]);
                }

                getchar();

                exit(0);
}

void* task(void* p)
{
        printf("Thread %d\n",*(int*)p);
        while(1);
}

gcc -pthread multi.c -o omulti.out -std=c99
./omulti.out

結果

• 各コア１００％食い尽くされている。

スレッドの開始する順番は不定なので連番にはなっていないがバグではない。 （排他制御等を実装しない限り、必ずしもスレッドが作られた順番にスレッドが進まない）

:~$ ./omulti.out
Thread 0
Thread 2
Thread 1
Thread 3
Thread 4
Thread 5
Thread 6
Thread 7

• 99% 使用されている。(このビューでは 100% になることはないので事実上すべてのCPUを専有している）

まとめ

ちゃんとマルチスレッドで動作しているようだ。

なんだから改めて見返してみると当たり前のような気がするが、 VMであれば、仮想マシンに割り当てる vCPU などで想像はつくが、カーネルに埋め込まれたエミュレーションレイヤーであったので試してみた。

余談だがタスクマネージャー上では Linux のプロセス名(~.out) でプロセス名が上がっていたが、こちらの詳細やプロパティは表示されなかった。 （何も表示されなかった）