room​/000b

特別会議室

• (by K, 2004.06.03)
• 詳しくはroom参照
  • この会議室内のトップページ：room​/000

圧縮しないのは非常識か？

• room​/000aからの続き

• 名無しさんはOSASKという、最小のパワーしか必要としないはずのOSに解凍という余計なパワーが必要なことを嘆いているのでは？実際にも、 -- 名無しさん 2004-05-30 (日) 02:04:13
• tek0で圧縮されたgoを解凍するのに相当な時間がかかってしまっているように思います。測定したわけではありませんが、HDDアクセスよりは遅い気も。 -- ところがこれも名無しさん 2004-05-30 (日) 02:08:51
• いやしかし仮にFDに無圧縮で収まったとして(FDが大容量だったとする)そのロード時間と比べてはどうでしょうか。(tek1では結構速くなってるみたいですが。) -- あえて名無し 2004-05-30 (日) 02:13:27
• ところがこれも名無しさんの意見はまったく正しいのであります。tek0はぽんこつです。あれはもはや駄作なのであります。駄作であることを知っているからこそ、できるだけ早期にtek1に切り替えたいわけです。tek0やL2D3は「圧縮ファイルサイズ*8*2」回ものシフト命令を実行するというとんでもない手抜き仕様でしたので。tek1やtek2ではその愚をちゃんと回避しております。 -- K 2004-05-30 (日) 02:13:50
• まず、私が疑問に思ったのは、解凍速度が重要なんだとする意見です。簡単な計算、FDのファイルの読み込みに10秒掛かるとします。半分に圧縮できたファイルを読み込むのに5秒、そのへっぽこ展開に5秒掛かるとすれば変わりませんが読み込む間に展開を始めれば5秒+αでできるわけです。ここで、展開を1秒で出来るように改良したとします。しかし圧縮率が変わらなければやっぱり5秒のままです。まあその分CPUが楽できるから悪くはないでしょう。で、彼のマシンが幾ら旧式といってもHDD位付いてるわけです。FDの10倍速いとすれば今まで5秒掛かったのが1秒で読めるでしょうね。つまり、今までの解凍速度が気になるというのはFD以外で使ってる人なんじゃないですか？それならば、1秒で読めて展開負荷がなんと0というある意味画期的な汎用圧縮方式が使えるじゃないですか。これがマシンでなくOSの制限で実用的に使えないということで避けようというのはOSASK的とはいえないんじゃないか？というわけです。FD環境での圧縮がOSASK的じゃないとは誰も言ってませんよね？ -- 名無しさん 2004-05-30 (日) 07:03:53
• だとしたら、基本的にFD起動の今、デフォルトが圧縮なのは別に間違っていないと思いますが。 展開速度が気になるなら、ユーザーが展開すればいいというのがK氏の意見では。-- あえて名無し 2004-05-30 (日) 09:45:55
• 書き直すと、
  • 彼のマシンが幾ら旧式といってもHDD位付いてるわけです。
    • ジャンクなどではHDDがついてない方が多いです。ただしノートならCFが使えることも多いですが。
  • 1秒で読めて展開負荷がなんと0というある意味画期的な汎用圧縮方式が使えるじゃないですか。
    • 圧縮していないものを圧縮というのは変では。
  • OSの制限で実用的に使えないということで避けようというのは
    • これはつまりOSASKがディスクイメージ式のデバイス対応しかしていないことを指していると思いました。
      しかしこれもKHBIOSとの連携により解消されるはずだったのでは。
• 結局問題点として挙がっているのは、デバイスのサポートが仮想FDになっている為なのでは。そうすると、何故先にデバイスのサポートをきちんとしないのかということになりますが、それはKHBIOSとの関連もあるので、まずKHBIOSを進めることになり、そのために必要だったのがtek1/tek2なのだと思いますが。開発順序についてはMLで説明がなされています。--あえて名無し
• というかそこに突っ込んだ覚えはないんですけどね。私は、「非常識」というのは単にFDベースの環境の制約に基因するものと考える訳で、メディアの容量や速度の条件がなくてもそう言えるのだろうか？という話で、それを言えるというのはちょっとわからないなという事なんですけどね。どちらもメリットがあればデメリットもあるだろうと。 -- 名無しさん 2004-05-30 (日) 10:43:47
• ええと衝突してしまいましたが、そこと言うのは一つ前の書き込みですね。まずKHBIOSをというのは言うまでもないわけですが、その場合最初のバージョンからtek1/tek2が必須だったかというとそうではないでしょう。まあその辺は好みでしょうが、逆にそれにまで手をつけているということなのでいよいよなのかと期待したわけです。 -- 名無しさん 2004-05-30 (日) 10:52:25
• なんか名無しさんの推論はおかしい気がするなあ。名無しさんの論によれば、とりあえずtek0でさえ読み込みの間に展開をすることで展開時間を0（もしくはごく小さい時間）にできるわけですよね。それなら圧縮しない理由はなおさらなくなると思うのです。・・・いやこの説明じゃ名無しさんには分からないかな。整理して書き直し。 -- K 2004-05-30 (日) 11:06:00
• 展開負荷かサイズかレイテンシーかという話がまずあると思います。展開負荷の軽減を極端に重視したのが無圧縮です。またサイズを極端に重視したのがrkです。そしてレイテンシー最小を狙っているのがtek1/tek2です。レイテンシーというのはそのデータを読み込み始めてから実際にRAM上で利用できるようになるまでの時間です。 -- K 2004-05-30 (日) 11:11:41
• レイテンシーを最小にすることが体感速度に一番響くと思います。無圧縮はCPUの負荷が最小であるというだけで、レイテンシーが最小であるというわけではありません。レイテンシーを下げるには圧縮率を上げたり、展開速度を上げたりする必要があります。しかしそのせいで他方が犠牲になるならバランスをとることも必要です。tek0→tek1においてはバランスをとるまでもなくどちらも同時に達成されています。 -- K 2004-05-30 (日) 11:15:44
• それと名無しさんはHDDの存在をやたらと仮定しますが、僕はできることならHDDは外したいのです。それはがちゃぴんPC構想でも明らかです。しかし仮にHDDがダメだとしてもメモリカードは使うつもりでいるので、どちらにしてもFDよりはアクセスは格段に速いですし、容量も大きいです。ということでこの件はそれほど論に影響があるわけではありません（容量の天井が80GBから256MBくらいに変わる程度です）。・・・OSASKとしては、もちろんHDDがあればそれはそれでよりいっそう便利に使えるけど、HDDがなくても十分に（というかかなり）便利に使えるようになりたいわけです。 -- K 2004-05-30 (日) 11:25:35
• FD→HDDにすれば、5+a秒が1秒になるでしょう。でもtek1があればその1秒が0.6+a秒になるわけで、結局tek1は無駄にはなりません。tek1のサポートが先かHDDの大容量サポートが先かの、どちらを先にやるべきかという問題以外には問題はないでしょう。HDDを買うときに他が同じ条件なら容量の大きいものを買うでしょう、他が同じ条件ならアクセスが速いものを買うでしょう。圧縮はそのどちらもソフトウェアだけで達成してくれる技術です。これを使わないのはやっぱり非常識に思えます。それはデバイスがFDであるかどうかとは関係ありません。もちろんデバイスが遅ければ遅いほど、容量が小さければ小さいほど、効果が顕著にはなります。 -- K 2004-05-30 (日) 11:42:58
• 別に話に対立する要素はなにもないわけですが、結局、体感速度に一番響くのは、FDよりもそういう速いメディアを使う事だろうと。そして圧縮はメディア容量に対して相対的にデータが多い時には必要だと思うけと、そうでない場合元々速ければたいした差は理論的にでないわけで、圧縮bmpの問題とか考えると無圧縮がいい事もある、少なくとも非常識とは思えない。しかしそういう現行の圧縮でも間に合うFDよりも速いデバイス上で効果的な圧縮法の開発をしているのだから、実はもう対応版は出来てたりするのかとね。正直、なんかもったいつけている様な感じに思えてしまったのも事実ですね。核に使えるイメージ操作ツールなんかはもう作っちゃったわけだし、あとは載っけるだけじゃないのかなあと。 -- 名無しさん 2004-05-30 (日) 12:51:42
• 後半の開発の順序に関することは、今のところ論じるつもりはありません（それは今話題にしている重要かもしれない指摘がはっきりしてからです）。僕は、名無しさんは僕に見えない何かが見えているのかもしれないと思うから、しつこくきいているわけですが、今の問題は圧縮しないほうがいいケースが一般的な事例として（エミュレータなどの特別なケースではなく）存在するのかということと、展開速度の向上が不要だとするその意見についてだけです。 -- K 2004-05-30 (日) 13:37:23
• 展開速度は、別に速くなって困ることはない、でもそれを「今」やるべきかというとそうは思わない、というだけのことでしょうか？もしそうであれば、これも開発優先順位に関することになるので、とりあえず飛ばしてください。 -- K 2004-05-30 (日) 13:39:33

• room​/000cへ続く