マイクロソフトのテクニカルノートを読んでいたら、以下のような記述を発見。
「各マクロの実装では、_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と1009では時間が6倍ほど変化している。同様に16368と16369では3倍ほど変化している。
_mallocaの速度が1008バイト付近で変化しているのは、サイズが_ALLOCA_S_THRESHOLD
なかなかの速度差である。他の条件も含めて表にまとめたのがこちら。黄色くハッチングしているのは、その前後で値が大きく変化している箇所。例えば、_mallocaについてデータサイズ1008と1009では時間が6倍ほど変化している。同様に16368と16369では3倍ほど変化している。
_mallocaの速度が1008バイト付近で変化しているのは、サイズが_ALLOCA_S_THRESHOLDを超えたからだろう。一方で16kBでの変化はよくわからない。16384、すなわち2^14が絡んでいるようには見えるが、なぜだろう？L1データキャッシュサイズ:32kBと絡んでいたりするんだろうか？アルゴリズム上、2^n単位でメモリを確保していて、16384を超えるとL1データキャッシュ全部が必要となってしまい、他のデータのキャッシュと取り合いになってL2データキャッシュに溢れちゃうとか。ちょっとおもしろいデータだった。
なおテストコードは概略こんなかんじ。
実際に使ったのは以下GitHubにて公開。