コグノスケ

デノーマルフラッシュの速度改善効果

目次: ベンチマーク

先日（2021年2月5日の日記参照）非正規化数（Denormal数）の計算は遅いと書きましたが、いかほどでしょうか？どのくらい遅いのか、デノーマルフラッシュでどの程度速くなるのか、この2点について見ていこうと思います。

おそらく世の中のどのFPUも割り算が一番苦手なはずです。入力を正規化数、非正規化数の2パターン用意して、下記の演算をたくさん実行してみます。

#define SIZE    10000

union uuu {
	double f;
	long long n;
};

...

void test_speed(union uuu *val)
{
	for (int i = 0; i < SIZE; i++) {
		dst[i].f =
			val[i].f / 1.08f -
			val[i].f / 1.07f +
			val[i].f / 1.06f -
			val[i].f / 1.05f +
			val[i].f / 1.04f -
			val[i].f / 1.03f +
			val[i].f / 1.02f -
			val[i].f / 1.01f;
	}
}

コードは全部貼り付けると邪魔くさいのでGitHubにおきました（GitHubへのリンク）。前回のFTZ, DAZのテストに使ったコードも一緒に入っています。

x86系のCPU

まずはx86系のCPUで測ってみましょう。手元にあるのはZen系（AMD Ryzen 7 2700）と、Atom系（Intel Pentium J4205）なので、この2つで測ります。コンパイラはgcc (Debian 10.2.1-6) 10.2.1 20210110、最適化レベルはO2です。

10000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  0.912859[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:OFF, DAZ:ON
  0.880695[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:OFF
  0.880633[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  0.880653[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  1.806291[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:OFF, DAZ:ON
  0.783578[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:OFF
  1.513203[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:ON
  0.783183[s]
  dst : 0.000000e+00(0x00000000)

1000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  1.024671[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:OFF, DAZ:ON
  1.025767[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:OFF
  1.025151[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  1.027414[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  12.147070[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:OFF, DAZ:ON
  0.309857[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:OFF
  7.126950[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:ON
  0.312373[s]
  dst : 0.000000e+00(0x00000000)

Ryzen 7 2700でもPentium J4205でも、Denormal数が計算に出現すると遅くなりますが、J4205はその傾向が顕著で10倍くらい遅いです。FTZ, DAZをONにすると、効果覿面に速くなります。

ARM系のCPU

次にARMで測ってみましょう。手元にあるのはRK3399です。Cortex-A72とCortex-A53が混載されているので、両方で測ります。カーネルはLinux 5.11.0-rc3-next-20210113、コンパイラはgcc (Debian 8.3.0-6) 8.3.0、最適化レベルはO2です。

ARMは仕様上FTZとDAZが分かれていない（FZという両方合わせたような機能がある）ので、片方だけONにした結果はありません。

$ taskset 0x10 ./a.out 10000

...

10000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  7.153237[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  7.118581[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  8.008282[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:ON, DAZ:ON
  1.779883[s]
  dst : 0.000000e+00(0x00000000)

$ taskset 0x1 ./a.out 10000

...

10000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  11.693382[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  11.691307[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  12.196882[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:ON, DAZ:ON
  11.697961[s]
  dst : 0.000000e+00(0x00000000)

Cortex-A72はデノーマルフラッシュの効果抜群ですが、Cortex-A53はデノーマルフラッシュによる変化はほとんどありません。どちらもARMが設計した同世代のCPUにも関わらず、速度の傾向は大きく異なります。詳細な理由はARMにしかわかりませんが、なかなか興味深い結果です。

在宅勤務環境改善

COVID-19が流行し始めた昨年2月ころ、在宅勤務が主となりました。当時の気持ちを正直に言えば「すぐ収束して、電車通勤に戻るだろう」で、完全にナメていました。在宅勤務の環境もまったく整えておらず、ダイニングテーブル、ノートPC＋8インチのモバイルディスプレイでした。夕食時は邪魔だから、仕事道具をガサガサ片付ける、といった具合です。

そんなこんなで1年間やってきたものの、COVID-19の予想外の長期化、それに加えて会社方針（COVID-19が収束しようとしまいと、今後は在宅勤務）もあって、在宅勤務の環境を改善することにしました。

部屋

家には、奥さんが一昨年の在宅勤務で使っていた部屋があって、幅100cmの机と背もたれ付きのオフィスチェアがあります。そのスペースを譲ってもらうことにしました。

• 1年目: 奥さん在宅勤務、私は電車通勤
• 2年目: 2人共電車通勤
• 3年目: 奥さん電車通勤、私は在宅勤務

すっかり勤務形態が逆転しました。会社のみなさんの話を聞くと、東京の狭い家で夫婦とも在宅勤務、子供まで自粛で家に居て、全く仕事にならん……みたいな地獄化したご家庭もあるみたい。我が家も夫婦同時に在宅勤務だと、スペースの確保がちょっと大変だったと思います。交代で在宅勤務になったのは、今思えば割とラッキーだったのかな？

テーブル

ダイニングテーブルはしっかりした作りで、間違いなく家で一番上等なテーブルです。一方のダイニングチェアは年中使い続けるような椅子ではなかったらしく、1年間酷使し続けたところ、座面、背面のクッションが潰れ椅子のフレームが腰にガツガツ当たるようになりました。痛ぇよーー。

部屋を移ってスペースが広がったので、大きめのデュアルディスプレイも目指します。幅120cmの机を買い足し100cmの机は横向きに合わせL字にします。

買ったのは山善のAMDT-1260 AMDL-70という一番シンプルな天板と脚だけのテーブルです（Amazonへのリンク）。Amazonで9,000円くらいとお安いです。理由はわからないですが、山善の公式サイトには載っていないんですよね。なぜだろね？

ディスプレイ

机の幅を考えると27インチx2が載りそうです。ただし、机の奥行きがあまりない（60cm）ので、大きすぎると端が見えなくなって、かえって使いにくいです。という点を勘案して24インチx2にします。

買ったのはEIZO FlexScan EV2480です。Amazonで1台4万円くらい。デュアルディスプレイにしたので、総額8万円くらい掛かりました。非常に高価ですが、これでも中位機種なんです。ちなみに上位機種のEV2495は1台7万円します。強烈！

FlexScanは重たいのが難点（純正スタンドがめちゃ重い）ですが、変な色やら、映らないやらのトラブルは皆無で非常に快適です。以前勤めてた会社（パナソニックやソシオネクスト）でも大変お世話になりました。良いメーカーですよね。

USB Type-C DisplayPort Alternate mode

現在使っているThinkPad E480はUSB Type-C端子とHDMI端子しかありません。先日（2021年2月12日の日記参照）新しく購入したディスプレイ2つに画像を出力するには、USB Type-CのDisplayPort Alternate Mode（VESAの機能紹介のページ（英語））を使う必要があります。接続はこんな感じです。

E480とデュアルディスプレイの接続

このときE480とディスプレイを繋ぐUSB Type-Cケーブルは3つの役割を果たします。

• USB 2.0/3.1のデータ通信（ディスプレイがUSBハブになる）
• USB Power Deliveryによる電力供給
• DisplayPort Alternate Modeによる画像出力

たった1本のUSB Type-Cケーブルで3役もこなす凄いヤツです。今まで「ACアダプタ」「DisplayPort」「USB Type-A」の3つに分かれていたコネクタが、USB Type-C 1つに統合できますから、省スペースが命のノートPCにとっては大歓迎の機能でしょう。

実はさほど便利じゃない

そんな凄いヤツを使い始めて数日ですが、既に嫌になってきました。正直な感想として、少なくともユーザーからすると便利と思えないし、使わなくて良いなら使いたくないです。

ケーブルの問題

1本で済むのは良いですが、ケーブルが硬すぎます。USB PD対応USB 3.1ケーブルはかなり高速な信号を通す関係上、3重シールド5〜6mm幅以上のごついケーブルばかりです。これならACアダプタとHDMI 2本の方がまだマシです。どちらもかなり細いので。

E480の問題

ノートPCの液晶、DisplayPort、HDMIの3系統を使えると思いきや、3画面に拡張デスクトップを設定するとバグるので、ノートPCの液晶とDisplayPortをミラーにしています。ノートPCの液晶が完全に無意味ですが、蓋を閉めるとスリープしちゃうので、半開きでテーブルの隅に放置しています。切ない。

USBハブの問題

ディスプレイがUSBハブの役目も果たしますが、ディスプレイの電源を切るとUSBハブとしての機能もOFFになります。マウス程度なら問題ありませんが、通信するような機器は繋ぐと毎回切られてストレスMAXです。あとUSBオーディオDACは繋いでも動作しませんでした。何か制約があるんですかね？

USB PDの問題

ディスプレイ側のUSB PDによる供給力の上限は、現状60Wの製品が多いです。60WはノートPCによっては給電能力がギリギリです。ディスプレイのUSB PD供給能力が足りない場合、純正アダプタに戻して給電し出画は諦めるorバッテリーを削りつつDisplayPort Altで出画するorディスプレイを買い替える、究極の3択を迫られます。

ケーブルの問題は今後、技術革新で細くなることを祈るしかありません。E480の問題は回避策不明です。HWの制約？USBハブの問題は、E480ならUSB Type-Aコネクタが別にあるので、そちらを使えば回避可能です。USB PDの問題は今の所E480だと困っていません。

しかし将来的にノートPCを買い換えるとUSB PDの問題が起きる可能性があります。回避策はあるでしょうか？USB Type-Cが3つ付いていて、1つはDisplayPort、2つ目はUSB PD電源供給、3つ目はPCに繋ぐ、変なハブ的なものがあれば良い？もはや「ケーブル1本でOK」のコンセプトは完全崩壊だし、ディスプレイ側のUSB PDは死蔵確定です。そんな訳のわからんことになるなら、素直にDisplayPortとUSB Type-Cのコネクタ2個付けてくれよって思います。

そもそもDislayPortとUSB PDなんて全く無関係のものを統合したら、どちらか壊れただけでPCが機能不全になることくらい、聡明なVESAやUSB-IFの面々には明らかなはずですけど、何でこんなデザインにしたんですかね？理解しがたいよ……。

USB PDとDisplayPort Alt Modeを見ると思い出すのは、あの商品

昔SHARP SF1という製品がありました（DIMEの記事）。スーパーファミコンとテレビが1つに合体した、当時小学生だった私には夢のような製品でした。配線なしで見た目スッキリ、場所も取らない、ACアダプタやビデオケーブルを接続する手間も不要、いかにも便利そうじゃないですか？結構お高いのもあって、友達が持っているのを見て羨ましかったです。USB Type-Cも似たような売り文句です。

しかし後から聞くところによれば、テレビが故障するとスーパーファミコンを外せないから他のテレビに繋げなくて困る、逆にスーパーファミコンが故障するとテレビごと修理になって高ぇわテレビがなくなるわで困る、元より不便になっています。元々バラバラの製品を無理やり一蓮托生にしたら、そりゃそうなりますわな……。無関係の機能をデタラメに統合してはいけない、という好例です。

残念なことにUSB Type-CもDisplayPortとUSB PDの機能統合で、似たような落とし穴に落ちています。小学生の私に「21世紀になっても人類はSF1と同じ過ちを繰り返しているよ」って教えてあげたいですね。

Wikipediaの数学のページを眺める

群とか環とか体とか、大学で教えてもらった記憶がうっすらありますが、何回見ても忘れます。幸いにもWikipedia先生に割と詳しく解説されているので、まとめておこうと思います。

群

集合Gと二項演算uの組（G, u）を考えます。uは乗法や加法と呼ばれる場合があるようです。以降u(a, b) をa + bの形で表します。

半群

閉性を満たす: 二項演算u（u: G + G -> G）の結果はGに含まれる

結合法則を満たす: a + (b + c) = (a + b) + c

モノイド

単位元eが存在する: a + e = e + a、整数の加法でいえば0

群

逆元xが存在する: a + x = x + a = e整数の加法でいえば -a

アーベル群

交換法則を満たす: a + b = b + a

下にある群は、上の群の性質をすべて満たします（以降も特に断りがなければ同じ）。なので、モノイドは半群の性質を満たしますし、群はモノイドと半群の性質を満たします。

環

集合Rと2つの二項演算u, tの組（R, u, t) を考えます。(R, u) はアーベル群です。uは加法、tは乗法と呼ばれるようです。以降t(a, b) をa * bの形で表します。

乗法半群

閉性を満たす: 二項演算t（t: R * R -> R）の結果はRに含まれる

結合法則を満たす: a * (b * c) = (a * b) * c

乗法モノイド

単位元eが存在する: a * e = e * a、整数の乗法でいえば1

環（モノイドでない場合がある）

加法の上に左分配律を満たす: a * (b + c) = (a * b) + (a * c)

加法の上に右分配律を満たす: (a + b) * c = (a * c) + (b * c)

可換環（モノイドでない場合がある）

交換法則を満たす: a * b = b * a

群と違って、環はモノイド（単位元が存在する）である必要はないみたいです。

零因子

可換環では零でない零因子という困ったことが起きます。

• a * x = 0となるx != 0が存在するときaは左零因子
• y * a = 0となるy != 0が存在するときaは右零因子

困る例として挙げられていたのはa * b = 0かつa != 0でもb = 0とは限らない、もしくは、a * b = a * cかつa != 0でも、b = cとは限らない、という例でした。

具体的な例が載ってませんでしたが、行列の和と積を考えると発生しそうに思えます。

A =
[1, 1]
[0, 0]

B =
[ 1, 0]
[-1, 0]

C =
[0, -1]
[0,  1]

A * B =
[0, 0]
[0, 0]

A * C =
[0, 0]
[0, 0]

A != 0だがB, Cは零行列ではない。A * B = A * Cだが、B = Cでもない。

環はこういうパターンが無数に出てきて、さらに条件を厳しくしないと困る場合がありますよ、ということですかね？

整域

変わった名前ですが、環の一種のようです。環で発生する零因子による困った問題を排除しています。

整域（乗法モノイドである必要がある）

零が唯一の零因子: a * x = 0かつa != 0ならばx = 0

非自明環: 自明環（零のみの集合は {0} 環となるので、自明環と呼ばれる）ではない

力尽きた

群環体の「体」まで辿り着きたかったのですが、整閉整域、一意分解整域、主イデアル整域、ユークリッド整域、体、有限体、と訳のわからない名前のオンパレードで、力尽きました。また今度調べます。

一般のご家庭にPCは何台ある？

内閣府の「主要耐久消費財等の普及率」「主要耐久消費財の保有数量の推移」（リンク）によると、2人以上の世帯のPC普及率は77.0％、100世帯辺り123.6台（2020年3月）だそうです。

保有世帯だけを考えれば123.6 / 0.77 / 100 = 1.61 [台/世帯] ですから、世帯人数 ＜PC台数です。PCを日常的に使う習慣がない限り、共有のPCが1台あれば十分ですし、納得感ある結果です。

一般のご家庭にPCは何台置ける？

では、一般のご家庭にPCは最大で何台置けるでしょうか？

PCの消費電力は様々ですが、夢はでっかく、高性能PCとして、AMD Threadripper 3990X, NVIDIA GeForce RTX 3090のマシンを考えましょう。CPUとグラボのTDPは280 + 350W = 630Wです。他の部品や損失を考えると、PC 1台あたり800W程度と思われます。

一般家庭の我が家の電気契約（40A）ですと、5台程度でブレーカーが飛びます。200V系のコンセントを増設し、200Vで給電すれば電流は半減するので10台くらいは置けるでしょう。30A契約のご家庭も多いでしょうから、「高性能PC 8〜10台」これが一般のご家庭の限界と思われます。

逸般の誤家庭にPCは何台置ける？

では、色々逸脱した逸般の誤家庭の場合はどうでしょうか？

家庭の電気契約は「従量電灯B」という契約（従量電灯B・C電気料金プラン - 東京電力エナジーパートナー株式会社）がほとんどです。従量電灯Bの最大契約アンペア数は60Aで、全て200Vから取ると最大12kWです。したがって12000 / 800 = 15台が限界です。ふーむ、意外と伸びませんね。

冷却の電力は完全に無視しています。冷却を無視したまま15台も置いたら、家の中は一瞬で灼熱地獄になり、人間もPCも死ぬと思います。

業務用なら青天井

大口需要向けに「従量電灯C」という契約もあります。

従量電灯Cの場合10Aごとに基本料金が従量的に増える青天井の契約になります。一般家庭でも契約可能のようです。基本料金を比較すると、従量電灯B＜ 従量電灯Cとなるため、一般のご家庭だと損するだけで契約する意味はありません。

本来、家電が大量にある豪邸や、業務用の電気機器がある商店用ですが、60Aに満足できない真の逸般の誤家庭にも向いているかもしれませんね。

Slideshare初利用

Slideshareを初めて使いました。LinkedInのアカウントが必要なのは知りませんでした。偶然LinkedInのアカウントを持っていたので、すんなり登録できました。

USB PDはもっとわかりやすくしてほしい

試しに USB Type-C, USB PDケーブルとお友達になろうをアップロードしました。ダウンロードもできるし、スライド置き場として優秀ですね。みんな使うわけだ……。

スライドの話もしておくと、USB Type-Cケーブルがどうして何種類もあって、値段が全然違うのか、気になったので調べたことをまとめたものです。USB初心者なので間違ってたらすみません。

最後まで分からなかったのはUSB Power Deliveryの3A/5Aケーブルを見分ける方法です。何か無いんでしょうか。当然USB PDのアナライザで見ればわかりますよ？でもアナライザなんか普通の人は持ってませんよ。パッケージから出した途端に見分けが付かなくなるなんて、一般消費者からしてみたら辛すぎません？

新キーボード購入

先日の在宅勤務環境改善（2021年2月12日の日記参照）にて、デュアルディスプレイにしたところ、ノートPC本体が邪魔になってしまったので、机の上からどけました。

当然、ThinkPad本体のキーボードには手が届きませんから、ワイヤレスキーボードLogicool K295を買いました。Amazonで1,900円くらいでした。K295は変なキーも少ないし、静かで良いですが、キーの認識が渋いです。私の場合、打鍵力が足りず人差し指担当のキー（T, Uなど）の誤打が多発してイライラします。

買ってすぐ買い替えるのもどうかと悩みましたけど、あまりに誤打が多く慣れるまで辛そうだったので、さっさと諦めFILCOのMajestouch赤軸を買いました。ヨドバシで15,000円くらいでした。Majestouchはキーが戻るとき＆底打ちしたとき「カーン！」と響く鐘のような音がやかましい以外は、非常に良いキーボードです。

キーボード使用歴

今まで、キーボードは標準的なキーボード（※）であれば、高くても安くても使い心地が気になることはないと思っていました。しかし今回K295がどうも合わなかったことから、実は自分とキーボードの相性って結構あるのか？と疑問に感じるようになりました。

（※）OADG 109A型の配列で、カーソルキー、ファンクションキー等の位置を移動していないキーボードのこと。

まずはキーボードの使用履歴を書き出してみます。

相性とか全く気にならなかった。

• DELLの標準キーボード
• Gatewayの標準キーボード
• HPの標準キーボード
• IBM/Lenovo ThinkPad X, Eシリーズ
• Logicool K270
• Majestouch赤軸
• NEC VersaPro
• Owltechの安いキーボード
• RealForce 108UBK
• サンワサプライの安いキーボード
• SONY VAIO Type-G
• TOSHIBA Dynabook R73

誤打しやすかった。

• Let's Noteシリーズ（理由: キーの形が横長）
• Logicool K295（理由: キーの認識が渋い）
• Logicool K340（理由: カーソル、ファンクションキー配置が変）

まともに打てなかった。

• HappyHacking（理由: キー配置が変すぎる）

以前K340やHHKで懲りて、特殊なキー配列のキーボードに触らなくなったので、コンパクト系のキーボードの利用歴はほぼゼロです。そもそもまともに打てないし、レビューできません。

ほとんどPC付属キーボード、ノートPCのキーボードばかりです。これはもしや、勝手に安物だと思いこんでいたPC付属の標準キーボード、実は質が高かったのではなかろうか？

大事な製品に標準で付属するものですし、高級ではないにせよ、あまりに変なものはつけませんよね。これが答えなのでは、という気がしてきました。

JIS配列キーボードとOADG配列キーボード

今まで、いわゆる日本語配列のキー配列のことを漠然とJIS配列と呼んでいましたが、どうもこれは正確ではないようです。

技術者たるもの、規格を粗末に扱ってはいけませんよね？？

JIS配列を定めているのはJIS X 6002-1980「情報処理系けん盤配列」です。この配列を見ると一目瞭然ですが、アルファベット、スペースなどは一致するものの、他のキーは全く違う位置にあったり、そもそもなかったりします。規格書は有料（1,100円）ですが、PFUのサイトでJIS配列の図をタダで拝めます。

JIS X 6002のキーボード配列（PFUのサイトより）

PFUのサイトへのリンク:
https://www.pfu.fujitsu.com/hhkeyboard/pfutechreview/section3.html

現状、主流の日本語キー配列はOADG（The PC Open Architecture Developers Group）が規格化した配列です。OADGは2004年に解散していますが、規格書はInternet Archiveで見ることができます。

Internet Archive: OADGテクニカル・リファレンス ハードウェア編1991年へのリンク:
https://archive.org/details/OADG1991/

規格の付録Aを見ると、

• OADG 104型（英語配列）
• OADG 109型（日本語配列）
• OADG 109A型（109型と同じだが、- や ^ キーの刻印が違う）

OADG 104型（英語配列）

OADG 109型（日本語配列）

OADG 109A型

OADG 109型（109A型と異なる部分を示した）

の3つが書かれています。市販のキーボードは、各社ともに適当に魔改造しているため、OADG規格と全く同じキー配列のキーボードは存在しないと思います。たぶん。

実例を出すと、Logicool K295はかなり109Aに近いです。しかし、右Windowsキーが欠けています（このタイプ、俗に108キーなどと呼ばれていますね）。

Logicool K295のキー配列

FILCO Majestouchも素直な109Aに近いですが、右Appキーがなく、右WindowsキーがFnキーに置換されています。

FILCO Majestouch Convertible 2のキー配列

私の場合は、最下段は 左Ctrl, 左Win, 左Alt, スペース, 右Alt, 右Ctrlしか使わないので、K295やMajestouchのように使わないキーが欠けていても気になりませんが、使う人からすると、何てことするの！？という気分になるでしょう。

さらに言うと、無変換、変換、ひらがなキーも使わないので、使っているキーの種類だけ考えたら、いわゆる英語配列（OADG 104型）で十分に思えます。しかし日本語配列で練習したため、英語配列は記号類を間違えまくります。私物で購入したことはありません。打てて損はないので、もうちょい修行しても良いかもしれませんね……？

メモ: 技術系の話はFacebookから転記しておくことにした。写真追加、加筆。

VSCodeを使ってWindowsからLinuxアプリのデバッグ その1

目次: Linux

その1、その2

同じことをしている人があまり居なさそうだったので、メモしておきます。

きっかけはGCCのコードをGDBのCUIモードで追っていて辛くなったことです。GCCのコードは超ぐちゃぐちゃの悲惨なコードで非常に追いづらく、GDBをもってしても何が起きているのか把握するのは困難です。せめてデバッガの画面くらいはGUIにして、見やすくできないか、と考えました。

WindowsからLinuxアプリのデバッグ、それぞれの役割

想定する構成は上記のとおりで、Linux側にはGUIがなく（ディスプレイを繋いでいない、など）、Windows側はデバッグのみで、Linux側でその他の全て（ビルドなど）を行う想定です。

Linux側の準備

この記事を読んでいるということは、既に何かデバッグしたいアプリケーションがあると思いますから、基本的なツールであるgccやmakeなどのインストールは省略させてもらいます。gdbserverをインストールするだけで良いはずです。

# apt-get install gdbserver

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  gdbserver
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/458 kB of archives.
After this operation, 1165 kB of additional disk space will be used.
Selecting previously unselected package gdbserver.
(Reading database ... 99167 files and directories currently installed.)
Preparing to unpack .../gdbserver_8.2.1-2+b3_amd64.deb ...
Unpacking gdbserver (8.2.1-2+b3) ...
Setting up gdbserver (8.2.1-2+b3) ...

デバッグするプログラムは何でも良いですが、下記を使用します。渡した引数を表示するだけのプログラムです。

#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("argc: %d\n", argc);

	for (int i = 0; i < argc; i++) {
		printf("argv[%d]: %s\n", i, argv[i]);
	}

	return 0;
}

$ gcc -Wall -g -O0 a.c

$ ./a.out a b c

argc: 4
argv[1]: a
argv[2]: b
argv[3]: c

まずは普通にCUIからGDBで追ってみます。図示するとこのような構成です。

GDBでLinuxアプリのデバッグ

あえてやる必要もなさそうですけど、このあとの一貫性のために試します。

$ gdb a.out

...
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...

(gdb) b main

Breakpoint 1 at 0x1144: file a.c, line 5.

(gdb) r a b c d

Starting program: /home/katsuhiro/share/falcon/projects/c/test_argv/a.out a b c d

Breakpoint 1, main (argc=5, argv=0x7fffffffdca8) at a.c:5
5               printf("argc: %d\n", argc);

(gdb) c

Continuing.
argc: 5
argv[1]: a
argv[2]: b
argv[3]: c
argv[4]: d
[Inferior 1 (process 4008866) exited normally]

普通です。次はgdbserverと連携させリモートでGDBで追ってみます。図示するとこのような構成です。

gdbserver + GDBでLinuxアプリのデバッグ

実際にやってみましょう。ターミナルを2つ用意してください。

★★ターミナル1つ目

$ gdbserver --multi localhost:1234 ./a.out a b c d

Process ./a.out created; pid = 4008908
Listening on port 1234
Remote debugging from host ::1, port 32918

★mainでbreakしたあとのcontinueを実行すると下記が出力される

argc: 5
argv[1]: a
argv[2]: b
argv[3]: c
argv[4]: d
 
Child exited with status 0


★★ターミナル2つ目

$ gdb

...
For help, type "help".
Type "apropos word" to search for commands related to "word".

(gdb) target remote :1234

Remote debugging using :1234
Reading test_argv/a.out from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading test_argv/a.out from remote target...
Reading symbols from target:test_argv/a.out...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/5b/e47e85c990f390b0dccb6ca9dc3e70f410dc6a.debug...
0x00007ffff7fd3090 in _start () from target:/lib64/ld-linux-x86-64.so.2

(gdb) b main

Breakpoint 1 at 0x555555555144: file a.c, line 5.

(gdb) c

Continuing.
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...

Breakpoint 1, main (argc=5, argv=0x7fffffffdd18) at a.c:5
5               printf("argc: %d\n", argc);

(gdb) l

1       #include <stdio.h>
2
3       int main(int argc, char *argv[])
4       {
5               printf("argc: %d\n", argc);
6
7               for (int i = 1; i < argc; i++) {
8                       printf("argv[%d]: %s\n", i, argv[i]);
9               }
10

(gdb) c

Continuing.
[Inferior 1 (process 4008908) exited normally]

ブレークもできますし、ソースコードも表示されます。良い感じですね。

使い勝手はGDB単体でデバッグするときとほぼ同じですが、1点だけ注意があります。デバッガとして動作するのはgdbserverであり、プログラムのprintfなどの標準出力は、gdbserverを動かしているターミナル側に出ることに注意してください。この使い方におけるGDBはgdbserverと通信するだけの役です。

Sambaのセットアップについては、ここで解説せずとも、詳しいサイトがたくさんあると思いますので、そちらをご参照ください。

思ったより長くなってきたので、続きは次回に。

VSCodeを使ってWindowsからLinuxアプリのデバッグ その2

目次: Linux

その1、その2

昨日（2021年3月3日の日記参照）の続きです。

GDBの準備

Windows側で使用するGDBを用意します。最初はMinGWのバイナリが使えるかと思ったのですが、MinGWのバイナリはWindowsの実行形式（COFF）のデバッグ用で、Linuxの実行形式（ELF）は認識せず、ダメでした。残念。

GDBはbinutilsに含まれています。ビルド方法を下記に示します。バージョンは何でも良いと思いますが、私はMinGWも使っている2.32にしました。

$ git clone git://sourceware.org/git/binutils-gdb.git
$ cd binutils-gdb
$ git checkout -b 2_32 binutils-2_32

$ mkdir build
$ cd build
$ ../configure \
    --host=x86_64-w64-mingw32 \
    --target=x86_64-unknown-linux-gnu \
    --prefix=`pwd`/_install \
    --disable-werror \
    --with-expat=no \
    --enable-sim \
    --enable-libdecnumber \
    --enable-libreadline \
    --enable-gas \
    --enable-binutils \
    --enable-ld \
    --disable-gold \
    --enable-gprof

$ make -j8
$ make install

ビルドが成功すると、build/_installディレクトリにWindows用のbinutilsのバイナリ（GDBも含む）がインストールされます。フォルダごとWindows側にコピーすれば動きます。ディレクトリの名前 _installはWindows側に持っていったあとに変更しても構いません。

比較的、新しい環境（Ubuntu 20など）だとMinGWが何か変らしく、gdb/common/common-defs.hにある _FORTIFY_SOURCEの定義を消さないと、リンクの時に __memcpy_chk() などの関数が見当たらないと言われてエラーになります。

  CXXLD  gdb.exe
/usr/bin/x86_64-w64-mingw32-ld: ada-tasks.o:/usr/share/mingw-w64/include/string.h:202: undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: amd64-tdep.o:/usr/share/mingw-w64/include/string.h:202: undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: breakpoint.o:/usr/share/mingw-w64/include/string.h:228: undefined reference to `__strcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: breakpoint.o:/usr/share/mingw-w64/include/string.h:228: undefined reference to `__strcpy_chk'
...

とりあえず下記のパッチでエラーは回避できますが、おそらく正しい直し方ではありません。原因は調べていません。もしご存知の方は教えていただけると嬉しいです。

diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
index e574de5ed66..a9b0520b4c5 100644
--- a/gdb/common/common-defs.h
+++ b/gdb/common/common-defs.h
@@ -69,7 +69,7 @@
    then we don't do anything.  */

 #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
-#define _FORTIFY_SOURCE 2
+//#define _FORTIFY_SOURCE 2
 #endif

 #include <stdarg.h>

面倒であれば、ビルド済みのバイナリ（ binutils_x86_64-unknown-linux-gnu.zip）をどこか適当なディレクトリに展開してもらえれば動くはずです。Windows 10で動作確認しています。

Windows側の準備

Visual Studio Codeをインストールします。Microsoftのサイトからダウンロードできます（Visual Studio Code - Code Editing. Redefined）。

はじめにC/C++ Extensionをインストールします。GDBと連携するためです。

VSCode C/C++ Extensionのインストール画面

先ほどのテストプログラムが置いてあるディレクトリを開きます。メニューの [File] - [Open Folder] です。ここではZ:\projects\c\test_argvにあるとします。

左側のタブからRun and Debugを選択します。Ctrl + Shift + Dでも良いです。次に青いRun and Debugボタンを押します。するとSelect Environmentというコンボボックスが出てくるのでC++ (GDB/LLDB) を選択します。

Run and Debug

C/C++ (GDB/LLDB) を選択

ソースコードペインにlaunch.jsonのテンプレートが表示されると思うので、下記の内容に書き換えます。miDebuggerPathやmiDebuggerServerAddressは適宜、環境に合わせて書き換えてください。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "cwd": "${workspaceFolder}",
            "MIMode": "gdb",
            "miDebuggerPath": "c:\\app\\binutils\\bin\\x86_64-unknown-linux-gnu-gdb.exe",
            "miDebuggerServerAddress": "192.168.1.2:1234",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
                {
                    "description": "Relace absolute path of source code",
                    "ignoreFailures": false,
                    "text": "set substitute-path /home/katsuhiro/share/falcon z:/",
                },
            ],
        },
    ]
}

ここで大事なのはsetupCommandsのset substitute-pathです。gdbはLinux側の絶対パスでソースコードの場所を通知してくることがあります。Linux側の絶対パスを渡されてもWindows側ではファイルを探せませんから、絶対パスの一部をWindows側に存在するパスに置き換えることで、VSCodeがソースコードを見つけられるように設定してあげないと、こんなエラーで怒られます。

ソースコードの場所の設定に失敗しているとエラーが出る

今回の例では、

• Linuxから見たテストプログラムのある場所: /home/katsuhiro/share/falcon/projects/c/test_argv
• LinuxからSambaでWindowsに見せている場所: /home/katsuhiro/share/falcon
• Windowsのリモートドライブレター: Z:
• Windowsから見たテストプログラムのある場所: Z:/projects/c/test_argv

このような設定にしていますから、Windows側のネットワークドライブZ:/ が、Linux側の /home/katsuhiro/share/falconを指していることを伝えるために、上記の例のように "set substitute-path /home/katsuhiro/share/falcon z:/" にします。もし対応がわからない場合はSambaの設定を確認しましょう。

いざデバッグ

いよいよ最終目的であるLinux側のgdbserverと、Windows側のVSCode + GDBを連携させます。図示するとこのような構成です。

WindowsからLinuxアプリのデバッグ、それぞれの役割（再掲）

実際にやってみましょう。最初にLinux側でgdbserverを起動します。

$ gdbserver --multi localhost:1234 ./a.out a b c d

Process ./a.out created; pid = 15409
Listening on port 1234
Remote debugging from host ::ffff:192.168.1.112, port 64957

★mainでbreakしたあとcontinueすると下記が出力される

argc: 5
argv[1]: aa
argv[2]: bb
argv[3]: cc
argv[4]: dd
 
Child exited with status 0

その後、VSCodeでmainにブレークポイントを設定します。F5キーを押してデバッグ開始すると、main() 関数で停止し、ソースコードが表示されるはずです。

Windows側からデバッグできている状態

うまくいきました、良かった良かった。

繋がらないときは

Unable to start debugging. Unexpected GDB output from command... のように言われて、デバッグできない場合は、

• miDebuggerPathの場所にx86_64-unknown-linux-gnu-gdb.exeはあるか？
• miDebuggerPathに指定したファイルはコマンドプロンプトなどから実行可能か？
• miDebuggerServerAddressは正しいか？
• gdbserverを起動し忘れていないか？
• Windows用のGDBからtarget remote [miDebuggerServerAddressに指定したアドレス] としたとき繋がるか？

上記を今一度チェックしてみてください。特にgdbserverはデバッグの度に毎回起動しなければなりません。割と忘れがちです。これ非常に面倒なので、改善方法が既にありそうな気がします（今はわかりません）。

Windows要らなくない？

そこに気づかれましたか、鋭いですね、おっしゃる通りです。私もbinutilsをビルドし終わった辺りで、もしやVSCodeをLinux側で動かせば何の苦労もなかったのでは？と気づきましたが、遅すぎたのでここまで突っ走りました。正直、Windowsを使うだけ面倒で、何も利点がないです。なるほど、この方法を実践している人が誰もいないわけです。

Windowsからデバッグだけする方法が向いている人、環境ですか……？うーん、ほとんど居ないと思いますが、強いていえばLinux PCのGUI環境を整備しておらず、整備も面倒と思っていて、普段遣いのWindows PCしか持っていないような方でしょうか。この手順も大概面倒くさいけどね。

気に入るマウスはどれ？

手に合うワイヤレスマウスを探し続け、高級製品、小さい製品、お手ごろ製品と買いまくり、一時は家に5個くらいワイヤレスマウスがありました。

日記から遍歴を辿ってみたところ、少なくとも下記の製品を持っていたようです。

• 2004年12月: Logitech Optical Mouse USB M-UV96
• 2007年1月: Logicool Nano Cordless Laser Mouse V450
• 2010年2月: Logicool Cordless Laser Mouse MX1100
• 2011年12月: Logicool Wireless Mouse M510
• 2012年4月: Logicool Perfomance MX M950
• 2013年10月: Microsoft Wireless Mouse 1000
• 2014年8月: Logicool Perfomance MX M950（2個目）
• 2017年5月: エレコムEX-G Ultimate Laser Mouse M-XGL20DLBK
• 2017年5月: Logicool Wireless Mouse M560
• 2017年12月: Logicool Marathon Mouse M705
• 2021年1月: Microsoft Basic Optical Mouse

全部で11個です。こんなに買っていたとは思いませんでした……。

最終的に辿り着いた先は

色々試して最終的に辿り着いたのは、Microsoftの1000円の有線マウス（Basic Optical Mouse）でした。このマウスは中身がほぼ空っぽでめちゃくちゃ軽いです。

はい、何ですか？ワイヤレスじゃないって？そうですね。ワイヤレスマウスはどうしても重くて、手首が疲れてしまいダメでした。

小さいワイヤレスマウスなら軽いですが、手の大きさと合わずやっぱり手が疲れてしまいます。どうもマウスの持ち方（親指と小指で挟むように持つ）が、小さいマウス、ワイヤレスマウスと合わないみたいです。

という訳でワイヤレスマウスは諦めました。有線マウスは安くて軽くて最高です！

メモ: 技術系の話はFacebookから転記しておくことにした。マウス遍歴を追加。

電源タップの雷ガード

在宅勤務環境を整えようと、電源タップを物色していました。電源タップを見ていると大体3つに分類できて、

• 普通のタップ
• スイッチ付き
• 雷ガード（雷サージ保護）付き

前者2つはわかりやすいです。3つ目の雷ガードとは何者でしょう？前から不思議だったので、軽く調べました。

雷ガードの定義

雷ガードは雷の直撃を防ぐわけではなく（それは避雷針の仕事）、落雷したとき電線に混入する1〜20kV程度のサージ電流を防ぐ仕組みのようです。パナソニックのタップは0.8kV, 1.2kV、LED照明器具は15kV、サンワサプライは15kV, 20kVを最大電圧とした製品を見つけました。

• 「雷サージ保護」の定義 - サンワサプライ
• 雷ガード（雷サージ吸収素子X3）TAP-SP302BK - サンワサプライ
• パナソニック耐雷サージ性能 | 安心品質実験レポート | パナソニック
• 「雷サージ」を防ぐタップを販売しているか、教えてください。 - タップ・延長コード - パナソニック

保護の仕組みですが、サンワサプライは電源系にはバリスタ（Varistor, Variable Resistor）を使っていると書いています。パナソニックのサイトも雷サージ対策にバリスタとあるので、バリスタがポピュラーな仕組みなのでしょう。

参考: 【EMC対策】雷サージ対策部品 "バリスタ" の落とし穴 - パナソニック

バリスタはいわゆる静電気（ESD, Electric Static Discharge）対策で使われる素子です。ツェナーダイオードを2つ逆接続したようなV-I特性で、電圧の正負を気にせず、とにかく高い電圧に対し低い抵抗値を持ちます。

参考: チップバリスタ - 電子デバイス・産業用機器 - パナソニック

バリスタと本体の電子機器を並列に接続します。回路に高い電圧が掛かると、バリスタ側の抵抗値が急激に下がり、バリスタ側に電流が流れます。バリスタ側に電流が逃げることで、本体の電子機器は高い電圧を食らわずに済みサージ電流から保護される仕組みです。

ESDの場合は素子が壊れないように十分な耐圧のバリスタを選定すると思いますが、雷サージの電圧は最大何Vかわかりません。時にバリスタが耐えられない電圧が掛かり、バリスタが故障します。特にバリスタがショートモードで故障し、ユーザーが気づかずに使い続けた場合、素子が加熱し火災が発生する恐れがあります。

これは実際に起きた事故で、10年前にNOATEKの雷ガード製品がバリスタの加熱＆火災を起こし150万個もリコールされました。NITEの解説を見る限り、この製品は「雷ガード＝バリスタ入れればOK」という甘い設計だったため、ショートモードで故障した後、加熱を検知できず火災に至ったようです。

• NITE（製品評価技術基盤機構）の解説
• 経済産業省: リコール情報

雷を防いだら、火事になりました、なんて製品は全く笑えません。安全な設計というのは難しいですね。

こんなことばかり調べているから、全然買い物が進みません。在宅勤務環境が整うのはまだ先のようです……。

メモ: 技術系の話はFacebookから転記しておくことにした。リンク、情報追加、加筆。