目次: Kindle
Kindle Fire HD 10の後釜として、Lenovo Tab M10 (3rd Gen, TB328FU) を買いました。ヨドバシで37,000円くらいでした。SoC UNISOC T610 (Cortex-A75 x 2, Cortex-A55 x 6)、RAM 4GB、Storage 64GBです。バッテリーは5000mAhらしい。UNISOCは中国系メーカー製のタブレットで採用されていますね。中国の国策の一環なんですかね?
RAMはそこそこあります。CPUやGPUはAnTuTuのスコアを見ると19万点くらいで、数年前のミドルエンド(Snapdragon 675)と同じくらいでした。10インチクラスのタブレットの中ではミドルエンド……いや、ローエンドくらいかなあ?私はタブレットでゲームをしたり、動画を見たりしないので何も問題ありません。
買う前から分かっていましたが、Kindleの本を買う手間は大幅に増えて面倒になりました。今まではKindle Fireから1クリックで買えましたが、これからは4手必要になって、めちゃくちゃ面倒です。
後から気づいたんですけど、本を買っても自動的にタブレットにダウンロードされない点も地味に不便です。イケてねーなあ。
目次: Kindle
Kindle Fireが壊れて起動しなくなったのは昨日お伝えしたとおりですが、本体が使えなくなる以上に困った事態が発生しました。なんと2022年分の既読/未読のデータ(約2,000冊分くらい)がきれいさっぱり消えました。
Kindle Fireの故障によって、近日のデータは消えても不思議はありません。が、1年分消えるとはどういう了見でしょうか?Kindleは既読/未読のデータを1年近くクラウド側に反映しなかった?実は1年前から故障していた?もうKindle Fireは起動しないので、原因を調べる術はありません。
Kindleの読書補助の機能は色々とおかしくて、ダウンロードフラグがバグったり、しおりが消えたり、購読位置が巻き戻ったり、色々と変な動きをします。そのなかで既読/未読フラグは堅牢で信用していましたが、こいつもダメみたいですね。
Kindleで信用できるデータは「購入済みフラグ」だけだと思います。このフラグが崩壊したら二重購入が発生しまくるのは目に見えているので、Amazonの利用自体をやめると思います。ECサイトの根幹機能ですし、さすがに大丈夫でしょう……きっと。
既読フラグを2,000冊分も吹っ飛ばしてくれたのは痛いですね。Kindle Fireの買いたい意欲がさらに下がりました、もう地の底に近いですよ……。
目次: Kindle
実家から東京に帰ってきてマンガを読もうと思ったら、なぜかKindle Fire HD 10の電源が切れていました。不審に思って電源ONするとホームアプリが無限に再起動してしまう病気になっていました。通常再起動でも、電源長押しの強制再起動でも、症状は改善せず。
Kindleアプリを起動すると「Kindleはお使いの端末でサポートされていません。お使いの端末が端末の製造元のAndroidの正式なバージョンを使用していること、また端末が最新バージョンに更新済みであることを確認してください。」という妙なエラーが出て全く動作しません。
再起動後1分くらいは操作できる猶予があることに気づいたので、起動直後に素早く工場初期化を選択しました。
が、残念ながらsystem recovery画面が表示されるようになってしまいました。さらに壊れたようです。ありゃー。
手始めにメニューの中で失敗してもダメージが少なそうな「wipe cache partition」を実行しました。意味はわからないですが、めちゃくちゃmountのエラーが出ます。eMMCが死んだのかなあ?
もはや直ることはほとんど期待していませんが、一応「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は市場を破壊するレベルで安く、1クリックでマンガが購入できて非常に便利です。しかしトラブルの多さと、意味不明な変更を頻繁&勝手に入れるのがストレスフルです。初代+七代目の合計10年間使ったものの、嫌い度が増すばかりで、可能ならもう次機種の候補に入れたくありません……。
AndroidタブレットはKindle Fireと比べると高いです。あとかつてのAndroidのKindleアプリも1クリックでマンガが購入できましたが、Googleの嫌がらせにより2022年6月から購入できなくなりました(「Kindle」Androidアプリ、電子書籍の購入が不可にGoogle Playのポリシー変更で - ITmedia NEWS)。使い勝手は悪化しました。
Kindleアプリが不便になる前ならAndroidタブレット一択でしたけど、今はどちらもイマイチです。どうしたもんかねえ?
ドラクエ1がカタカナを削減していた話(「カタカナは20文字だけ」「没アイテムで宝箱がカラッポに」ファミコンハードの限界に挑んだ制作者たち - ねとらぼなど)は非常に有名です。ドラクエ1の背景テーブルの文字部分(左上です)を見ると、ねとらぼの記事に書かれていた通りカタカナは一部しか存在しません。
さらに濁音や半濁音もありません。ドラクエ1の画面は1文字に2行使っていて、1行目は「濁点or半濁点」、2行目は「清音のかなorカナ」のように表示しているからです。
ドラゴンクエスト1の文字表示(1行につき背景キャラ2つ分を使う)
利点はもちろん濁音や半濁音をテーブルから排除できることです。欠点としては一度に表示できる行数が減ることですが、ひらがなばかりのメッセージ欄に読みやすい行間を作り出す手法として活用していて、素晴らしい工夫だと思います。
ドラゴンクエストはハードの限界に対する工夫にあふれていて本当に面白いですが、不思議な点も見受けられます。
1つ目の不思議な点は「名前用の濁点・半濁点」です。通常のメッセージ欄で使っている濁点・半濁点とは別に専用の濁点・半濁点が用意されています。不思議と言っておいてなんですが、これは理由が割と明確でUIデザインの都合だと思われます。
素人考えだと、メッセージ欄用の濁点・半濁点を再利用すればもっと背景テーブルを節約できる?と思いますが、実際にやってみると一発でダメなアイデアだとわかります。
無理やり再現するとこんな感じです。点が右下にきてしまいおかしいな表示になります。
2つ目の不思議な点は「ド」です。これは私が見た限りでは名前専用の濁音・半濁音と違って「ド」を特別扱いする強い理由が見当たりませんでした。「ド」とは何のことかというと、背景テーブルの「ラ」「ロ」の横にある「ド」です。2行下に「ト」があるため「ド」=「ト」+「゛」で表現できますが「ド」だけ特別扱いです。
まず理由として思いつくのは、コマンド欄のUIデザインの都合です。コマンド欄は上に余裕がなく、メッセージ欄のように2行使って濁点を表現する方法は使えませんから、特別に文字を用意せざるをえなかった?という推測です。
もっともらしいんですが、下記のように名前用の濁点を使えば「ド」=「ト」+「゛」に分解できます。頻繁に目にする部分であり、見た目が良くないから避けたのでしょうか?しかし同じくらい目にする名前欄は良いのにコマンド欄だけこだわる理由は?……どうも説得力に欠けます。
もう1つ思いつくのは、後から「ト」を追加したが既に「ド」を使ってたくさんのメッセージを書いてしまい「ト」+「゛」への修正が(時間、手間的に)困難だったのでは?という理由です。「ミスキト」が別領域にあること、メッセージに使われている「ド」が「ト」+「゛」になっていない点からの推測です。
メッセージの「ゴ」は「コ」+「゛」、「ド」は特別(「ト」+「゛」ではない)
しかしこれも「ラダトーム」のように「ト」を使っている部分は既にあったはずなのに、「ド」だけ修正が困難だった?……というのはちょっと強引な気もしますね。正解は当時の開発に携わっていた人でないとわかりませんけどね。もしご存じの方は教えていただけると嬉しいです。
目次: サンタ
去年(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だとマッハ数はもっと高く出る)です。今年はそんなにずれていないみたいです。改善されましたねw
去年のサンタさんは、実質マッハ2という現代戦闘機+アフターバーナー並みの猛烈な速度で飛んでいましたが、今年はマッハ1.3と大幅にスピードダウンしました。とはいえスーパークルーズ(音速以上の飛行)であり、戦闘機並みの飛行性能であることは変わりありませんね……。来年の速度も気になります。覚えていたらまた計算してみましょう。
目次: RISC-V
CoreMarkを以前(2019年7月5日の日記参照)測りましたが、ARM系のGCCのバージョンを上げたのと、x86系と、RISC-V系のFU740の計測結果を追加しました。FU540の値は以前のままです。
x86_64
AArch32/AArch64
RISC-V
動作周波数については後述します。
コンパイル条件は下記の通りです。
Ryzen 7はなぜかO2よりOfastの方が遅かった(O2: 41946, Ofast: 40442)ので、O2の結果を採用しました。RK3399はCA72とCA53の2種類のコアがあるので、taskset 0x1 ./coremarkのように実行するコアを固定して計測しています。
CoreMarkのIterations/Secの結果はCPUの動作周波数の影響を受けてしまうため、CPUの性能比較をする際はIterations/SecをCPU動作周波数で割った値を使うことが多いです。
SoC (x86) | CPU/micro arch | Iterations/Sec | GHz | CoreMark/MHz | Board/Machine |
---|---|---|---|---|---|
Ryzen 9 5900X | Zen 3 | 44345.89800 | 4.7 | 9.435 | |
Ryzen 7 5700X | Zen 3 | 42040.35874 | 4.6 | 9.139 | |
Ryzen 9 3950X | Zen 2 | 36140.22407 | 4.5 | 8.031 | |
Core i5 8250U | Cabylake R | 29237.62883 | 3.6 | 7.694 | ThinkPad E480 |
Core i7 6700 | Skylake | 26963.26256 | 3.8 | 7.489 | |
Pentium J4205 | Goldmont | 13319.12627 | 2.6 | 5.122 | ASRock J4205-ITX |
SoC (ARM) | CPU/micro arch | Iterations/Sec | GHz | CoreMark/MHz | Board/Machine |
A311D | CA73 | 12491.41215 | 2.2 | 5.677 | Khadas VIM3 |
A311D | CA53 | 5909.213000 | 1.8 | 3.282 | Khadas VIM3 |
RK3588 | CA76 | 18228.21728 | 2.4 | 7.595 | Radxa ROCK 5B |
RK3588 | CA55 | 6745.983074 | 1.8 | 3.747 | Radxa ROCK 5B |
RK3566 | CA55 | 6023.766497 | 1.6 | 3.764 | Radxa ROCK 3C |
RK3399 | CA72 | 10218.15767 | 1.8 | 5.676 | Pine64 ROCKPro64 |
RK3399 | CA53 | 4622.852300 | 1.4 | 3.302 | Pine64 ROCKPro64 |
RK3328 | CA53 | 4215.259238 | 1.3 | 3.242 | Pine64 ROCK64 |
RK3288 | CA17 | 8594.421439 | 1.8 | 4.774 | ASUS tinkerboard |
BCM2837 | CA53 | 3877.973113 | 1.2 | 3.231 | Raspberry Pi 3B |
SoC (RISC-V) | CPU/micro arch | Iterations/Sec | GHz | CoreMark/MHz | Board/Machine |
Key Stone M1 | X60 | 6350.305969 | 1.8 | 3.527 | Milk-V Jupiter |
JH7110 | U74-MC | 5324.298161 | 1.5 | 3.549 | StarFive VisionFive 2 |
FU740 | U74-MC | 4134.509372 | 1.2 | 3.445 | SiFive HiFive Unmatched |
FU540 | U54-MC | 2255.130422 | 1.0 | 2.255 | SiFive HiFive Unleashed |
NS31A | NS31A | 58.164129 | 0.025 | 2.326 | Local RAM, FPGA(Digilent Arty A7-100T, Xilinx Artix-7) |
やはり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を名乗るにはまだ厳しそうですね。
LinuxでCPUの動作周波数を取得する方法は色々あって、イマイチ統一感がないですけれども、このベンチマークでは下記のようにしています。
FU740の動作周波数はCore PLL(/sys/kernel/debug/clk/corepll/clk_rateの値 = 1196000000)から得ました。ARM系はCPU周波数が負荷に応じて変化するため、yes > /dev/nullなどを起動してCPUに負荷をかけた状態で見ています。
もし私が何か勘違いしていてCPU動作周波数を間違えているとどうなるかというと、Coremark/MHzが間違った値になります。Iteration/Secは変わりません。
今日、東京や千葉で輪のような形で雨が降っていると教えてもらいました。本当だ……不思議な現象ですね。
この現象、調べてみると既に名前がついていて「ブライトバンド」と呼ぶそうです。かっこいい名前ですね。ブライトバンドについてはウェザーニュースの解説が非常にわかりやすかったです(参考: 秋田県の雨雲レーダーに映る 謎のドーナツ型の正体は? - ウェザーニュース)。
詳しくはぜひウェザーニュースの解説を読んでいただきたいですが、簡単に言えばレーダーが融解層(雪→雨に変わる部分)を捉えて過剰に反応している状態で、実際には強い雨が降っているとは限らないとのこと。
ブライトバンドが出ているときに降水量の過去情報を見ると、ブライトバンドは出たり消えたりするだけで、その場からほとんど動かないことがわかります。
30分経っても移動しない(松戸、取手、習志野の近辺のまま、横浜の輪は消えた)
天気予報システムはブライトバンド=強い雨雲と解釈して予想をするようで、輪が他の雨雲とともに移動するような予報を出しています。気象の専門家ではないので「それが何か問題でも?」に対する答えは持ち合わせていませんが……。
1時間後の予報、輪が移動している(習志野の近辺が右に流れている)
ブライトバンドの付近での局所予報は少し食い違うかもしれませんが、過去情報と予報を見比べても特に破綻しているようには見えませんし、ブライトバンドを雨雲とみなそうが、無視しようが大勢に影響はないのでしょう。
目次: 独自OS
最近、趣味&趣味からの発展で仕事でも独自OSを作成しています。独自OSの設計目標は下記の通りです。
最初の2つの項目は大抵トレードオフですが、3つ目の項目を活かして軽く&便利を両立させることが狙いです。
「便利、手軽」の実現のため、ソースコードレベルの互換性の確保を目指します。具体的にはLinux用に書かれたソースコードをそのままアクセラレータ用にコンパイル&実行できれば、プログラマから見てLinuxの使い勝手を実現できている、と言えるはずです。
一方で「軽く、速く」を実現するため、Linuxとのソース互換を目指しつつも、アクセラレータ向けに割り切った制限をいくつか設けます。
これらの制限が妥当かどうか?について今は結論は出ないので、実装して使って問題があれば今後修正したいと思います。アクセラレータやOSに詳しい方々の意見も聞いてみたいです。
アクセラレータに処理を依頼する際のインタフェースはいくつかありますが、いずれも定番ではなさそうです。今回はOpenCL風のAPIを採用しました。OpenCL規格に準拠はしませんが、ある程度(例えばclinfoに応答できる程度)のOpenCL APIを実装します(ホスト側のソースコードのリンク)。
ホストとアクセラレータ間のデータ移動や実行制御の方法も考える必要があります。ホスト側からアクセラレータ側に何か計算を依頼するケースと、もう一つアクセラレータ側のスタンドアローン実行(ホスト側から制御なしでアクセラレータ側のみ単独実行するモード)はデバッグの利便性を考えると、必須に近い機能です。
またホスト側に過度に依存しないように、ホスト側のAPIが気に入らなくなったら別のAPIを実装することができるように、アクセラレータ側の独自OSとは別のリポジトリに分離して実装します。
独自にOSを実装する道を選びました。既存のOSSを改造するより実装期間が短く済むと思ったくらいで、独自実装しなければならない強力な理由はないです。個人的な理由も入れて良ければ、独自OS実装に対する興味があったことが大きいです。
RTOSにLinux互換レイヤを積む方法、Linuxをダウンサイズする方法、などでも実現できるのではないでしょうか。Linuxをダウンサイズする方法だとスレッド周りの制約実現が難しいですかね……?やったことがないので何とも言えません。
そんなの簡単にできるよ、という方はぜひOS作成フレンズになりましょう。
目次: 独自OS
最近、趣味&趣味からの発展で仕事でも独自OSを作成しています。OSと呼ぶほどの機能はありませんが、位置的にはCライブラリよりハード寄りのいわゆるOSレイヤーです(ソースコードへのリンク)。
想定する動作環境は、複数プロセッサで構成されたシステムにおいて、片方がホスト、もう片方がアクセラレータとして動作する環境です。想定する制御方法は、ホスト側で実行したくない、時間がかかる処理をアクセラレータ側に任せて終わるのを待つ、シンプルなユースケースで下記のようになります。
このようなシステムにおいてPC系のプログラマが気軽にアクセラレータ側のソフトウェアを書ける環境が欲しい、という発想から、アクセラレータのプログラマの補助となるようなOSの作成が目的です。
独自OSの設計目標は下記の通りです。
最初の2つの項目は大抵トレードオフですが、3つ目の項目を活かして軽く&便利を両立させることが狙いです。
アクセラレータを動作させるという観点で見れば、わざわざ独自OSを作成せずとも既存のアクセラレータ用言語を使ったり、既存OSの転用でも動作させることができます。
既存のアクセラレータ用言語、CUDAやOpenCLですね。速度は最高だと思います。プログラマ視点から見ると、これら言語の習得には若干手間が掛かります。
LinuxなどPC系OSを転用する場合、使い勝手はPCそのものなので最高でしょう。しかしアクセラレータ向けとしては大規模で大げさでもあり、ハードウェアのリソース特にメモリがかなり必要です。
RTOSを転用するの場合、省メモリかつ大抵の実装は速度も速いです。しかし目的が違う(リアルタイム処理を記述するためのOS)ため、色々なOS独自ルールが存在します。PC系のプログラマには馴染みが薄いです。
手法 | 速度 | メモリ | 手軽さ |
---|---|---|---|
アクセラレータ用言語 | 〇 | 〇 | × |
PC系OS(Linuxなど) | △ | × | 〇 |
RTOS | 〇 | 〇 | △ |
独自OSでは使い慣れたC/C++ 言語が使えて、速さを殺さず、Linuxの使い勝手を可能な限り両立させることを目指します。
< | 2023 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 | - | - | - | - |
合計:
本日: