CeriumにおけるGPUとMultiCore CPUの同時実行
|
Yuhi TOMARI
|
研究目的
当研究室ではCellおよびLinux、
Mac OSX上で動く並列プログラミングフレームワーク、
Ceriumの開発・改良を行っている。
本研究では新たにGPU上での並列実行に対応し、
ヘテロジニアス(異種混合)環境下でのプログラミングをサポートする
GPGPUでは通常のマルチコアCPUとは異なる並列プログラミング
と特別なチューニングが必要となる。
そこでCeriumを用いてその差を吸収し、自動的なチューニングを可能にする。
しかし、GPUのみで並列計算を行った場合、Taskによっては並列度が出ない場合がある。
そこでチューニングの一環として、MultiCoreとGPU上での同時実行を可能にする。
進捗
- s6 Slide整えて遊んでた
- mallocのお勉強
- kernel reading party(小崎さん)
- 動画
- 資料
mallocってなんだっけ……？
void *malloc(size_t size);
- mallocはsizeバイト分のメモリを割り当て、ポインタを返す
- 返ってくるのはvoidのポインタなので、戻り値を型でキャストする必要がある
- 中身は初期化されていない
- 確保した領域はfreeを忘れずに
char *str = (char*)malloc(length); // 使う型でキャストする
古典的malloc
- 使用可能なブロックを繋げたリスト構造、free list (freeされているブロックのlist?)
- listを使ってメモリを管理
- 管理領域(header)分だけ多くallocateして、先頭に管理領域を付加
- first fit
union header {
struct {
union header *ptr; // 空きリストの上なら次のブロック
unsigned size; // このブロックの大きさ
} s;
};
First Fit
リストを頭から見ていって、最初に見つけたものを使用するというすごいシンプルな方法。
First Fit
実は、もう一個先にもっと適切なブロックがあった。こんな場合に対応できない…というか、対応しないのがfirst fit。
あまりよくない……
free
void free(void *ptr);
メモリの開放自体は、使用中のブロックをfree listに追加するだけで良い。
引数で受け取ったポインタ部分を開放したら良い……かに思える。
でもそれだけじゃダメで、開放したい領域と隣接しているブロックが空きブロックなら併合しないといけない。
free
listから最初のポインタと、その次のポインタを取得。prev < p < nextを満たすまで走査していく
free
あった！！
開放後に前後のメモリと併合する必要がある場合があるので、prevとp・pとnextが隣接してるか判定する。
- (prev+prev-> size) != p なので、隣接していない
- (p+p-> size) = next なので、隣接している
ブロックが隣接している場合は併合する。
free
チェックに引っかかったところをマージする。
古典的malloc & freeまとめ
フラグメンテーションが頻発する。
このmallocが主流だった時は「メモリはプログラムの最初に一気に確保するもの」だった
メモリが充分に空いている状態で、
必要なメモリを一気に確保するならフラグメンテーションは起きにくい
今はJava・C++のようなオブジェクト指向言語、
Rubyのようなスクリプト言語等、小さいmallocが頻発する
それをfirst fitでやるのはよくない
mallocの改良
そもそも、一つのfree listで管理することが無理がある
サイズ16用のリスト、サイズ24用のリスト……というようにリストを複数作ってやる
