No Such Blog or Diary

«Prev || 1 | 2 | 3 |...| 992 | 993 | 994 |...| 1247 | 1248 | 1249 || Next»

なるほど

OpenMPのプログラムが遅いのは全スレッドで大量にメモリのアロケーションを行うせいかもしれない.一斉にmapを大きくしだすからなぁ.MPIならメモリ空間が分かれているからアロケーションが速いのかも.とりあえずプロファイルとってみるか.

設けるならば,博打はすべきかせざるべきか

博打しなければ何も儲からないから博打したほうが儲かる.何かおかしいだろうか?

MPIよりOpenMPのが遅い

次の輪講用にMapReduceの例であるword countをMapReduceを使わないでMPIとOpenMPで実装しているのだが….なぜかOpenMPの実装がMPIでの実装に比べてかなり遅い.所詮同じループし貸していないのに.

どうやら中間データをマージするローカルのループ部分で遅くなっているらしいけど,アセンブラ見ても同じようなコードなので何が遅いのやら.

一考

写真とって下さいと一眼レフを渡されたのだが,視度調整が+側に振られていたようでファインダーのぞいてもピントの合致が分からない.とりあえずAFのを信じて適当に撮ったらピントあってたので良かったけど….人に撮影を頼むなら画面見ながらピントあわせできるコンパクトデジカメの方が無難な気がする.

それにしてもUSから応答ないなぁ.

istringstream + binary_iarchive ではまってみる

MPIで可変サイズのデータを通信するために boost::serialization を使おうとして,受信部に下のようなコードを書いた.繰り返しサイズ不定なデータを受信するので,バッファはvector<char>にしてサイズを楽に変えられるようにしている.そして,受信したデータの復元のためにバッファをistringstreamに包んでbinary_iarchiveに投げている.細かいことを気にしないと正しく動くように見える.コンパイルも通るし.

std::vector<char> buf;
for (int stage = 1; stage < procs; stage <<= 1) {
  // snip
  unsigned int s = 0;
  MPI_Recv(&s, 1, MPI_INT, target, TAG1, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
  if(s > buf.size()) buf.resize(s);
  MPI_Recv(&(*buf.begin()), s, MPI_BYTE, target, TAG2, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
  std::istringstream  is(&(*buf.begin()), std::ios_base::in | std::ios_base::binary);
  boost::archive::binary_iarchive bai(is);
  // snip
}

が,これを動かすとbinary_iarchiveのコンストラクタでbad_allocを食らって落ちる.なぜ?

しばらく頭も回らず原因が分からなかったけどよく考えるとistringstreamのeofが判定できないんじゃないかと気づく.そのせいでbinary_iarchiveがめちゃくちゃな量を読みに行くかなんかしてメモリ不足で落ちているのではないかと.

ということで,下のように書き換えたら動いた.でもstring作る分だけ無駄だよなぁ.どうすりゃいいんだろう?

  std::string str(&(*buf.begin()), s);
  std::istringstream  is(str, std::ios_base::in | std::ios_base::binary);
  boost::archive::binary_iarchive bai(is);

夜の銀杏

今から寝ると午前のセミナーに起きられない気がするのでライトアップされている銀杏を撮ってきた.

TOKINA AT-X 116 PRO DX 11-16mm F2.8

真夜中のくそ寒い時にも関わらずカメラと三脚持った人間が他にも数人.お疲れ様です.

«Prev || 1 | 2 | 3 |...| 992 | 993 | 994 |...| 1247 | 1248 | 1249 || Next»
Search
Feeds

Page Top