2020年、今年買ったもの

OPPO A5 2020

サブ機＆検証機として購入。値段 (安くて2万円) からすると非常に出来はいいですね。日本 (東京) でビジネスするにはSuicaがあったほうがより売れるだろうなというのはあるし、Suicaがないから別にメインで使うこともない。

秋に普段使いしているXPERIAを修理に出しているときに、メイン端末として使ってたので、ちょうどいいタイミングだった

Rakuten Mini

楽天モバイルの無料サポータープログラムにあたったのでその端末として購入。各サービスのパスワードはランダムにしているためパスワードマネージャが使えないとパスワードの入力ができないのだが、この端末は指紋認証がないため、パスワードマネージャを使うたびに (この小さい端末のソフトウェアキーボードで) 非常に長いパスワードを入力するはめになり、そのことがまったく普段使用に耐えられなかった。少なくともこのサイズでリリースするのであれば、指紋認証ないと無理。

なお、楽天モバイルは自分の行動範囲であれば大概つながるので、一日10GB制限な高速ネットワークの恩恵は受けている。しいてあげればWiMAXのように速度制限を夜だけにしてくれればとは思う

Ryzen 9 3900X

Zen 2のマシンが欲しかったのもあったけど、12コア24スレッドで6万円強という値段を見て、マザボとかを含めても8万円と考えたら安いと思って購入。その後電源容量が足りなくて電源も買い直し。コアが多いとFirefoxのビルド時間が短縮できて満足してます。

MacBook Air 2020

以前から持ち運び用としてMacBook 12インチを持っていたのだけど、一部キーボードが反応しなくなってきたという理由と、AppleのARM初ラップトップということで購入。Qualcomm等のチップだとARMv8.2までのサポートで、Appleくらい (あとはMarvellのThunderX3) しかARMv8.3に対応しているとかはなかったので期待してたのだけど、思ったよりも高パフォーマンスだった。

不満は前まで使ってたMacBookよりも重いということ

Dyson Pure Cool Me

空気清浄機＋扇風機的なのが欲しかったので購入。使う場所は仕事部屋 (4.5畳もない) なのでこのモデルにした。これを買ったもう一つの理由はディスカウントで2万円くらいで手に入ったということ。

そもそもこの仕事部屋についているエアコンが壊れてしまったので (引っ越すかどうかを決めてないので買い直してない)、この夏には欠かせないものになってた。

ヘルシオ ホットクック KN-HW10E

ちょうどコロナ禍の前に購入。電気圧力鍋を買うかどうかを悩んできたのだけど、ホットクックだと低温調理もあるし、面白そうなのでということで。材料だけ切って入れてしまえば、ある程度料理ができるという手抜き料理には役に立っている。

ただレシピ本とかだとこの1.6か2.4リットルのサイズのものが大半なので、1.6の方を買えばよかったかもとちょっと後悔してる

ワッフル＆ホットサンドベーカーVWH-50-R

つい12月に購入。中のプレートを外して洗えるのはいいですね。まだ購入して日が浅いのでそのくらい

Apple M1のSHA512命令

新しいARM Crypto Extensionだと、中国系のSM3とかSHA3とかSHA512とかの専用命令があるのだけど、Appleは比較的こういうところに投資をしてるので、Appleのチップだと実装されている。

パフォーマンス的な情報はインターネットに転がっていないので、試しに手元で実装してみた。データはいつもの通りのNSSでのデータ。

実装前のデータはこれ。

#     mode          in  opreps  cxreps     context          op   time(sec)     thrgput
sha512_e         1Gb     15M       0       0.000   10000.000      10.000       168Mb

実装するとこうなる

#     mode          in  opreps  cxreps     context          op   time(sec)     thrgput
sha512_e         4Gb     47M       0       0.000   10000.000      10.000       503Mb

SHA1、SHA256と同様に3倍くらい速くなる感じですね。

SHA256とは違って、ROUNDに対するレジスタが足りないので、extを使って、利用するベクタを選択しながらループしないといけないのでシンプルにはならない

#define ROUND(n, a, b, c, d, e, f, g, h, w0, w1, w2, w3, w4)              \
    {                                                                     \
        uint64x2_t t, fg, de;                                             \
        t = vaddq_u64(a, vld1q_u64(K512 + n * 2));                        \
        t = vreinterpretq_u64_u8(vextq_u8(vreinterpretq_u8_u64(t),        \
                                          vreinterpretq_u8_u64(t), 8));   \
        de = vreinterpretq_u64_u8(vextq_u8(vreinterpretq_u8_u64(w1),      \
                                           vreinterpretq_u8_u64(w2), 8)); \
        fg = vreinterpretq_u64_u8(vextq_u8(vreinterpretq_u8_u64(w2),      \
                                           vreinterpretq_u8_u64(w3), 8)); \
        w3 = vaddq_u64(w3, t);                                            \
        w3 = vsha512hq_u64(w3, fg, de);                                   \
        w4 = vaddq_u64(w1, w3);                                           \
        w3 = vsha512h2q_u64(w3, w1, w0);                                  \
        if (n < 32) {                                                     \
            a = vsha512su0q_u64(a, b);                                    \
            a = vsha512su1q_u64(a, h,                                     \
                                vextq_u8(vreinterpretq_u8_u64(e),         \
                                         vreinterpretq_u8_u64(f), 8));    \
        }                                                                 \
    }

なお、SHA512のIntrinsicsはgccの最新であれば実装されているが、clangの場合は最新のコードでも実装されていないので、インラインアセンブラ使うなりアセンブラで書かないといけない

Apple M1におけるARM Crypto Extensionのベンチマーク

MacBook Airを入手したので。NSS (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS) に含まれるbltestでのベンチデータ。比較対象にAWSのm6g.mediumのデータを置いておく

Apple M1 with ARM Crypto Extension (xcode's clang)

#     mode          in symmkey  opreps  cxreps     context          op   time(sec)     thrgput
 aes_ecb_e        24Gb     256      1B       0       0.000   10000.000      10.001         2Gb
 aes_ecb_d        23Gb     256      1B       0       0.000   10000.000      10.000         2Gb
 aes_cbc_e         7Gb     256    532M       0       0.000   10000.000      10.000       812Mb
 aes_cbc_d        24Gb     256      1B       0       0.000   10000.000      10.001         2Gb

#     mode          in  opreps  cxreps     context          op   time(sec)     thrgput
    sha1_e         8Gb    282M       0       0.000   10000.000      10.000       861Mb
  sha256_e         8Gb    155M       0       0.000   10000.000      10.000       828Mb

AWS m6g.medium with ARM Crypto Extension (Ubuntu's clang 10)

#     mode          in symmkey  opreps  cxreps     context          op   time(sec)     thrgput
 aes_ecb_e         8Gb     256    550M       0       0.000   10000.000      10.000       840Mb
 aes_ecb_d         7Gb     256    502M       0       0.000   10000.000      10.000       766Mb
 aes_cbc_e         6Gb     256    465M       0       0.000   10000.000      10.000       710Mb
 aes_cbc_d         6Gb     256    442M       0       0.000   10002.000      10.002       674Mb

#     mode          in  opreps  cxreps     context          op   time(sec)     thrgput
    sha1_e         4Gb    141M       0       0.000   10000.000      10.000       430Mb
  sha256_e         3Gb     66M       0       0.000   10000.000      10.000       354Mb

AES-CBCモードのEncryptionだけなぜか遅いという結果。ECBモードだと変わらないので、clangが生成したコードがApple M1のパイプラインでペナルティが発生するような状態と推測される。

なお、ARM Crypto Extensionを無効にすることもできるので、その場合。

Apple M1 without ARM Crypto Extension

#     mode          in symmkey  opreps  cxreps     context          op   time(sec)     thrgput
 aes_ecb_e         2Gb     256    155M       0       0.000   10000.000      10.000       236Mb
 aes_ecb_d         2Gb     256    143M       0       0.000   10000.000      10.001       218Mb
 aes_cbc_e         1Gb     256    133M       0       0.000   10000.000      10.000       203Mb
 aes_cbc_d         1Gb     256    130M       0       0.000   10000.000      10.000       199Mb

#     mode          in  opreps  cxreps     context          op   time(sec)     thrgput
    sha1_e         3Gb    108M       0       0.000   10000.000      10.000       331Mb
  sha256_e         1Gb     21M       0       0.000   10000.000      10.000       113Mb

AWS m6g.medium without ARM Crypto Extension

#     mode          in symmkey  opreps  cxreps     context          op   time(sec)     thrgput
 aes_ecb_e         1Gb     256     82M       0       0.000   10000.000      10.000       126Mb
 aes_ecb_d         1Gb     256     80M       0       0.000   10000.000      10.000       122Mb
 aes_cbc_e         1Gb     256     81M       0       0.000   10000.000      10.000       124Mb
 aes_cbc_d         1Gb     256     73M       0       0.000   10000.000      10.000       112Mb

#     mode          in  opreps  cxreps     context          op   time(sec)     thrgput
    sha1_e         1Gb     45M       0       0.000   10000.000      10.000       139Mb
  sha256_e       872Mb     16M       0       0.000   10000.000      10.000        87Mb

AWSのarm64インスタンスでarmhfなバイナリを動かす

自分用メモ。AWSのa1またはm6インスタンス上のUbuntu 20.04はarm64バイナリは実行できるが、32-bitなARM、例えばarmhfは実行できない。チップはA32を実行できるようなので、multiarchを使えば動く。これでA32のテストも可能。

例えば、

dpkg --add-architecture armhf
appt update
apt install gcc-arm-linux-gnueabihf libc6:armhf

な感じ。

Chat Channels of Web Engine

メジャーブラウザを作っている三者 (Apple、Google、Mozilla) は知ってる限り、各ブラウザプロジェクト用チャットチャンネルを持っている。FreenodeにChromiumとWebKitのチャンネルはあるのだけど、実際そんなに使われているわけではなくて、別のものを使っている。AppleとGoogleはSlackに、MozillaはMatrix上に存在する。Mozillaも社内向けには別のチャンネルがあるし、ずっとIRCサーバーを運用してたのだけど、最近Matrixに移行した

Chromium

https://chromium.slack.com/。chromium.orgアカウントを持っているとか、彼らにとってのパートナー会社であれば、Slackのチャットサーバーに入ることはできる [*]

Gecko

https://chat.mozilla.org/。githubアカウントでもFirefoxアカウントでも入ることが可能

WebKit

https://webkit.slack.com/。https://webkit.org/getting-started/に招待リンクがあるから、そこから入ることはできる

メモとして残しておく

IS_PRIVATE on Windows 10 20H1

昔書いたHow to use Microsoft IME's private mode on not IE/Edigeの続きの話。

このとき調べたようにMicrosoft IMEにおけるPrivate Mode (変換情報を学習しない) という機能は、Microsoft IMEがIE内部の隠しAPIを呼ぶことで実現してた。そのためMicrosoft EdgeやInternet Explorerでのみ使える機能で他社のWeb Browserでは使うことができなかった (というかWeb Browserに限定しないけど)。

で時は過ぎ、Microsoft EdgeがChromiumベースになることになった。Chromiumベースになったということでこれで晴れて公開APIができると思ったけど、全くそんなことはなかった。ただ、非常に面白いパッチがChromiumに入った。

For TSF1 on Windows 10, we need to set input scope to IS_PRIVATE if we
are in "Incognito" or "guest" mode.

Bug: 958054
Change-Id: I35e4adec0fd1800cff1ec2fcfe7983e2a65540e8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1591886
Commit-Queue: Siye Liu 
Reviewed-by: Yohei Yukawa 
Cr-Commit-Position: refs/heads/master@{#657438}

この修正を見たところ、「以前Microsoft IMEはIS_PRIVATEを見てないはずなのに。もしかしてWindows Insiderビルドで直ってたの？」と思ったのだけど、ダウンロード可能なWindows Insiderビルド+Chrome Canaryで全然直ってない。あれ？ということで、MicrosoftのIMEチームへ直接コンタクトしてみたところ、「IMEチームのバグリストには存在してるんですが。。。」的な回答が返ってきた。さすが自分がいたころ (10年以上前) と一緒で、縦割りすぎて横連携できない会社のままだなぁと思ったのだが、それで放置しても誰も得をしないので、IMEチームの人といろいろやり取りして、Windows 10 20H1のMicrosoft IMEではInputScopeのIS_PRIVATEを見るようにしてもらいました。IS_PRIVATEをつけてる場合は、IMEは学習しないようになっているため、もしアプリケーションでIMEの学習機能を無効にしたいのであれば、IS_PRIVATEを使ってください。FirefoxでもWindows 10 20H1を使えばプライベートモードであれば学習しないようにしてます。

キオクシアのNVMeを買ったらハマった

ブラウザの話じゃないです。

10万円の給付金が入るので、自宅のPCをいろいろアップグレード(Ryzenにとか)したのだが、OSの起動ディスクは未だHDDを利用している。自宅で仕事をすることも多いので、OSの起動ディスクのアップグレードを行おうと思いNVMeを買うことにした。せっかくだから応援の意味も兼ねて日本のキオクシア(旧東芝メモリ)に。

今使ってるマザーボードは、ASRockのB450 Steel Legendなのだが、まぁ相性とかの問題なんて今更起きないだろうと高を括ってた。買ったキオクシアのNVMeはSSD-CK500N3P/NでAmazonの評価を見る限り、まぁまぁ良い感じ。ちょうどタイムセールで安くなってたのでオーダーした。

ちょっと届くのに時間がかかったが、無事到着。マザーボードのM2スロットの刺してブートしてみたけど、認識しない。あれ？。もうひとつのスロットに挿しても当然のように認識しない。マザーボードのサイトを見たところ最新のBIOSがおいてあったので、それにアップデートしてみたけどそれでも認識しない。一瞬NVMe側の問題と思ったけど、でも納得行かないので、PCI ExpressスロットにNVMeを直接させる変換カードを買ってそれを使ってみたところNVMeを認識した。マザボ側とキオクシア側の問題かということで決着した。

なお、その後kakaku.comのBBSで同じ問題にハマってる人がいるのを発見。まぁなんというか、キオクシア買うのは早々だったなぁと。

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) なので、実験端末として有望でした。

WebKitとBlinkのスタンスの違い

最近WebKitとBlinkの実装が異なってることでいろいろ困っているんですが、その話はさておき、WebKitのスタンスが明確にわかるようなメールスレッドが最近あった。

Web NFCのエディタのFrançois Beaufort (Google)がWebKitサイドへWeb NFCについての意見を聞きたいということで、webkit-devにメールを投げたのだけど、そのお話。

メールスレッドはこれ。
https://lists.webkit.org/pipermail/webkit-dev/2020-January/031006.html

事実上WebKitトップのMaciejが、

We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification.

という話を出ししてて、まぁプロンプト程度で有効にするしないで決められるようなAPIはおそらく実装されることはないんだろうなと

In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.

ということで、WebKitに関しては基本的にデバイスを触るようなAPIは(よほどのユーズケースがない限り)実装されるのはほぼないようだ。

なお、出来レースなんだろうなという感の強いblink-devへのIntent to experimentは全くこういう話を語られることはないし、LGTMとしか反応がない感強いし、もし議論があったとしてもたぶんpublicな場で議論することはないんだろうなと。

webkit-devでは、とどめにniwaさんに、

I'll go off a bit on a tangent and say that one of the primary strengths of the Web is that users can visit any website without the fear of their computing devices being permanently compromised

というように、"Web" というものの利点が語られて、

If we continue this path, at some point (or maybe we're already there), the Web will turn into any other non-Web platform where ordinary users can (or are advised to) only use well known trusted applications or visit well known trusted websites just like how native apps work today.

言われてて、WebKitの考えるWebの利点と反するようなものはWebKitでは実装されないのだろうとわかる。

いろいろなMeet upでたまにDevice API系の話 (WebUSBとかWebMIDIとか) をする人を見かけるけど、WebKitがこんな感じなのでWICGとかを抜けて標準化に持ってくもの (≒2つのエンジンの合意) はほぼなさげだよなと (Mozillaはプライバシー問題が解決されないものは基本実装されない感じ)