目次: GCC
RTLは(演算子 引数1引数2 ...) という形で表記されます。LispのS式に似ているんですかね?前回(2019年6月14日の日記参照)出力したRTLのうち5番目のinsnを例にとります。
(insn 6 5 7 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])
(reg:SI 104)) "a.c":3 132 {*movsi_internal}
(nil))
RTLはいくつも種類があり、codeという番号で区別されています。RTLをファイルに出力する際はcodeは名前に変換され、開きカッコの後に書かれます。
先頭のRTLは (insn ... で始まっているので、code = insnのRTLで、その後 (set ... とあるので、code = setのRTLがあるんだな、ということがわかります。上記のRTLに出てくるcodeは、insn, set, mem, plus, reg, const_intの6種類です。
RTLは引数を取ります。先程の例に出てくるRTLの引数はrtl.defに定義されています。一例を示すと下記のとおりです。
例えばsetのeeであればeという種類の引数を2つ取る、という意味です。GCCではRTLの引数をこのように定義します。かなり意味不明だと思いますが、こういうものだと思うしかないです。
さらにeという種類の 引数は別のRTLを含んでOKなので、RTLは入れ子になります。先の例に出てきたRTLを分割してみます。
____________________________________________________________________________________________________________________________________ ________ ______________________ _______ | e insn__________________________________________________________________________________________________________ ________________ | i insn | i insn | e insn | | e set __________________________________________________________________________ _ _______________ | e set | | | | | | e mem ______________________ _______________________________________ |0 | mem additional | | | | | | | | e plus _________ | e plus _________________________ | | | ______ | | | __ __ _ | | | | | r reg | | w const_int | | | | r reg | | | | u | u | B | | | | | | | | | | | | | | (insn 6 | 5 | 7 | 2 | (set | (mem/c:SI | (plus:SI | (reg/f:SI | 65 frame) | (const_int | -4 [0xfffffffffffffffc])) | | [1 a+0 S4 A32]) | (reg:SI | 104)) | "a.c":3 | 132 {*movsi_internal} | (nil))
途切れ目が非常にわかりにくいです。私も正直ぱっと見ではわかりません。特に引数eは入れ子になっていて、ひたすら見づらいです。RTLの引数の正確な切れ目を知るには、print_rtx_operand_code_e() など、引数のprint関数を見るのが一番早いかもしれません。
RTLの出力をリアルタイムで見たいときは、gdbでprint_rtl_with_bb() 辺りにブレークを掛けておいて、ステップ実行していくとわかりやすいです。
その際printf系の出力がバッファリングされると、printした文字列がなかなかファイルに出力されません。デバッグ時はprint文と、実際に出力されている文字列の対応が確認しづらいため、最初にsetvbuf() を呼んでバッファリングを無効にしておいたほうが見やすいと思います。
/* Like dump_function_to_file, but for RTL. Print out dataflow information
for the start of each basic block. FLAGS are the TDF_* masks documented
in dumpfile.h. */
void
print_rtl_with_bb (FILE *outf, const rtx_insn *rtx_first, dump_flags_t flags)
{
const rtx_insn *tmp_rtx;
setvbuf(outf, NULL, _IONBF, 0); //★★この行を足した★★
if (rtx_first == 0)
fprintf (outf, "(nil)\n");
else
{
enum bb_state { NOT_IN_BB, IN_ONE_BB, IN_MULTIPLE_BB };
//...
あとは観察したいRTLファイルをtail -fとかで追い続ければ良いでしょう。
RTLの名前と引数の情報を定義したrtl.defというファイルがあるのですが、これだけを見るといかにも整然としたルールに則っているように見えます。ですが実際は例外だらけで、コードを読んでいるとなかなか辛いものがあります……。
例えば、今回の例で行くとmemの最後に何か([1 a+0 S4 A32] というやつ)出力されていますよね?rtl.defを見るとmemの引数の定義は "e0" なので、"0" の一部だろうと考えたくなりますが、残念ながら、この情報についてはrtl.defには一切記述がありません。これはひどい。
RTLを文字列として出力するprint_rtx() 関数の実装を見ると、最後の方でMEM, CONST_DOUBLE, CONST_WIDE_INT, CONST_POLY_INT, CODE_LABELだけ特別扱いして、特別に出力が追加されます。16進数だと見づらいし、とりあえず出しておこうという感じでしょうか……。
目次: GCC
GCCの内部情報を出力してみます。GCCのバックエンドはGIMPLEとRTL (Register Transfer Language) があります。
ざっくり言ってC言語(など)→ GIMPLE → RTL → アセンブラの順に変換されます。GIMPLEの内容はまだよく知らないので説明できません……。今回はRTLを見ていこうと思います。
GCCでRTLを出力するには、コンパイル時に-fdump-rtl-allオプションを付けます。
$ riscv32-unknown-elf-gcc a.c -fdump-rtl-all
試しに下記のコードをコンパイルし、RTLを出力させると、
void main()
{
int a = 1, b = 2, c;
c = a + b;
return c;
}
下記のようなRTLが出力されます(GCC-8.3.0での結果)。C言語のファイル名がa.cだとすると、RTLはa.c.NNNr.XXXXという名前で出力されます。NNNは最適化パスの番号、XXXXは最適化パスの名前が入ります。
;; Function main (main, funcdef_no=0, decl_uid=1514, cgraph_uid=0, symbol_order=0)
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg:SI 104)
(const_int 1 [0x1])) "a.c":3 132 {*movsi_internal}
(nil))
(insn 6 5 7 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])
(reg:SI 104)) "a.c":3 132 {*movsi_internal}
(nil))
(insn 7 6 8 2 (set (reg:SI 105)
(const_int 2 [0x2])) "a.c":3 132 {*movsi_internal}
(nil))
(insn 8 7 9 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -8 [0xfffffffffffffff8])) [1 b+0 S4 A32])
(reg:SI 105)) "a.c":3 132 {*movsi_internal}
(nil))
(insn 9 8 10 2 (set (reg:SI 107)
(mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])) "a.c":5 132 {*movsi_internal}
(nil))
(insn 10 9 11 2 (set (reg:SI 108)
(mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -8 [0xfffffffffffffff8])) [1 b+0 S4 A32])) "a.c":5 132 {*movsi_internal}
(nil))
(insn 11 10 12 2 (set (reg:SI 106)
(plus:SI (reg:SI 107)
(reg:SI 108))) "a.c":5 3 {addsi3}
(nil))
(insn 12 11 17 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -12 [0xfffffffffffffff4])) [1 c+0 S4 A32])
(reg:SI 106)) "a.c":5 132 {*movsi_internal}
(nil))
(insn 17 12 0 2 (const_int 0 [0]) "a.c":7 240 {nop}
(nil))
RTLは最適化処理を実行するたびに内容が変わるため、たくさんのファイルが出力されます。上記のRTLはGIMPLEからRTLに変換した後、命令割当のみ行った状態のものです。最適化パス名でいうとvregsというパスが終わった後のRTL です。
長くなってきたので分割します。
Facebookで都道府県営水道は東京だけではないと教えていただきました。
以前(2019年6月7日の日記参照)書いたように、水道は基本的には市町村が運営するものです。市町村で維持が難しくなった水道事業を都道府県が引き取る形になっているせいか、各県ごとに運営形態も提供範囲もバラバラです。
全ての都道府県を全て調べるのは大変なので、人口の多そうな都道府県を中心に水道事業の統合について、調べてみました。
東京以外にも色々なところでやっていますね。共通しているのは人口が多い、供給面積が広い、ダムから遠く水源がないなど、1市町村で水道を賄えなくなっていることでしょうか。
今まで住んだことのある市町村は、偶然いずれも広域水道に入っていませんでした。つまり田舎ばかりだったということか……?
※1: 千葉県の水道企業団
九十九里地域水道企業団(匝瑳市、東金市、茂原市、横芝光町、大網白里市、九十九里町、山武市、一宮町、睦沢町、長生村、白子町、長柄町、長南町)
北千葉広域水道企業団(千葉県水道局、松戸市、野田市、柏市、流山市、我孫子市、習志野市、八千代市)
東総広域水道企業団(銚子市、旭市、東庄町)
君津広域水道企業団(千葉県水道局、木更津市、君津市、富津市、袖ケ浦市)
印旛郡市広域市町村圏事務組合水道企業部(成田市、佐倉市、四街道市、酒々井町、八街市、印西市、白井市)
南房総広域水道企業団(館山市、勝浦市、鴨川市、大多喜町、いすみ市、御宿町、鋸南町、南房総市、三芳(企))
※2: 愛知県の水道企業団
愛知中部水道企業団(豊明市・日進市・みよし市・長久手市・東郷町)
北名古屋水道企業団(北名古屋市・豊山町)、丹羽広域事務組合(大口町・扶桑町)
海部南部水道企業団(愛西市・弥富市・飛島村)
メモ: 技術系の話はFacebookから転記しておくことにした。大幅加筆した。
普段、蛇口から出てくる水道水をグイグイ飲んでいますが、特に味や臭いが気になることはありません。以前、つくばに住んでいた時は水道水から異臭がしていたので、天と地の差です。
どこの水か気になったので、調べていたら、東京都水道局がとても便利なサイトを提供してくれていました(配水系統〜ご家庭の水道水情報 | 水源・水質 | 東京都水道局)。住所を入力すると、配水している浄水場、水質検査の結果を見ることができます。
我が家は大田区の東、つまり羽田空港側です。サイトで調べると三郷浄水場から水が来ているようです。家から30kmくらい離れてます。埼玉からはるばるお疲れ様です……。
水源は江戸川で、水質の良い川ではありませんが、その分浄水場が頑張っていて(高度浄水設備を備えている)、浄水後の水質はかなり良いようです。
メモ: 技術系の話はFacebookから転記しておくことにした。
東京の水道は他の地域に比べるとちょっと変わっています。
水道のことは「東京都」水道局に連絡しますよね?東京以外、例えば以前住んでいた高槻では「高槻市」水道部に連絡します。「大阪府」ではないのです。
水道法は水道を市町村レベルで管理、運営することを定めています(水道法 第六条の2)。特別区(東京23区)については下記規定があり、東京都が管理するものと定められています。
第四十九条
特別区の存する区域においては、この法律中「市町村」とあるのは、「都」と読み替えるものとする。
しかし東京都は23区以外も、武蔵野市、昭島市、羽村市及び檜原村を除いて「東京都」が全ての市町村の水道を管理します。これはかなり変わった運用形態だと思います。
経緯はリンク先(多摩の水道 | 水道事業紹介 | 東京都水道局 - 多摩水道について)にさらっと書かれています。超人口密集地だと、水道一つとっても苦労が多いんですね……。
メモ: 技術系の話はFacebookから転記しておくことにした。
病院に行くと大抵の場合、何らかの抗生物質が処方されます。昔、おなかを壊したとき(2010年2月1日の日記参照)はホスホマイシンを処方されました。
色々種類があるようなので、ちょっとした興味で調べてみたんですが、思っていたより抗生物質の種類は多かったよ……。
系統 | 例 | 作用原理 |
---|---|---|
β-ラクタム系 | ペニシリン | 細胞壁(ペプチドグリカン)に必要なムレイン架橋を阻害 |
アミノグリコシド系 | ストレプトマイシン | リボソーム50Sサブユニット、23SrRNA阻害 |
リンコマイシン系 | リンコマイシン | リボソーム50Sサブユニット阻害 |
ホスホマイシン系 | ホスホマイシン | MurA阻害、細胞壁(ペプチドグリカン)に必要なムレイン合成を阻害 |
テトラサイクリン系 | テトラサイクリン | リボソーム30Sサブユニット阻害 |
クロラムフェニコール系 | クロラムフェニコール | リボソーム50Sサブユニット阻害 |
マクロライド系 | エリスロマイシン | |
ケトライド系 | テリスロマイシン | |
ポリペプチド系 | コリスチン | 細胞壁の傷害、合成阻害など |
グリコペプチド系 | バンコマイシン | 細胞壁(ペプチドグリカン)に必要なムレイン合成を阻害 |
キノロン系 | キノロン | DNAジャイレース阻害 |
ニューキノロン系 | フルオロキノロン | DNAジャイレース阻害 |
サルファ剤 | サルファメソキサゾール | 葉酸合成阻害 |
オキサゾリジノン系 | リネゾリド | リボソーム50Sサブユニット阻害 |
「〜マイシン」という命名が多いです。これは放線菌(Streptomyces属)が産出する抗菌剤を意味するのだとか。なぜ放線菌が数多の抗生物質を作り出すのか、不思議ですね?
細菌に存在する生命維持の機構も、いくつか種類があるので、万能の抗生物質はありません。理解しているのはこのくらいで、作用原理は書き写してみたものの、詳しい仕組みは知りません。
付け焼刃の知識ですが、抗生物質の基本的な戦略は、
「人間には存在せず、細菌にしか存在しない生命維持もしくは増殖機構を妨害する」
当たり前ですよね、人間の生命活動まで妨害したら、細菌と一緒に人間まで死んでしまう(=副作用)ので、薬として成立しません。
例えば、リボソームはmRNAからたんぱく質を生成する器官です。リボソームの働きを妨害すると生命維持に必要なたんぱく質が作れなくなって、細胞は死んでしまいます。リボソームは真核生物(人間)の細胞にも、原核生物(細菌)の細胞にも存在しますが、大きさと形が異なります。真核生物は60S, 40Sという大きさ、原核生物は50S, 30Sという大きさのサブユニットを持っています(参考: 生命の重要な機構である「リボソーム」 | 株式会社A&T)。
ですので50S, 30Sのサブユニットだけを妨害するような物質を使えば、細菌のみ攻撃して退治できるという寸法です。賢い戦略ですよね。
しかし世の中はそう単純ではなく、真核生物は細胞内にミトコンドリアを持っています。ミトコンドリアは酸素を使いエネルギーを生成するための、非常に大事な器官です。ミトコンドリアは少々変わった器官で、太古の昔に真核生物の細胞内に共生した細菌(リケッチアに近い種類)が祖先と考えられています。
細菌が先祖のミトコンドリアは、細菌と似たようなリボソームを持っています。そのため抗生物質が間違ってミトコンドリアのリボソームまで攻撃してしまい、人間の具合まで悪くなる(=抗生物質の副作用)原因となっているそうです。
真核生物の中に原核生物が融合しているなんて、何とも場当たり的でムチャクチャに思えますが、ムチャクチャなのに驚きの精密な機構があったりして、生物って面白いですね。
目次: RISC-V
HiFive UnleashedにDebianを導入した記念に、いつもやっているベンチマークを取ってみました。
モナコインのハッシュ方式に使われているLyra2REv2のベンチマークです。1秒にいくつハッシュ値を計算できるか測ります。
おそらくクロスコンパイルでビルドすることもできるとは思いますが、curl, libsslなどに依存していて意外と面倒です。Debianの力を借りてセルフコンパイルすると超簡単です。
測定結果ですが、結論から言うと、Unleashedはメチャクチャ遅いです。Unleashedの結果は下記のとおりです。4コアなので4スレッド並列で測定しています。
CPU #0: 4.53 kH/s CPU #2: 4.53 kH/s CPU #1: 4.53 kH/s CPU #3: 4.53 kH/s Total: 18.12 kH/s
参考までにROCKPro64 RK3399(Cortex-A72 x 2, Cortex-A53 x 4)で同じプログラムをコンパイルして測定すると、下記の結果になります。6スレッド並列です。
CPU #4: 64.17 kH/s CPU #5: 64.16 kH/s CPU #1: 34.07 kH/s CPU #2: 34.11 kH/s CPU #0: 33.97 kH/s CPU #3: 33.92 kH/s Total: 264.94 kH/s
CA72は64kH/sくらい、CA53は33kH/sくらいです。このプログラムはCubeHashにNEON対応を入れた特別版ですが、NEON対応を外してもCA53は29kH/sくらいは出ます。
買う前からUnleashedがあまり速くないことは知っていましたが、4コア束になってもCA53 1コアに勝てないとは思っていなかったです……。
しかもこのボード、かなり高価(10万円以上する)なので、お蔵入りは避けたいんですが、拡張性に乏しくて(USBがない)、一体何に使えるのか謎です。
追加でROCK64上で測定したので、結果を載せておきます。
4 miner threads started, using 'lyra2rev2' algorithm. CPU #2: 31.29 kH/s CPU #0: 31.22 kH/s CPU #1: 31.23 kH/s CPU #3: 31.30 kH/s Total: 125.04 kH/s
RK3399のCortex-A53とあまり変わりません。同じCPUコアで動作周波数もほぼ同じなので、当然といえば当然ですけども。
メモ: 技術系の話はFacebookから転記しておくことにした。多少追記。
目次: RISC-V
SiFiveのHiFive Unleashedを購入しました。現状、世界唯一かつ最速のLinuxが動作するRISC-V 64bit SoC です。
ボードにはSDカードが付属しておりbuildrootがインストールされています。電源を入れればLinuxが起動し、ユーザroot、パスワードsifiveでログインできるようになっていました。
インストールされているカーネルは、
Linux buildroot 4.15.0-00044-g2b0aa1d #1 SMP Tue Mar 20 12:18:35 PDT 2018 riscv64 GNU/Linux
でした。うーん、4.19かと思ったら、意外と古い?
Linuxとbuildrootだけでは面白くないのでDebian portsからriscv64向けのパッケージを引っ張ってきてDebianの環境を構築しました。
Debianのriscv64向けポーティングは絶賛作業中らしく、ffmpegなど用意されていないパッケージもチラホラありますが、自分で用意する手間を考えれば、使えるだけでどれだけありがたいかわかるというものです。
元のSDカードを書き潰すのは若干ためらわれた(後で元に戻せなくなった時に面倒)ので、今はchrootで使っています。
Crowd Supplyから購入しました。本体 $999, 送料 $40, 消費税が5,000円くらい、合計で11万円くらいです。SBCにしてはかなり良いお値段です。
送料を払うのですが、家には着払いで届く点にも注意しなければなりません。
UPSが米国→日本まで持ってきて、国内はクロネコヤマトが運びます。受け取りの際に、消費税を着払いでクロネコに払う必要があります。私は消費税のことを知らなくて、何で送料を2回払うんだ??と混乱しました。
メモ: 技術系の話はFacebookから転記しておくことにした。かなり追記。
< | 2019 | > | ||||
<< | < | 06 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | - | 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 | - | - | - | - | - | - |
合計:
本日:
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.3.8.
using GD bundled (2.1.0 compatible)(png support.)