XPS 13 のモニターに当選しました #DELLアンバサダー

DELLアンバサダープログラムでXPS13のモニターに当選し、今日届きました。これから約1か月モニターしていきます。

モニターに応募した理由は、ちょうど今使っている ThinkPad X 250 の次のノートを物色していたからです。 XPS 13 以外の候補は、 X1 Carbon (14インチなのに1.13kgと軽い！), hp の Envy 13 (大きさ重さはほぼ同じだけど、12万円台でSSDが512GBにできる！), MateBook X (高いけど1kg台と軽くてモニターが3:2！)とどれも魅力的なので、XPS13も次のモデルではマイチェンじゃなくてもっとせめて欲しいところ。（あとできれば Ryzen mobile APUにしたい）

ちなみに、モニター終わったら貰える／安く買い取れるとかそういうのはないので、変に気を遣わずに X250 や会社で使っている MBP 13" (多分 2013 late) と比べて気になる点は厳しくガンガン書いてしまいます。

ThinkPad X250 と比べると、フットプリントはほぼ同じで、液晶が12.5インチから13.3インチに拡大しました。まだ日本語の読み書きしかしていないので、このサイズ差が生産性に影響するかは未知数です。 厚さも、X250のキーボード側の厚さがちょうど XPS13 の厚さくらいで、今どきの Macbook や ZenBook 3 みたいな感動的な薄さではないものの、十分スタイリッシュになりました。

液晶側は180度までは開きませんが、特別窮屈な感じはしません。カウンターキッチンの上において立ったまま使うときなどでも問題なく使えます。これが狭めのノートだとソファでくつろぎながら膝を立てたところにノートPCを載せて使う時とかに窮屈な感じになってしまうのですが、XPS13は及第点です。

液晶は3200x1800のタッチパネルで奇麗です。Windowsで推奨のスケールは250%になってますが、200%にするとちょうどいい感じだし、フルHDの場合に使う125%や150%によくあるボケやレイアウトずれ（文字のはみだし）なんかも200%なら軽減されるんじゃないかなという淡い期待もあります。

一方で、重さはFull HDモデルが1.2kgなのに対してQHD+モデルは1.29kgらしく、スケールメーターを持ってないので計測はできませんが、持った感じはズシリと感じます。X250は1.44kgあるのでまだそれよりは軽いんですけどね。タッチなしのQHD+出ないかなぁ。タッチ欲しい人は2in1買うでしょ。今どきあえてクラムシェル選ぶ人にはタッチ要らないでしょ。(偏見)

その他のスペックはi7/8GB/256GBです。DellのオンラインストアではQHD+は16G/512Gのモデルでしか選べないので簡単に入手できるスペックとは違うみたいです。個人的にはCPUがi5で良いので16GB/512GB/QHD+タッチなしが15万以下で選べるようになってほしいところ。 色はピンクゴールドだけど、落ち着いた色で男が使っても違和感無いです。

気になるのが、ときどきキーボードの左側（Sキーあたり）からキュルキュル音が鳴ります。なるタイミングはよくわからない。 調べるとコイル鳴き症状があるようでたぶんそれだと思います。

キーボードのストロークは2013年のMBPと同じくらいで、感じはMBPがカシャカシャなのに対してちょっとゴムっぽいクリック感になります。ゴムっぽいといってもグニョっとネバ付く感じはなくて別に悪くないです。キーボードは右側が細くなってますが X250 も同じなので特に問題には感じてません。音もMBPより静かになったと思います。

ただ、エンターキーの右側を押すとキーが水平に下がるのではなく右側が下がる感じになるので、それが気になる。キーボードの右側の少し高くなってる面に小指が当たってしまいます。 MacBook, ZenBook 3, MateBook X みたいに本体の左右ギリギリまでキーボードが広がっている必要はありませんが、それでももう少しだけ余裕が欲しかった。 それ以外の配置はとてもよく、特にスペースキーはホームポジションで両手の親指がちょうどスペースキーの左右に乗せられるのが好印象です。

ファンの音はMBP13と同じくらいですが、Chromeでこの記事を書いてる間もずっと回っていて、MBP13よりも回り始めやすい印象。あと、回ってるときに本体を傾けたり、液晶を閉じて持つと、ファンがどこかに干渉してハチが飛ぶ音みたいな音が鳴ります。ファンが壊れそうで耐久性が不安になるのでこれは改善してほしい。

モニタープログラムの決まりで改造は禁止なのですが、質問したところ返却前にリカバリするならデュアルブート化してUbuntuをインストールするのは問題ないそうです。 が、Windowsのディスク管理からパーティションの縮小ができなかったので、とりあえずWindows 10 CU にアップデートして使っています。

go-sql-driver/mysql の v1.3 が出たよ

リリース日が去年の12月なんでもう時間経っちゃってるんだけど、一応日本語でアナウンスしておきます。

MySQLドライバの go-sql-driver/mysql が、 Go 1.8 の新機能サポートの前に安定版リリースしようということで、 v1.3 のタグが打たれました。

master ブランチに昨日 (2017-03-23) から 大きい変更 をマージし始めたんで、glide などの依存管理ツールを使ってる人は、プロダクション／ステージングでは v1.3 に固定しておくことをお勧めします。 (それ以外の人はむしろ master ブランチでテストしてくれると嬉しい。)

Windows では2020年を待たずに Python 2.7 が使い物にならなくなっていく

昨日 mysqlclient 1.3.10 をリリースしました。 今までは Windows 版の wheel は Python 2.7 だけに提供していたのですが、 1.3.10 からは 3.5 と 3.6 だけに提供して 2.7 はドロップしました。

そもそも今まで Python 3 に wheel を提供できてなかったのは、 MySQL Connector/C の VC14 (VS2015) に対応したライブラリが提供されておらず、 Python 3.5, 3.6 は VC14 でビルドされていて VC12 用のライブラリにリンクすると大量のエラーでるわ自分で手順読みながら頑張って MySQL をソースからビルドしてもなんか動かないわで諦めてたからです。

それが、2年待て、よーーーやく MySQL Connector/C 6.1.9 から VC14 のライブラリが同梱される用になりました。 GPLだから困ったら自分でなんとかしろと言われればそれまでなんですが、もうちょっと早くできなかったんでしょうか、Oracleさん。。。

一方で、 Python 2.7 は VC9 (VS2008) でビルドされています。しばらく前の（具体的なバージョンは忘れた） MySQL Connector/C から、 vc10, vc11, vc12 用のライブラリしか提供されてなかったのですが、 vc10 と無理やりリンクするとリンクエラーも起こらずちゃんと動いてるっぽかったし、特にライブラリ側でmallocしたメモリをPython側でfreeするみたいな明らかな問題も無かったので、vc9とvc10のランタイムライブラリを両方リンクすることでなんとか wheel を提供できていました。

それが、 Connector/C 6.1.9 からは vc11, vc12, vc14 のライブラリだけが提供されるようになり、 vc10 のライブラリが消えました。 一応、 utf8mb4 に対応した後、 6.1.9 以前のライブラリバージョンを使ってビルドし続けることもできるんですが、もともと気持ちよくない構成でビルドしてたので思い切って Python 2.7 wheel のビルドをやめることにしました。

Windows でバイナリ互換性を維持するには VCRT のバージョンを固定する必要があり、 Python 2.7 は 2008 年の VCRT にずっと依存しています。 Python コア開発者は 2020 年まで Python をメンテしていますが、サードパーティーのライブラリは 2020 年まで 2008 年の VCRT をサポートしてくれるわけではありません。 VC++ 2013 や 2015 に移行したライブラリは、 VC++ 2008 では利用できない機能 (<stdint.h> とか) を喜んで使うでしょう。古いバージョンのライブラリを使い続けるのにも、セキュリティ fix をバックポートする努力をしなければ、安全でないものを配布することになります。 (Python 2.7 サポートを望む声に負けて、安全でないライブラリを配布してるライブラリがすでに存在するかも知れません。というか存在すると思います。)

Windows 向けに binary wheel を提供している開発者は、そろそろ Python 2.7 のサポートのために変に頑張るのを止めて、代わりにユーザーに Python 3 への移行を頑張ってもらうべきだと思います。

Windows で Python 2.7 を使っている開発者は、 pip install が成功するからという理由で Python 2.7 を使い続けるのをやめましょう。 「Python 2.7 サポートのためにバグやセキュリティホールのある古いライブラリが使われてないか」をチェックし続ける努力より、 Python 3 に移行する努力のほうが建設的ですよ。

pip 9.1 から msgpack が使われるようです

Adopt cachecontrol 0.12.0 with msgpack support というコミットがありました。

どうやら CacheControl というのが pip が使っている requests 用のキャッシュライブラリで、その最新版が msgpack を使っているようです。

前のバージョンはバイナリデータを base64 した上で json に入れて gzip していたのですが、もともと圧縮されてるバイナリを扱うときに gzip は base64 によって増えた分を減らす以上の効果は期待できない上、 PyPI からダウンロードするファイルってほぼ100%圧縮済みなので、キャッシュファイルの読み書きで無駄なオーバーヘッドがあったみたいですね。

バンドルされてる msgpack は pure Python で実行できる fallback モジュールのみなのでどこでも動くし、 Cython 版じゃないのも今回みたいにファイルが大きい以外はデータは多くなくて単に base64 + gzip の負荷を減らしたいときは完全に安全だし、まさに msgpack の典型的な成功例 (json にバイナリ詰めたかったら msgpack!) のように見えます。

ということで、 pip 9.1 がリリースされたら msgpack のユーザーが爆発的に増えそうです。

処理系ベンチマーク環境としての Azure VM vs EC2 vs GCE

ISUCON の練習で、Azureの「開発者プログラム特典」という1年間限定で毎月3000円の無料枠を使い始めたのと、副賞でさらに無料枠を貰えそうなので、最近一番 IaaS を使ってる Python のベンチマーク環境として Azure も使ってみています。

ラップトップPCだけで生活してる人が、時間の掛かるベンチマークをするためだけに IaaS を時間借りするというニッチな視点で、既に使った経験のあるEC2, GCE と Azure を雑に比べてみます。

Hyper Threading

EC2 と GCE は Hyper Threading が有効です。 EC2 の c4 系も、 GCE の n1-highcpu 系もコア数は偶数になっています。両者とも汎用系だと HyperThreading の仮想1コアのマシンが作れるみたいなので、間違ってもベンチマーク用途でそういったインスタンスを使わないようにしましょう。

一方 Azure は Hyper Threading が無効みたいです。CPU重視の F や Dv2 系インスタンスも1コア単位です。

性能の安定性

2回 pyperformance run -b 2to3 した結果です。インスタンスガチャはしてないので、絶対性能は無視して安定性に注目してください。

Azure VM (F1):
Median +- std dev: 622 ms +- 17 ms
Median +- std dev: 644 ms +- 21 ms

EC2 (c4.large):
Median +- std dev: 537 ms +- 4 ms
Median +- std dev: 540 ms +- 4 ms

GCE (n1-highcpu-2):
Median +- std dev: 819 ms +- 7 ms
Median +- std dev: 817 ms +- 7 ms

Azure が 3% 程度、EC2とGCEは1%程度のばらつきがあります。 インスタンスの停止＆起動を繰り返していないので断言できませんが、 Azure は EC2 より性能が安定しない感じがしていたので、この結果通りなんじゃないかなと思います。

3% のチューニングを10回すれば25%以上の性能向上になるので、ベンチマークの誤差が3%あるのはかなり痛いです。

その他

Azure VM

Azure は固定IPをしなくても固定DNS名を用意してくれるので、固定IPを買ったりDynamicDNSを設定したりsshの設定を毎回切り替えたりしなくても良いのがとても便利です。

新規マシンの作成はちょっと遅い気がしますが、停止・起動はEC2と同程度な気がします。 時間指定してシャットダウンするオプションを管理コンソールから簡単に設定できて停止忘れ対策になるのがとてもうれしい一方、 ssh してる状態で shutdown -h コマンドで停止してもインスタンスが開放されず課金が続くのは若干面倒。

あと、SSDがGB単位で使えないのが痛すぎます。一番小さい P10 で128GBです。

EC2

インスタンスガチャをしてみないと分かりませんが、Pythonのベンチマークではマルチコアを有効に使えないので、コアあたりの性能が良さそうな EC2 c4 インスタンスが一番魅力的です。

ちょっと奮発して c4.8xlarge を使えば、 Turbo Boost を切ることができてさらにベンチマークの安定性が増します。

一方、新しいインスタンスをVPCから作ろうとすると、 ssh できるようになるまでにネットワーク周りで設定しないといけないことが多くて手順覚えてられないのが難点。

GCE

管理画面があっさりしていて、仮想マシンを作るのがとても楽です。ウィザードに従って設定しても、 「gcloud コマンドでこれをするには」がコピペできるので、コマンドの使い方を調べる手間が要らないのと、そのコマンドを使うための環境をローカルに用意しなくても Cloud shell に造ってしまえるのがとても楽。

あと、プリエンプティブインスタンスが停止されてもデータが消えないでまた起動して続きからできるのがとても楽。EC2のスポットインスタンスはちょっと新規インスタンス立てて何かのベンチマークを実行しようってときに使う気にならないけれども、GCEだと積極的に使える。

結論

すごく重要な点として、どの仮想マシンも、CPUのパフォーマンスカウンタが見えません。キャッシュミスとかの統計が取れない。つらい。 できるだけ管理するもの（物理）を減らしてスッキリしたかったのですが、仕方ないので会社にラップトップと別に好きにいじれる物理PCを用意してもらうことにしました。

それさえなければ、大抵のCPUを使うプログラムのベンチマークは、シングルコア性能が良い EC2 c4 か、手軽な GCE で良いと思います。 そしてせっかく無料枠あるのに Azure を使うモチベーションが…何に使おう。