gm300の日記: とりあえず thread bzip2 2
日記 by
gm300
前回の納品用意の時に、客のマシンからデータを吸い上げてDVDに移すのに苦労した。なぜかftpが遅いので、焼き用のマシンにデータを転送するのにえらく時間がかかる。それでbzip2で圧縮ということにしたが、bzip2 -9 だとすごく遅い。
# しかも source 見ると圧縮率はそれほど変わらないとある。
転送が遅いのはどうもどこかで帯域を制限していたためらしい。解決するためには転送dataを切り分けて並行して送ること。あるいは、同じ1つのデータを複数のstreamで送るようなftpを見つけること。後半は無理っぽい。調べてないけど。
bzip2 のspeed upは普通の部分はすでに完了していると思う&今は興味無いので、thread 化。去年の今ごろ試したところでは、4CPUあれば4倍になる。しかもgzip のzlib を使ったところでは圧縮率にはあまり影響がでない。
RFC で gzip のformatを調べて source code で bz2 の format を調べる。gz の方は拡張の可能性があるが、bz2 のほうはほとんどない。header は BZhn で n は圧縮の程度、'1' - '9' だ。圧縮の程度とは、内部アルゴリズム、ループの回数ではなくbuffersize / 100K だ。block の大きさは 50,000 byte でblock の頭に 1AY&SY という文字が埋め込まれる。たぶん、作者の名前か何かじゃないか。最後のblockは、何か別の標識が書かれることもある。
全体のheader というものはないし、将来の拡張を考えた field というものもない。
# しかも source 見ると圧縮率はそれほど変わらないとある。
転送が遅いのはどうもどこかで帯域を制限していたためらしい。解決するためには転送dataを切り分けて並行して送ること。あるいは、同じ1つのデータを複数のstreamで送るようなftpを見つけること。後半は無理っぽい。調べてないけど。
bzip2 のspeed upは普通の部分はすでに完了していると思う&今は興味無いので、thread 化。去年の今ごろ試したところでは、4CPUあれば4倍になる。しかもgzip のzlib を使ったところでは圧縮率にはあまり影響がでない。
RFC で gzip のformatを調べて source code で bz2 の format を調べる。gz の方は拡張の可能性があるが、bz2 のほうはほとんどない。header は BZhn で n は圧縮の程度、'1' - '9' だ。圧縮の程度とは、内部アルゴリズム、ループの回数ではなくbuffersize / 100K だ。block の大きさは 50,000 byte でblock の頭に 1AY&SY という文字が埋め込まれる。たぶん、作者の名前か何かじゃないか。最後のblockは、何か別の標識が書かれることもある。
全体のheader というものはないし、将来の拡張を考えた field というものもない。
つまり (スコア:1)
# なんとなくそういう感想をもったので聞いてみるテスト
/.configure;oddmake;oddmake install
Re:つまり (スコア:1)
そうです。でも普通に実用の範囲ではそれほどさがない気もします。どちらでも、user 定義の新しいblockを入れたり、オイラがやろうとしている thread 対応は簡単にはできそうにないです。でも普通にはそんなことはどうでもいいような感じがします。
bzip2 のドキュメントには以下のようにあります。
Nevertheless, this is not a painless decision. Development work since the release of bzip2-0.1 in August 1997 has shown complexities in the file format which slow down decompression and, in retrospect, are unnecessary.
しかしながら、ドキュメントの他の部分には以下のようにあります。これがオイラの見ている部分のことを指しているかどうかはわかりません。たぶん違うでしょう。
It would be fair to say that the bzip2 format was frozen before I properly and fully understood the performance consequences of doing so.