OSASK-WikiのKの落書きの過去ログ

  • 本家:OSA:K
    • 過去ログにコメントしたい人も、本家のこめんと欄に突っ込んでください。
      • そのうちKによって下のこめんと欄に移動しますので。

UPX vs tek

  • (2005.01.05-2005.01.06)
  • ななしさんにファイルサイズが64KB未満で拡張子を.comにすればとりあえずなんでもUPXで圧縮できると教えてもらったので、その方法でいろいろ実験してみました。
  • 実験対象は3つ用意しました。一つはmake46のnec98ディレクトリにある、vgadrv0.ask。もう一つは、OSASK ver.4.7にバンドルされているtest128.bmpをbim2binで-restoreしたものです(テキストばかりやってもしょうがないと思いましたので)。最後の一つは、同じくOSASK ver.4.7のkaos2c.helをbim2binで-restoreしたものです。
  • 最初に結論を書くと、こんな感じです。
    • .com化する方法では、圧縮アルゴリズムは「NRV2B/10」というものになる。一方、win32の.exeだと、「NRV2D/10」がデフォルトだが、「NRV2B/10」も選べる。UPX自身の圧縮で比較したところでは、「NRV2D/10」のほうが、0.4%だけ圧縮率がよかった。
    • dos/com形式で「NRV2B/10」の場合、SFXルーチンは128バイトらしい。これは先頭に57バイト、末尾に71バイト。先頭の57バイトは主に圧縮データ+展開ルーチンの上位転送、変数の初期値代入を行っている。末尾の71バイトは展開ルーチンのコアである。
      • 初期値代入が6バイトくらいなので、合計77バイトだ。このサイズは、UPXの圧縮率からすると絶賛に値する。
    • このヘッダサイズを差し引いた上でtek等と圧縮率を比較すると、
      圧縮率低い ← tek1 tek2 tek0 NRV2B/10 gzip stk5 tek5 → 圧縮率高い
    • となる。つまりUPXはtek2よりもよいが、gzipには勝てない。展開速度的にも、おそらくtek2とgzipの間であろう(tek2はLZOと同じくらいの速さなので)。これだけの圧縮率がありながら、わずか77バイトで展開ルーチンがかけるところは本当にすごい。展開速度と圧縮率という観点では、tekと同じくらいのバランスだと思う。
    • 基本的には安定したアルゴリズムでありその点は評価できる(dgcaは圧縮対象によって順位が乱高下しており、汎用性が乏しい)。ただ、LZ圧縮が効かない領域で大きくロスする性質があり、それが不安定要因になっている。
  • 使ったupx: UPX 1.25w
    • 圧縮方法:拡張子を.comに変えて、--bestで圧縮。出てきたファイルのサイズから128を引く。
  • SFXルーチン量の見積もり:
    • いくつかのファイルをUPXしてみると、どうも最初の出だしと末尾のいくらかが全く同じである。このヘッダとフッタがSFXルーチンであると見た。
    • そこでvgadrv0.askの最後の1バイトを0a→08に変更したものを用意し、どちらもUPXをかけ、FCコマンドで比較させてみた。これの狙いは、どこからフッタが始まっているのかを見極めることである。
    • 0x0039-0x3292が完全に一致したので、これ以外がヘッダとフッタであると考えられる。これはたかだか136バイトしかないので、aksaを使って逆アセンブルした。これにより、先頭のSFXルーチンは確かに0-0x38までであり、また末尾のSFXルーチンは0x329b-0x32e1であることを確かめた。合計で57+71=128バイトである。
    • このルーチンは16ビットモードで動くことを非常に意識しており、データが16bit単位になっていた。おそらくこれを32bit化しただけのものが「NRV2D/10」ではなかろうかと想像する。
    • またこれはコードを読んだから分かることだが、このルーチンはうまく圧縮できるデータに対してはなかなかよい圧縮率をたたき出せる代わりに、圧縮が効かない部分に差し掛かるとデータを1割以上も増加させてしまう。この観点でl2d3並みである。tek1やtek2やtek0やtek5にはそのような挙動はない。
      • こういう性質は、データの一部がうまく圧縮できなくても、圧縮できるところだけをきっちりと圧縮できるという安定性に直結する。upxでは、そういうデータを含んでいると、そこでサイズを増やしてしまうために、圧縮でがんばっても生きてこない。こういうのは、sarやtarで作ったアーカイブなどではたまに出現する。
      • 例:OSASK ver.4.7にバンドルしたkaodun01.bin(33219バイト)の前に、ヘッダとして16KBの0x00を付け加えたもの。
      • ヘッダは容易に圧縮できるが、本体のこれ以上の圧縮は困難であろう。
        format無圧縮upxpaq4gzipstk5stk1stk2tek5tek0
        サイズ496033698533397333903336433263332573325733251
        指標1149.17111.23100.44100.42100.34100.04100.02100.02100.00
        指標2-1.4770.0003.2423.2913.4985.7406.4336.433(inf)
  • vgadrv0.askでの比較(テキストファイル):
    format無圧縮tek1tek2tek0yz2upxgzipbzip2dgcaLZMAstk5tek5PPMdpaq4
    サイズ64108155801461213976134671289812609119581144011402112031099699577992
    指標1802.15194.94182.83174.87168.50161.39157.77149.62143.14142.67140.18137.59124.59100.00
    指標2-2.0010.0000.1360.2370.3260.4360.4970.6490.7890.8000.8600.9271.351(inf)
  • test128.bmpでの比較(ベタ画像ファイル):
    format無圧縮yz2dgcatek1tek2tek0upxbzip2PPMdLZMAgzipstk5tek5paq4
    サイズ8310134412161128993924887877846829746712666422
    指標11969.2318.43288.15267.30235.31218.96210.19207.82200.47196.45176.78168.72157.82100.00
    指標2-2.1470.0000.1490.2670.4790.6080.6850.7060.7770.8181.0461.1571.329(inf)
  • kaos2c.helでの比較(汎用データ):
    format無圧縮tek1yz2tek2tek0dgcaupxbzip2PPMdgzipLZMAstk5tek5paq4
    サイズ240124658423939603801360035063466333130442877258325142077
    指標11156.1224.27204.09190.66183.00173.33168.80166.88160.38146.56138.52124.36121.04100.00
    指標2-2.1400.0000.1770.3150.4040.5270.5910.6200.7220.9821.1711.6291.776(inf)

リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: 2006-02-16 (木) 18:00:09 (5977d)