The_Middleware

A middleware to support on-demand massive-scientific-data-visualization

HTTP interface

header type

FirstContact (再初期化も含む)

header = {
    'type':'init',
    'offset':BlockOffset,
    'L3Size' : 1000,
    'L4Size': 1000,
    'Policy' :'LRU',
    'FileName' : 'test',
}

例えば、L3Sizeが0の時にはL3cacheがoffってことを意味します。

ここにリプレイスメントポリシーを入れるって感じにしたいと思います。キャッシュサイズも決められるようにしたいと思います。ーー＞ここは直そう

BlockRequest これは、ユーザではなく、プリフェッチャがサーバにリクエストするための関数です。

header = {
    'type':'BlockReq',
    'tol':BlockId[0],
    'timestep':BlockId[1],
    'x': BlockId[2],
    'y': BlockId[3],
    'z': BlockId[4]
}

noCompress なんだこれ？このシステムに必要か？ああ、実験のためのね。圧縮せずに全部持ってくる感じです！！作ったな。

header = {
    'type':'noCompress',
    'timestep':BlockId[1],
    'x': BlockId[2],
    'y': BlockId[3],
    'z': BlockId[4]
}

userPoint これは、L1とL2でヒットしたとき、データをサーバにリクエストすることはないけど、ユーザの位置を知らせる必要があるってことで、その関数です。

header = {
    'type':'userPoint',
    'timestep':BlockId[1],
    'x': BlockId[2],
    'y': BlockId[3],
    'z': BlockId[4]
}

getStats ユーザのリクエストシーケンスが0になった後にサーバ側でのキャッシュヒットがどうだったかをリクエストするためのやつです。

header = {
    'type':'getStats'
}

BlockReqUsr これは、ユーザがリクエストしたってことです。

header = { 'type':'BlockReqUsr', 'tol':BlockId[0], 'timestep':BlockId[1], 'x': BlockId[2], 'y': BlockId[3], 'z': BlockId[4] }

body

compressed array

対戦相手と提案手法の亜種一覧

HDF5とTileDBどっちも
multipleGPU/singleGPU
Pure TileDB
FP16
traditional approach (つまり、ftpとかgridftpで必要なデータを交換してから読み出すやつね。これも評価出来たらめっちゃいいなーって思っています！)

scpによるmonaka → muffin2のデータ転送は、 22.0 ~ 23.0 MB/sでした。この数値を使ってやってもいいと思いますよ！ちなみに、ftpはめっちゃ早くて、ほぼ帯域幅を使い切れるようにできているみたいです。大体6倍くらい早いんだけど、 2268 = 1056Mb/s って感じで、ちゃんと帯域幅を使い切ってくれていますね。これは意外です。

うん、普通にこの数値を使ってやりたいと思います。ちなみに、研究室ネットワークのnetwork latencyは、約0.1msです。で、iperfを使って調べたネットワークの帯域幅は、約960Mb/sでしたね。

評価のためのメモ

./client/eval_dataの中に評価で得たcsvファイル一式と、csvファイルを読み込んでグラフを出力するjupyter notebookのプログラムが入っています。どうぞ、よろしくお願いします。

評価指標

1リクエストに対する遅延。これは、上の対戦相手全部で試せます。FP16とFP8も行けるんで。
n個のリクエストに対する平均遅延。分散やほかの指標も入れる。
psnrも評価に入れた方がいいかもしれない。入れようか

parameters for access patern

独自のパラメータをい定義した。

同じデータを何回踏むか : data_recycle_ratio

1 - num_of_unique_blocks_in_requests/num_of_requests

アクセス密度 : アクセスシーケンスのブロックの中で一番離れているブロック間のチェビチェフ距離 / アクセスシーケンスの長さまあ、これ、なかなかクセのあるパラメータでね。一タイムステップの中で一番離れている点は、対角ブロックで、この距離はたったの4なんだよね。で、タイムステップを考えると、64タイムステップあって、タイムステップは別に加算するから、どんなに離れていても、4 + 64 = 68しか離れられないんだよね。だから、分母をアクセスシーケンスの長さにするのはちょっと刻なのではないかな？とも思っているわけです。つまり、もしかしたら、パラメータを変えた方がいいのかもしれない。が、まだ何がいいかはちょっとわかっていない。

clione上でのsingularity環境起動コマンド（--bindでのマウントを忘れずに）

muffin2上でもこれで問題なく行けた。いい感じだ。

singularity shell --bind /scratch/:/scratch/ --nv  pymgard.sif

cuSZpの実行環境の起動方法 (共有ライブラリへのパスを通すことを忘れないでください。)

~/new_research/The_middleware/container
singularity shell --nv --bind /scratch/:/scratch/ szp7.sif
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
~/new_research/The_middleware/component_bench/cuSZp/
nvcc compress_bench.cpp -lcudart -I/usr/include/hdf5/serial -L/usr/lib/x86_64-linux-gnu/hdf5/serial/ -I /usr/local/include/cuSZp/ -lhdf5 -lcuSZp -lcudart -lcudadevrt -lcudart
./a.out 1 128 128 128 0.001

ここが頼みの綱です。よろしくお願いする。

注意

libcuSZp.soへのリンクパスを通すときに、以下のようにやりがちですが、これだと、ほかのプログラムの実行に必要なライブラリがリンクできなくなります。

NG:export LD_LIBRARY_PATH=$(pwd)
OK:export LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH

デバイスポインターではなく、ホストポインターを使ったバージョンでベンチマークを測定する方法

singularity shell --nv --bind /scratch:/scratch szp7.sif
cd ../third_party/cuSZp/build/
export LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH
cd ~/new_research/The_middleware/component_bench/cuSZp
nvcc compress_bench2.cpp -lcudart -I/usr/include/hdf5/serial -L/usr/lib/x86_64-linux-gnu/hdf5/serial/ -I /usr/local/include/cuSZp/ -lhdf5 -lcuSZp -lcudart -lcudadevrt -lcudart

一応、third_party/cuSZp/buildの中の共有ライブラリが、int -> size_tを変更したソースになります。そこが大事なのかわからないけど。

cuSZp_entry_f32.cuのバグ発見について

マジで、これバグじゃね？

size_t bsize = cmp_tblock_size_f32;
size_t gsize = (nbEle + bsize * cmp_chunk_f32 - 1) / (bsize * cmp_chunk_f32);
size_t cmpOffSize = gsize + 1;
size_t pad_nbEle = gsize * bsize * cmp_chunk_f32;

ここのsize_tがintになっていたんだよね。これ、オーバフローを起こすことあるでしょ。pad_nbEleとかさ。マジである。 cmp_tblock_size_f32 = 32 cmp_chunk_f32 = 8192 nbEle = 100010001000 = 1000000000で、まあ一回入れてみよう bsize = 32 gsize = (100000000 + 328192 - 1) / (328192) cmpOffSize = 32 pad_nbEle = (100000000 + 328192 - 1) / (328192) * 32 * 8192 いや、セーフか？？セーフな気がした。 1024**3はどうなんだ。

cuszpyの実行環境の起動方法 (こっちはなんでかわからんけど、/usr/local/lib/の方の共有ライブラリをリンクしようとするとバグる)

export PYTHONPATH=/usr/local/python/cuSZp/
ではなく、
export PYTHONPATH=/path/to/

変数とほしいデータ

キャッシュ構成
キャッシュのサイズ
ユーザの処理時間
アクセスパターン
許容誤差

はっきり言って、この5つしかない。俺が変えられる変数は。

変数の変化に伴うレイテンシーの変化を裏付けるための情報

キャッシュのヒット率
ユーザがリクエストした時にそれぞれの処理にかかった時間

まあ、簡単に言うと、

latency = latency(キャッシュ構成、キャッシュのサイズ、ユーザの処理時間、アクセスパターン、許容誤差)
cacheHitRatio = latency(キャッシュ構成、キャッシュのサイズ、ユーザの処理時間、アクセスパターン、許容誤差)
各処理にかかった時間 = 各処理にかかる(キャッシュ構成、キャッシュのサイズ、ユーザの処理時間、アクセスパターン、許容誤差)

縦軸は、絶対にレイテンシーにしないといけません。そして、横軸は、5つある変数の内の4つを固定して、残りの1つを変化させてみる、って感じです。

どういうグラフが欲しいか？

ある変数を固定した時の、レイテンシーと、キャッシュのヒット率折れ線になっているグラフ
1を補助するグラフとして、横にキャッシュヒットの内訳を積み上げグラフとしておいておきたい
さらに、この横に、ユーザがリクエストした時の各処理にかかった時間を積み上げグラフとしておいておきたい 1,2,3がワンセットになっている。上にも書いた通り、キャッシュのヒット率とユーザがリクエストした時にそれぞれの処理にかかった時間がレイテンシーを説明するものだからね。

で、変数を一つ一つ固定して、進めていきますよと。

組み合わせ (この時、それぞれのキャッシュサイズ、処理時間、許容誤差、は固定されている)
キャッシュのサイズ (このとき、一つのキャッシュ構成に対して、増やしていったときどうなるか) だから、L1のみで、キャッシュサイズを横軸にとってどんどん大きくしていったとき 2^4通りのグラフができるよね
ユーザの処理時間 (一つのキャッシュ構成に対して、ユーザの処理時間が増えていったときにどうなるか) これも2^4通りのグラフができるよね。
アクセスパターン 4通り
許容誤差

どういう結果になることを想定しているか？

GPU (compressor) について

インスタンスの生成場所

L3_L4prefetcher.py --> プリフェッチャが使う用のコンプレッサー
NetAPI.py --> ユーザリクエストとL2プリフェッチャからのリクエストが使う用のコンプレッサー

GPUのデバイス番号と対応

0 --> A100 40 1 --> A100 80 defaultでは、0が設定されるようになっている。ユーザリクエストがA100 80を使うようにしたい。

ロックについて

NetAPIでユーザがGPUを使うときにロックがかかる。 GPU2だったら、気にしなくていいけど、GPU1だったら、ちゃんと制御してほしい

ネットワークレイテンシー、バンド幅の測定方法

レイテンシーはpingで測定できますね。バンド幅は、iperfを使って測定できます。

人工的にネットワークレイテンシーを発生させる方法について

tcコマンドを使ってカーネル空間で、人工的にレイテンシーを発生させることができます。

クライアントのshark上で測定することにします。必要なのは、network interfaceの名前 shark : eno1 次のコマンドで制御できます。

sudo tc qdisc add dev <network interface> root handle 1:0 netem delay <追加したい遅延 in ms>

つまり、100ms追加したいときは次のようにします。

sudo tc qdisc add dev eno1 root handle 1:0 netem delay 100ms

設定の解除方法も忘れずに

sudo tc qdisc del dev eno1 root

tsharkを使てパケットダンプをする方法。

sudo tshark -i eno1 -Y 'tcp.port==8080'

これで、eno1のポート8080に来るデータの解析ができます。

情報エントロピーの計算方法

内部にベクトルを持っているやつだけど、

これ、別に難しいことをしているわけではないのです。本当に、ただ、取ってくる順番を、時間方向を優先にしただけなのです。マジで。マジでそんなに難しいことじゃない。提案手法としては、すごく簡単に拡張できる。うん、簡単だね。その方向から順番に何個取ってくるかって話だからね。それだけの話。まじで！！

1/20のTODO

MTUとwindowサイズについて、勉強。cubicってアルゴリズムでMTUのサイズを変えていることを確認。
TCPダンプする。どうやってやるんだろうなーーー。これは、証明になるから。で、
ネットワークレイテンシーを大きくした時に、なんで、あんなに遅くなるのか？MTU, Window Sizeで説明ができるように、TCP dumpをする。これ、どうやってやるんだろうなーー。説明はできる。スリーウェイハンドシェイクに totalLatency = round_trip_time (Network) + decompression_time + OverHead round_trip_time = 3way_handshake + storage_read + compress + Network_transfer = 0.2 ( 実際に、リクエストがサーバに届くまで ) + 0.1 + 0.1 + Network_transfer

1/27のTODO

修論を書きまくってください

1/28のTODO

修論を書きまくってください

1/29のTODO

グロゼミの準備をしてください

1/30のTODO

グロゼミの準備をして、グロゼミに出てください。
終わり次第、修論を書きまくってください。

1/31のTODO

修論を書きまくってください。
できれば、この日に印刷しておきたい。
徹夜もいとわない

2/1のTODO

修論を提出してください。
提出し終わったら、すぐにAPDCMに切り替えてください。まず、アブストを適当に書いてすぐ出してください。
アブストを書き終わり次第、

時間があったらのTODO

TODO

overall

apdcmに出す 2/8の朝９時。最悪、本審査が終わった後、頑張ればいけると思います。

client

server

置換とプリフェッチをするメカニズムは実装しました。あとは、計算量が少なくなるように、アルゴリズムとデータ構造を最適化してください。

Done Things

overall

access patern

アクセスパターンについて。同じデータに何回アクセスするかっていう指標は作る。再利用率
アクセスパターンを定義する入力パラメータを考える。これに関しては、雅先生からもらった論文を読むのが一番早いかもしれない。
アクセスパターンはランダムに何個か作って、それを全部出力させておくのがいいと思う。パラメータと一緒に。というのも、パラーメータを入力させてアクセスパターンを生成するのは難しいと思う。逆問題的なね。だから、アクセスパターンをランダムにたくさん生成して、アクセスパターンを定義するパラメータを算出してその中から、目的のものを抽出する方が簡単だと思います。

client

リクエストを連続的に送信
統計的に提案手法有意義であることを示すために、様々な解析パターンをどうにか用意しないといけない。どうすればいいのだろうか？--> 連続リクエストとランダムのミックスを使うしかないと思う。
現状、クライアントのAPIにリクエストするよりも、それをすっ飛ばして直接サーバにリクエストした方が早く終わる、という結果が出ています。つまり、クライアント側でバグが起こっていますと。どこで起こっているのか、解析しないといけません。そのために、pythonのプロファイラを使いたいと思います。ー－＞これ、ちゃんといい結果が出るようになったので気にしなくていいです。

python -m cProfile -o main.prof my_script.py

このように実行することでプロファイルできますと。さらに、line_profileっていうのもあるから、自分で調べてみて。

L2プリフェッチャが動いてなくて、単なるキャッシュになっている問題を解決したい。
最初のプリフェッチがうまくいっていない。データ転送でエラーが生じる。 --> これのせいで、コネクション張りすぎだって怒られてしまうエラーが起こるので早く解決してほしいです。 The above exception was the direct cause of the following exception:
L1プリえっちゃは、L2を見てなかったら、もうあきらめましょう。そういう設定にした方がいいです。
連続リクエストとランダムのミックスが対話的解析のリクエストとして妥当性があるのかどうか？そこを示す論文を探さないといけない。 ---> これについては連続でないと勝ち目がないとわかりました。連続の中でも何個かパターンを作ってやりたいと思います。
初期コンタクトでサーバからデータの範囲を受信。つまり、(t,x,y,z)ね。
リクエストとレスポンスにそれぞれの処理時間をのっけた評価 --> ユーザがリクエストしたやつだけでいい。その平均を出せるようにしておく
L2プリフェッチャがちゃんと働いていない可能性。ユーザ地点がちゃんとL2に伝えられていて、さらにサーバ側にリクエストを送っているか確認。
L1プリフェッチャがちゃんとL2にリクエストを出しているかを確認。
L2プリフェッチャのevictionがおかしい。ちゃんと追い出されているのか？？マジで。

クライアント側で起こっているバグ。

Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/import/gp-home.ciero/aoyagir/new_research/The_Middleware/src/python/client/L1_L2prefetcher.py", line 80, in thread_func
    loop.run_until_complete(self.fetchLoop())
  File "/usr/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
    return future.result()
  File "/import/gp-home.ciero/aoyagir/new_research/The_Middleware/src/python/client/L1_L2prefetcher.py", line 72, in fetchLoop
    self.L2Cache.put(nextBlockId,compressed)
  File "/import/gp-home.ciero/aoyagir/new_research/The_Middleware/src/python/client/L1_L2Cache.py", line 39, in put
    self.usedSizeInMiB += value.nbytes/1024/1024
AttributeError: 'bytes' object has no attribute 'nbytes'
the rest of request:63

72行目っていうのが、これ

    async def fetchLoop(self):
        while not self.stop_thread:
            if (not self.prefetch_q_empty()) and (self.L2Cache.usedSizeInMiB < self.L2Cache.capacityInMiB):

                nextBlockId,d = self.pop_front()
                compressed = self.Netif.send_req_urgent(nextBlockId)
                self.L2Cache.put(nextBlockId,compressed)
                self.enque_neighbor_blocks(nextBlockId,d) # ここ、あってるかもう一度確認してくれ。頼む。
                
            else:
                await asyncio.sleep(0.01)  # Sleep for 1 second, or adjust as needed

で、39行目っていうのがこれ

    def put(self, key, value):     # key = tuple, value = {"data":ndarray,"distance":dist_from_userpoint}
        if (self.capacityInMiB) == 0:
            return
        
        with self.CacheLock:
            if key in self.cache:
                pass
            elif self.usedSizeInMiB >= self.capacityInMiB:
                removedItem = self.cache.popitem(last=False) # returns (key,value).
                self.usedSizeInMiB -= removedItem[1].nbytes/1024/1024
            self.cache[key] = value
            self.usedSizeInMiB += value.nbytes/1024/1024

これの、self.L2Cache.putがうまくいっていない。なんでだ？ユーザがリクエストしたやつはたまっているのになんでだ？ (type)で、valueの値を出してみましょう。
ユーザ用のエンドポイントを使っても同じ結果になってしまった。つまり、サーバ側の問題ではない。ユーザ側のプログラムの問題。

あと、L1とL2がちゃんとUserの位置をInformedされているかを確認してくれ。

まじで、ちゃんと解決しました。完璧です。原因は、サーバから送られてくるものは、単なるバイトなのに、あたかもnumpyであるかのように、 compressed.nbytes、をしてしまっていたこと。numpyには、nbytesっていうメンバーはあるんですけど、単なるバイトにはないので、len(compressed)ってやらないとだめでした。現在、L2プリフェッチャもちゃんと動きまくっています。完璧です。

ユーザの地点がL1とL2にインフォームドされているかを確認。

server

ただのMutexによる共有資源 (ストレージ) へのアクセス制御
slicerにキューを持たせて、L3やユーザはそのキューを介して資源を使えるようにする。しかしこの場合は、ユーザ、L3, L4みんなで同じSlicerインスタンスを共有しないといけない。その時に、上の問題を解決しないといけない。その方法を考えたい。どうやるか？次のキーワードで検索してみよう。「How to controle a situation where Multiple threads want to use a class's methods?」的な感じで。ここをうまくやらないといけないんですわ。逆にここがうまくいけばかち。 --> これなんだけど、なんかもう限界に達している気がする。だから、L4のプリフェッチャの動きをちゃんとしたい。つまり、ユーザの動きに合わせてちゃんとプリフェッチしてほしい。あと、キューをクリアするのにかかる時間はほとんどないからそんなに気にしなくていいよ。 evictionにかかる時間はほぼないから気にしなくていい。まあ、この問題は、結局どんなに頑張っても、マルチスレッドで実行すると、sequentialにやるか、一緒にやって、バンド幅を減らすか、それしかないのでこれ以上の向上は望めないということで。あきらめましょう。ユーザの解析時間をついかすることでバックグラウンド実行ができるようになるのでましにはなるかと思います。

"echo 1 > /proc/sys/vm/drop_caches"

なんですね。しかしね、これ、singularityの中から実行することはできないんです。 singularityないではsudoを実行できないので。だから、違う方法を使うしかないんです。ってことで、file_cache_server をmuffin2の上で動かしておいて、 muffin2のThe_middlewareサーバのreInit()メソッドの中で、file_cache_clientがサーバにクリアリクエストを送って、クリアされる感じにしたいんですね。

寝ている間に、ちゃんと全部動くかの実験をする。tmuxでセッションを作って。よろしくお願いします。
クライアントの方のバグを直してくれ。恐らくL2プリフェッチャが機能していない。ただのキャッシュになっている。解決してくれ。よろしく頼む。

Exception in thread Thread-423 (thread_func):
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/import/gp-home.ciero/aoyagir/new_research/The_Middleware/src/python/client/L1_L2prefetcher.py", line 86, in thread_func
    loop.run_until_complete(self.fetchLoop())
  File "/usr/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
    return future.result()
  File "/import/gp-home.ciero/aoyagir/new_research/The_Middleware/src/python/client/L1_L2prefetcher.py", line 78, in fetchLoop
    self.enque_neighbor_blocks(nextBlockId,0) # ここ、あってるかもう一度確認してくれ。頼む。
  File "/import/gp-home.ciero/aoyagir/new_research/The_Middleware/src/python/client/L1_L2prefetcher.py", line 98, in enque_neighbor_blocks
    x = centerBlock[2]
IndexError: tuple index out of range
送信スレッドでexeptionが発生!
tuple index out of range

このバグが発生するせいで、クライアントの方で、ソケットが開いて、空いたままになって、閉じられない、ってうバグが発生している気がする。これを直した方がいいですね。

メモ？

つまり、まずはちゃんと狙いすましてプリフェッチしよう。キャッシュのヒット率を上げればだいぶ解消されるはずです。まあつまり、無駄なプリフェッチをなくしてくれや。ーーー＞ロックをかけるとさらに遅くなってしまうという現象が起こっている。これね、どうするかね。ーー＞おそらくmutexでロックをかけるのがシステムコールだからさらに遅くなってしまうってことなんだよね。だからね、これは、mutexではなく、自作ロックでいいってことにしよう。 strictLock (0.49418292999267577) のところ、 looseLock (0.48913016319274905) No cache って感じです。ちなみに、なんでコンテキストスイッチでオーバヘッドが大きくなるんだ。

結局、無駄な読み出しをどれだけ削減できるかが大事になってくる。 --> これだね。本当に、どうやって無駄なプリフェッチを減らすかが大事。でも、そこは俺の研究範囲ではないのでお暇する。これは、論文にも書いた方がいい。実際そうだから。もう少し連携を高めよう。マジで。連携な。

キャッシュミスのペナルティーがめちゃめちゃでかい！

今後の展望

wayを追加？どうやって？
onion-cache。exclusive cacheにした方がメモリ効率は良くなるよねって話。まあ、時間もないだろうし、厳しいんじゃない？今後の展望ってことで。
c++で書き直す。やっぱシステムソフトなので、c/c++の方がぽい。通信部分も一回一回コネクションを張るやつではなく、 javidexさんのあの自作プロトコルがいいと思う。
やはりHTTPだとオーバヘッドが大きい。というのも、一回一回コネクションを張らないといけないから。これのせいで、セッションも管理しないといけない。pythonでできるかわからないけど、通信部分も自分で書いた方がいいかもしれない。

hdf5 > tiledbである理由

https://docs.h5py.org/en/stable/mpi.html この辺を読んでください。hdf5はsingle fileで全部管理するのですが、スレッド並列をサポートしていないんですよね。プロセス並列はサポートしているんですけど。だから、3つのスレッドが例えば、aaa,bbb,cccっていうデータを読み出したいときに、それぞれの読み出しがシリアライズされて、こんな感じで、 abcabcabcになるんですよね。だからめっちゃ遅くなるって話です。はあ、って感じですね。低レイヤー勉強して俺が作り直したるわ、って感じです。

The_Middleware

HTTP interface

header type

body

対戦相手と提案手法の亜種一覧

評価のためのメモ

評価指標

parameters for access patern

clione上でのsingularity環境起動コマンド（--bindでのマウントを忘れずに）

cuSZpの実行環境の起動方法 (共有ライブラリへのパスを通すことを忘れないでください。)

注意

デバイスポインターではなく、ホストポインターを使ったバージョンでベンチマークを測定する方法

cuSZp_entry_f32.cuのバグ発見について

cuszpyの実行環境の起動方法 (こっちはなんでかわからんけど、/usr/local/lib/の方の共有ライブラリをリンクしようとするとバグる)

変数とほしいデータ

変数の変化に伴うレイテンシーの変化を裏付けるための情報

どういうグラフが欲しいか？

どういう結果になることを想定しているか？

GPU (compressor) について

インスタンスの生成場所

GPUのデバイス番号と対応

ロックについて

ネットワークレイテンシー、バンド幅の測定方法

人工的にネットワークレイテンシーを発生させる方法について

tsharkを使てパケットダンプをする方法。

情報エントロピーの計算方法

内部にベクトルを持っているやつだけど、

1/20のTODO

1/27のTODO

1/28のTODO

1/29のTODO

1/30のTODO

1/31のTODO

2/1のTODO

時間があったらのTODO

TODO

overall

client

server

Done Things

overall

access patern

client

server

メモ？

今後の展望

hdf5 > tiledbである理由

About

Languages