いろんな OS の中で Linux 環境が使えるようになってきました。OS の中に同居し、Native なアプリと同時に Linux のソフトウエアも走らせられるようになっています。ハードウエアまるごとエミュレーションする仮想 PC とは異なります。RAM やストレージに境界はなく、カーネルをそのまま共有しつつシステムに間借りする形で動きます。

● Windows 10 WSL

複数の Distribution が用意されており、Microsoft Store からアプリとしてインストールできます。事前に WSL を有効化しておく必要があります。

(1) 設定→ 「アプリと機能」→「プログラムと機能」→「Windows の機能の有効化または無効化」
(2) 「Windows Subsystem for Linux」にチェックを入れて再起動。

● Chrome OS (Chromebook/Chromebox 等)

ChromeOS は Chrome Browser のための Platform です。普段 PC で Chrome ブラウザを使っているなら、Chrome OS に触ると大半の作業がブラウザで事足りることに気が付きます。利用できる Chrome アプリは限られているものの、必要なら Android や Linux アプリを使うことができます。アプリ選択の自由度は意外に高くなっています。

現在 Chrome OS デバイスで Linux を走らせる方法は複数あります。それぞれ複数の Distribution から選ぶことができます。(Linux Apps を除く)

公式に対応した Linux Apps は対応機種がまだ少ないですが、Developer mode に切り替える必要がないので非常に扱いやすくなりました。

インストール＆起動方法で分けると下記の 3種類です。

(1) Native Install

　普通の PC と同じように Linux をゼロから install します。Gallium OS 他。

(2) Dualboot (ChrUbuntu)

　カーネルを流用して Linux を起動します。boot 時に選択します。(ChrUbuntu)

(3) Chrome OS と同居

　コンテナとして Chrome OS 上で動きます。Chrome OS と同時利用が可能。

さらに (3) の方法にも複数の選択肢ができました。

1. Crouton : chroot で Linux を install。古くから存在し多くのデバイスで利用可能。

2. Android Apps : Android アプリとして Linux 環境 (UserLAnd 等) を install

3. Linux Apps (crostini) : ChromeOS 公式の Linux 環境

2. および 3. は比較的新しい機種のみ対応しており、古い機種では使うことができません。

なお Crouton は Chrome OS 内に Linux Desktop を表示できますが、X11 の動作モードが 2種類あります。(sudo startsfce4 -X xiwi 等のオプションで切り替え)

・xiwi : Chrome OS のウィンドウの一つとして表示。ソフトウエア描画。

・xorg : 全画面を乗っ取ってしまうがハードウェアアクセラレーション対応。

下記画面は Crouton の xiwi で Linux Desktop を表示したものです。

・GitHub: Crouton
・GitHub: ChrUbuntu
・Gallium OS

● Android

(UserLAnd) は Android アプリとして Linux 環境を install します。root 無しに利用可能で、複数の Distribution から選ぶことができます。現在は Arch, Debian, Kali, Ubuntu の 4種類用意されているようです。

アプリからは SSH Terminal, VNC の 2種類の接続方法を選ぶことができます。公式サイトにあるように X Server も使えます。

　1. アプリ install
　2. 任意の Distribution を選択 (Debian, Ubuntu 等)
　3. フォルダへのアクセス許可
　4. ユーザー名とパスワードの入力
　5. 利用方法の選択 (SSH or VNC) あとから変更可能
　6. 初回のみ ConnectBot or bVNC Free の install
　7. 6. で install した場合はアプリに戻ってもう一度選択すると起動

VNC 利用時の desktop install 手順。

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install lxde
$ mv ~/.vnc/xstartup ~/.vnc/xstartup.bak
$ cp /usr/bin/startlxde ~/.vnc/xstartup

VNC の解像度変更方法

“~/.vnc/tightvncserver.conf” を作成して下記のように任意の解像度を書き込む。この指定がない場合 1024×768 になっています。

$geometry = "1280x720"

2160×1080 や 1920×1080 等、スマートフォンで実解像度を指定すると小さすぎて文字が読めなくなる可能性があるので注意。↓ は ZenFone AR の画面です。

・UserLAnd

関連エントリ
・ARM CPU 上の開発環境とコンパイル時間の比較 (2) Pixel 3/UserLAnd
・Android/Linux MaruOS その4
・Nexus 7 上に開発環境をつくる (4) Ubuntu 13.04

スマートフォンの性能が上がっています。Snapdragon 845 搭載の Pixel 3 を手に入れたので、開発環境としてどのくらい使えるか再び試してみました。(前回の記事はこちらです)

また Android 上で一般アプリとして実行可能な Linux 環境 UserLAnd がリリースされているので、Termux と合わせてテストしました。どちらも root 不要です。

● 今回の結果 (Android + Termux)

・time = コンパイル時間。単位は秒。この値が小さい方が速い。

Cortex-A75 ベースとなった Snapdragon 845 は非常に速く、Desktop PC と比べても遜色ない速度でコンパイルが完了しています。普通に開発環境として使いたいレベル。

下記はスマートフォン以外のデバイスを含めた比較です。

・W10 + VMware = VMware Workstation 15 Player + Ubuntu 18.04
・W10 + WLS = Windows Subsystem for Linux + Ubuntu 18.04

前回同様 C++ ライブラリの Build を行っています。Build Target は Linux 向けで統一。実行はコマンドラインから行い、それぞれ 2回連続で走らせたうち速い方を採用しています。

Chromebook C720 は crouton + Ubuntu 18.04 です。Chromebook Flip C101PA は Android の Termux ではなく ChromeOS 公式の Linux 機能 (Debian stretch) を使用しています。

Windows PC の場合は WSL (Windows Subsystem for Linux) や VMware Workstation Player を利用しているので、若干オーバーヘッドがある点に注意してください。

どの程度オーバーヘッドがあるのか、WSL と VMware を比較してみた結果は下記のとおりです。直接 Linux を install するよりも効率は落ちており、また VirtualMachine 系よりも WSL の方が遅くなっていることがわかります。いずれも Windows 10 1809 と Ubuntu18.04。

Termux は利用できるパッケージに制限がありましたが、UserLAnd はほぼそのまま一般の Linux Distribution が利用できるようです。下記は Termux と UserLAnd + Ubuntu の速度比較です。

・UserLAnd = Ubuntu (18.04) + SSH

残念ながらビルド時間は UserLAnd の方が倍以上遅くなっています。ファイルシステムの違いが原因と思われますが、それでも Pixel 3 の速度は十分使える範囲です。

なお UserLAnd の場合、古いデバイスではカーネルの違いか正しく動かないものがありました。Pixel3, ZenFone AR, Nexus 5X で動作したものの、それ以外の Android 端末では使えませんでした。

Pixel 3 は手持ちの古い Note PC よりも快適そうなので、持ち歩ける PC としてまじめに使ってみたいと思います。

↓ Android Pie の画面分割機能を使った画面です。左側が UserLAnd (SSH) で右が Termux。普通に日本語環境の構築もできます。Ubuntu 以外にも Arch, Debian, Kali Linux が利用可能。VNC で GUI も使えるようです。

関連エントリ
・ARM CPU 上の開発環境とコンパイル時間の比較
・AMD CPU Ryzen とコンパイル時間の比較 (2)
・AMD CPU Ryzen とコンパイル時間の比較
・ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較
・2955U vs N3150/J1900/Athlon5350 (コンパイル時間の比較)
・Raspberry Pi 2 で速くなったコンパイル時間の比較
・BayTrail vs Kabini (Celeron J1900 vs Athlon 5350)
・コンパイル時間の比較 BayTrail
・Atom vs Core i7

Apple Watch S2 42mm を使って 2年 (と数ヶ月) 経ちました。watchOS も 5 になり当初から 2つ上がっています。今のところ一番利用している機能は Suica です。バッテリーは 2日に一度の充電ペースでしたが、最近充電頻度があがりました。

● バッテリーの持ち

バッテリーは使い方にもよりますが 42mm モデルの Watch OS 4 時でだいたい 3日使えます。3日といっても 24 x 3 = 72 時間フルに持続するわけではなく、朝充電器から外すと 3日目家に帰るまで持つ感覚です。およそ 12 x 5 の 60時間前後でしょうか。当初の 2年間は、2日に一度の充電ペースでも余裕を持って運用できていました。

ところがこの数ヶ月、秋に Watch OS 5 に更新したあたりから充電ペースが上がっています。2日目の余裕がほとんど無いので毎日充電するようになりました。Watch OS 5 で消費電力が増えたのか、もしくはバッテリーが劣化したせいかもしれません。

● Apple Pay の Suica と改札

1日に 8回改札を通過しており買い物にも利用しています。今では外出に欠かせない物となってますが、使い始めた当初は慣れずに自動改札で引っかかることが多々ありました。

(1) IC カードと比べて若干認識速度が遅い
(2) 手首でのタッチは指先でカードを持つよりも距離が遠い
(3) 認識結果のアラームが鳴るタイミングが不定
(4) いつの間にか自動ロックがかかっている事がある

(1)～(3) は比較的すぐ慣れましたが (4) は未だにあります。

Apple Pay 利用時はセキュリティのためパスコードによるロックが必須となっています。といっても身につけている間は常にロックが解除されており不便はありません。センサーが常時腕を認識しており、腕から外すと自動的にロックがかかる仕組みです。

非常に良くできているのですが、ベルトを緩めにしているせいか気が付かないうちにロックされていて、稀に改札で締め出しをくらうことがあります。袖口が時計と腕の隙間に入り込むのかもしれません。

● Suica の残高表示のずれ

watch OS 3～4 の頃、Suica の残高表示が正しく反映されない (変わらない) ことがありました。見た目だけの問題で、支払いは自体は正しく行われているため実害はありません。他にも通知に表示される支払い金額がつねに 1つ前のものだったり、改札の内外通知が逆転したこともあります。

どうやら Apple Watch 側の再起動で直るようです。watchOS 5 ではまだこの症状に遭遇していないので改善しているのかもしれません。

● スマートウォッチの操作

通知など情報を受けるには便利なスマートウォッチですが、操作面では少々難があります。小さいタッチ画面もそうですし、操作には両腕が必要です。荷物やつり革で片手が埋まっている場合は、片手でも操作できるスマートフォンを取り出した方が早いことになります。タイマーのように簡単なものは Siri によるボイスコマンドを利用するようになりました。

● ワークアウトの自動判定

watchOS 5 からワークアウトの自動判定ができるようになりました。ある一定時間負荷が持続すると通知が来るので、応えると時間を遡ってワークアウト期間とみなしてくれます。非常に便利なのですが、もしかしたら watchOS 5 で消費電力が増えた原因の一つかもしれません。自動判定の通知自体は設定で Off にすることができます。

設定→一般→ワークアウト→ワークアウトの開始を通知

関連エントリ
・Apple Watch S2 の CPU と浮動小数点演算
・Apple Pay を iPhone SE + Apple Watch S2 で使ってみた (2)
・Apple Pay を iPhone SE + Apple Watch S2 で使ってみた
・Apple Watch の CPU の種類と浮動小数点演算速度

Perforce は Workspace 毎に改行コードの変換ルールを設定することができます。設定は下記の 5種類です。

git のような変換無しのモードは特に無く、text の場合は OS (改行コード) 毎に変換が行われているようです。サーバー上の改行コードは LF で統一されています。

“Local” は OS 依存で “Unix”, “Mac”, “Win” の何れかと同じ意味になります。”Mac” は OSX より古い OS 用のもので、現在の OSX/macOS は “Unix” に含まれます。

実際にどのように変換されるか調べてみました。下記はテキストファイルを Perforce サーバー経由で取得し直した結果です。

Mode        Local PC      Server(p4d)    Local PC
--------------------------------------------------
Unix        CRLF     ->   CRLF     ->    CRLF
Win         CRLF     ->   LF       ->    CRLF
Shared      CRLF     ->   LF       ->    LF

Unix        LF       ->   LF       ->    LF
Win         LF       ->   LF       ->    CRLF
Shared      LF       ->   LF       ->    LF

Unix                      CRLF     ->    CRLF
Win                       CRLF     ->    CRCRLF
Shared                    CRLF     ->    CRLF

“Unix” は改行コードを LF に統一しているわけではなく、単に何もしていないだけであることがわかります。

各モードの変換の動作をまとめると下記のとおりです。

Perforce の変換モードと git との比較

Perforce ではサーバー上の改行コードは LF で統一されており、CRLF のファイルが存在することを想定していないようです。”Unix” は事実上無変換モードなので、CRLF の text ファイルもそのまま Uploard することができてしまいます。”Win” 設定で受け取ると余計な CR が挿入されてしまいます。

Direct3D 12 は Metal や Vulkan と同じ低レベル API に属します。新しい API Set ですが、GPU の世代更新に合わせたというよりも Direct3D 11 世代の再定義に近いものでした。ShaderModel は 5.1 のままで、GPU の新機能対応も当初は 11/12 両方に行われています。

Direct3D 11 の Release は Windows 7 と同時ですが、Windows 10 になっても 11.3/11.4 と更新が続いていたことがわかります。しかしながら Windows 10 1607 以降は ShaderModel 6.0 も導入されており、機能面での違いも増えてきたように思います。

コメントで Vega の ShaderModel 6.0 の対応状況について情報を教えていただいたので、あらためてそれぞれの GPU で確認してみました。新しい世代の GPU はいずれも最新ドライバで 6.1 に対応していることがわかりました。

下記は ShaderModel 6.0 の wave 命令の lane 数

その他 GPU 毎の対応状況の詳細は下記のページに載せています。

・Direct3D 12 (DirectX 12) Windows 詳細

GPU は頂点や Pixel のように大量のデータを扱います。これは並列化が容易なので、CPU の Multi Thread と同じように複数の Shader Core で分散実行しています。

CPU と異なっているのは、一定の Thread Group (wave) 毎に実行する命令 (Instruction) を共有していることです。同じ Instruction で同じ演算を行うという意味では SIMD に近いのですが、各 Thread はそれぞれ単一の Scalar 要素にだけアクセスできるようになっています。これは SIMT と呼ばれています。

例えば 4 並列の SIMT を考えてみると、Thread 0 は SIMD Vector Register の x だけ、Thread 1 は y だけ使って演算を行っていることになります。コード上は Scalar 演算と同等です。

ShaderModel 6.0 の wave 命令では、この Thread 毎の Scalar アクセスの制限が緩和されており、ある程度相互に情報をやり取りできるようになりました。先程の例でいえば、本来 Thread 0 しかアクセスできない x の要素を Thread 1～3 からも参照できることになります。

なお ShaderModel 6.0 からは ShaderCompiler が変更されているようです。5.1 までは fxc.exe (D3DCompiler_47.dll) ですが、6.0 以降は dxc.exe (dxcompiler.dll) を使います。

dxc shader.hlsl -T ps_6_0 -E pmain -Fo shader_ps.bin

dxc でコンパイルした bytecode はそのまま PipelineState (D3D12_GRAPHICS_PIPELINE_STATE_DESC) に渡すことができます。

PS_OUT  pmain( VS_OUT pin )
{
    PS_OUT  pout;
    float2  pos= pin.Position.xy;
    if( WaveIsFirstLane() ){
        pos.x*= 1.0f/500.0f;
        pos.y*= 1.0f/500.0f;
    }
    pos= WaveReadLaneFirst( pos );
    if( WaveIsFirstLane() ){
        pout.Color= float4( 0.0f, 0.0f, 1.0f, 1.0f );
    }else{
        pout.Color= float4( pos.x, pos.y, 0.0f, 1.0f );
    }
    return  pout;
}

少々わかりにくいですが、上の PixelShader で Wave Size (Lane 数) の違いを視覚化してみたものです。同一 Wave を同じカラーで塗りつぶします。

↑左から RADEON Vega56, Skylake (Intel HD Graphics 530), GeForce GTX1070

Vega が最も Lane 数が多いので tile の色分けがわかりやすくなっています。真ん中の Intel HD Graphcis が最も細かいことがわかります。

関連エントリ
・AMD Vega と Direct3D 12
・Direct3D 12 GPU GeForce GTX 1070 Pascal と RADEON RX 480 Polaris