J

2004 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 12 |
2008 | 01 | 02 | 04 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 12 |
2013 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2014 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2015 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2016 | 01 | 02 | 04 | 05 | 06 | 07 | 09 | 11 | 12 |
2017 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 |

ホーム

日記内の"morihyphen.hp.infoseek.co.jp"へのリンクは切れてます。必要な場合はお手数ですが int.main.jp へ書き換えをお願いします。

TODO: ファイル名確認を忘れないこと > 自分

twitter

 | 

2011-07-19

またレイテンシ測るためだけに…の続編 21:26

まあ…A8-3650が手元にあるので…とりあえず…測った…(のは10日ほど前)

計測コードはこれと一緒

ちなみに、あの後もうちょっと調べて、どうやら、バックグラウンドで何か処理してCPU時間を使っておくと、レイテンシが縮むらしい、ということがわかったので、バックグラウンドのMeadowで(while t)してる状態で測った。

  • empty latency: 85usecぐらい
  • read 1byte: 200usecぐらい

という感じであった。

ちなみに同じ条件でE350測ると、

  • empty latency: 150usec
  • read 1byte: 500usec

ぐらいだった。


A8-3650で、

#include <windows.h>
#include <process.h>
#include <stdio.h>

HANDLE s2c;
HANDLE c2s;

void __cdecl
client(void *p)
{
    while (1) {
        WaitForSingleObject(s2c, INFINITE);
        ResetEvent(s2c);
        SetEvent(c2s);
    }
}

void __cdecl
server(void *p)
{
    while (1) {
        unsigned int b, e;
        getchar();

        b = __rdtsc();
        SetEvent(s2c);
        WaitForSingleObject(c2s, INFINITE);
        e = __rdtsc();
        ResetEvent(c2s);

        printf("%d\n", e-b);
    }
}

volatile int s2cM;
volatile int c2sM;

void __cdecl
clientM(void *p)
{
    while (1) {
        while (s2cM == 0)
            ;
        s2cM = 0;
        c2sM = 1;
    }
}

void __cdecl
serverM(void *p)
{
    while (1) {
        unsigned int b, e;
        getchar();

        b = __rdtsc();
        s2cM = 1;
        while (c2sM == 0)
            ;
        e = __rdtsc();
        c2sM = 0;

        printf("%d\n", e-b);
    }
}


int
main(int argc, char **argv)
{
    s2c = CreateEvent(NULL, TRUE, FALSE, NULL);
    c2s = CreateEvent(NULL, TRUE, FALSE, NULL);

    if (argc < 2) {
        _beginthread(client, 0, 0);
        _beginthread(server, 0, 0);
    } else {
        _beginthread(clientM, 0, 0);
        _beginthread(serverM, 0, 0);
    }

    Sleep(10000);
}

とかやって、Win32スレッドの通信レイテンシ測ると、何かプロセッサが動いてるときは4万clk、全プロセッサが寝ているときは、6万clkぐらい。で、2.6GHzだから…15usecぐらいか。

まあ、つまり、Win32スレッド間通信の4〜5倍くらいの時間でGPUと通信できていることになる。と、考えると、まあ、ギリギリ真面目に使えるか、と、いう感じ?1msecぐらいの処理なら、適用できそうという雰囲気。


あとメモリがのレイテンシがまだ200usecとかで大きいなぁ。

OpenCLは、メモリ共有してるGPUのために、ホストのメモリを直接GPUに渡すというのがサポートされていて、clCreateBuffer するときに、CL_MEM_USE_HOST_PTRとかCL_ALLOC_HOST_PTRとか渡せばよい。


が、今のAMD Fusion(llanoとzacateの両方)は、CPUとGPUが自由に同じ領域に読み書きできるようにはなっていない、具体的には多分CPUとGPUでコヒーレンシとってなくて、GPUからキャッシュ領域に高速で読み書きすることができないようになっている。

表にまとめると、

メモリの種類GPUCPU
1.普通のページ(CL_USE_HOST_PTR:ロックされてなくてスワップするかも)何もできない普通に使える
2.ロックされてキャッシュ可能なページ(CL_ALLOC_HOST_PTR)読み書きゆっくり普通に使える
3.WriteCombinedでキャッシュ不可普通に使える読みゆっくり/シーケンシャルな書きは普通
4.GPU領域(普通にclCreateBuffer)普通に使える使えない

となっている。


で、3番目の、「WCでッキャッシュ不可」、をOpenCLで表現できないので、AMDOpenCLは拡張が入っていて、CL_MEM_USE_PERSISTENT_MEM_AMDというフラグがある。


CL_MEM_USE_PERSISTENT_MEM_AMDを付けて、メモリ確保すると、「ページスワップとか移動しなくてキャッシュ不可でWC」なメモリが割り当てられる。このメモリは、GGPGPU的には以下のような特性を持つ

  • GPUで読み書きするのはフルスピードでアクセスできる(キャッシュ気にしないでよいので)
  • CPUで読むのはすっごい遅くなる。(キャッシュ不可になると、読み込み単位がワード単位になって、バースト転送効かないので)
  • CPUでシーケンシャルに書き込むのは、そこそこのスピードで実現できる(書き込みはWCが効くので、64byteのバースト転送になる)AMDのサンプルに入っている、BufferBandwidth で -I とか -O の値を変えると、このへんの変化が見られる。

これをうまく使えば、CPU<->GPU間のデータ転送を最小限にすることができる。


  1. ファイルから大量のデータ読み
  2. ちょっと加工してGPUへ送る
  3. GPUで処理
  4. 結果をホストへ返す
  5. 結果をホストで表示

と、いう処理をしたとして、このとき、

2. で加工するときに結果をWCメモリに置く、んで、GPUから返すデータはなるべく小さくなるようにする。

と、無駄な転送が無くなる。

(あとはSSE4.1の_mm_stream_load_si128みたいなのが欲しいところである)


まあ、めんどいすぎるけど…はやくキャッシュ領域に自由に読み書きできるようになってほしいところである。

あ。よく考えたらCUDAのWCメモリと全く同じ物だった。

ゆっくりというと 21:26

JR大井町駅の登りエスカレータの案内ボイスが若干ゆっくりボイスっぽくてJRはSoftalk使ってるんだろうか疑惑。

WikiVS 21:26

宗教戦争Wikiを作るのが俺の人生の目標みたいな感じだったが既にあった。

http://www.wikivs.com/


初見だと何でもあるように見えたが、ちょっと調べるとそうでもないな…

とりあえず思い付いた範囲だと

あたりが無い。

21:26

大家さんに「再来月はどうなるかわからん」的なことを言われたがそろそろ限界か…

トラックバック - http://d.hatena.ne.jp/w_o/20110719

2011-07-09

暑い 15:31

室温が33.5℃とかで今シーズン記録更新しておる。

32℃超えると扇風機が熱風発射機になって辛くなってくるな、とか、33℃超えるとあんまりなんかわからなくなってくるな…と思ってたが、去年も32℃こえるときついとか書いててちゃんと一致している。

http://d.hatena.ne.jp/w_o/20100925#1285391801


もう冷房使ってやろうか…

http://www.tepco.co.jp/forecast/index-j.html (本日7/9分)

とか見ると、去年相当日と全く同じカーブを描いていて、しかも供給に余裕があるように見えるので、もう節電ポスターとか作るほうがエネルギーの無駄だからさっさとやぶって捨ててしまえとかいう気分になるな…まあ、ビルとか店が冷房の設定温度上げているのは確実で、それは多少はグラフにあらわれるだろうということを考えると、相当日の設定が間違ってるだけだろうけど。


大体、東電が「今の供給力」しか表示せず、「安定して供給できる最大量」と、「ピーク時供給できる最大量と連続して供給できる時間」を示さないあたりで、なにそれという感じであって、あれって結局「お前らは俺らの言いなりになるしかないんだゼェ…ヘッヘッヘ…」グラフ以上の意味は無いよなぁ…

つまり、あのグラフを見て考えないといけないことは、「節電しよう」ではなく、「我々は何者かによって支配されている!支配からの独立を!戦え!武器を握れ!うおおおぉおッ!俺達はッ自由であり続けなければならなぃッッ!!!1!!」ということである。うぉおおおぉおッ!俺達は、自由であり続けなければならないッッ!!!1!!


まあ、もちろん、今の電気は去年以上にCO2を排出しているはずなので、節電すべきということに変わりはないが、いや、そう考えると、去年までの電気は、ヨウ素セシウムを排出していたと考えるべきではセシウムおいしいです。

トラックバック - http://d.hatena.ne.jp/w_o/20110709
 |