Chapter Seventy one

第71話

今回はプログラムを改良して使い物になる動作速度にできるか検討する予定だった。

しかし、プログラムのチューンナップを試みていたら、仕様の確認が不十分だったことが分かった。ブロックサイズは32kBが最大だと思い込んでいたのが大きな間違いで、最大で32kBに限定されているのは非圧縮ブロックだけだった。前回のプログラムはブロック毎に32kBのデータを読み込んでおく方式だったので、ブロックサイズが大きい場合は破綻してしまうことになる。プログラムの構造に関るところなので困ってしまったが、これも人生とあきらめて作り直すことにした。

バグに気がつくまではプログラムの動作速度に関して検討していたのだが、読み込んだU8配列データをビット配列に変換するところで時間がかかっているようだったので、typecastで一気に変換ができないか、とか、U32で読み込んで変換回数を1/4に減らせないか、などと考えていた。色々試してみたのだが、U8データの最下位ビットがビット配列の0番目になるようにするには、前回のプログラムのようにU8を'Number To Boolean Array'でビット配列に変換する方法しか無いようだとあきらめた。できるのは、動作確認用に置いていた文字列表示器などの削除やエラー判定機能ぐらいに限られてしまいそうだ。

さて、あらかじめ決められたバイト数を読み込んでおくことができないので、getBits.viの中にファイルからの読み込み関数を組み込んで、データが必要になる都度読み込むことにした。

ファイルからの読み込み関数はバッファーを持っているようなので、機械的なファイルアクセスが頻繁に発生するわけでは無い。結果的にプログラムで抱え込むデータ量が減り、実行時間の面でもメリットがあったようだ。特にファイルサイズが大きくなったときに前回のプログラムではファイルサイズ当りの時間が大きくなっていったのが、今回のプログラムではファイルサイズに比例するようになった。

ファイルからの読み込みを都度行うようにしたので、入出力のクラスターの要素は、offset、bit array、posに変更した。offsetはファイルのオフセット値、posはbit arrayの未使用要素の先頭の指標を示す値だ。bit arrayの肥大化を防ぐために、ファイルから読み込む時点で仕様済みの要素は捨てること。入出力クラスターには多くのVIが関っているため、クラスターの要素の変更はかなり大変だった。

下にあるダイアグラムは前回のプログラムだが、大部分の場面では使用しないリセット機能を持っていた。必要なところでリセットするプログラムを別に組むことにしてここからは削除することにした。必要なビット数がわかっているにも関らず、１バイトづつビットに変換して不足している場合は再度ループを回すようにしているのも無駄な気がしたので変更した。

動作速度を確認するためのテストファイルとして、139kBのテキスト形式の地震データをもとにテストファイルとして24kB,　38KB,　54kB, 139kBのデータファイルを作り、ZIP圧縮を行った。このファイルを伸長するのにかかった時間を測定してグラフに書いてみた。

但し、前回のプログラムFileWindow3は前回ホームページに載せた状態では、139kBのデータは正常に終了しなかったので、ロックのデータ読み込み上限を8000Hから10000Hに拡大して実行した。

その結果、今回のFileWindow5（ピンクの実線）はデータサイズとともにほぼ直線的に実行時間が増加していく。FileWindow3（紺色の実線）ではデータサイズが大きくなるにつれて非直線的に実行時間が長くかかっていた。100KB付近でのデータがあれば非直線的な増加がグラフ上で分かりやすくなりそうだが、面倒なのでこのままにしておこう。

　

　

　

さて、どのサブVIが速度向上に寄与したのだろうか？　下のグラフは139kBのファイルを伸長したときにプロファイルで解析した結果だ。

HuffmanDecoder.viとcommonLenDist_Decoder.viが飛躍的に速くなっている。

HuffmanDecoder.viはハフマンコードの最小ビット長に応じて始めに読み込むビット数を指定していたのだが、どんな場合でも1ビットづつ読み込むことにして判断、分岐を削除した。さらに、ハフマンコードの最長のビット数を超えても該当するものが見つからなかった場合のエラー処理を削除した。そんなに効果があるとは思えない部分なのだが、なぜこんなに効果的だったのかは今のところ不明なのだ。

commonLenDist_Decoder.viはクラスターの変更以外は手を付けていないので、クラスターのデータが軽くなったためかもしれない。

getBits.viはファイルからの読み込みを取り込んだため若干遅くなったが、このぐらいで済んでいるのは御の字だろう。

　

今回はFileWindowができたと思ったときに大きなミスに気がついてさらに大きく変更したため、これを書きながらも何かしっくりしない感じが残っている。次回は圧縮部分を取り込んでみよう。

See you!

Nigel Yamaguchi

戻る



		今回はプログラムを改良して使い物になる動作速度にできるか検討する予定だった。しかし、プログラムのチューンナップを試みていたら、仕様の確認が不十分だったことが分かった。ブロックサイズは32kBが最大だと思い込んでいたのが大きな間違いで、最大で32kBに限定されているのは非圧縮ブロックだけだった。前回のプログラムはブロック毎に32kBのデータを読み込んでおく方式だったので、ブロックサイズが大きい場合は破綻してしまうことになる。プログラムの構造に関るところなので困ってしまったが、これも人生とあきらめて作り直すことにした。バグに気がつくまではプログラムの動作速度に関して検討していたのだが、読み込んだU8配列データをビット配列に変換するところで時間がかかっているようだったので、typecastで一気に変換ができないか、とか、U32で読み込んで変換回数を1/4に減らせないか、などと考えていた。色々試してみたのだが、U8データの最下位ビットがビット配列の0番目になるようにするには、前回のプログラムのようにU8を'Number To Boolean Array'でビット配列に変換する方法しか無いようだとあきらめた。できるのは、動作確認用に置いていた文字列表示器などの削除やエラー判定機能ぐらいに限られてしまいそうだ。さて、あらかじめ決められたバイト数を読み込んでおくことができないので、getBits.viの中にファイルからの読み込み関数を組み込んで、データが必要になる都度読み込むことにした。

		ファイルからの読み込み関数はバッファーを持っているようなので、機械的なファイルアクセスが頻繁に発生するわけでは無い。結果的にプログラムで抱え込むデータ量が減り、実行時間の面でもメリットがあったようだ。特にファイルサイズが大きくなったときに前回のプログラムではファイルサイズ当りの時間が大きくなっていったのが、今回のプログラムではファイルサイズに比例するようになった。ファイルからの読み込みを都度行うようにしたので、入出力のクラスターの要素は、offset、bit array、posに変更した。offsetはファイルのオフセット値、posはbit arrayの未使用要素の先頭の指標を示す値だ。bit arrayの肥大化を防ぐために、ファイルから読み込む時点で仕様済みの要素は捨てること。入出力クラスターには多くのVIが関っているため、クラスターの要素の変更はかなり大変だった。下にあるダイアグラムは前回のプログラムだが、大部分の場面では使用しないリセット機能を持っていた。必要なところでリセットするプログラムを別に組むことにしてここからは削除することにした。必要なビット数がわかっているにも関らず、１バイトづつビットに変換して不足している場合は再度ループを回すようにしているのも無駄な気がしたので変更した。

		動作速度を確認するためのテストファイルとして、139kBのテキスト形式の地震データをもとにテストファイルとして24kB,　38KB,　54kB, 139kBのデータファイルを作り、ZIP圧縮を行った。このファイルを伸長するのにかかった時間を測定してグラフに書いてみた。但し、前回のプログラムFileWindow3は前回ホームページに載せた状態では、139kBのデータは正常に終了しなかったので、ロックのデータ読み込み上限を8000Hから10000Hに拡大して実行した。その結果、今回のFileWindow5（ピンクの実線）はデータサイズとともにほぼ直線的に実行時間が増加していく。FileWindow3（紺色の実線）ではデータサイズが大きくなるにつれて非直線的に実行時間が長くかかっていた。100KB付近でのデータがあれば非直線的な増加がグラフ上で分かりやすくなりそうだが、面倒なのでこのままにしておこう。　　　さて、どのサブVIが速度向上に寄与したのだろうか？　下のグラフは139kBのファイルを伸長したときにプロファイルで解析した結果だ。

		HuffmanDecoder.viとcommonLenDist_Decoder.viが飛躍的に速くなっている。 HuffmanDecoder.viはハフマンコードの最小ビット長に応じて始めに読み込むビット数を指定していたのだが、どんな場合でも1ビットづつ読み込むことにして判断、分岐を削除した。さらに、ハフマンコードの最長のビット数を超えても該当するものが見つからなかった場合のエラー処理を削除した。そんなに効果があるとは思えない部分なのだが、なぜこんなに効果的だったのかは今のところ不明なのだ。 commonLenDist_Decoder.viはクラスターの変更以外は手を付けていないので、クラスターのデータが軽くなったためかもしれない。 getBits.viはファイルからの読み込みを取り込んだため若干遅くなったが、このぐらいで済んでいるのは御の字だろう。　今回はFileWindowができたと思ったときに大きなミスに気がついてさらに大きく変更したため、これを書きながらも何かしっくりしない感じが残っている。次回は圧縮部分を取り込んでみよう。