コグノスケ

Kindle Fire HD死亡の余波

目次: Kindle

Kindle Fireが壊れて起動しなくなったのは昨日お伝えしたとおりですが、本体が使えなくなる以上に困った事態が発生しました。なんと2022年分の既読/未読のデータ（約2,000冊分くらい）がきれいさっぱり消えました。

2022年の購読数が0 = 既読フラグが全部消えている

Kindle Fireの故障によって、近日のデータは消えても不思議はありません。が、1年分消えるとはどういう了見でしょうか？Kindleは既読/未読のデータを1年近くクラウド側に反映しなかった？実は1年前から故障していた？もうKindle Fireは起動しないので、原因を調べる術はありません。

Kindleの読書補助機能

Kindleの読書補助の機能は色々とおかしくて、ダウンロードフラグがバグったり、しおりが消えたり、購読位置が巻き戻ったり、色々と変な動きをします。そのなかで既読/未読フラグは堅牢で信用していましたが、こいつもダメみたいですね。

Kindleで信用できるデータは「購入済みフラグ」だけだと思います。このフラグが崩壊したら二重購入が発生しまくるのは目に見えているので、Amazonの利用自体をやめると思います。ECサイトの根幹機能ですし、さすがに大丈夫でしょう……きっと。

既読フラグを2,000冊分も吹っ飛ばしてくれたのは痛いですね。Kindle Fireの買いたい意欲がさらに下がりました、もう地の底に近いですよ……。

Kindle Fire HD死す

目次: Kindle

実家から東京に帰ってきてマンガを読もうと思ったら、なぜかKindle Fire HD 10の電源が切れていました。不審に思って電源ONするとホームアプリが無限に再起動してしまう病気になっていました。通常再起動でも、電源長押しの強制再起動でも、症状は改善せず。

ホームアプリが無限に再起動

Kindleアプリを起動すると「Kindleはお使いの端末でサポートされていません。お使いの端末が端末の製造元のAndroidの正式なバージョンを使用していること、また端末が最新バージョンに更新済みであることを確認してください。」という妙なエラーが出て全く動作しません。

Kindleアプリのエラー画面

再起動後1分くらいは操作できる猶予があることに気づいたので、起動直後に素早く工場初期化を選択しました。

Amazon system recovery画面

が、残念ながらsystem recovery画面が表示されるようになってしまいました。さらに壊れたようです。ありゃー。

system recoveryを試す

手始めにメニューの中で失敗してもダメージが少なそうな「wipe cache partition」を実行しました。意味はわからないですが、めちゃくちゃmountのエラーが出ます。eMMCが死んだのかなあ？

wipe cache partitionの実行ログ

もはや直ることはほとんど期待していませんが、一応「wipe data/factory reset」も試しました。先ほどと同様にエラーが大量に出てます。ダメそうですね。

wipe data/factory resetの実行ログ

あと復帰できそうなメニューは「apply update from ADB」ですが、これを選んでもadb shellなどは弾かれるので何も調査できませんでした。adb sideloadしかできません。AmazonはKindleのOTAパッケージを公開していないので、使い物になりません。Amazonのサポート部門の人が使うための機能でしょうね。

もうできることはなさそうだな、と再起動したところfireの画面から先に進まなくなってしまい、見事に文鎮と化しました。あーあ……、ダメだなこりゃ……。

日記を見返すとKindle Fireを購入は2017年（2017年10月12日の日記参照）でした。5年間も頑張ってくれました。ありがとう。素直に諦めて次の機種に買い替えることにします。

次の機種

今のところ考えている選択肢は2つです。

• Kindle Fire HD 10の現行世代を買う
• Androidタブレットを買って、Kindleアプリを使う

Kindle Fireは市場を破壊するレベルで安く、1クリックでマンガが購入できて非常に便利です。しかしトラブルの多さと、意味不明な変更を頻繁＆勝手に入れるのがストレスフルです。初代＋七代目の合計10年間使ったものの、嫌い度が増すばかりで、可能ならもう次機種の候補に入れたくありません……。

AndroidタブレットはKindle Fireと比べると高いです。あとかつてのAndroidのKindleアプリも1クリックでマンガが購入できましたが、Googleの嫌がらせにより2022年6月から購入できなくなりました（「Kindle」Androidアプリ、電子書籍の購入が不可にGoogle Playのポリシー変更で - ITmedia NEWS）。使い勝手は悪化しました。

Kindleアプリが不便になる前ならAndroidタブレット一択でしたけど、今はどちらもイマイチです。どうしたもんかねえ？

ドラクエ1の「ド」

ドラクエ1がカタカナを削減していた話（「カタカナは20文字だけ」「没アイテムで宝箱がカラッポに」ファミコンハードの限界に挑んだ制作者たち - ねとらぼなど）は非常に有名です。ドラクエ1の背景テーブルの文字部分（左上です）を見ると、ねとらぼの記事に書かれていた通りカタカナは一部しか存在しません。

ドラゴンクエスト1の背景テーブル

さらに濁音や半濁音もありません。ドラクエ1の画面は1文字に2行使っていて、1行目は「濁点or半濁点」、2行目は「清音のかなorカナ」のように表示しているからです。

ドラゴンクエスト1の文字表示（1行につき背景キャラ2つ分を使う）

利点はもちろん濁音や半濁音をテーブルから排除できることです。欠点としては一度に表示できる行数が減ることですが、ひらがなばかりのメッセージ欄に読みやすい行間を作り出す手法として活用していて、素晴らしい工夫だと思います。

特別な濁点、半濁点

ドラゴンクエストはハードの限界に対する工夫にあふれていて本当に面白いですが、不思議な点も見受けられます。

1つ目の不思議な点は「名前用の濁点・半濁点」です。通常のメッセージ欄で使っている濁点・半濁点とは別に専用の濁点・半濁点が用意されています。不思議と言っておいてなんですが、これは理由が割と明確でUIデザインの都合だと思われます。

名前欄専用の濁点・半濁点

素人考えだと、メッセージ欄用の濁点・半濁点を再利用すればもっと背景テーブルを節約できる？と思いますが、実際にやってみると一発でダメなアイデアだとわかります。

名前用の濁点・半濁点の表示

メッセージ欄用の濁点・半濁点を使ったときの表示

無理やり再現するとこんな感じです。点が右下にきてしまいおかしいな表示になります。

特別な「ド」

2つ目の不思議な点は「ド」です。これは私が見た限りでは名前専用の濁音・半濁音と違って「ド」を特別扱いする強い理由が見当たりませんでした。「ド」とは何のことかというと、背景テーブルの「ラ」「ロ」の横にある「ド」です。2行下に「ト」があるため「ド」＝「ト」＋「゛」で表現できますが「ド」だけ特別扱いです。

濁音「ド」だけ特別に存在する

まず理由として思いつくのは、コマンド欄のUIデザインの都合です。コマンド欄は上に余裕がなく、メッセージ欄のように2行使って濁点を表現する方法は使えませんから、特別に文字を用意せざるをえなかった？という推測です。

コマンド欄

もっともらしいんですが、下記のように名前用の濁点を使えば「ド」＝「ト」＋「゛」に分解できます。頻繁に目にする部分であり、見た目が良くないから避けたのでしょうか？しかし同じくらい目にする名前欄は良いのにコマンド欄だけこだわる理由は？……どうも説得力に欠けます。

コマンド欄の「ド」を分解

もう1つ思いつくのは、後から「ト」を追加したが既に「ド」を使ってたくさんのメッセージを書いてしまい「ト」＋「゛」への修正が（時間、手間的に）困難だったのでは？という理由です。「ミスキト」が別領域にあること、メッセージに使われている「ド」が「ト」＋「゛」になっていない点からの推測です。

メッセージの「ゴ」は「コ」＋「゛」、「ド」は特別（「ト」＋「゛」ではない）

しかしこれも「ラダトーム」のように「ト」を使っている部分は既にあったはずなのに、「ド」だけ修正が困難だった？……というのはちょっと強引な気もしますね。正解は当時の開発に携わっていた人でないとわかりませんけどね。もしご存じの方は教えていただけると嬉しいです。

サンタがマッハ1で街にやってくる（2022年）

目次: サンタ

去年（2021年12月24日の日記参照）と同様に、飛行機の位置をリアルタイムに表示するFlightradar24というサービス（サイトへのリンク）にてサンタが出現しました。クリスマス・イブの日にサンタが出現するのは毎年恒例のお約束演出です。

去年のサンタはおかしくて表示された対地速度は40ktsなのに、サンタの位置から計算した速度はマッハ2 = 1300ktsと変な状態でした。今年は対地速度の表示は727kts（1346.4km/h, マッハ1.1くらい）です。

23:49:35時点の位置（緯度22.2887度、経度88.8772度）

23:50:35時点の位置（緯度22.4296度、経度88.6613度）

去年同様、ある程度の時間をあけ（今回は1分間）でどれくらい進んだか計算します。今回も距離の計算には国土地理院のページを使いました、緯度経度から距離を一発で計算してくれて便利です（サイトへのリンク）。

緯度、経度から距離と方位角を計算（国土地理院のサイト）

2地点間の距離は約27.2km、時間差は60秒から計算すると、対地速度は約1,630km/hです。地上でのマッハ1.3（ただし、サンタが飛んでいる高さ38,000ftsだとマッハ数はもっと高く出る）です。今年はそんなにずれていないみたいです。改善されましたねｗ

去年のサンタさんは、実質マッハ2という現代戦闘機＋アフターバーナー並みの猛烈な速度で飛んでいましたが、今年はマッハ1.3と大幅にスピードダウンしました。とはいえスーパークルーズ（音速以上の飛行）であり、戦闘機並みの飛行性能であることは変わりありませんね……。来年の速度も気になります。覚えていたらまた計算してみましょう。

x86とARMとRISC-VでCoreMark対決

目次: RISC-V

CoreMarkを以前（2019年7月5日の日記参照）測りましたが、ARM系のGCCのバージョンを上げたのと、x86系と、RISC-V系のFU740の計測結果を追加しました。FU540の値は以前のままです。

• AMD Ryzen 9 5900X / 3.4GHz Turbo 4.9GHz
• AMD Ryzen 7 5700X / 3.4GHz Turbo 4.6GHz
• AMD Ryzen 9 3950X / 3.5GHz Turbo 4.7GHz
• Intel Core i5 8250U / 1.6GHz Turbo 3.4GHz
• Intel Core i7 6700 / 3.4GHz Turbo 3.8GHz
• Intel Pentium J4205 / 1.5GHz Turbo 2.6GHz
• Amlogic A311D（Cortex-A73 / 2.2GHz x 4, Cortex-A53 / 1.8GHz x 2）
• Rockchip RK3588（Cortex-A76 / 2.4GHz x 4, Cortex-A55 / 1.8GHz x 4）
• Rockchip RK3399（Cortex-A72 / 1.8GHz x 2, Cortex-A53 / 1.4GHz x 4）
• Rockchip RK3328（Cortex-A53 / 1.3GHz x 4）
• Rockchip RK3288（Cortex-A17 / 1.8GHz x 4）
• Broadcom BCM2837（Cortex-A53 / 1.2GHz x 4, 32bit mode）
• StarFive JH7110（U74-MC / 1.5GHz x 4）
• SiFive FU740（U74-MC / 1.2GHz x 4）
• SiFive FU540（U54-MC / 1.0GHz x 4）
• NSITEXE NS31A（NS31A / 25MHz x 1）

動作周波数については後述します。

測定条件と結果

コンパイル条件は下記の通りです。

• Ryzen 9 5900X: GCC-9.4.0 O2
• Ryzen 7 5700X: GCC-12.2.0 O2
• Ryzen 9 3950X: GCC-7.5.0 Ofast
• Core i7 6700: GCC-9.4.0 Ofast
• Core i5 8250U: GCC-11.2.0 Ofast
• Pentium J4205: GCC-10.2.1 Ofast
• A311D: GCC-9.4.0 Ofast
• RK3588, RK3399, RK3328: GCC-10.2.1 Ofast
• RK3288: GCC-10.2.1 Ofast, 32bit
• BCM2837: GCC-8.3.0 Ofast, 32bit
• JH7110: GCC-11.3.0 Ofast
• FU740: GCC-10.2.0 Ofast
• FU540: GCC-8.3.0 Ofast
• NS31A: GCC-12.2.0 Ofast

Ryzen 7はなぜかO2よりOfastの方が遅かった（O2: 41946, Ofast: 40442）ので、O2の結果を採用しました。RK3399はCA72とCA53の2種類のコアがあるので、taskset 0x1 ./coremarkのように実行するコアを固定して計測しています。

CoreMarkのIterations/Secの結果はCPUの動作周波数の影響を受けてしまうため、CPUの性能比較をする際はIterations/SecをCPU動作周波数で割った値を使うことが多いです。

やはりx86系CPUの速さは圧倒的です。Ryzen 7は異次元の速さですし、ローエンド向けに思われがちなAtom系コアもARM Cortex-A72を圧倒しています。（12/28追記）Pentium J4205の動作周波数が間違っていた（1.5GHz → 2.6GHz）ので修正しました。

RISC-V勢はFU540（U54-MCコア）はかなり遅く、FU740（U74-MCコア）でやっとRK3328（Cortex-A53コア）などのSoCと並ぶくらいです。FU740を搭載したHiFive UnmatchedはPCと同じホームファクタのMini-ITXを採用しており、NVMe SSDやグラフィックカードが装着できる点などは非常に素晴らしいのですが……、PCの代わりに使用するとなると非力すぎて、RISC-V PCを名乗るにはまだ厳しそうですね。

CPU動作周波数の取得

LinuxでCPUの動作周波数を取得する方法は色々あって、イマイチ統一感がないですけれども、このベンチマークでは下記のようにしています。

• x86系: /proc/cpuinfoのcpu MHz欄
• ARM系: /sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_cur_freq
• RISC-V系: SoC次第

FU740の動作周波数はCore PLL（/sys/kernel/debug/clk/corepll/clk_rateの値 = 1196000000）から得ました。ARM系はCPU周波数が負荷に応じて変化するため、yes > /dev/nullなどを起動してCPUに負荷をかけた状態で見ています。

もし私が何か勘違いしていてCPU動作周波数を間違えているとどうなるかというと、Coremark/MHzが間違った値になります。Iteration/Secは変わりません。