3: 2008-12-09 (火) 18:01:33  |
4: 2008-12-09 (火) 18:01:33 |
| | -またrjcに相当するフィルタは、LZMA(7z)やUPXでも当然のように利用されていて、rjcを使わないtek5とこれらを比較すると場合によっては圧縮率で逆転します。それじゃあtek5の実力が誤解されかねません。それは僕としては不本意です。もちろんrjcはtek5以外のtek圧縮とも併用できますし、相性もいいです。 | | -またrjcに相当するフィルタは、LZMA(7z)やUPXでも当然のように利用されていて、rjcを使わないtek5とこれらを比較すると場合によっては圧縮率で逆転します。それじゃあtek5の実力が誤解されかねません。それは僕としては不本意です。もちろんrjcはtek5以外のtek圧縮とも併用できますし、相性もいいです。 |
| | -rjcを使わずにtek5した場合と、rjcしてからtek5した場合のサイズの差は、たいてい1割前後です。この差はかなり大きいです。tek5の改良だけで（たいした速度低下もなく）1割も圧縮率を改善するというのはほぼ不可能といっていいレベルだと思います。 | | -rjcを使わずにtek5した場合と、rjcしてからtek5した場合のサイズの差は、たいてい1割前後です。この差はかなり大きいです。tek5の改良だけで（たいした速度低下もなく）1割も圧縮率を改善するというのはほぼ不可能といっていいレベルだと思います。 |
| - | -rjcは極めて処理時間が短く、コードもとても小さい簡単なフィルタです。rjcによってサイズが増えたり減ったりすることはありません。処理内容を簡単に説明するとIA-32のコードは相対ジャンプ命令（near-callも該当）が中心で、同じオフセットへのジャンプであってもそれぞれ違う機械語になっています。つまり同じ場所へのジャンプ命令であるにもかかわらず、それは何度出てきても初出の命令列になり、スライド辞書圧縮がほとんどききません。こういうコードはIA-32の一般的なプログラムでは頻出するので、これをrjcエンコードフィルタによってスライド辞書法が適用しやすい形式に変換してから圧縮してやろうというわけです。また展開時には通常のtek展開の後にrjcのデコードフィルタをかけることで、展開処理を完了します。 | + | -rjcは極めて処理時間が短く、コードもとても小さい簡単なフィルタです。rjcによってサイズが増えたり減ったりすることはありません。処理内容を簡単に説明するとIA-32の分岐処理のコードは相対ジャンプ命令（near-callも該当）が中心で、同じオフセットへのジャンプであってもそれぞれ違う機械語になっています。つまり同じ場所へのジャンプ命令であるにもかかわらず、それは何度出てきても初出の命令列になり、スライド辞書圧縮がほとんどききません。こういうコードはIA-32の一般的なプログラムでは頻出するので、これをrjcエンコードフィルタによってスライド辞書法が適用しやすい形式に変換してから圧縮してやろうというわけです。また展開時には通常のtek展開の後にrjcのデコードフィルタをかけることで、展開処理を完了します。 |
| | *** (2) | | *** (2) |
| | -rjcは以下のような簡単な関数で、エンコード・デコードできます。この関数が返す値は、rjcが変換した箇所の個数です。以下はabcdw006で採用されているrjcです。 | | -rjcは以下のような簡単な関数で、エンコード・デコードできます。この関数が返す値は、rjcが変換した箇所の個数です。以下はabcdw006で採用されているrjcです。 |
