Edge/ARM64の出来をみると、Windows on ARMのx86エミュレーターは結構速い

WebCrypto APIのベンチマークというのは結構難しくて、そもそも現在のWebCrypto APIはPromiseベースの実装のため、下手をするとWebブラウザに実装されたマイクロタスクをテストするだけのものになることもある (≒なのでベンチマークを取るとったとしても正確なデータかというと、、、な時がある。WebCryptoを使ったベンチマークを説明する時にPromiseの話を触れない人は正しいマイクロベンチマークを書くことが出来ない人なのかもしれない)。Promiseで結果を返すようなAPIはベンチマークが正しい結果を出すとは限らないのだが、それを抜きにしても面白いデータが取れたのでここに書いておく。

jsperf.comに簡単なWeb Cryptoのベンチが置いてあったのだけど、まずx86版ChromeをWindows 10 on ARMで動かしたデータが以下になる。

これをARM64版Edgeで実行すると以下になる。

なんとx86版のほうがAESのベンチマークが圧倒的に速いという結果になる。これはx86版はAES-NIをちゃんと使っていて、x86エミュレーターがちゃんとAES-NIをARM専用命令に置き換えているからと思われる。

ARM64にもAESは専用命令があるのだが、OpenSSL/BoringSSLでは、アセンブラで書かれているコードでARMの専用命令を使っていて、これはGNU AS用のアセンブラコードなので、MicrosoftのARM RealView形式のアセンブラと互換性がないから、おそらく無効にされているのだろう。

なお、ARM64版Firefoxだとこういう結果になる

これはちゃんとしたネイティブ実装 (by 自分) をしており、AESとSHA2はARM Crypto Extensionを使った実装になっているので、ちゃんとネイティブの方が速い。

ネイティブ版でも必ずしもエミュレーターよりも常に速いわけではない。というよりも、もっとARMに対してやる気出せよ、Microsoftと。

結局Flexispotを買った

個人的に家で働くのは好きではないのだけど、一ヶ月ほど家で働いてる。家にもデスクトップPCがあるので効率はさほど変わらないのだが使っている机の高さが若干低くて (あと10-20cm高いものがほしい)、今使っている椅子、Vitra ID Meshとの相性が若干悪かった。いっそうのことスタンディングデスクを買おうとずっと思っていて、IKEAに行くたびにスタンディングデスクを見てたのだけど、この際だからということでFlexispotのEC1を買った。天板は今使っている安い机の天板を流用することにしたが、もし変えたくなれば買い直せばいいやということで。

いろいろなブログをみたところ、組み立ての話が出ているけど、ただ重いだけで組み立ては難しいわけでもなかった。IKEAとかと変わらない。

あと、感想としては、スタンディングデスクをなぜ今まで買わなかったのかということだけですね。モニタ (DELL P2415Qをずっと使ってる) はモニターアームで固定しているので、上げ下げしても問題ないしね。

真ん中にあるのは、某社に5年いるともらえた置き時計 (今はもうこれはもらえないらしく、鈍器な置物に変わったらしいが)。10年だと10株もらえるってのは面白いところだったけどね。

Twitterの仕様の認識間違いに対してのMozillaの反論

TwitterがMozilla Firefoxに保存されているTwitterデータのキャッシュについてというブログを書いてきたことに対して、Mozillaから反論のブログが書かれているのだが、内容としてはよくありがちなWeb開発者のミスではある。Mozillaのblog.mozilla.orgの方はEric Rescorla (ekr) が書いてて、Mozilla Hacks Blogの方はMatrin Thomson (mt) が書いているのだが、彼らが誰かを知ってると、この指摘はなおさらタメになる話である。

そもそもekrは今Firefox CTOという役職ではあるが、RFCのTLS 1.1 / 1.2 / 1.3のAuthor。

またmtはRFCのHTTP/2のAuthor。

仕様を作ってる張本人たちから指摘されるという面白い展開ではあった。

safe-area-insets が本当に使われているとは思えない

Webの仕様はいろんな議論の末にできるものではあるけれど、ある種の企業の都合が発生する場合はそうではない。例えばノッチがついたデバイスがリリースされることが決まった場合、ノッチをどうWebの仕様で盛り込むか？と考えた時、企業の都合 (iPhone Xのリリース日までにはどうにかしたいとか) が多々発生するし、そういうことに依存した仕様ってのは実装も含めて適当なことがたまにある。

ノッチ部分を除いた表示エリアを定義できるsafe-area-insetsというものがCSS Environment Variables Module Level 1で定義されてるのだが、これについてWebKit Blogで、Designing Websites for iPhone Xで解説されている。ようはノッチが含まれないエリアをマージンなどで指定すれば、ノッチのエリアにコンテンツが配置されないようにできる機能。

これがBlinkでの実装がどうなるかというと、フルスクリーン表示のみこのsafe-area-insetsが適用される模様で、WebKitのようにデバイスを回転した場合にちゃんと適用されるわけではない模様。動作をテストする限り、彼らはこれはフルスクリーンでのみ適用するような実装をしてしまってる。

また、Android特有の話にはなるのだけど、フルスクリーン表示をしようとして、 System UI visibilityを変更しようとしても、ちゃんと色々考慮しないとデバイスによってはちゃんとステータスバーが簡単に消えないものがあったりする。Blinkは、もしこのステータスバーが消えてなかったとしても、safe-area-insetsが適用してしまうようで、WebKit Blogのようなサイトを作ったとしても、ノッチとは関係ない変な空白ができてしまうことになる。(OPPO A5とGalaxy S10でテストした限り、間抜けな感じになる。これらでテストする限り、ステータスバーが消えない)

だからこのsafe-area-instes、これがマトモに使われてるとは思えない。無駄な空白が空いてしまうし、フルスクリーンではない時に逆にノッチ領域を除外できないし。一番使われているであろうWebブラウザでね。

それよりも当然バグとして報告はしてあるんだけど、バグと認めさせる (=というよりも、まずフルスクリーンの時にステータスバーが消えてないのがまず大きな問題の一つ) のは面倒ではあったけど、おそらくすぐ直るとは思ってないから、この動作大丈夫なのと本当に思ってる。

なお、Firefox Previewはviewport-fit値はまだ見てないけど、Firefox Preview NightlyであればWebKit Blogのサンプルはちゃんと動作するはず。

Rakuten miniを手に入れた

最近手に入れたいと思う端末がまったくなかったのだが (開発用で仕方なしに手に入れることはある)、久々に地雷感のするものが現れた、楽天モバイル。無料サポーターに当選したため、ついでにRakuten miniも手に入れてきた

Rakuten miniの契約だけは実店舗に行かないといけないようなので (おそらくeSIMのみの端末のため、設定も含めて面倒みるからだとは思う)、仕方なく実店舗への予約をする羽目に。この予約をWeb経由でしようとしたが平日の昼間しか空きがなかったが、ネットの情報を見る限り、直接店舗に行けば (待ち時間があれど)、予約できるようなので、恵比寿の楽天モバイルまで行くことにした (いつも通うジムの通り道にあったのだけど、いつ出来たの？)

店舗での契約も実に効率よくできてて、

• 予約をしてなくても店舗の端末で電話番号の登録すれば問題ない。契約可能になれば電話 (またはメールなど) で教えてくれる
• 通知の際の電話は、自動音声。オペレーターを排除してる
• Surface端末でいろいろ店員が入力して、自動車運転免許証の写真をとるだけで基本的な契約は終了
• 楽天IDと紐づくので、楽天IDでいろんな処理を簡素化

特にドコモのような従来の店舗だと、店舗で待たないといけない状況だったりするので (今は変わってるかのかもしれないが)、こういうところは楽天に好感を持った。他社も楽天のように受付だけは店舗の外で待てるような仕組みがほしい (ネットだとできないことをするために仕方なしに行くと本当につらい)。ドコモショップとかはドコモ直営じゃないところがほとんどだから致し方ないけどね。

なお、いいことばかりでもなくて、残念なところは楽天IDと紐づくためにパスワードを入れないといけないところ。自分の場合は楽天IDのパスワードがランダム生成された非常に長い英数字記号を含むものだったこと。まぁ入力つらい。特にRakuten MiniのサイズでしかもiWnnで入力しないといけない (記号入力ほぼ不可)。GBoardも入ってたので、それに切り替えて事なきを得た。

このRakuten Mini、GPUがAdreno 505なので、Firefox Preview NightlyだとWebRenderがデフォルト有効 (Bug 1602597) なので、実験端末として有望でした。