Snapdragon 845 の CPU は Qualcomm の Kryo 385 が使われています。big.LITTLE の 8 core (4+4) 非対称構成なので、ぞれぞれの CPU core 毎に測定してみました。下記はいずれも big.LITTLE 構成の CPU を使った SoC です。

Device Single thread Multi thread
SoC CPU Core big little big little Total
Snapdragon 845 Kryo3854+4 22.3 13.7 84.4 54.9 139.3 GFLOPS
Exynos 7420 A57+A534+4 16.8 11.8 55.5 47.1 102.6 GFLOPS
Rockchip RK3399 A72+A532+4 16.1 11.8 32.1 47.2 79.3 GFLOPS
Snapdragon 808 A57+A532+4 14.5 11.2 29.1 44.9 74.0 GFLOPS
Snapdragon 821 Kryo 2+2 18.7 12.6 37.4 25.3 62.7 GFLOPS

・big = big core, little = little core
・Total = Multi thread の合計

vfpbench の単精度の結果のみ抜き出しています。単位は GFLOPS 。数値が大きい方が高速です。

表の CPU は Kryo, Kryo 385 (A75), Cortex-A57 いずれも 64bit x2 pipe なので、ピーク性能の差は純粋に core 数と clock 数で決まっています。

同様に little core の Cortex-A53/A55 も 64bit x2 の FP pipe を持っているので、数値上はほぼクロック差だけの違いとなっています。32bit 時代の little core Cortex-A7 と比べると性能は大きく上がっています。

初代 Kryo は Qualcomm 独自 core ですが、Snapdragon 845 の Kyro 385 は ARM Cortex-A75 + A55 がベースになっているようです。そのため Snapdragon 845 Kryo 385 の特性は初代 Kryo は異なっています。

例えば Kyro と Kyo 385 は積和命令のピーク演算はどちらも同一ながら、加算だけなら Snapdragon 821 の Kryo の方が 2倍速く回っています。

下記の表は 1 cycle に実行できる命令数 (IPC)

Device 64bit 128bit
CPU Core mul/fma add mul/fma add
Kryo (Snapdragon 821) 2 4 1 2
Kryo 385 (A75/A55)/A72/A57/A53 2 2 1 1

Kryo 385 のもとになった Cortex-A75 は ARM の新しい命令セットに対応しています。

Kryo 385 (A75/A55) ARMv8.2-A
Cortex-A72/57/53 ARMv8.0-A

以前の fp16 (半精度浮動小数点) 対応は変換命令だけでした。ロードストアは fp16 でも演算は fp32 以上に変換してから行います。v8.2 対応の A75/A55 では Deep Learning 向けに 16bit 命令が強化されています。fp16 のまま直接演算できるようになりました。

ARM FPU (VFP/NEON) の種類

例えば NEON (Advanced SIMD) では 128bit 時に 8並列で演算が行われます。単精度 32bit と比べると 2倍の速度が出るはずなので、余裕があったら試してみたいと思います。


テストに使った機種の詳細

Pixel 3 Snapdragon 845 SDM845 4+4 Kryo 385 (A75/A55) 2.8GHz 1.8GHz
Galaxy S6 Exynos 7420 4+4 Cortex-A57/A53 2.1GHz 1.5GHz
C101PA Rockchip RK3399 2+4 Cortex-A72/A53 2.0GHz 1.5GHz
ZenfoneAR Snapdragon 821 MSM8996 2+2 Kryo 2.3GHz 2.1GHz
Nexus 5X Snapdragon 808 MSM8992 2+4 Cortex-A57/A53 1.8GHz 1.4GHz


関連エントリ
ARM CPU 上の開発環境とコンパイル時間の比較 (2) Pixel 3/UserLAnd
ARM CPU の浮動小数点演算能力まとめ
HTC 10 Snapdragon 820 Kyro の浮動小数点演算能力
HTC 10 Snapdragon 820 Kyro の浮動小数点演算能力
iPhone SE, Apple A9 の浮動小数点演算速度
Raspberry Pi 3 の速度比較, Cortex-A53 の速度
ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較
iPod touch 6 の浮動小数点演算速度は Core 2 Duo ライン超え
iPad Air 2 (Apple A8X) の浮動小数点演算能力


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

Windows WSL (Windows Subsystem for Linux)
Chrome OS Linux Apps, Crouton, Android Apps
Android UserLAnd



● 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 を表示したものです。

{image}

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" を作成して下記のように任意の解像度を書き込む。この指定がない場合 1024x768 になっています。

$geometry = "1280x720"


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

null

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)

Device SoC/CPU RAM Thread time 速度比
Pixel 3 Snapdragon 845 4GB 8/8 32 4.2x
Galaxy S6 Edge Exynos 7420 3GB 8/8 77 1.8x
ZenFone AR Snapdragon 821 8GB 4/4 111 1.2x
Nexus 5X Snapdragon 808 2GB 6/6 135 1.0x

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

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

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

Device SoC/CPU RAM Thread time
Desktop W10+VMware Ryzen 7 1800X 32GB 16/8 24
Desktop W10+VMware Core i7-6700K 32GB 8/4 29
Pixel 3 Snapdragon 845 4GB 8/8 32
MacMini 2012 Core i7-3615QM 16GB 8/4 43
Galaxy S6 Edge Exynos 7420 3GB 8/8 77
Desktop Linux A10-7870K 8GB 4/2 82
Chromebook C101PA RK3399 4GB 6/6 87
MacBook Pro 2013 Core i5-3210M 8GB 4/2 97
Desktop Linux Celeron J1900 8GB 4/4 108
ZenFone AR Snapdragon 821 8GB 4/4 111
Nexus 5X Snapdragon 808 2GB 6/6 135
Tegra Note 7 Tegra 4 1GB 4/4 148
Note W10+WSL Atom x7-Z8700 4GB 4/4 200
Chromebook C720 Celeron 2955U 4GB 2/2 222
Nexus 9 Tegra K1 2GB 2/2 272
Nexus 7 2013 Snapdragon S4 Pro 2GB 4/4 275
MeMO Pad 7 ME176C Atom Z3745 1GB 4/4 312

・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。

Device CPU RAM Thread time
Desktop W10+VMware Ryzen 7 1800X 32GB 16/8 24
Desktop W10+WSL Ryzen 7 1800X 32GB 16/8 27
Desktop W10+VMware Core i7-6700K 32GB 8/4 29
Desktop W10+WSL Core i7-6700K 32GB 8/4 39
Desktop Linux (Native) A10-7870K 8GB 4/2 82
Desktop W10+VMWare A10-7870K 8GB 4/2 86
Desktop W10+WSL A10-7870K 8GB 4/2 104
MacBook Pro Palallels Core i5-3210M 8GB 4/2 154
MacBook Pro W10+VMWare Core i5-3210M 8GB 4/2 159
MacBook Pro W10+WSL Core i5-3210M 8GB 4/2 189

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

Device (Termux) CPU RAM Thread time
Pixel 3 Snapdragon 845 4GB 8/8 32
Galaxy S6 Edge Exynos 7420 3GB 8/8 77
ZenFone AR Snapdragon 821 8GB 4/4 111
Nexus 5X Snapdragon 808 2GB 6/6 135
Device (UserLAnd) CPU RAM Thread time
Pixel 3 Snapdragon 845 4GB 8/8 78
ZenFone AR Snapdragon 821 8GB 4/4 221
Nexus 5X Snapdragon 808 2GB 6/6 361

・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 も使えるようです。


null

null


関連エントリ
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種類です。

変換 Mode 改行 code
Local -- OS 依存
Unix LF OSX/macOS 含む
Mac CR Mac OS 9 以前
Win CR+LF Windows
Shared LF

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 に統一しているわけではなく、単に何もしていないだけであることがわかります。

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

変換 Mode PC → Server Server → PC
Win 変換あり CRLF → LF 変換あり LF → CRLF
Unix 変換無し 変換無し
Shared 変換あり CRLF → LF 変換無し

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

Perforce の変換 Mode 対応する git の設定
Win autocrlf=true
Unix autocrlf=false
Shared autocrlf=input

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


| 次のページ(日付が古い方向)>>