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と。
2020-06-08
2018-12-10
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の一番の判断のミスは、古いOSへのサポートがなかったことだろう。WinRTのサブセットをWindows 7に持ってくるか、二つのOS対応のコードを作ればよかったのでは (MainsoftがInternet Explorer 5に対して行ったようにshimレイヤー作ればよかった。Tridentだって抽象化レイヤーあったのに)。EdgeがWindows 7で動かない以上、Internet Explorer 11へ対応することが求められる。Internet Explorer 11だって2013年のリリースだから5年前。そりゃつらい。
個人的な感覚で言えば、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みたくいろんな戦略を間違った結果なんだよね。たらればだけど。ソフトウェアライフサイクルの定義は難しい。2016-01-08
How to add API status to Firefox Platform Status
ChromeやEdge、WebKit (決してSafariではない) に続き、Firefoxもステータスページを作った。
MDNにも対応情報はあるがこれの情報はMDNと同期してるわけではない。また、例えばChrome Statusとかcaniuseには載っているけど、FirefoxのStatusにおなじ情報がないってのもある。
ただ当然のことならが、githubにこのコンテンツ用のレポジトリが存在してて、issueを立てたりPull Requestを送ることで、ここに項目を追加したり情報を修正することは可能になってる。実際features配下へマークダウンファイルを追加することで項目を追加できる (実際、実装やってたAPIのIssue投げたらPull Request投げろって言われて投げた)。詳細はCONTRIBUTING.mdに書いてある。
なお、Chrome Statusは、https://omahaproxy.appspot.com/からJSONとかでも取得できる。
何か情報が間違ってれば、WebKit以外は以下のgithubでissueとかを投げられるし、WebKitもhttps://bugs.webkit.org/に投げれば拾ってくれるはず。
MDNにも対応情報はあるがこれの情報はMDNと同期してるわけではない。また、例えばChrome Statusとかcaniuseには載っているけど、FirefoxのStatusにおなじ情報がないってのもある。
ただ当然のことならが、githubにこのコンテンツ用のレポジトリが存在してて、issueを立てたりPull Requestを送ることで、ここに項目を追加したり情報を修正することは可能になってる。実際features配下へマークダウンファイルを追加することで項目を追加できる (実際、実装やってたAPIのIssue投げたらPull Request投げろって言われて投げた)。詳細はCONTRIBUTING.mdに書いてある。
なお、Chrome Statusは、https://omahaproxy.appspot.com/からJSONとかでも取得できる。
何か情報が間違ってれば、WebKit以外は以下のgithubでissueとかを投げられるし、WebKitもhttps://bugs.webkit.org/に投げれば拾ってくれるはず。
- Chrome ... https://github.com/GoogleChrome/chromium-dashboard/
- Edge ... https://github.com/MicrosoftEdge/Status
- Firefox ... https://github.com/mozilla/platatus/
登録:
投稿 (Atom)