room​/000 のバックアップソース(No.18) :: OSASK計画

• 差分^[1] を表示
• 現在との差分^[2] を表示
• room/000^[3] へ行く。

* 特別会議室
-詳しくは[[room]]参照
-(by [[K]], 2004.06.03)

*** 圧縮しないのは非常識か？
-過去ログリスト
--[[room/000a]] 2004-05-29 (土) 12:50:09　-　2004-05-30 (日) 01:55:06
--[[room/000b]] 2004-05-30 (日) 02:04:13　-　2004-05-30 (日) 13:39:33
--[[room/000c]] 2004-05-30 (日) 13:47:11　-　2004-05-30 (日) 17:13:27
--[[room/000d]] 2004-05-30 (日) 17:15:24　-　2004-05-31 (月) 12:00:47
--[[room/000e]] 2004-05-31 (月) 13:31:21　-　2004-05-31 (月) 23:00:21
--[[room/000f]] 2004-05-31 (月) 23:07:48　-　2004-06-01 (火) 12:48:41
--[[room/000g]] 2004-06-01 (火) 12:58:57　-　2004-06-02 (水) 01:37:30
--[[room/000h]] 2004-06-02 (水) 01:47:32　-　2004-06-02 (水) 04:02:39
--[[room/000i]] 2004-06-02 (水) 16:02:18　-　2004-06-03 (木) 05:34:10
--[[room/000j]] 2004-06-04 (金) 15:18:39　-　2004-06-10 (木) 02:10:57
-関連リンク
--[[tmp/圧縮について]]
--[[hideyosi]]
----

-すみません。改めてこちらに書きます。せんえつながら意見とか少し思った事です。・極々小さなファイルは逆に大きくなる。既にエントロピーの高いデータ(jpeg等)に圧縮を行うのは無駄⇒無圧縮形式もあるべき。・ファイルサイズだけでなくクラスタギャップも重要視すると完璧(FAT等も考慮)⇒小さいファイルはアーカイブも行う・大きなファイルの途中を開く時先頭セクタから順次見る必要が出る⇒大きなデータは複数チャンクに分けファイル先頭に索引つける・キャッシュファイルも圧縮？・ランダムアクセスは辛くないかな？・DMA転送のみで終わる無圧縮に比べ複数バスやCPUを使うので優しくない？⇔CPU、メモリとHDD容量のトレードオフ -- ''Chihaya'' SIZE(10){2004-06-22 (火) 21:12:30}
-たくさんの論点がありますが、まずは簡単なものだけを。圧縮してもろくに小さくならないものについては、僕も圧縮するべきではないと思います（というか小さくならない時点で、既に圧縮ではなくなって、ただのエンコードになっている）。ファイルサイズではなくて消費クラスタの観点をということについては、OSASKのファイルシステムでカバーする予定（複数の小さいファイルを1つのクラスタにまとめる）ですので、圧縮の是非の問題からとりあえず切り離します。大きいファイルを開くときに前からアクセスしなければいけないという点については、それは他の圧縮形式に言えることであって、ランダムアクセス対策を施しているtek1～tek3には無縁です（内部がマルチブロック化されており、先頭にブロック先頭位置を高速に割り出すための階層構造のインデックスまでついています）。このおかげでランダムアクセス性能も問題ないでしょう。残りの論点はあとで。 -- [[K]] SIZE(10){2004-06-22 (火) 22:10:16}
-クラスタギャップに関してはファイルシステムでの対応は知ってますし圧縮の是非とは多少離れてるのも分かってます。ですがFAT等にも適用出来れば鬼に金棒かなと。そしてOSASKの遅延書き込み機構を考えると実際のライトバック頻度はかなり軽減されると思うので管理領域変更やセクタ移動、フラグメンテーション等のペナルティも少ない気がするのでカーネルレベルでのアーカイブ機構も検討してないのならご一考と思った次第です。本来ならデータ圧縮はHDDのコントローラでやるのが常識。わたしも圧縮するのは至極当然だと思いますよ。 -- ''Chihaya'' SIZE(10){2004-06-23 (水) 16:36:26}
-lzopはソースコード公開してますよ。 http://www.lzop.org/download/lzop-1.01.tar.gz -- ''laira'' SIZE(10){2004-06-25 (金) 21:51:57}
-画像形式は別に圧縮率が一番の売りでは無いと思います。例えばPNGにはαチャンネルやγ補正といった特徴がありますし、プログレッシブにも対応しなきゃいけないし、アニメーションへの応用(MNG)も当初から考えられていたので展開が早くないといけないし。 -- ''laira'' SIZE(10){2004-06-27 (日) 21:59:16}
-おお、気がつけばたくさんの書き込みが。lzopのソースは既にダウンロードしています。ざっと見た範囲では、tek2を超えるような技術はなさそうでしたので、とりあえずそのままほったらかしています。 -- [[K]] SIZE(10){2004-06-27 (日) 22:20:00}
-画像形式についてですが、僕の考えはこうなのです。画像専用形式だとするからには、画像特有の性質を利用して圧縮形式を決めることができ、それが展開速度や圧縮率で有利になることにつなげられると思うのですが、実際はPIを除けばそのような効果は期待できないようなのです。結局pngも内部に汎用圧縮形式を採用しただけで、イマイチの感が否めません。・・・で、画像圧縮形式がそういうものであるならば、無圧縮形式にtekを適用したほうが圧縮率がよくなったり展開速度が上がったりするかもしれないわけです。・・・もう一つの論点であるアルファチャンネルやガンマ補正などはもちろん重要なことですが、それはここで話題になっている圧縮とは特に関係なく、むしろ無圧縮でそのような情報をもっている形式を最初に考えてそれを適当な汎用形式で圧縮すればいいだけのことです。僕が言っているのは、PNGの全てがダメだということではなく、PNGの圧縮周りがダメだということだけです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:38:13}
-Chihayaさんへのレス：まず前に残していた問題の、展開時にCPUに多少の負荷がかかるという点ですが、それはそのとおりでしょう。それがよろしくない場合も当然ありますが、一般的に期待されるケースとしてはとりあえず公開するようなものについては圧縮しておくという基本方針で問題なかろうと思います。実際の使用時に無圧縮にしておくかどうかはユーザの自由ということで。 -- [[K]] SIZE(10){2004-06-27 (日) 22:44:11}
-で、順序を入れ替えて「本来なら圧縮はHDDのコントローラでやるべき」という点についてです。僕は、これは条件付で賛成です。どういう条件かというと、圧縮・展開を伴わない読み書きもサポートされるなら、ということです。・・・ああでも、やっぱりHDDのコントローラじゃなくて、チップセットのオマケ機能とかのほうがありがたいですねえ。これならHDD以外のデバイスにも使えるわけですし。・・・もしChihayaさんの想像している「HDDのコントローラによる圧縮展開」が、OSから感知されないような内部で勝手にごにょごにょ形式であるなら、僕は賛成ではありません。それは結局ファイルシステムが圧縮展開をサポートする状況をハードウェアレベルでやったようなものであり、同じ欠点を持つからです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:50:57}
-クラスタギャップの問題については、僕はこう考えます。まず、Chihayaさんも結局根本的な解決はファイルシステムを改善することであって、アーカイブ形式によるフォローは次善の策でしかない、という点で納得していただいていると僕が思い込んでいるので、そこが違ったら指摘してください。・・・で、OSASKやKHBIOS的な発想では、たとえばFATファイルシステム内のディスクイメージファイルをパーティションの一つとして解釈するので（註：FAT以外のファイルシステムであってももちろんかまわない）、FATの中の一部にOSASKのファイルシステムをいれてしまうことはできます。つまり、新規にアーカイブ形式を考えるまでもなく、ディスクイメージがそのままアーカイブ形式なのです。これであれこれとフォーマットを乱発しないで済みます。OSASKではないOSではこのディスクイメージファイルをOSASKの規定するフォーマットで解釈してやれば、それでChihayaさんの目的は達せられるのではないでしょうか？ -- [[K]] SIZE(10){2004-06-27 (日) 22:58:11}
-ベイサイドさんのいう、「（tek3が）ロジックサイズがtek0の2倍になったことを考えるとあまりメリットは見出せない。」というコメントについて。これはつまり展開ルーチンが短いことが重要という考え方だと思いますが、その論で行くと、むしろstk1あたりがベイサイドさんのベストなんじゃないでしょうか。ソースが半分になるのに、圧縮ファイルは2割しかサイズが増えていませんから。・・・僕はそもそも展開ルーチンサイズにそれほどこだわるべきではないと思いますけどね（「展開ルーチンサイズ＋圧縮ファイルサイズ」の合計が小さくなりさえすれば、問題なし。むしろ展開速度のほうが重要だと思っています）。 -- [[K]] SIZE(10){2004-06-29 (火) 11:42:52}
-Kタンが追求しているバイナリーの小ささに関していうとメリットが見出せないということです。多少サイズが大きくなっても展開速度も速いんだし、問題なしという考え方からいけばメリットは十分にあります。あと、stk3のデコードサンプルコードがほしいっす。 -- ''bayside'' SIZE(10){2004-06-30 (水) 08:03:19}
-割といい成績だったbim2bin4iについてですが、bim2bin.exe in:test.bmp out:test.bin -osacmp -tek2 BS:0 clv:5 MD:0 として圧縮したBMPを tstdstk2.exe test.bin output.bmp で解凍したらデコード画像が壊れてます。バグがありませんか？ -- ''bayside'' SIZE(10){2004-06-30 (水) 08:08:20}
-bim2bin.exe in:test.bmp out:test.bin -osacmp -tek2 BS:0 MD:0 だったらうまくいきました。clv:5 はつけてはいけないようです。 -- ''bayside'' SIZE(10){2004-06-30 (水) 08:12:50}
-僕は展開ルーチンのサイズを追求していません。かつては追求していましたが。詳しくは[[［OSASK 6985］>OSASK:6985]]を参照してください。 -- [[K]] SIZE(10){2004-06-30 (水) 11:11:08}
-bim2bin4iは既に過去の形式なのでバグが残っていたとしても直しません。でもbim2bin4kのtek2もたまに挙動不審です。昨日気がつきました。これは直します。ちなみにbim2bin4iのtek2の後継はtek4です。今のtek3はbim2bin4iでいうところのtek1相当です。bim2bin4iのtek1と今のtek3を比べて、これから出てくるtek4にわくわくするのが現時点でのbim2bin4iの使い方でしょう。 -- [[K]] SIZE(10){2004-06-30 (水) 11:13:46}

#comment

• room/000 のバックアップ一覧^[6]
• room/000 のバックアップソース(No. All)
  • 1: 2004-06-03 (木) 12:45:08^[7]
  • 2: 2004-06-04 (金) 15:43:08^[8]
  • 3: 2004-06-08 (火) 00:39:06^[9]
  • 4: 2004-06-08 (火) 14:36:32^[10]
  • 5: 2004-06-08 (火) 14:36:32^[11]
  • 6: 2004-06-10 (木) 02:45:04^[12]
  • 7: 2004-06-10 (木) 02:45:04^[13]
  • 8: 2004-06-10 (木) 16:34:53^[14]
  • 9: 2004-06-10 (木) 16:34:53^[15]
  • 10: 2004-06-16 (水) 22:15:29^[16]
  • 11: 2004-06-22 (火) 22:10:16^[17]
  • 12: 2004-06-23 (水) 16:36:26^[18]
  • 13: 2004-06-25 (金) 21:51:57^[19]
  • 14: 2004-06-27 (日) 22:58:11^[20]
  • 15: 2004-06-29 (火) 13:39:25^[21]
  • 16: 2004-06-30 (水) 08:12:50^[22]
  • 17: 2004-06-30 (水) 11:13:46^[23]
  • 18: 2004-06-30 (水) 11:13:46
  • 19: 2004-07-02 (金) 03:38:04^[24]
  • 20: 2004-07-02 (金) 14:32:04^[25]
  • 21: 2009-11-17 (火) 12:07:17^[26]
  • 現: 2024-01-08 (月) 12:59:01^[27] k-tan^[28]