# HG changeset patch # User Masataka Kohagura # Date 1390399158 -32400 # Node ID 62463090ce750511e05058ea5448f09a081f72a0 # Parent f45b36a7d0e6ebba72d449623a7875b3f50be350 add memo diff -r f45b36a7d0e6 -r 62463090ce75 2014/January/memo/14th.txt --- a/2014/January/memo/14th.txt Wed Jan 22 22:38:25 2014 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,73 +0,0 @@ -・Ceriumの並列処理向けIOの研究 - -・研究内容 -・マルチコアCPUを活かすためには並列度を向上させていくのがCerium -・ファイル読み込み等のIO部分を並列に実装する部分を作成していく -・IOと並列処理の関係 -・この場合のIOもファイル -・1GBのファイルがあったらそれを10個、100個に分割して走らせる -・ファイル分割による並列 -・そういったものを自明に走らせる(1つめ) -・読み込みながら処理して、読み込み終わりで処理を終えたい -・読み込みと計算が同時に進む(2つめ) -・読み込み自体を並列する -・それらを実現するライブラリをつくりたい - -・正規表現はおまけ -・grepとかwcとか - -・したこと -・wcの部分、分割readが出来るようになった -・IOスレッドいまから動かす -・1つのファイルにたいしてmmapつかって -・メモリにtextデータ格納していた -・いまはreadを使って -・1度に読み込むのではなく、 -・あるサイズ単位で読み込ませていく？ - -・読み込みと実際の計算をやる -・分割したファイル自体を並行実行する -・今回は１つしか書いてなかった -・読み込みながらちゃんと並列に計算できているか -・それを調べるには？ -・表示した瞬間に測定できなくなる -・IOの並列度はそういうもの -・時間とlogだけで判断しなければならない - -・mmapと速度的にどうなのか？ -・測定しないと駄目 - -・readする単位をでかくすれば早くなるはず -・最初に計算をするのが遅くなる -・最初に全部読み込むことになったらバランスが悪くなる -・最初だけ小さくしてあとから大きくするという工夫とか - -・ファイルはcacheに入ってしまう -・cacheの効果がどうなるか -・low read(ファイルを読み込むだけ)これで早くなっているはず -・read rootを回すだけと変わらなかったらそれの原因を確かめないといけない - -・readの代わりにmmapするという方法がある -・最初のタスクの時に同時に投入できる - -・mmapよりreadが早い・・・迷信？ -・これがどうなのかを証明していく - -・ファイルサイズをメモリよりも大きくしないといけない -・100GBのデータを作って実験？ -・fireflyだったら16GB以上 -・自機では4GB以上 - -・map reduceでまとめたい -・map reduceに似ていると言われる？ - -・mmmapの解説 -・64bitアーキテクチャ -・read map よりも mmap がよいと言われている -・遅い時期があったため、遅いと言われている -・コピーしなくてすむからmmapはwriteの方が早いと言われている - -・評価(ベンチマーク) -・mmap、map reduceの解説をかく - -・卒論は、理解することをアピールするためにかく diff -r f45b36a7d0e6 -r 62463090ce75 2014/January/memo/15th.txt --- a/2014/January/memo/15th.txt Wed Jan 22 22:38:25 2014 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,7 +0,0 @@ -2014/01/22 (Wed) - - [今後の実験方針] - ・とりあえず memory 以上のファイルを生成してそれを噛ませばいちいち再起動しなくても測れるよね?? - ・Linux でも試してみよう (blade上でも試してみよう) hyper threading 込みの 24 Coreまで。 - ・パラメータ調整してどう実行結果に影響するのかも計測 - ・分割 read → 分割 mmap で書き換えて早くなるかどうか。 diff -r f45b36a7d0e6 -r 62463090ce75 2014/January/memo/21st.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/2014/January/memo/21st.txt Wed Jan 22 22:59:18 2014 +0900 @@ -0,0 +1,73 @@ +・Ceriumの並列処理向けIOの研究 + +・研究内容 +・マルチコアCPUを活かすためには並列度を向上させていくのがCerium +・ファイル読み込み等のIO部分を並列に実装する部分を作成していく +・IOと並列処理の関係 +・この場合のIOもファイル +・1GBのファイルがあったらそれを10個、100個に分割して走らせる +・ファイル分割による並列 +・そういったものを自明に走らせる(1つめ) +・読み込みながら処理して、読み込み終わりで処理を終えたい +・読み込みと計算が同時に進む(2つめ) +・読み込み自体を並列する +・それらを実現するライブラリをつくりたい + +・正規表現はおまけ +・grepとかwcとか + +・したこと +・wcの部分、分割readが出来るようになった +・IOスレッドいまから動かす +・1つのファイルにたいしてmmapつかって +・メモリにtextデータ格納していた +・いまはreadを使って +・1度に読み込むのではなく、 +・あるサイズ単位で読み込ませていく？ + +・読み込みと実際の計算をやる +・分割したファイル自体を並行実行する +・今回は１つしか書いてなかった +・読み込みながらちゃんと並列に計算できているか +・それを調べるには？ +・表示した瞬間に測定できなくなる +・IOの並列度はそういうもの +・時間とlogだけで判断しなければならない + +・mmapと速度的にどうなのか？ +・測定しないと駄目 + +・readする単位をでかくすれば早くなるはず +・最初に計算をするのが遅くなる +・最初に全部読み込むことになったらバランスが悪くなる +・最初だけ小さくしてあとから大きくするという工夫とか + +・ファイルはcacheに入ってしまう +・cacheの効果がどうなるか +・low read(ファイルを読み込むだけ)これで早くなっているはず +・read rootを回すだけと変わらなかったらそれの原因を確かめないといけない + +・readの代わりにmmapするという方法がある +・最初のタスクの時に同時に投入できる + +・mmapよりreadが早い・・・迷信？ +・これがどうなのかを証明していく + +・ファイルサイズをメモリよりも大きくしないといけない +・100GBのデータを作って実験？ +・fireflyだったら16GB以上 +・自機では4GB以上 + +・map reduceでまとめたい +・map reduceに似ていると言われる？ + +・mmmapの解説 +・64bitアーキテクチャ +・read map よりも mmap がよいと言われている +・遅い時期があったため、遅いと言われている +・コピーしなくてすむからmmapはwriteの方が早いと言われている + +・評価(ベンチマーク) +・mmap、map reduceの解説をかく + +・卒論は、理解することをアピールするためにかく diff -r f45b36a7d0e6 -r 62463090ce75 2014/January/memo/22nd.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/2014/January/memo/22nd.txt Wed Jan 22 22:59:18 2014 +0900 @@ -0,0 +1,7 @@ +2014/01/22 (Wed) + + [今後の実験方針] + ・とりあえず memory 以上のファイルを生成してそれを噛ませばいちいち再起動しなくても測れるよね?? + ・Linux でも試してみよう (blade上でも試してみよう) hyper threading 込みの 24 Coreまで。 + ・パラメータ調整してどう実行結果に影響するのかも計測 + ・分割 read → 分割 mmap で書き換えて早くなるかどうか。