RIP EdgeHTML. Software lifecycle is difficult

丁度USへ行っている最中にMicrosoft EdgeがChromiumベースになるというニュースが入ってきた。とにかく残念というしかない。

個人的な感覚で言えば、BillGだったらもう少し違ったやり方を行っているだろう。おそらく今止めるって判断をしない (EdgeHTMLを作る前に止めるか、そもそももっとリソースを投入して製品としての品質を上げる。今のEdgeはUXがちょっと中途半端だと思うんだ) 、ナデラはサーバーサイドの人だからそういう判断もするだろうなと。

Internet Explorer / Microsoft Edgeに対していろいろ怨念なことを書いている人は多いけど、この怨念って (Microsoftの強みでもある) プロダクトライフサイクルが原因としか思えないのだよねと思うことが多々あって、ちょっと書きたくなった。

プロダクト・ソフトウェアライフサイクル

従来 (1990年代) のMicrosoftのプロダクトサポートポリシー (≒Hotfixの提供、セキュリティ修正プログラムの提供) はN-1だった (現在のメジャーバージョンと一つ前のバージョンという意味)。これだと一つ前のバージョンのサポートがいつ終わるが明確ではないということで2000年代にちゃんと正確な日付を設定するようになった。Windows 2000以降上に乗るInternet Explorerというのはこのポリシーとはちょっと異なっており、OSに乗ってるバージョン (Windows 2000の場合はInternet Explorer 5.01) と最新バージョンがサポート対象という考えだった。それをみんな (≒社内も含む) 理解しておらずN-1ルールだと思い込んでいて、5.01はサポート終了するから5.5にアップグレードしてれば安全とか顧客に言ってた人たちが「どうにかならないか？」と私とかに交渉しにくるのは多かった。(Sustained Teamと一緒に働いていた関係上) 日本における最終的に泣きつく先が私だったので。なぜこうなっているかはソースコードが誰のオーナーなのかとかビルドラボとかいろんな事情があるんだけど。

またWindows XPも結果として2014年までサポートすることになったが、そもそもリリースされた最初の段階ではそこまでライフサイクルが長い製品になるなんて誰も思ってなかった。次のWindows Vistaのリリースが2006年になったのはLongHornが失敗したのが原因なのだが (LongHornはBuild 4xxxだったのだが、Build 5000を入れたときにWindows XPまんまの画面が出たのは記憶に残ってる)、リリース期間が開いてしまった結果、より多くの環境でWindows XPが使われることになった。またVistaのリリースの頃くらいに、エンタープライズ系の顧客からの要望の結果、サポート期間がWindows XPのEOL (End Of Life。サポート期間の終了) が2014年になるという話になる (このメールを見たときに殺気を覚えたのはいうまでもない。自分のハードディスクからこのソースコード消せないのかと。それよりも先に会社を退職したけど)。

Windows XPのサポート期間の延長の決定がInternet Explorer 6のサポートが2014年になってしまうということに。Webブラウザが13年間サポートされるというこがいかにクレイジーなのか (GNOME 2.0でさえ2002年のリリースだよ！)。もしサポートがWindows 7のリリースと同時に終了してれば、Web開発者はそこまで不満を持たなかっただろう。

Internet Explorer 6に対して標準準拠のことをよく言われるが、1990年代というのは標準化というのは後で付いてくるようなもので、NetscapeやMicrosoftはその相互運用性なんてそこまで考えてはなかった (自分はよくIntranet Explorerという言葉を使ってた。イントラネット環境においての最高なブラウザである意味)。Internet Explorer 6なんてその頃に生まれたような産物で、Netscape/MozillaだってGeckoベースになるまでは標準化なんてそれほど考えてなかった。Internet Explorer 7でいろいろ軌道修正を行っていろんな問題を解決し始めて (7の開発時に本社のInternet Client All Handsに行った時はその話がメインだった)、Internet Explorer 9では非常にトレンドにのった実装になったし、さすがMicrosoftだなと (Internet Explorer 8を作ってる最中に9も同時進行だったんだろうなと推測される)。

また、Webの進化を進めるため、Chromeが仕掛けたラピッドリリースモデルも彼らへの不満を増幅させた要因になった。リリースから2年経過したブラウザの対応が辛い状況を作られれば、Microsoftの従来のやり方だと不満しか残らなくなる。

結果として、Microsoft製ブラウザへの対応をすることへの不満に持つ人が増える。これは完全にプロダクトライフサイクルのせいだろう。

その後、OSに付随するバージョンのInternet ExplorerのサポートはOSと同時に終わるのをやめて最新バージョンのみになったが、決断が遅かった。

EdgeHTML

個人的にEdgeHTMLの一番の判断のミスは、古いOSへのサポートがなかったことだろう。WinRTのサブセットをWindows 7に持ってくるか、二つのOS対応のコードを作ればよかったのでは (MainsoftがInternet Explorer 5に対して行ったようにshimレイヤー作ればよかった。Tridentだって抽象化レイヤーあったのに)。EdgeがWindows 7で動かない以上、Internet Explorer 11へ対応することが求められる。Internet Explorer 11だって2013年のリリースだから5年前。そりゃつらい。

まとめ

Windows 7上でEdgeHTMLが動いて、半年サイクルでMicrosoft Edgeが全OS向けにリリースされていれば、EdgeHTMLをやめるというニュースを喜ぶ人も少なかったのだろうなと思う。Windows Phoneみたくいろんな戦略を間違った結果なんだよね。たらればだけど。ソフトウェアライフサイクルの定義は難しい。

llvmとrustにおけるWindows/aarch64のサポート

llvm自体には基本的にはWindows/aarch64 (COFF/aarch64) の初期サポートがすでに入っていたのだけど、Unwind InformationとかExceptiion Handlerのサポートは入ってなかった。そのため、C++のコードをコンパイルしようとしても以下のようなInternal Compiler Errorでclangとかがクラッシュする状況だった。

clang version 6.0.1-5 (tags/RELEASE_601/final)
Target: aarch64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
...
fatal error: error in backend: Funclet EH is not implemented for this target clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 6.0.1-5 (tags/RELEASE_601/final)
Target: aarch64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-1a3737.cpp
clang: note: diagnostic msg: /tmp/test-1a3737.sh
clang: note: diagnostic msg:

先月くらいからいろいろLLVMにコードが入り始めており (ex. https://reviews.llvm.org/D49637)、基本的なUnwind Informationとかをllvmが生成できるようになってきている。そのため、rustにもWindows/aarch64対応が入った。ただし、rustup等でインストール可能ではなく、自分でビルドする必要がある。

rustc.exe --target aarch64-pc-windows-msvc -O hello.rs

で生成されたバイナリをみると確かにaarch64のコードが生成されている

Microsoft (R) COFF/PE Dumper Version 14.15.26726.0
Copyright (C) Microsoft Corporation.  All rights reserved.

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
AA64 machine (ARM64)
8 number of sections
5B7D2340 time date stamp Wed Aug 22 19:38:00 2018
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses

...

main:
str     lr,[sp,#-0x10]!
mov     x3,x1
adrp    x8,0000000140001000
adrp    x1,anon.4a7df3b253b8104c34e7c5ba0fd9252b.0.llvm.9631437952416841302
sxtw    x2,w0
add     x8,x8,#0x30
add     x1,x1,#0
add     x0,sp,#8
str     x8,[sp,#8]
bl      _ZN3std2rt19lang_start_internal17hac3e63ad7889c515E
ldr     lr,[sp],#0x10
ret

なお、Microsoft Visual Studio 15.8に入っているaarch64アセンブラ (armasm64) はそれ単体だとUnwind Informationを生成できないので、Cプリプロセッサを使ってマクロを読み込んでUnwind Informationを生成しないといけないという面白状態 (それもドキュメントがないのだけど、dotNETとかChakraのコードを読めば理解できる) なのだが、Cプリプロセッサ通さなくてもいいようにしてほしいと願ってる。

Web Replay

Mozillaとして今年はWeb or アドオン開発者へ向けての機能を充実させようというのがテーマにあるんだけど、Brian Hackett (元々SpiderMonkeyの型推測とかやってた人) がWeb Replayというものを作ってる。まだ本体には入っていないのだけど、これはRecording & Replayデバッガと呼ばれてるもの。

デバッグをしていと誰もが経験すると思うのだけど、ブレークポイントを仕掛けて止まった時に、調べようと思ってた現象 (バグ) がすでに起きてしまってて、「あー、このポイントでは遅かったか。。。」ということは何度も経験あると思う。そうするともう一度デバッグのやり直しになると思う。Recording & Replayデバッガがあると、その際にその現象が起きるところまで巻き戻すことができる。そのためデバッグの効率が非常に高くなる。

またその一連の動作を保存できれば、現象を何度も起こす必要なくそれを再生すればいいだけなので、QAが見つけてきたものを開発者がより効率的に調査できる。

そのような機能をFirefoxに搭載しようとしていて、これがWeb Replayと呼ばれているもの。

ちょうど今月のJSConf EUでJason Lasterがそのプレゼンやっててビデオがここにある。10分くらいからそのデモがある。


こういう機能がブラウザに入ればよりデバッグが楽になるよね！Firefox 63 or 64くらいかなと。

追記

Replyじゃなくて、Replayですね。emkさんありがとうございます。

Windows 10 + Snapdragon 835を採用したASUS NovaGoを手に入れてみた

これはWindows/arm64 (Windows on Arm) を採用し、Snapdragon 835を搭載したラップトップ。まずこのarm64を採用したWindowsの最初のリリースはHP Envy x2とこのASUS NovaGoとLenovo Miix 630はこの3機種。HPのは3月リリース、Lenovoのは6月。ASUSは4月くらいにはリリースされてたようなんだけど、6月になってやっと手に入りやすくなった。NovaGoがAmazon.com (US)で入手可能になったので手に入れてみた。なおUSのMicrosoft Storeでもオーダー可能になってる (日本へ発送可能かは知らない)

お値段は、本体価格が699ドル+送料で、781.08ドル。輸入コストも考えると比較的安く手に入った。(ホントは6月にアメリカ行ってる時に現地で入手したかったけどどこにもなかった)

普通に起動 & セットアップして、Windows Sモードを解除 (Microsoft StoreでWindows 10 Proを入手すればいいだけ。無償) した後、いろいろテストしてみた。

アプリケーション

• Edgeは当然のことながらネイティブアプリケーション
• x86なアプリケーションを動かすためのJITはXTCACHEというプロセスがやっている模様
• arm64なネイティブアプリ以外にも、arm 32bit (ARMNTと呼ばれるThumb2モードのみのもの。Surface RTとかWindows Phone 8以降で使ってたモード。これもネイティブで動作可能)、x86 (これはJIT使って動的にarm64へ変換してるはず)、と3つのアーキテクチャをサポートしてる
• \Windows\SysWow64、\Windows\SysArm32、\Windows\System32と各CPUモード毎にSystem32ディレクトリがある。なお、\Program Filesも\Program Files (Arm)とか\Program Files (x86)とか存在する
• Windows Subsystem for Linuxはversion 1803に上げると使える。
  
• Internet Explorer 11も含まれているけど、どうもx86版のみ
  
• Firefox (x86)は動作するけど、Chrome (x86)はVersion 1709だとちょくちょくクラッシュする。Version 1803にすれば安定するし、パフォーマンスもちょっとよくなる

WebブラウザのJITで生成されたコードをJITでarm64に変換するのはよりコストがかかる (モジュールだったら一回コンパイルした後キャッシュ持てばいいだけだし) ので、もっと遅いかと思ったら、まぁこんな程度でしょう的な感じ。これはFirefoxでSunSpiderを実行した結果

Edgeだと

開発環境

• Visual Studioはx86なら動くのでインストール可能。x86_arm64なクロスコンパイラがあるので、これでクロス環境でなくてもネイティブアプリを作ることはできる (amd64_arm64なコンパイラだと起動できないため)
• デバッガ (cdb、windbg) はネイティブ版 (arm64) がWindows SDKに含まれているので、それを使えばネイティブアプリをデバッグ可能
• 生成コードを見る限りUNIXなAArch64 ABIと同様。ARMNT (Thumb2) の時と同様これはarmの定義したABIをそのまま使ってる

ファーストインプレッションはこのような感じです。

x86/x64最適化勉強会に行ってきた

申し込もうと思ったら、もうすでに満席だったのでLTやるということで参加できた。セーフ。

何をLTで話そうと考えてたのだけど、ScalewayのARM64クラウドが思ったよりパフォーマンスがよくなくて、その理由を調べてたところこれがThunderXを採用してたために遅かった。それでいろんなベンチマークを取ってたら20ドルで買ったPINE64よりも遅い話が見つかったのでnssのコードを書くのとARMv8の勉強を兼ねて発表してきた



FirefoxではOpenSSLを使わずにNetscape由来のnssというライブラリを使っていて、今はRedHatと共同開発ということになっている。これがARMの上だと全く最適化を入れていない (昔ARMv7の頃に最適化は自分が書いた) し、ARMv8にはせっかくAESとかSHA256とかのハードウェア命令が入っているので、それを使ってみようということで3日間くらい仕事終わりの深夜にコードを書いてた。

パフォーマンスデータもCortex-A72とかNVIDIA Danverとかのデータを取りたかったけど、android/aarch64用にベンチを取るためのコンパイル環境を整える時間がなかったので、取ってない。取ったら資料をアップデートするかも。Cortex-A72の解析用にHiKey960買おうかな。

ということで、いろいろ勉強にはなったので、後でパッチを投げておく。たぶんFirefox 62には間に合えばって感じで。

追記 (2019.7)

AESやGCMの最適化はGecko 70には入ります。なのでFirefox Preview (Fenix) の次のメジャーバージョンには含まれます。

追記 (2019.11)

最適化が入るのは71に変更になりました。Firefox for Androidは68で終了 (後継バージョンはFenix) なので、関係するのは、Linuxディストリビューションとかに含まれるLinux版くらいです。

2017年に買った物

デスクトップPC

家のデスクトップPCはずっとSandBridge世代を使ってたので、デスクトップをi7-7700で組直した。以前のPCはそのままicecreamのクラスタに参加してるので、これで家のビルド環境は1.5倍くらいには早くなったと思う。

YubiKey 4

今働いてる会社だと2段階認証を使ってるので、いちいちスマホで認証するのも面倒だってことで、会社で使ってるワークステーション用に購入。便利ですよね、マジで。これを複数買うって言ってる人達の気持ちが非常に分かります。2018年はFirefoxでもFIDOサポート入るしね

GPD Pocket

LibrettoやVAIO Pのオーナーだった自分としては買わないと行けないでしょ！ってことで購入。でもキーボード配列が変態過ぎるためコーディングには使いづらいし、スペースキーを深く押さないと認識してくれないので、LibrettoとかVAIO Pとかはキーボードが超優秀だったんだなと改めて認識した。

ということで使う時はLGのBluetoothキーボードとともに使ってる。

OSはDebian/sidに入れ替えたのだけど、最新カーネルを使わないとブートしないとか音が鳴らないとかbluetoothを使うためにはちょっとしたスクリプトを実行する必要があるとか細かい不具合はあるのだけど、Libretto 20の頃なんてUSB-FDDを使うためにドライバ書いたりしたけど、今は楽になったなぁと感じる。

Amazon Echo Plus

Alexa使ってみたくて。でもAmazonのオーダーを試そうとしたけど、自分の欲しいものを上手く認識してくれない。また音楽もロックやダンスミュージックばかりで、これも認識するのが非常につらい。まだ自分にとっては音声認識は早かった模様。

ということで目覚ましと天気予報として使ってる。2万円する目覚まし時計ですね。