2022年まとめ

もう何時間もなく2022年も終わる。
うちの部隊にとって、2022年は2019年と同様な激変の年だった。

まず、引退または死亡したマシンの話題から。
長年稼働を続けた録画サーバの(旧)ユリアがついに引退した。CPUはCore 2 Quad 6600、就航は2007年夏、15年近く24時間365日ほぼ停止なしという、以前には全く想像もできないような稼働実績だった。
さすがにここ何年かは録画サーバの世代交代を重大な課題と考えていて、このマシンは2020東京の後に引退という想定だった。しかし新型コロナウイルスの影響で東京2020は1年延期。とすると、その次の冬季北京五輪まで半年である。引退をさらに延ばした。2008年夏北京五輪当時のエース格マシンが、14年後の冬北京五輪まで戦い抜き、役割を終えた。
また、Core i7 2600Kのマシン(MB)が天に召された。以前、うちの部隊にはSandy Bridge-E(Core i7 3930K)と無印Sandy Bridgeの2台があり、この2台が最速だった期間は実に8年近くある。-Eのほうはしばらく前に亡くなっている。名機Sandy Bridgeも2台ともお亡くなりとなって、現役のマシンはすべて2019年以降の世代のものになった。
このようなtwitterが話題になったくらいだから、Sandy Bridge世代はそろそろハードウェアそのものの寿命を迎えつつあるのだろう。
https://t.co/whRXcGkdhC

2022年は、そもそもIntel/AMD両方のCPU世代交代、Nvidia/AMD両方のGPU世代交代があることがロードマップで明らかにされていて、大幅な更新を予定していた年ではある。しかしながら、極端な品不足とマイニングバブルによるGPU価格の暴騰のために、そもそも2020～21年にすべき戦力強化が遅れに遅れていた。
まずGW期間中のセールなどを利用して、ようやくRTX3000番台のボードを戦線投入。それまでは、新型コロナウイルスとの戦いで酷使され力尽きつつあるRTX2000番台のボードを別にすれば、どれもPascal世代のGPUどまりだった。それに合わせてCPUもRyzen5000番台に。この時、LinuxによるFolding@Home（以降F@Hと表記）の検証機扱いだったマシン(MB)のCPUとGPUを強化してF@H本番機に昇格していて、F@H本番機と検証機の役割が入れ替わる形になった。
しかし、11月に入ってさらに次のF@H本番機のパーツを買い集め、一気に環境構築・就航させた。結果的にわずか半年の間に2回本番機が世代交代するという、なんともあわただしい事態になった。
次期F@H本番機をCore iの13世代にするかRyzen 7000番台にするかはかなり迷った。一時はRyzenのほうが無難な選択とも思ったものの、結局Core iを選んだ。この時点ではマザーボードも含めた費用に結構な差があったためである。Ryzen 7000番台はマザーボードの高額さが特に大きな障害となり売れ行きが思わしくなかったようで、後にはセット購入で大幅割引、さらにCPU自体の値下げもあった。
さて、Ryzenのほうが「無難な選択」と書いた理由は、Intel core 12世代以降はPコア(高性能)とEコア(高効率)の混成構成だからである。PコアとEコアへの振り分けを支援するのがIntel thread directorという機能である。Linuxの場合、カーネル5.18以降でIntel thread directorに対応となっている。それより古いカーネルではそもそもインストールできないか、インストールはできても性能が出ないのではないかという不安があった。
結論から言えば何も問題は起きず、Linux Mint 21(カーネルは5.15)で動作している。GPUでのF@Hでは、必要なCPU1コアはPコアが割り当てられ、パフォーマンス上の問題もない。ただし、CPUでの分散計算はフルスペックのコアが多いRyzen上位に分がありそうだ。CPUでの分散計算実行では、Pコアが空いているのにEコアが使われるという、懸念された問題も経験している。

見えにくいところにもとてつもなく大きな強化がある。ついにうちの部隊に2.5GbpsのLANが導入された。
宅内に1GのLANが導入されたのは00年代の前半。2005年頃の記事には、当時の主力のマシンはすでに1Gbpsになっているのにサブマシンが100Mbps止まりで困ったというくだりがある。それから実に20年近く、LANの速度は1Gbpsのままだったのだ。将来の10Gbpsまでの移行を想定し、LANケーブルは基本的にカテゴリー6e/6a以上としたのも、もう遠い昔である。しかし、長い間PC側のLANインタフェースは1Gのままだった。2.5Gとかそれ以上の設備はきわめて高価だった。何より、ハードディスクから（に）転送している限り、ディスクの速度が100MB/s程度だから、1Gbpsでほぼボトルネックにならない。
しかし、ここ何年かで2.5GbpsのLANのハブ・インタフェースは劇的に価格が下がった。現役の全マシンのWindows起動ストレージは、SATA SSDかさらに高速なNVMe SSDとなった。また、気が付いてみれば、現役で稼働している自作PCのうち、MBのLANインタフェースが1G止まりなのはわずか1台のみ（そのPCにも2.5Gのインタフェースボードを追加した）、それ以外はすべてMBに2.5GbpsのLANインタフェースを備えている。ついにLAN強化すべきときがやってきた。

GPU Folding@Home始まってこのかたの大躍進

Nvidia Geforce RTX 4090がついに発売された。30万円前後ととてつもなく高額ながら、絶対パフォーマンス・ワットパフォーマンス両方で前世代を圧倒している。
ここで話題にするのはFolding@Home(以降F@Hと表記)でのパフォーマンスである。F@Hでも前世代を圧倒することが、以下の動画により速報された。
https://youtu.be/mzgfWSEJzk8?t=1875
https://foldingforum.org/viewtopic.php?t=38564
ポイントの伸びやすい課題(p18213)では2600万PPD、これまで最速の3090Tiと比べて3倍近いとんでもないスコアをたたき出している。
しかし実際のところ、筆者は、理論的にはさらなる高みに到達しうるとさえ考えている。この3つが一度にそろう、GPUでのF@Hが始まってこのかたの大躍進だからだ。
・シェーダ数の大幅な増加(約5割増加)
・クロックの大幅上昇(約5割上昇)
・(F@Hに有利になるはずの)アーキテクチャ更新
このスコアですら、4090のポテンシャルを出し切ったものではないかもしれない。懸念されたことだが、下記のどちらか（または両方）がボトルネックとなっている可能性がある。
・増加したシェーダをフルに使いきれるほど大きなたんぱく質の課題が存在しない
・CPUの性能（主にシングル性能）が足りない
これまでの歴史をいくらか振り返るに、アーキテクチャ更新が強かったのはMaxwell(9xx/750Ti/750)とTuring(RTX2000)の世代である。TuringはF@Hにおいてはきわめて強力で、Pascalと比べてシェーダ数は約2割増(2080Tiと1080Tiの比較)、クロックも上がっていないにもかかわらず、PPDは最終的に2倍を大きく超えた。ボーナスポイントを逆算した処理速度でも2倍近くで、アーキテクチャ更新による純増が50%を超える計算になる。歴史的に評価の高い（そしていまだにPascalで十分おじさんを大量生産しているとされる）Pascal世代では、実はクロック上昇が一番効いている。Maxwell世代で1.3～1.4GHzだったところ1.9GHz近辺まで約4割の上昇である。一方でAmpere(RTX3000)はF@Hと相性はあまりよくなかった。2080Ti→3090でPPD1.5倍程度で、ワットパフォーマンスではそれほど差がない。

Windows 11 22H2への更新手順について

以前、動作要件を満たさない環境でWindows11にアップデートする記事を書いた。

この環境で毎月の品質更新は通常に受け取って更新できているが、おそらく年1回の機能更新は受信できないものと思われる。先日Windows11 22H2が公開されたが、それのことである。
機能更新の手段のうち、Windows Updateでは、動作要件を満たす環境だけに配信されることが明らかにされている。また、Windows 11 インストールアシスタントを筆者が動かそうとしたところ、Windows正常性チェックツール云々といったメッセージが表示されたため、正常性チェックツールでのチェックに引っかかって更新はできないと考えられる。

結論としては、Windows 10から11にアップデートしたときと同じ手順で、機能更新を適用できる。
・Windows 11の新バージョンのISOイメージをダウンロード
・ダウンロードしたISOイメージから、動作要件チェックを行わないインストール媒体を作成
・作成したインストール媒体を使い、Windows 11上からアップデート

Windowsの機能更新では、特定のハード・ソフトとの組み合わせで問題が起きることがままあり、そのような問題が検出された場合、Windows Updateでは該当の環境への機能更新の配信が抑止される。しかしインストール媒体を使って手動でアップデートする場合は、そのようなセーフガードはない。この観点でもリスクのあることを承知である。

World Community Grid(WCG)で課題待ち時間を減らして、難病解明にさらに貢献

分散計算プロジェクトの一つ、World Community Grid(本記事ではWCGと略す)において、長期にわたったIBMからの移管もようやく終わって再開するも、課題受信に高確率で失敗する。瞬間的に連続で受信成功するタイミングもあるものの、基本的にランダムに成功・失敗しているようだ。
WCG(というかBOINCで動くプロジェクト)で受信に失敗が続いた場合、リトライの待ち時間が倍々ペースで長くなっていく。初回のリトライは1,2分後だが、10回も連続で失敗したら5時間といった待ち時間になる。さらに、WCGのOpenPandemicの課題は、1課題につき5つくらいのファイルが送られてきて、それが全部そろわないと解析を始められない。要は、ずっと監視していて課題のリロードをしまくらない限り、課題受信にことごとく失敗しPCが遊んでいるだけになる。
以前Folding@Home(F@H)でも似たような状況を経験した。（当時は参加者が増えすぎて課題自体が枯渇していたことが主な原因）

Folding@Homeで課題待ち時間を減らして、難病解明にさらに貢献 - 雑記帳(新居)

F@Hの場合は、Telnet接続のAPIが用意されており、課題の状態もJSON形式で取得可能である。そこで、課題受信待ちの状況を解析して待ち状態に陥っていたら待ち時間のリセット、ということをスクリプトで書けた。
BOINCもコマンドインタフェースはあるものの、スクリプトなどで解析して課題送受信させるのは極めて困難そうで、正面から攻めることは断念した。その代わり、人間の操作の自動化を試みる。
・BOINC managerのウィンドウをアクティブ化
・[ファイル転送]タブをクリック
・Ctrl-Aキーで全ファイルを選択
・[今すぐ再試行]ボタンを押す
今回、筆者はUWSCという自動化ツールを利用した。

UWSCの詳細情報 : Vector ソフトを探す！

上記の操作をUWSCで記録し、記録された(UWSCの)スクリプトから必要な部分だけを抜き出し、上記程度であればごく簡単なものになる。これを1分ごとに自動という設定もできる。

これで、ようやく枕を高くして寝ることができる。

(追記)ただし一つ問題があることが判明した。通常、5分とか10分とか一定時間操作をしないと、ディスプレイの電源を切るように設定している。しかし、この方法ではごく短い間隔でWindowsの操作を繰り返すので、ディスプレイが常に点灯したままになってしまう。使用しないときは電源スイッチから切るようにしたが、毎回ディスプレイの裏側に回り込んで電源のON/OFFをする必要がある。考えてみればこれが本来あるべき使い方だが、なんとも億劫である。

Stable Diffusionの環境を構築してみた

画像生成AIのStable Diffusionが大きな話題になっている。高精度な画像を生成できるAIが無料で一般公開され、しかも出力した画像も基本的に自由に利用できるライセンスとなっている。
筆者もStable Diffusionをローカルで動作させる環境を構築して実行してみた。
（筆者が最初に参考にしたサイトの例題: a dog painted by Katsushika Hokusaiで生成してみた画像）

公式的な手順では、Python実行環境とCUDA Toolsを導入、AI関連のパッケージを順次導入し、Stable Diffusionの環境を構築する。その環境で、コマンドインタフェースでオプションを指定したうえでスクリプトを実行、画像生成するのが、本来のやり方である。しかし、それにはPythonに関する知識なども必要で、不慣れな人には敷居が高い。
そこで、前提パッケージを一括導入できたりGUIもついていたりするものも、有志によっていくつか公開されている。
(9/13追記)下記で紹介されている環境に差し替えた。前に試した環境よりもさらに多機能である。
https://gigazine.net/news/20220909-automatic1111-stable-diffusion-webui-how-to-use/
よりよい環境が出てくるたびに、Python(Anaconda)の仮想環境を削除、さらにPython自体入れ替えになるのでてんやわんや。
(追記ここまで)
筆者は下記で紹介されている手順を利用した。
https://golabo.net/stablediffusion_local_webgui/
これを選択した理由は、GUIによって、画像生成だけでなく画像の拡大・顔の調整という後処理も行えることである。

Stable Diffusionで生成される画像の解像度は、デフォルトで512*512である。これより大きい画像を生成しようとすると、必要なGPUのVRAM量が急増する。筆者の環境はVRAM11GBで、768*576程度が最大のようだ。それより高い解像度を指定するとエラーが発生する。VRAM使用量を最適化する設定もあるが、それでも768*768が限界で、またその設定をするとVRAM使用量削減と引き換えに画像生成の速度が低下する。
そのため必然的に、Stable Diffusionで生成する画像の解像度は低いままで、後処理で拡大となる。そこで、この手順で導入するGUIが便利というわけである。
また、Stable Diffusionは画像生成の学習を主に512*512解像度で行っていて、縦横の比率が1:1から大きく離れると奇妙な画像が生成される可能性が高くなるとのことだ。4:3(3:4)程度までならあまり問題は起きないようだ。

ところで、GPUの需要が急激に縮小し、価格を下げても在庫をさばききれない状況になっているようだ。Stable Diffusionが大流行すれば、NVIDIAにとってはGPUの需要を回復させるワンチャン救いの手になるかも？（無理すぎ）もっとも、Stable Diffusion用途とすれば2060-12GBか3060ばかり売れそうだが。この種の用途はVRAM多いのが正義だ。
以下のURL末尾に参考情報として各GPUでの画像生成の所要時間がある。
https://rentry.org/GUItard
3090Ti（おそらく3090無印も）は飛びぬけて高速だが、promptを変更しながら100枚単位で画像生成とかしない限り、2060(12GB版)～3060でも十分と思われる。1000番台以前は相当遅い。2000番台以降のAI向け機能強化の効果も大きいことがわかる。