目次: Linux
昨日(2021年3月3日の日記参照)の続きです。
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で動作確認しています。
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) を選択します。
ソースコードペインに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がソースコードを見つけられるように設定してあげないと、こんなエラーで怒られます。
今回の例では、
このような設定にしていますから、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() 関数で停止し、ソースコードが表示されるはずです。
うまくいきました、良かった良かった。
Unable to start debugging. Unexpected GDB output from command... のように言われて、デバッグできない場合は、
上記を今一度チェックしてみてください。特にgdbserverはデバッグの度に毎回起動しなければなりません。割と忘れがちです。これ非常に面倒なので、改善方法が既にありそうな気がします(今はわかりません)。
そこに気づかれましたか、鋭いですね、おっしゃる通りです。私もbinutilsをビルドし終わった辺りで、もしやVSCodeをLinux側で動かせば何の苦労もなかったのでは?と気づきましたが、遅すぎたのでここまで突っ走りました。正直、Windowsを使うだけ面倒で、何も利点がないです。なるほど、この方法を実践している人が誰もいないわけです。
Windowsからデバッグだけする方法が向いている人、環境ですか……?うーん、ほとんど居ないと思いますが、強いていえばLinux PCのGUI環境を整備しておらず、整備も面倒と思っていて、普段遣いのWindows PCしか持っていないような方でしょうか。この手順も大概面倒くさいけどね。
目次: Linux
同じことをしている人があまり居なさそうだったので、メモしておきます。
きっかけはGCCのコードをGDBのCUIモードで追っていて辛くなったことです。GCCのコードは超ぐちゃぐちゃの悲惨なコードで非常に追いづらく、GDBをもってしても何が起きているのか把握するのは困難です。せめてデバッガの画面くらいはGUIにして、見やすくできないか、と考えました。
WindowsからLinuxアプリのデバッグ、それぞれの役割
想定する構成は上記のとおりで、Linux側にはGUIがなく(ディスプレイを繋いでいない、など)、Windows側はデバッグのみで、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 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で追ってみます。図示するとこのような構成です。
実際にやってみましょう。ターミナルを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のセットアップについては、ここで解説せずとも、詳しいサイトがたくさんあると思いますので、そちらをご参照ください。
思ったより長くなってきたので、続きは次回に。
今まで、いわゆる日本語配列のキー配列のことを漠然とJIS配列と呼んでいましたが、どうもこれは正確ではないようです。
技術者たるもの、規格を粗末に扱ってはいけませんよね??
JIS配列を定めているのはJIS X 6002-1980「情報処理系けん盤配列」です。この配列を見ると一目瞭然ですが、アルファベット、スペースなどは一致するものの、他のキーは全く違う位置にあったり、そもそもなかったりします。規格書は有料(1,100円)ですが、PFUのサイトでJIS配列の図をタダで拝めます。
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を見ると、
の3つが書かれています。市販のキーボードは、各社ともに適当に魔改造しているため、OADG規格と全く同じキー配列のキーボードは存在しないと思います。たぶん。
実例を出すと、Logicool K295はかなり109Aに近いです。しかし、右Windowsキーが欠けています(このタイプ、俗に108キーなどと呼ばれていますね)。
FILCO Majestouchも素直な109Aに近いですが、右Appキーがなく、右WindowsキーがFnキーに置換されています。
FILCO Majestouch Convertible 2のキー配列
私の場合は、最下段は 左Ctrl, 左Win, 左Alt, スペース, 右Alt, 右Ctrlしか使わないので、K295やMajestouchのように使わないキーが欠けていても気になりませんが、使う人からすると、何てことするの!?という気分になるでしょう。
さらに言うと、無変換、変換、ひらがなキーも使わないので、使っているキーの種類だけ考えたら、いわゆる英語配列(OADG 104型)で十分に思えます。しかし日本語配列で練習したため、英語配列は記号類を間違えまくります。私物で購入したことはありません。打てて損はないので、もうちょい修行しても良いかもしれませんね……?
メモ: 技術系の話はFacebookから転記しておくことにした。写真追加、加筆。
先日の在宅勤務環境改善(2021年2月12日の日記参照)にて、デュアルディスプレイにしたところ、ノートPC本体が邪魔になってしまったので、机の上からどけました。
当然、ThinkPad本体のキーボードには手が届きませんから、ワイヤレスキーボードLogicool K295を買いました。Amazonで1,900円くらいでした。K295は変なキーも少ないし、静かで良いですが、キーの認識が渋いです。私の場合、打鍵力が足りず人差し指担当のキー(T, Uなど)の誤打が多発してイライラします。
買ってすぐ買い替えるのもどうかと悩みましたけど、あまりに誤打が多く慣れるまで辛そうだったので、さっさと諦めFILCOのMajestouch赤軸を買いました。ヨドバシで15,000円くらいでした。Majestouchはキーが戻るとき&底打ちしたとき「カーン!」と響く鐘のような音がやかましい以外は、非常に良いキーボードです。
今まで、キーボードは標準的なキーボード(※)であれば、高くても安くても使い心地が気になることはないと思っていました。しかし今回K295がどうも合わなかったことから、実は自分とキーボードの相性って結構あるのか?と疑問に感じるようになりました。
(※)OADG 109A型の配列で、カーソルキー、ファンクションキー等の位置を移動していないキーボードのこと。
まずはキーボードの使用履歴を書き出してみます。
相性とか全く気にならなかった。
誤打しやすかった。
まともに打てなかった。
以前K340やHHKで懲りて、特殊なキー配列のキーボードに触らなくなったので、コンパクト系のキーボードの利用歴はほぼゼロです。そもそもまともに打てないし、レビューできません。
ほとんどPC付属キーボード、ノートPCのキーボードばかりです。これはもしや、勝手に安物だと思いこんでいたPC付属の標準キーボード、実は質が高かったのではなかろうか?
大事な製品に標準で付属するものですし、高級ではないにせよ、あまりに変なものはつけませんよね。これが答えなのでは、という気がしてきました。
Slideshareを初めて使いました。LinkedInのアカウントが必要なのは知りませんでした。偶然LinkedInのアカウントを持っていたので、すんなり登録できました。
試しに USB Type-C, USB PDケーブルとお友達になろうをアップロードしました。ダウンロードもできるし、スライド置き場として優秀ですね。みんな使うわけだ……。
スライドの話もしておくと、USB Type-Cケーブルがどうして何種類もあって、値段が全然違うのか、気になったので調べたことをまとめたものです。USB初心者なので間違ってたらすみません。
最後まで分からなかったのはUSB Power Deliveryの3A/5Aケーブルを見分ける方法です。何か無いんでしょうか。当然USB PDのアナライザで見ればわかりますよ?でもアナライザなんか普通の人は持ってませんよ。パッケージから出した途端に見分けが付かなくなるなんて、一般消費者からしてみたら辛すぎません?
内閣府の「主要耐久消費財等の普及率」「主要耐久消費財の保有数量の推移」(リンク)によると、2人以上の世帯のPC普及率は77.0%、100世帯辺り123.6台(2020年3月)だそうです。
保有世帯だけを考えれば123.6 / 0.77 / 100 = 1.61 [台/世帯] ですから、世帯人数 <PC台数です。PCを日常的に使う習慣がない限り、共有のPCが1台あれば十分ですし、納得感ある結果です。
では、一般のご家庭に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台」これが一般のご家庭の限界と思われます。
では、色々逸脱した逸般の誤家庭の場合はどうでしょうか?
家庭の電気契約は「従量電灯B」という契約(従量電灯B・C電気料金プラン - 東京電力エナジーパートナー株式会社)がほとんどです。従量電灯Bの最大契約アンペア数は60Aで、全て200Vから取ると最大12kWです。したがって12000 / 800 = 15台が限界です。ふーむ、意外と伸びませんね。
冷却の電力は完全に無視しています。冷却を無視したまま15台も置いたら、家の中は一瞬で灼熱地獄になり、人間もPCも死ぬと思います。
大口需要向けに「従量電灯C」という契約もあります。
従量電灯Cの場合10Aごとに基本料金が従量的に増える青天井の契約になります。一般家庭でも契約可能のようです。基本料金を比較すると、従量電灯B< 従量電灯Cとなるため、一般のご家庭だと損するだけで契約する意味はありません。
本来、家電が大量にある豪邸や、業務用の電気機器がある商店用ですが、60Aに満足できない真の逸般の誤家庭にも向いているかもしれませんね。
群とか環とか体とか、大学で教えてもらった記憶がうっすらありますが、何回見ても忘れます。幸いにもWikipedia先生に割と詳しく解説されているので、まとめておこうと思います。
集合Gと二項演算uの組(G, u)を考えます。uは乗法や加法と呼ばれる場合があるようです。以降u(a, b) をa + bの形で表します。
下にある群は、上の群の性質をすべて満たします(以降も特に断りがなければ同じ)。なので、モノイドは半群の性質を満たしますし、群はモノイドと半群の性質を満たします。
集合Rと2つの二項演算u, tの組(R, u, t) を考えます。(R, u) はアーベル群です。uは加法、tは乗法と呼ばれるようです。以降t(a, b) をa * bの形で表します。
群と違って、環はモノイド(単位元が存在する)である必要はないみたいです。
可換環では零でない零因子という困ったことが起きます。
困る例として挙げられていたのは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でもない。
環はこういうパターンが無数に出てきて、さらに条件を厳しくしないと困る場合がありますよ、ということですかね?
変わった名前ですが、環の一種のようです。環で発生する零因子による困った問題を排除しています。
群環体の「体」まで辿り着きたかったのですが、整閉整域、一意分解整域、主イデアル整域、ユークリッド整域、体、有限体、と訳のわからない名前のオンパレードで、力尽きました。また今度調べます。
現在使っているThinkPad E480はUSB Type-C端子とHDMI端子しかありません。先日(2021年2月12日の日記参照)新しく購入したディスプレイ2つに画像を出力するには、USB Type-CのDisplayPort Alternate Mode(VESAの機能紹介のページ(英語))を使う必要があります。接続はこんな感じです。
このときE480とディスプレイを繋ぐUSB Type-Cケーブルは3つの役割を果たします。
たった1本のUSB Type-Cケーブルで3役もこなす凄いヤツです。今まで「ACアダプタ」「DisplayPort」「USB Type-A」の3つに分かれていたコネクタが、USB Type-C 1つに統合できますから、省スペースが命のノートPCにとっては大歓迎の機能でしょう。
そんな凄いヤツを使い始めて数日ですが、既に嫌になってきました。正直な感想として、少なくともユーザーからすると便利と思えないし、使わなくて良いなら使いたくないです。
ケーブルの問題は今後、技術革新で細くなることを祈るしかありません。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の面々には明らかなはずですけど、何でこんなデザインにしたんですかね?理解しがたいよ……。
昔SHARP SF1という製品がありました(DIMEの記事)。スーパーファミコンとテレビが1つに合体した、当時小学生だった私には夢のような製品でした。配線なしで見た目スッキリ、場所も取らない、ACアダプタやビデオケーブルを接続する手間も不要、いかにも便利そうじゃないですか?結構お高いのもあって、友達が持っているのを見て羨ましかったです。USB Type-Cも似たような売り文句です。
しかし後から聞くところによれば、テレビが故障するとスーパーファミコンを外せないから他のテレビに繋げなくて困る、逆にスーパーファミコンが故障するとテレビごと修理になって高ぇわテレビがなくなるわで困る、元より不便になっています。元々バラバラの製品を無理やり一蓮托生にしたら、そりゃそうなりますわな……。無関係の機能をデタラメに統合してはいけない、という好例です。
残念なことにUSB Type-CもDisplayPortとUSB PDの機能統合で、似たような落とし穴に落ちています。小学生の私に「21世紀になっても人類はSF1と同じ過ちを繰り返しているよ」って教えてあげたいですね。
COVID-19が流行し始めた昨年2月ころ、在宅勤務が主となりました。当時の気持ちを正直に言えば「すぐ収束して、電車通勤に戻るだろう」で、完全にナメていました。在宅勤務の環境もまったく整えておらず、ダイニングテーブル、ノートPC+8インチのモバイルディスプレイでした。夕食時は邪魔だから、仕事道具をガサガサ片付ける、といった具合です。
そんなこんなで1年間やってきたものの、COVID-19の予想外の長期化、それに加えて会社方針(COVID-19が収束しようとしまいと、今後は在宅勤務)もあって、在宅勤務の環境を改善することにしました。
家には、奥さんが一昨年の在宅勤務で使っていた部屋があって、幅100cmの机と背もたれ付きのオフィスチェアがあります。そのスペースを譲ってもらうことにしました。
すっかり勤務形態が逆転しました。会社のみなさんの話を聞くと、東京の狭い家で夫婦とも在宅勤務、子供まで自粛で家に居て、全く仕事にならん……みたいな地獄化したご家庭もあるみたい。我が家も夫婦同時に在宅勤務だと、スペースの確保がちょっと大変だったと思います。交代で在宅勤務になったのは、今思えば割とラッキーだったのかな?
ダイニングテーブルはしっかりした作りで、間違いなく家で一番上等なテーブルです。一方のダイニングチェアは年中使い続けるような椅子ではなかったらしく、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は重たいのが難点(純正スタンドがめちゃ重い)ですが、変な色やら、映らないやらのトラブルは皆無で非常に快適です。以前勤めてた会社(パナソニックやソシオネクスト)でも大変お世話になりました。良いメーカーですよね。
目次: ベンチマーク
先日(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で測ってみましょう。手元にあるのは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で測ってみましょう。手元にあるのは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にしかわかりませんが、なかなか興味深い結果です。
最近の日本やら先進国やらの迷走を見ていると、民主主義って人口ピラミッドが逆転することを考慮できていないのでは?と疑問を感じます。
人口ピラミッドが逆転して高齢世代が主流派になると、
このような政策が支持されるので、少子化はさらに加速し、先のない高齢世代に最大投資しまくる、まさに今の日本みたいな状態になります。当然ながら経済力は下がる一方ですし、滅亡一直線の国家です。
民主主義のバグとしか思えないですね……。
目次: 車
ディーラーから電話がかかってきて「(車検と一緒にセットで頼んだ)半年点検どうしましょうか?」と聞かれました。実は頼んだことを忘れていたので、確認してもらって助かりました。「半年前の車検で一緒にご依頼されました半年点検なんですが〜」と説明が妙に手慣れた感じだったところを見るに、頼んでおいて忘れてしまう、私みたいな人が多いんだな〜なんて思った。
点検結果はというと、走行系の異常はありませんでした。フロントのウォッシャー液を送るゴムホースが破損していて、フロントのウォッシャー液が出ないうえ、むりやり使ったらエンジンルームにダダ漏れするそうです。え、そうなの??全く気づいていませんでした。ウォッシャー液って全然使わないんだよね……。
部品の取り寄せが要るためすぐには直せず、修理の際はご予約いただきたい、とのことだったので、またどこかの土曜日にでも持っていこうと思います。
私のようなおじさんがディーラーに行くと、新車のカタログをたくさん渡されて「新車どうです?」って話されるんですが、最近のスバルではなーんにも聞かれません。今のスバルはレガシィB4 GTの乗り換え先がないからです。
スバルの現行車種でセダンはインプレッサG4だけです。G4は上級グレードの2.0iでも、2リッターNA(154馬力)です。レガシィB4 GTの2リッターターボ(280馬力)から乗り換えると大幅パワーダウンは否めず、おすすめしづらいのでしょう。現にディーラーでもカタログだけもらったものの、ほとんどプッシュされませんでした。
ちょっと前なら、インプレッサWRX S4 STI Sportがありましたが、生産終了してしまいました。仮に現行車種だったとしても、一般人向けとは思えんし、気軽に「WRX S4いかがですか?」とは言いにくいでしょう。スバルのディーラーにとってセダン乗りは鬼門ですね。
< | 2021 | > | ||||
<< | < | 03 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | 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 | - | - | - |
合計:
本日: