Steamsで遊べる無料ゲー「Upload Labs」でシステムレベル24になって次レベルまで数週間かかる見込みとなり、色んな最適化もやりきった気分になった。なので最後に攻略記事を書いてみる。ただし、プレイ開始～中盤については多数の方が攻略記事を執筆済みなので、ここでは中盤～終盤の攻略記事を書くことにする。
注：本記事はVer. 1.1.6のときのものである。
■Steams:
■Upload Labsとは：
続きを読む
今更だけど、2025年のさつきまつり情報。
新しい環境でC++RESTを使うことになったので、C++RESTおよびそのために必要なVCPkgの導入方法をメモ。
C++REST (cpprest)をスタティック構成のMFCと一緒に使う - ドナドナされるプログラマのメモを参照しながら以下を実行。
cpprestsdk:x64-windows-static
今使っているLenovo ThinkPad T14 Gen1 AMDを購入してから4.5年が経過し、当初予定していた買い替え期日を過ぎたので買い替えた。買ったのはLenovo ThinkPad T14 Gen5 AMD、つまり同一シリーズの後継品。ThinkPadはメンテナンスマニュアルが充実しているので、自分みたいにノートPCを時々分解する人には助かるのよね。
購入したのはRAM 8GB, SSD 256GBのWindows11 Professional品(型式: 21MCCTO1WW)。RAMやSSDの容量が心もとなく見えるけど、Lenovo外で大容量のものを購入して交換・増設したほうが圧倒的に安いので最小容量のものを選択した。
今回ミスったのは、スマートカードリーダーの有無。Gen1ではスマートカードリーダーオプションを付けなくてもSDカードを読めたんだけど、Gen5ではスマートカードリーダーオプションを付けないとSDカード読み取り不可能。何度見返しても商品説明ページにそんな事書いてなくて、商品到着後に悲しんだ。。。
買い替え前後でのPCスペックを比較すると、こんな感じ。右が今回購入したPC。
そして、RAMは空いているスロットにSO-DIMM DDR5 5600 16GB(crucial CT16G56C46S5; ￥5680)を追加し、SSDは今までのノートPCにつけてた1TB品と交換した。
まずはそれぞれのPCで回復ディスクを作成して、SSD交換後のWindows新規インストールに備える。そして交換は、メンテナンスマニュアルにかかれているとおりに
・Windowsにて高速起動の無効化
・UEFIにて内蔵バッテリの切り離し
をやってからカバーを開けて、バッテリの接続線を外してから実施。
あとは元通りカバーを閉めて、Windowsのクリーンインストールを開始。これが終わったらベンチマークをしよう。
マイクロソフトのテクニカルノートを読んでいたら、以下のような記述を発見。
「各マクロの実装では、_alloca() 関数を使用して、ヒープではなくスタックからメモリを割り当てます。 スタックからメモリを割り当てると、メモリをヒープに割り当てるよりもはるかに高速であり、関数が終了したときにメモリが自動的に解放されます。 」
具体的にはどのくらい速度が違うんだろう？ということで試しに測ることにした。比較には、malloc()やnew, _alloca()に加え_malloca()を用いた。_malloca()は割り当てようとするメモリ量によってはヒープから確保する(malloc()等と同じ動作をする)らしい。以下、_alloca()および_malloca()のドキュメントへのリンク。
_alloca()で確保したメモリは関数から抜ける際に自動開放されるらしいので、メモリを確保するだけの関数を用意し、それを複数回呼び出して所要時間を比べた。CPUクロックのブーストなどの影響を最低限とするため、malloc->new->_alloca->_malloca->malloc->new...と測定対象を順番に切り替える実装とした。ただし、1呼び出しごとに切り替えると時間計測関連の処理時間が無視できない気がしたので、測定対象はloop回ずつ実行してから切り替えるように実装し、測定対象切り替えをtrialセット繰り返すようにした。コードのイメージは文末に記載しているので、イメージの把握はそちらからどうぞ。
こうしてできたソフトがこちら。
これによる計測結果の例がこちら。
なかなかの速度差である。他の条件も含めて表にまとめたのがこちら。黄色くハッチングしているのは、その前後で値が大きく変化している箇所。例えば、_mallocaについてデータサイズ1008と1009では時間が6倍ほど変化している。同様に16368と16369では3倍ほど変化している。
_mallocaの速度が1008バイト付近で変化しているのは、サイズが_ALLOCA_S_THRESHOLDを超えたからだろう。一方で16kBでの変化はよくわからない。16384、すなわち2^14が絡んでいるようには見えるが、なぜだろう？L1データキャッシュサイズ:32kBと絡んでいたりするんだろうか？アルゴリズム上、2^n単位でメモリを確保していて、16384を超えるとL1データキャッシュ全部が必要となってしまい、他のデータのキャッシュと取り合いになってL2データキャッシュに溢れちゃうとか。ちょっとおもしろいデータだった。
なおテストコードは概略こんなかんじ。
