エルザ・ジャパン様の対応が神レベルだった件

雑文です。

現在取り組んでいる SSD-to-GPU ダイレクト機能の実装には、PostgreSQL/PG-Strom側の機能拡張だけれなく、NVMe SSDからGPU RAMへのDMAを実行する Linux kernel ドライバの開発が必要になる。

Linux kernelにはDMAを実行するためのインフラが既に多数揃っているので、ドライバの開発自体はそれほど大仕事ではないのだが、GPUがその機能に対応している必要がある。

NVIDIA提供のドキュメントによると、
GPUDirect RDMA :: CUDA Toolkit Documentation

GPUDirect RDMA is available on both Tesla and Quadro GPUs.

と、あり、いわゆるコンシューマ向け廉価製品であるGTXでは対応していない。

対応していないというのは、GPU上のRAMをホストアドレス空間にマップするためのAPIである nvidia_p2p_get_pages() がエラーを返してしまうので、それ以上は如何ともし難いという事である。

int nvidia_p2p_get_pages(uint64_t p2p_token,
                         uint32_t va_space_token,
                         uint64_t virtual_address,
                         uint64_t length,
                         struct nvidia_p2p_page_table **page_table,
                         void (*free_callback)(void *data),
                         void *data);

試しに、手元で利用可能なGPU何種類かでトライしてみたところ

  • × GTX 750Ti
  • × GTX 980
  • ○ Tesla K20c

という結果。GTX980は割とハイエンドのモデルではあるのだが、それでも対応してないモノは対応していない。

会社で使う分には Tesla K20c があるので良いのだが、問題は週末プログラマの開発環境。
特に今年のゴールデンウィークは長いので、"動作確認・デバッグは連休明けまでお預け" なんて事になると精神衛生上も大変によろしくない。

ので、上記の GPU Direct 機能に対応していて、かつ、できるだけ廉価な製品を買う事にした。

Teslaシリーズはさすがに高くて手が出ないので、ワークステーション向け Quadro のラインナップから選択。エントリーモデルかミドルレンジ程度ならなんとか手が出る。

NVIDIA Quadro シリーズ | カテゴリー製品情報 | 株式会社 エルザ ジャパン

とはいえ、今回購入する事になった Quadro K1200 は4万円程度の品で、個人で買うには覚悟の要る品物。『TeslaとQuadroで対応って書いてあるけど、あれってハイエンドモデルだけだから(テヘペロ』みたいのが一番困るので、日本でのNV社代理店であるエルザ・ジャパン様に問い合わせてみた。

質問)
Quadro K1200 の購入を検討しているのですが、GPUDirect RDMAには対応しているでしょうか?

NVIDIA社のドキュメントには以下の記述があります。
http://docs.nvidia.com/cuda/gpudirect-rdma/index.html

GPUDirect RDMA is available on both Tesla and Quadro GPUs.

回答)
GPU Directにつきましては、サポートされていますので、下記のアドレスを参照してください。
http://www.nvidia.com/object/compare-quadro-gpus.html

ただ、製品ごとの機能マトリックスには『GPUDirect for Video』という項目が掲載されており、しかもK1200にはチェックが付いていないという内容であったので、再度確認してみた。

当方が気にしているのは、以下の GPU Direct 機能の対応可否です。
https://developer.nvidia.com/gpudirect

Using GPUDirect, multiple GPUs, third party network adapters,solid-state drives (SSDs) and other devices can directly read and write CUDA host and device memory, eliminating unnecessary memory copies

とあるように、SSDGPUへの直接データ転送を行う Linux kernel ドライバの開発に使用したいと思っているのですが、『本当にこれを買ってしまっていいの?』 という疑問が腹落ちしておりません。

お手数ですが、再度確認をお願いできないでしょうか?

その後、

失礼しました。

実際に動作確認をしますので、少しお時間をいただけますでしょうか?
後日、ご連絡いたします。

という連絡があり、その数時間後に、

別の部署にて確認しましたところ、動作はするようですが、
K1200 の IB 4ノードクラスタより、1ノードで、Tesla の方が速いそうです。

と、実際に動作確認を行った上で回答を頂いた。

GPUは開発・デバッグ用に使いたいだけなので、性能は全く気にしていない。なので、早速ポチっと注文。日曜日の夕方には届いたので早速PCに装着してみた。


これまで使っていたGTX 750Tiを取り外し、Quadro K1200を装着する。


Quadro K1200とIntel 750 SSDを同じPCI-Eバス上に装着。
これで SSD-to-GPU ダイレクトを使用する前提条件が整った・・・ハズ。

試しに、作成途中のカーネルモジュールをロードし、テストプログラムで ioctl(2) を叩いてみる。

$ sudo insmod nvme-strom.ko
$ ./driver_test -p 4 /opt/nvme/testfile
vaddr=0x701720000 length=4194304
ioctl(STROM_IOCTL_PIN_GPU_MEMORY) = 0

OK、0が返ってきたという事は、Quadro K1200上で nvidia_p2p_get_pages() が正しく動作している。

$ dmesg | tail -80
[ 6933.359672] nvme-strom: P2P GPU Memory (handle=18446612149830398528) was mapped
  version=65537, page_size=1, entries=64
[ 6933.359675] nvme-strom:   H:0000000701720000 <--> D:00000000e0180000
[ 6933.359676] nvme-strom:   H:0000000701730000 <--> D:00000000e0190000
[ 6933.359677] nvme-strom:   H:0000000701740000 <--> D:00000000e01a0000
[ 6933.359677] nvme-strom:   H:0000000701750000 <--> D:00000000e01b0000
                   :

ログメッセージにも、デバイスの仮想アドレスと物理アドレスの対応が表示されており、GPUのページテーブルを正しく取得できたという事を示唆している。これで勝つる。

という訳で、こんな質問を投げるマニアは一体何人おるんだというニッチな問い合わせに対して、しかも小売価格で高々4万円の製品を売るために、わざわざ動作検証まで行っていただいたエルザ・ジャパン様のユーザ対応に大変感動した次第である。

GTCで喋りました

という訳で、GTCで喋ってきました。

www.slideshare.net

今までの発表とは少し趣を変えて、PG-Stromそのものの説明よりも、現実世界のワークロードを実行するときにどういった使い方があり得るか、どういった効果が得られるかに主眼を置いた内容。

f:id:kaigai:20160408081720p:plain
伝統的にDBMSは、正に字面の通り、データベースをマネジメントするソフトウェアである訳なので、インデックスを張って目的のレコードを高速に取り出したり、テーブル同士を結合する事は得意だが、(一応SQLの構文で書く事はできるとはいえ)大量の計算をこなすには向いていない。
少なくとも、データ解析専用に設計されたツール(例えばR言語)を使って計算させた方が高速で、しかも統計解析系のパッケージも揃っているので、普通はデータベースからデータをエクスポートした上でデータ解析処理を行う。

では、PG-Stromを入れることで計算処理が早くなれば、この前提が変わるか?というのが今回のお題。

■ DB内で解析処理を行う事のメリット

  • サーバ~クライアント間でデータを移動せずにすむ。数GB単位の大きさになると無視できない。
  • 通常はクライアント側よりも強力なサーバハードウェアの計算能力を使用できる。
  • 常に最新のデータセットに対して解析処理を行うことができる。

■ DB内で解析処理を行うことのデメリット

  • サーバ側が十分な計算能力を持っている必要がある。
  • DBMSがデータ解析処理に対応するよう設計されている必要がある。
  • 専用APと比べると、ライブラリ類の整備が不十分。

ライブラリ類の充実はともかくとして、計算能力に関してはいかほどのものか。

f:id:kaigai:20160408081727p:plain

今回の実験のターゲットは、創薬に関連したワークロードの一つで、大量の化合物の中からできるだけ特性の異なった化合物を選択するというもの。これにより、実際に化合物を合成して特性を調べるなど、"お金のかかる" ステップを少なくしたいというモチベーションがある。

f:id:kaigai:20160408081740p:plain

使用したアルゴリズムはMAX-MIN法と呼ばれるもの。実際には何個かのクエリを繰り返し実行するのだが、ワークロードの中核、最も計算が重い部分は赤点線で囲った距離計算の部分。
化学物質の特性を数値パラメータ化し、比較対象との"距離"を計算する。
基本的にはこの距離が大きな化学物質を順に選択することで、ある一群からピックアップした k 個の化学物質の特性ができるだけ他と異なるものになる。

f:id:kaigai:20160408081748p:plain
これを、SQLによるデータエクスポート+R言語でのローカル計算、SQLで実行+R言語で結果参照 with/without PG-Strom の3パターンでそれぞれトライしてみた。
結果は、PG-Stromなしのパターンが圧倒的に遅く、R言語のローカル実行と、SQL+PG-Stromのリモート実行が概ね同じという結果になった。

そのため、現状でも『わざわざデータをEXPORTしてローカルで計算しなくても、SQLで全部計算させて結果だけ取ってきた方がデータ管理が楽ですよ』というのは言えるだろう。


一方で、他の並行セッションでは、よりHPCに近く計算能力を必要とする人工知能の研究成果が発表されており、『SQLを高速に処理する』がためにGPUを使用するPG-Stromの設計では専用にチューンしたアプリケーションに太刀打ちすることはできない。
(する必要があるのかどうか、という議論は当然あるが)

しかし、データに最も近い場所でCUDAプログラムを実行しうるプラットフォーム機能を既に有しているというアドバンテージを活かすのであれば、OLTP/OLAPという伝統的DBの世界から外れたところのワークロードについて考えてみる価値はあるだろう。おそらく、必要な要素技術は既に揃っている。

f:id:kaigai:20160408085151p:plain

検討してみたいのは、前回のエントリでも書いたアイデアで、CUDAのロジックをSQLで記述するための機能。

PostgreSQLでは、SQL関数を記述する言語を拡張モジュールによって定義する事ができる。
したがって、CUDAによって記述されたSQL関数を実現するのはそれほど難しい話ではない。

SQL上で hogehoge(matrix, vector) などと定義された関数であれば、実行時には、第一引数に行列をコピーしたバッファのポインタを、第二引数にベクトルをコピーしたバッファのポインタを渡すようにすればよい。フラットな単純配列に対してCUDAカーネルを起動すれば、あとは普通のHPC屋さんがやっている内容になる。

現状のSQL->CUDAへのコード変換の場合、SQLに由来するNULLチェックや四則演算の都度発生するオーバーフローチェックが入っているため、計算処理に重きを置くのであれば相当に効率の悪いコードになっている。

何から何までCUDAのコードを書かせるのはアレだが、R言語などでもパッケージ化されていて比較的良く使われる関数、例えば kmeans() 相当がCUDAのフルスピードで実行できるようになったらどうだろうか?

SQLでkmeans法のアルゴリズムを記述した場合、繰り返し処理の記述性が高くなく無駄な処理が入っていることもあり、現状では PG-Strom を用いてもRのkmeans()関数の1.5倍程度の時間を要している。(PG-Strom無しだと実行完了を諦めるレベルだが)

CUDAのフルスピードで行列演算を実行できれば、計算部分の処理速度を現状から更に一桁向上させる程度はできるだろう。
RDBMS的にはニッチもニッチでいい所の機能だが、『明らかに高速化の効果を実感できる』機能として、前倒しトライしてみるのも良いかなと思えてきた。

GTCに来ています

今年もサンノゼで開催されている GPU Technology Conference 2016 に参加しています。

# なお、当方の発表『In-Place Computing on PostgreSQL: SQL as a Shortcut of GPGPU』は木曜日の予定

f:id:kaigai:20160405081234j:plain
キーノートでは、NVIDIA社CEOのJen-Hsum Huang氏より"ディープラーニング向けプロセッサ"と銘打って、新アーキテクチャPascalを搭載したTesla P100が発表に。また、CUDA8.0のリリースが6月である事も発表された。
(一方で、事前に噂されていたPascalベースのコンシューマ向けGTXモデルへの言及はなかった)

f:id:kaigai:20160405102340j:plain

このPascalアーキテクチャベースのTesla P100であるが、Inside Pascal: NVIDIA’s Newest Computing Platformに記載のある通り、

...等々のお化けプロセッサである。

プログラムを書く上で、Maxwell世代から変わっている点、新機能が追加になった点がある。

  • SM(Streaming Multiprocessor)あたりのCUDA Core数が減っている

128個 -> 64個になった。一方でSM数は56個に増えており、これでトータル3584CUDA Coreという訳だが、SMあたりのレジスタファイル容量(256KB)は据え置き、共有メモリ容量(64KB)は33%増加*1であるので、システム全体として見ると、大幅な増強となっている。

また、SMあたりのコア数が少なくなった一方で、レジスタ、共有メモリの容量が据え置きになっているという事は、ある特定のSMに対して一度に投入できるタスクの数が増え、それにより、例えばDRAMアクセス待ちの間に他のタスクにスケジュールして計算コアの使用率を上げる事ができると思われる。

PG-Stromのようにnone-coalescedなメモリアクセスが多いワークロードでは嬉しいかも。

PG-Stromには嬉しい新機能。現状、PostgreSQL数値計算系の関数は全て64bit浮動小数点で、標準偏差や分散、共分散などを集計する時には、内部的には cmpxchg 命令を使った atomic 演算のエミュレーションを行わざるを得ないので、H/Wによりネイティブの atomic 演算がサポートされれば集計系の性能向上が期待できる。

  • プリエンプションの対応

仮想化環境での利用を見込んだ機能か?上述のSMに投入できるブロック数が増えたという事も併せて考えると、Pascal世代ではGPUの同時並行利用が大いに促進されるような気がする。

  • デマンドページング

従来は、予め必要となるバッファサイズを予測してCUDA Kernelを起動する前にデバイスメモリのアロケーションが必要であったが、これにはある程度マージンを取る必要があるので、実際には無駄になる領域が少なからずあった。GPU側でもPage Fault→デバイスメモリ割当てという流れが可能になる事で、リソースの有効利用が可能となる。
一方で、Page Faultのコストは無視できないほど高いので、cudaMemPreFetchAsync()などCUDA8.0で対応となる新APIにより、プログラムがヒントを与えてやる必要がある。

  • HBM2

一目で分かるように、スループットが大幅に引き上げ。現行世代の3倍弱。
ただし、これはメモリアクセスがcoalescedな場合の性能向上で、none-coalescedなメモリアクセスはレイテンシが律速要件になるため、現行世代と比較して10%程度の向上との事。

行指向データ構造を使うPG-Stromとしてはちょっと悲しい所だが、対策としては、例えばDRAMからデータを一旦共有メモリにロード(ここはcoalescedなアクセスで)。その後の共有メモリへのアクセスはL1キャッシュと同じレイテンシなので、そんなに気にはならないはず。

SMあたりのCUDAコア数が減った事で、こういう最適化も考えられる。


さて、会場でSさんとHさんに『PG-Stromの上でMachine Learningのアプリとか動かせるようにならないんですかね~?』と無茶振りをされる。

現状、"PostgreSQLと同じ使用感"で使える事を優先するために、本来は効率の悪い行指向データをリッチな計算リソースで無理やり並列処理しているので、専用のアプリケーションでの処理と比べるとどうしても分が悪い。

ただ『データのある場所で計算を行う』というのは正しい方向性なので、SQLで数式を書いたら自動的にコード生成⇒GPU実行、という流れに拘らなければ、SQLクエリ実行の過程でデータ密度の高いデータ構造を作り出し、これをGPUで実行するMachine Learning用の(でも、何か他の数値計算の)アプリケーションに渡してやるという事はそんなに不自然ではないのかな、とは思う。

例えば、32bit浮動小数点型の2次元配列・NULLなしというデータ構造であればぎっしりデータが詰まっており、先頭からのオフセットだけでアクセスすべきデータを特定できる。つまり、行指向ならではの不都合はない。これを仮に matrix 型と名付けて、

SELECT my_deep_leraning(SELECT make_matrix(x0, x1, x2, ..., xN)
                          FROM data_source
                         WHERE 抽出条件
                         GROUP BY グループ化条件);

みたいなクエリで実行できれば、、、、って事にはなるだろう。

ただ、当然に考えねばならん課題もあり、
・生成するMATRIXがGPUのRAMサイズに収まらない場合
・粗行列の場合、本当に単純な配列表現でいいのか?
・一行に対して複数のCUDA Kernelで処理する事になるので、PG-Stromにとってはwhat's new

面白いアイデアなので、もう少し考えてみたいところではある。

*1:たぶんブロックあたりのサイズの事を言っている。SMあたり容量ならMaxwellの上の方は96KBなので

さらばドイツ

2011年2月にドイツへ赴任し、以降2年10ヵ月間、SAP社とのアライアンス業務に携わっていたわけですが、11月末で任地での業務を終了し日本へと戻る事になりました。

振り返れば、初めてフランクフルトの空港に到着した後、一歩外へ出たら氷点下の世界(注:ドイツの2月です)で『こりゃトンデモない場所に来たもんだ』と思ったものですが、まぁ、住めば都で何とかなるもんですな。

オフィスはドイツ南西のWalldorf市(SAP本社がある)。住むには少し規模が小さな街なので、隣のHeidelberg市の旧市街のマンションを借り、1月遅れで嫁さんも日本からやってきました。
f:id:kaigai:20120331145434j:plain

お仕事的には、2011年前後というのはちょうどSAP社がSUSE LinuxベースのインメモリDB製品 "SAP HANA" をぶち上げ始めた頃で、主に技術面でSAPやSUSEとの折衝や、HANA認定取得の実作業というのが駐在中のメインのお仕事でした。

NEC SAP HANA向けアプライアンスサーバを販売開始
http://www.nec.co.jp/press/ja/1203/0901.html

その他にも、NECのHA製品CLUSTERPROで、SAP NW~HA製品間で連携するためのインターフェース認証を取得したりとか。

NEC、「SAP HA Interface Certification」認定を取得した「CLUSTERPRO X 3.1 for SAP NetWeaver」を発売
http://jpn.nec.com/press/201210/20121002_01.html

この手の "○○認証" という仕事が多かったのですが、SAPの認定プログラムはちょくちょくおかしくて、例えば SAP Linux 認証プログラムは80コア/160HTのNECサーバの認定を通すために、SAPの認定プログラムの方を手直しして認定を通したりとか。

一方、OSS活動は工数の20%~30%を充当して良いという事を条件に赴任したので、まだ中途であるSE-PostgreSQLの開発も継続する事ができた。これは会社に感謝。ただ、OSS活動に専従という訳ではないので、MLでの反応が遅れたりと、コミュニティに対して少し申し訳ない。
ドイツに居る間に新たに開発してみたのが PG-Strom というモジュールで、クリスマス休暇の間にCUDAを使ってプロトタイプの実装を行ってみた。これがもう一つ、自分にとって軸となるソフトウェアになるかもしれない。
http://kaigai.hatenablog.com/entry/20120106/1325852100

f:id:kaigai:20131201153401j:plain
これをプラハでのPGconf.EUで発表した際に、非常に大きな反響があった事は"コレは行けるんじゃないか?"という確信に繋がった。これはNECに限った事なのか分からないけども、自分の組織の外に対して何かを発表し、フィードバックを得るという機会が極端に少ない、あるいはナイーブになっているような気がする。
そうすると、自分の提案したい事が第三者の視点から見て価値ある事なのか、そうでないのか確信できないので、上司にちょっとダメ出しされただけで萎縮してしまうという事に繋がらないか。
先日、晴れて四捨五入したらオッサン年代に突入したので偉そうな事を書くと、若い人は公式非公式を問わず、自分のアイデアを社外で発表する機会を持った方がよい。そうすると、上司のダメ出しが的を得ているのか、的外れなのか、自分の判断基準を持てるようになるから。

この辺SAPが偉いなと思うのが、SCN(SAP Community Network)という仕組みを用意し、Wikiやブログを通して開発者やパートナー企業とエンドユーザが直接意見交換できる仕組みが機能している事。例えば製品の変な使い方やプロトタイプ的に作ってみた機能(当然公式にはサポート外)をオープンにして、それに対するフィードバックを受けられるようにしている。
もちろん、これはSAPのように非常に強力なパートナー網、顧客網というエコシステムを持っているからこそできる事。同じ事ができる企業は非常に限られている。
ただ、エコシステムの主催者でなくともコントリビュータとして社外の意見フィードバックを活用するというのは可能。まさにOSSコミュニティが日常的に行っている事で、だからこそイノベーションがそこにある。

仕事環境で言うとドイツ人が偉いのは、きっかり時間通りに仕事を切り上げる事。
2011~2013シーズンはBaden-Hillsカーリングクラブでプレーしていたのだけども、毎週火曜日19:30~のリーグ戦に皆きっちり集まるのがすごい。日本のカルチャーでは難しい所もあるけど、ぜひ見習いたい。目前の業務にばかり時間を費やして、別の領域にアンテナを張る時間や余暇の時間がなければ新しい発想なんて生まれないし、それが中長期的には組織を徐々に蝕んでいく事になるんじゃないかと思った。
f:id:kaigai:20111011183217j:plain

その他、生活面では嫁さんが考えて日本食を作ってくれたので、病気をする事もなくきっちり職務を遂行する事ができた。感謝。結婚してからの3年間、風邪をひく事すら無くなった。
ヨーロッパに住んでいる事で、なかなか日本からは行きにくい場所を旅行できた事は役得だけど、書き出すとキリがないのでないのでこれはまた別の機会に。

f:id:kaigai:20120331154344j:plain

日本に帰った後は、SAPから離れて再びOSSの仕事に戻ります。
自分で手を動かしてコードを書くと同時に、それをお金に換えていく方法をデザインする事が求められているので、タフな仕事だけども、一つのロールモデルとして後進に示せれば良いかなと。

それでは明日、ドイツを発ちます。

人生に影響を与えたプレゼンテーション

10年近くも技術者をやっていると、他の人のプレゼンテーションを見る機会はちょくちょくある。(別にOSS/Linuxに限った話じゃなくて)
全く印象に残らないものから、発表後にプレゼンターを捕まえて議論が始まるもの、中には自分の考え方や活動に影響を与えたプレゼンテーションというのもあるハズ。

パッと二つ思い浮かんだのでご紹介。
・・・まぁ、他の人はどんなプレゼンテーションを見て心動かされたのか知りたい、という下心もあるんですが。

How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon/Japan 2009)

なぜオープンソースへの貢献が重要で、ビジネス上も意義のある事である事なのかを説いたLinuxCon/Japan 2009でのキーノートの一節。
本来、企業が何か"価値"を顧客に届けるには、その価値の源泉であるUnique Innovationの部分と、その前提であるDelivery Support for the innovationの部分に投資をしなければならないが、オープンソースを活用する事で企業はUnique Innovationの部分に注力でき、コミュニティと歩調を合わせて進む(勝手forkをしない)事でDelivery Support for the innovationの部分をShared Cost(そう、freeではなくshared costなのです)に保つ事ができるという趣旨の発表。

確かに自分のケースを振り返ってみても、SE-PostgreSQLを開発するために、その価値の源泉であるSELinuxとの連携モジュールはともかくとして、SQL構文解析やクエリ最適化、クエリ実行といったRDBMSそれ自身を作るなんてのはあり得ない話。確かに自分も"巨人の肩に乗って"開発しているんだと納得したものだ。

企業がオープンソースの開発に貢献した方が、より低いコストでイノベーションを達成できる事、そして"Free"でなく"Shared cost"である事。この考え方は正に自分の人生に影響を与えたと思う。

Parallel Image Searching Using PostgreSQL and PgOpenCL (Tim Child, 3DMashUp; PGcon2011)

もう一つは、昨年のPGconで聴講したTim ChildのPG/OpenCLの発表。
内容はRDBMSに格納した画像データ(レコード長がかなり大きい)をGPUで高速に処理するというもの。
何が心に刺さったかというと、(一字一句正確ではないかもしれないが)最後のまとめで彼が語った『Database records are ideal data structure for parallel processing(データベースのレコードは理想的な並列処理のデータ構造だ)』という一言。

これを聞いて、なるほどGPUを使ってCPUをオフロードすれば、検索処理を高速に処理できるではないか・・・?という発想でCUDAやOpenCLを調査し、その半年後にできたのがPG-Stromというモジュールだったりする。

さて、他の人に聞いてみたら、どんな『自分の人生に影響を与えたプレゼンテーション』が出てくるのだろう?

はてなダイアリーに引越ししました

今までさくらのブログを使って『KaiGaiの俺メモ』を書いていたが、はてなダイアリーに引っ越す事にした。

自分のメモは、性質上、ソースコードを引用することが多いが、さくらのブログではそういう場合、<pre>〜</pre>タグを使わなくちゃいけなかったり、HTMLタグを直打ちにした場合に、他の改行すべき部分にも全て<br>を挟まないとダメとか、段組のための記法がない、とかで、ブログを記述するのがモチベートされない(←重要)という欠点があった。

なお、はてなダイアリーの仕様上、過去のコメントはインポートされませんので、過去記事に関しての議論などは旧KaiGaiの俺メモを参照して下さい。

足元の寒さ対策

この時期、長時間PCデスクに向かっていると、どうしても足元が冷えてしまう。自分はあまり頓着しない方だが、こうも毎日寒いとさすがに参ってしまう。

そこで、某hibikiさんが愛用しているという湯たんぽを購入してみた。近所の商店街で880円也。
(ただし、これは電子レンジ不可)

お湯を注いで足元に置いてみたところ、非常に善い!!

3リットルとかなり容量のあるものを買ったので、両足を置いても平気だし、なにより4〜5時間は温まってくれるというのがよい。
素晴らしいコストパフォーマンスだ。ローテク万歳。