HiFive Unmatchedが届いた

RISC-Vの話は、実際のシリコンでの話は少く、大概エミュレーター作ったとかFPGAに実装してみてるとかが多く、(FPGAじゃない) 実際のシリコンでの話ってのは少ない。シリコンのデザインをしてる会社のプレゼンテーションを見ると大体このくらいのパフォーマンスという話は出ているが、実シリコンの話はプレゼンテーションの中の(都合のよい)話でしかなく、ソフトウェアエンジニアであれば、実際のシリコン上での動作を見てみたいものだ。

ということで、半年前くらいにオーダーしてたHiFive Unmatchedが届いた。このボードはSiFiveのSoC (SiFive Freedom U740) を載せており、しかもPCIe、NVMeスロット付という自分が待ち望んでいた感じのもの。ただしお値段は$679+4,200円。Mac Mini買える値段。

簡単にUNIX Benchmarks走らせた結果。RasPi3クラスかなって程度だが、コンパイラ自体の成熟度が増せばいろいろ違うだろうし、そもそもこのテストはSDカード上で行っているので、ストレージをSDカードからNVMeに変更すればまた違う

   BYTE UNIX Benchmarks (Version 5.1.3)

   System: unmatched: GNU/Linux
   OS: GNU/Linux -- 5.11.10 -- #1 SMP Wed Apr 7 17:37:34 UTC 2021
   Machine: riscv64 (riscv64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   08:19:19 up 16 min,  1 user,  load average: 0.32, 0.23, 0.21; runlevel 2020-12-17

------------------------------------------------------------------------
Benchmark Run: Mon May 31 2021 08:19:19 - 08:47:43
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        4443367.3 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1189.1 MWIPS (9.8 s, 7 samples)
Execl Throughput                               1502.3 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         85504.8 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           40618.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        116919.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              299710.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  54294.3 lps   (10.0 s, 7 samples)
Process Creation                               2426.7 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    905.7 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    358.4 lpm   (60.1 s, 2 samples)
System Call Overhead                         586221.6 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    4443367.3    380.8
Double-Precision Whetstone                       55.0       1189.1    216.2
Execl Throughput                                 43.0       1502.3    349.4
File Copy 1024 bufsize 2000 maxblocks          3960.0      85504.8    215.9
File Copy 256 bufsize 500 maxblocks            1655.0      40618.3    245.4
File Copy 4096 bufsize 8000 maxblocks          5800.0     116919.4    201.6
Pipe Throughput                               12440.0     299710.9    240.9
Pipe-based Context Switching                   4000.0      54294.3    135.7
Process Creation                                126.0       2426.7    192.6
Shell Scripts (1 concurrent)                     42.4        905.7    213.6
Shell Scripts (8 concurrent)                      6.0        358.4    597.3
System Call Overhead                          15000.0     586221.6    390.8
                                                                   ========
System Benchmarks Index Score                                         260.2

------------------------------------------------------------------------
Benchmark Run: Mon May 31 2021 08:47:43 - 09:16:48
4 CPUs in system; running 4 parallel copies of tests   

Dhrystone 2 using register variables       17753848.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     4712.2 MWIPS (9.9 s, 7 samples)
Execl Throughput                               5703.9 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        159065.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           65531.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        208282.9 KBps  (30.2 s, 2 samples)
Pipe Throughput                             1179603.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 248734.2 lps   (10.0 s, 7 samples)
Process Creation                               9186.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2695.8 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    395.6 lpm   (60.1 s, 2 samples)
System Call Overhead                        2176448.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   17753848.1   1521.3
Double-Precision Whetstone                       55.0       4712.2    856.8
Execl Throughput                                 43.0       5703.9   1326.5
File Copy 1024 bufsize 2000 maxblocks          3960.0     159065.0    401.7
File Copy 256 bufsize 500 maxblocks            1655.0      65531.5    396.0
File Copy 4096 bufsize 8000 maxblocks          5800.0     208282.9    359.1
Pipe Throughput                               12440.0    1179603.9    948.2
Pipe-based Context Switching                   4000.0     248734.2    621.8
Process Creation                                126.0       9186.8    729.1
Shell Scripts (1 concurrent)                     42.4       2695.8    635.8
Shell Scripts (8 concurrent)                      6.0        395.6    659.3
System Call Overhead                          15000.0    2176448.1   1451.0
                                                                   ========
System Benchmarks Index Score                                         737.3

Windows 10Xがなくなった今、今年最大のオモチャかも

サードパーティ製IMEは、Web Browserのプライベート・シークレットウィンドウなんて考えてくれない

最近のブラウザは、プライベート・シークレットモードが搭載されている。このモードになれば、ブラウザはCookieを保存しないとかいろいろプライバシーを考慮された動作になる。 ただ、いくつかの言語 (とAndroidのようなソフトウェアキーボードを使う場合)、IMEというものを仲介して文字を入力するため、プライベートモードであっても入力履歴はIMEが保存してしまうかもしれない。そのため、入力履歴を学習しないようにするのを通知する機能というのがある。

Androidで言えば、InputMethods.IME_FLAG_NO_PERSONALIZED_LEARNING、Windows 10 20H1以降のText Service FrameでのIS_PRIVATEがそれだ (IS_PRIVATEの話は以前のブログ参照)。なお、GTKも4以降で機能を追加してもらった。この機能を使うことでプライベートモードであれば入力履歴を学習しないようになる。ChromiumやFirefoxではこれを使っているのでプライベートモードでは学習しないようにしてる。

ただ、この機能が動作する条件がもう一つあって、IME側でも対処が必要であるということ。この機能をちゃんと使うのは純正IME (Androidで言えばGBoardとかGooglen日本語入力、Windowsで言えばMicrosoft IME) くらいしかない。Androidの場合だとサードパーティ製IMEでこれを使っているのはあるかもしれないけど、どうも徳島にある某社のATOK (Windows版、Android版) はこの機能を使ってない模様。自分としては (毎月330円払っているユーザーとして)直してほしいのだけど、彼等はこういうところに興味がないから言ったとしても難しそうな気がする。

なお、ここで触れてない (本社がクパチーノにある) 某OS は未だに存在しない機能の模様なのだが、プライバシーとかを最近重視しているのであれば、実装してほしい。

CSS疑似クラスの:read-onlyと:read-writeが仕様通りに実装されることになった

いろんなやりとりを仕事がらするのだけど、自分のイメージ的には、WebKitは仕様上間違ってるという話を振れば、直してくれることが多くて、BlinkはQAが変な方向に持っていくか、開発者が斜め上の方向の話にしてしまいwontfix扱いになるということが多々ある。

最近やっと直す方向になった、CSS疑似クラスの:read-only / :read-writeがそのパターン。

元々は、Geckoが-moz-プレフィックス付きで実装してたものの一つで、その後、WebKit (確かBlinkに分かれる前) に実装されてた。しかもプレフィックスなしで。実装されたとしても、そもそも仕様として固まっていないものだったので、いろいろと差異が出るので、ちゃんと仕様として書かれたのだが、それが今回の発端である。

仕様がそもそもその時点のブラウザとは違う定義をしていたので (プレフィックスがあれば、別にいいやとは思うのだが、特にWebKitとBlinkがプレフィックスなし)、「これどういうこと？」と思い、WebKitとBlinkに対してバグを登録した。仕様自体を変更するという議論もありだと思っていたので、それぞれ (AppleとかGoogle) がやってくれるでしょ？ってことだしね。

WebKitは、さくっとこのバグを修正。エッジケースでまだ間違ってることはあるだろうけど、こっちが指摘した動作に関しては修正してくれた。

で一方、Blinkはというと、「これGeckoとかと同じ動作にしたからこういう動作なんでwontfix」。という結論に。個人的には「え？ならCSSWGで議論してよ」と。なぜ彼らはwontfixにする際に仕様に対してのコントリビュートとかWeb Platform Tests書くとかしないのかなぁと。たぶん人によるのだけど、残念ながら個人的にはよくあるパターン。

こういう状況だとGecko側もどうしようもないので (しかもGeckoだけプレフィックス付きだし、プレフィックス外すのだったらこれ結論必要だから) 困ると。ということで、CSSWG行きになった。(wontfixと言った張本人がなぜそっちに議論を移さないのかと本当に思うんだが)そこで議論のやり直しが発生した。

結論書くと、結果としては仕様を変えないということになり、emilioがGecko側をプレフィックス削除とともに仕様通りに修正を行った。

さて、問題はwontfixにしてしまっているBlink側ということになる。emilioがそのバグを再オープンし直したが、つい先日やっと直すことになったようで、そろそろBlinkでも直りそうということに。やれやれ。

そもそもBlinkは他の2つ (Gecko、WebKit) に比べて圧倒的な人的リソースを持っているわけだし、シェアも圧倒的なのだから、こういう仕様とは異なる動作の修正にリソースを割いてほしいと思うのだけど。。。。無理かなぁ。。。