5: 2004-06-08 (火) 14:36:32  |
6: 2004-06-10 (木) 02:45:04 |
| | -さっそくVix 2.21でOSASKの壁紙をPI形式で保存させてみました。5625バイトでした。この例でもPNGには勝っているようです。さすがですね。ではtekはどうなのかというと、まずtek0とtek1では歯が立ちませんが、BMP+tek2ならMD:32kでも5618なので微妙に勝っております。これはなかなか悪くない気がしました。もっとも他のBMPファイルで試したらtek2惨敗の可能性はあります。 -- [[K]] SIZE(10){2004-06-08 (火) 13:30:00} | | -さっそくVix 2.21でOSASKの壁紙をPI形式で保存させてみました。5625バイトでした。この例でもPNGには勝っているようです。さすがですね。ではtekはどうなのかというと、まずtek0とtek1では歯が立ちませんが、BMP+tek2ならMD:32kでも5618なので微妙に勝っております。これはなかなか悪くない気がしました。もっとも他のBMPファイルで試したらtek2惨敗の可能性はあります。 -- [[K]] SIZE(10){2004-06-08 (火) 13:30:00} |
| | -2chのOSASKスレッドをみたらLZOという形式が紹介されていたので探してみました（できれば特徴と圧縮ツールのURLくらいは書いておいてほしいと思いました）。LZOはlzopというプログラムで圧縮展開でき、猛烈に展開が速いことが特徴のようです。多分tek1よりも速いです。ただ、圧縮率は結構犠牲になっています。LZOは圧縮もモードによってはかなり速くできるので、インターネットでのパケット圧縮などで活躍しているそうです。で、肝心の圧縮結果ですが、-9の最高圧縮率で次のようになりました。括弧内はtek1に対するパーセントです（対rkではないので注意）。bim2binc：16015(110.6%)、kdun00b：52148(123.9%)、osaskgo：1177820（107.3%）、osask.bmp：8618(145.2%)。展開が速いのがとてもありがたいことは間違いないですが、tek1はわずかなコードの追加で結構健闘しているtek2をサポートできるということもありますし、圧縮である以上やっぱりそれなりの圧縮率もほしい気がしますので（あまり圧縮率がよくないと結局は使ってもらえない可能性もある）、とりあえずLZOは見送りです。しかしファイルシステムで圧縮するときや、OSがRAM内部のデータを圧縮してスワップを減らすなどの、展開速度だけではなく圧縮速度もそれなりに重要なときは、LZOは大変ふさわしいアルゴリズムのような気がします。 -- [[K]] SIZE(10){2004-06-08 (火) 14:36:32} | | -2chのOSASKスレッドをみたらLZOという形式が紹介されていたので探してみました（できれば特徴と圧縮ツールのURLくらいは書いておいてほしいと思いました）。LZOはlzopというプログラムで圧縮展開でき、猛烈に展開が速いことが特徴のようです。多分tek1よりも速いです。ただ、圧縮率は結構犠牲になっています。LZOは圧縮もモードによってはかなり速くできるので、インターネットでのパケット圧縮などで活躍しているそうです。で、肝心の圧縮結果ですが、-9の最高圧縮率で次のようになりました。括弧内はtek1に対するパーセントです（対rkではないので注意）。bim2binc：16015(110.6%)、kdun00b：52148(123.9%)、osaskgo：1177820（107.3%）、osask.bmp：8618(145.2%)。展開が速いのがとてもありがたいことは間違いないですが、tek1はわずかなコードの追加で結構健闘しているtek2をサポートできるということもありますし、圧縮である以上やっぱりそれなりの圧縮率もほしい気がしますので（あまり圧縮率がよくないと結局は使ってもらえない可能性もある）、とりあえずLZOは見送りです。しかしファイルシステムで圧縮するときや、OSがRAM内部のデータを圧縮してスワップを減らすなどの、展開速度だけではなく圧縮速度もそれなりに重要なときは、LZOは大変ふさわしいアルゴリズムのような気がします。 -- [[K]] SIZE(10){2004-06-08 (火) 14:36:32} |
| | + | -7zはLGPLのオープンソース「LZMA: Improved and optimized version of LZ77 algorithm」…[[7zFormat:http://www.7-zip.org/7z.html]]より…[[lzmaのsdk:http://www.7-zip.org/sdk.html]](できれば多少は調べて欲しいと思いましたｗ、サポートするのがコミュニティの役目の一つだから、浮いた時間を開発時間に使ってもらえればいいんだけれど)短いので、解説だけでも読んでくだされば。私もソースを読む時間等は取れませんが。 -- ''くーみん'' SIZE(10){2004-06-09 (水) 20:58:41} |
| | + | -実はこれでも20分くらい「LZMA」などでせっせと検索したのですが（7zとは独立に存在しているアルゴリズムだと頭から思い込んでいたせいもあって）、見つけられませんでした。非常に助かりました。ありがとうございます。で、LZMAはとてもいいです。ついさっきまで、かなり本気でtek2を完全に破棄して、LZMAをtek2の中身にしてしまおうと考えていたくらいです。 -- [[K]] SIZE(10){2004-06-09 (水) 23:22:49} |
| | + | -それをかろうじて思いとどまらせたのは、展開速度の問題でした。LZMAはあのtek0よりもさらに遅いのです（わずかな差ではありますが）。今、いろいろと最適化の余地を検討していますが、どうにかなるものなのかどうにもならないのか、まずはそれを突き止めたいです。 -- [[K]] SIZE(10){2004-06-09 (水) 23:26:02} |
| | + | --参考：EPIA-VE5000でのosaskgoの展開速度（C版 --- ASKA版は多分1.5～2倍は速い） |
| | + | |meth.|deco.time|size|vs rk|score|score2| |
| | + | |tek0|1.39[sec]|1149662|126.4|RIGHT:36.7|RIGHT:175.7| |
| | + | |tek1|0.75[sec]|1097475|120.6|RIGHT:15.5|RIGHT:90.5| |
| | + | |tek2|0.82[sec]|1092517|120.1|RIGHT:16.5|RIGHT:98.5| |
| | + | |tek3|0.22[sec]|1318722|144.9|RIGHT:9.9|RIGHT:31.9| |
| | + | |LZMA|1.42[sec]|RIGHT:953821|104.8|RIGHT:6.8|RIGHT:148.8| |
| | + | |LZO|0.20[sec]|1177820|129.5|RIGHT:5.9|RIGHT:25.9| |
| | + | |bzip2|2.52[sec]|1047411|115.1|RIGHT:38.1|RIGHT:290.1| |
| | + | --bzip2とtek3（暫定）とLZOはおまけです。たぶんLZOは既にアセンブラ化されていると思います（そうでないとこの圧縮率でこの速さは出ない）。bzip2はアセンブラ化されているかどうかは僕には想像がつきませんが、ブロックソート法では圧縮率の代償として展開速度低下があるという傾向はつかめると思います。 |
| | + | --score = time x (vz_rk - 100) |
| | + | ---なんとなく計算してみたくなったので（笑）。小さければ小さいほど圧縮率と展開速度のバランスに優れていることを示していると思う。 |
| | + | ---LZOが僕の予想通りアセンブラ化されているとすれば、公平化のためには1.5倍くらいして8.9くらいのつもりで見るといいと思う。 |
| | + | --score2 = time x vz_rk |
| | + | ---scoreの指標がどれくらい実感に近いのかを確認するために計算した参考値。この値はrkのスコアに影響されないが、あんなにがんばっているLZMAがtek2に劣ることになってしまう。これはいくらなんでも圧縮率の評価が弱すぎるわけだ。 |
| | + | -ちなみにLZMAは展開時の消費メモリと展開ルーチンの複雑さの観点では、さしたる問題はなさそうです。うーん、やっぱり併用なのかなあ、tek1/tek2/tek3/LZMAの。これだけ全部入れたら、さすがに3KBくらいはOSが大きくなりそうだけど、でもここまで強烈だと、LZMAをあきらめるのは惜しい・・・。 -- [[K]] SIZE(10){2004-06-09 (水) 23:52:23} |
| | + | -tek3の暫定版とLZOも表に入れておきました。tek3の圧縮率がひどいように見えるかもしれませんが、例によって僕は展開速度と安定重視で符号化の方針を決めているので、これはしょうがないです。LZOはOSASK.BMPやkdun00bが苦手で（というかテキストと実行バイナリに特化している感じ？）、汎用としては少々弱いところがあります。まあその辺のことはbim2bin4iのリリース時に説明しますので、今はこれくらいにします。 -- [[K]] SIZE(10){2004-06-10 (木) 01:58:51} |
| | + | -LZMAはアルゴリズム的にはこれ以上速くはできないっぽいです。もちろんASKA化によってそれなりには速くできそうですが、（デコードされた）1bitを得るためには整数乗算を1回やらないといけないので、C→ASKAにしてもtek系と同じ比率で速くなるという見込みはあまりありません。なんかもったいないなあ。・・・ということで将来的には併用確定。LZMAは時間が取れたらOSASKやKHBIOSでのサポートを実装するということにして、とりあえず今はtek系の実装を急ぐことにします。 -- [[K]] SIZE(10){2004-06-10 (木) 02:10:57} |
| | | | |
| | #comment | | #comment |
