page0103

続サイズ対決

• (by K, 2014.07.29)

(0)

• かつてKは、サイズ対決と称して、同じ内容のアプリをさまざまなOS向けに書き直した場合の最小サイズの比較をやっていました。
• あれから月日もたったので、もう一度やろうと思います。

• なお、MS-DOSのCOMファイルのようにシグネチャを含まない実行ファイルはペナルティとして2バイトを加算します。
  • シグネチャが1バイトの場合は、1バイトのペナルティです。
  • このルールは、私たちがシグネチャを削って判定にしくくなった実行ファイルの流行を望んでいないためです。

• おことわり：
  • そもそもこんな小規模なアプリでは実際のユースケースを反映していないという指摘は十分すぎるほど説得力があります。しかし規模が大きくなればなるほど、作り比べるのが大変になります。ですからまずこの辺りから始めるのは、十分に合理的であるとKは考えます。

• 備考：
  • 青字はOSASK計画以外での世界最高記録です。

(1) hello, world対決

• 画面に「hello, world\n」を出力すること。それだけです。
  • 末尾に!は入れません。これはK&R（有名なC言語の教科書）のサンプルに由来します。
  • GUIで表示するのなら、改行を出力しなくても構いません。

    OS/VM	サイズ	備考
    osecpu-rev2	14バイト	app0110, osecpu125d以降
    osecpu-rev1	14バイト	app0091
    第二世代OSASK	16バイト
    MS-DOS	24バイト	（シグネチャ補正前は22バイト）
    Linux/x86	57バイト	http://d.hatena.ne.jp/kikx/20061111 から!の分を引いた
    Java	336バイト

(2) chars対決

• 画面にキャラクターコード0x20から0x7e（印字可能なASCIIキャラクタのすべて）と改行を出力するという課題です。順序は逆順でも構いません。

   !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

  OS/VM	サイズ	備考
  osecpu-rev2	7バイト	app0109, osecpu125d以降
  osecpu-rev1	8バイト	app0036
  CLE on OSZ	8バイト	http://nerry.hatenablog.com/entry/2014/06/19/005735
  第二世代OSASK	13バイト
  COM64plus	14バイト
  MS-DOS	19バイト	（シグネチャ補正前は17バイト）
  Java	352バイト

(3) hexdump対決

• 指定されたファイルの16進数ダンプを画面に表示します。
  • 以下のフォーマットを再現してください。

     offset   +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F  0123456789ABCDEF
    ---------------------------------------------------------------------------
    00000000  05 E2 AE 3A 0C 46 4B B3 DA 41 D8 10 95 A0 53 51  ...:.FK..A....SQ
    00000010  11 72 C0 75 10 77 71 79 C3 5B 75 AC 38 1B FA 4A  .r.u.wqy.[u.8..J
    00000020  BB B8 BC 46 46 8F 5B 48 81 01 43 02 46 B8 88 6B  ...FF.[H..C.F..k
    00000030  94 00 B4 88 10 3A 50 09 70 11 A5 08 74 53 40     .....:P.p...tS@

    OS/VM	サイズ	備考
    osecpu-rev2	104バイト	app0129, osecpu125d以降
    第二世代OSASK	168バイト	hexdump

(4) グラデーション対決

• 画面の256x256ピクセルの領域に、それぞれ違う色で点を描画します。32Kカラーしかサポートできない場合に配慮して、同じ色の点が2つまでならあってもよいとします。3つ以上あったら課題を満たしていません。
  • したがって32K未満のカラーモードしか持たないOSは、この課題に参加できません。
  • 上記の条件を満たしていれば、グラデーションになっていなくてもOKです。
    

    OS/VM	サイズ	備考
    osecpu-rev2	6バイト	app0124, osecpu124d以降
    osecpu-rev1	12バイト	app0092

(5) bball対決

• 定番の以下の画像を描画します。むやみに拡大縮小してはいけませんが、1ピクセル程度の誤差は許容します。色はこの配色ではなくとも構いませんが、色数を減らしてはいけませんし、線が重なるところはどちらが先に描画しても結果が同じになるように、OR演算でやってください。
  • OR演算で描画できない場合は、この課題を満たしていないと判断します。・・・ただし描画順序を工夫して重なり部分の色に一貫性があるなら、例外的に課題を満たしているとします。
    

    OS/VM	サイズ	備考
    osecpu-rev2	63バイト	app0103, osecpu122d以降
    osecpu-rev1	71バイト	app0023
    MS-DOS/PC-9801	114バイト	（シグネチャ補正をしたかどうか不明）
    第一世代OSASK	186バイト

(6) コルモゴロフ複雑性対決

• Wikipediaには「コルモゴロフ複雑性」というページがあり、そこにマンデルブロ集合の画像があります。
  • http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%AB%E3%83%A2%E3%82%B4%E3%83%AD%E3%83%95%E8%A4%87%E9%9B%91%E6%80%A7
• その画像にはキャプションがあり、以下のように書かれています。
  • この画像はフラクタル図形であるマンデルブロ集合の一部である。このJPEGファイルのサイズは17KB以上（約140,000ビット）ある。ところが、これと同じファイルは140,000ビットよりも遥かに小さいコンピュータ・プログラムによって作成することが出来る。従って、このJPEGファイルのコルモゴロフ複雑性は140,000よりも遥かに小さい。
• 「遥かに小さい」って、なんか逃げた表現ですよね。はっきりと○○バイトで書けるって言い切ってしまえたら、この説明はもっとすっきりすると思いませんか？
• それならば、この画像に十分に近い画像を何バイトのプログラムで書けるのかを競おうではないか、というわけです。

• 解像度は1024x768です。色数は24ビットカラーかそれ以上です。
  

  OS/VM	サイズ	備考
  osecpu-rev2	88バイト	app0125, osecpu124d以降

• 画質を十分に上げるために、4x4=16倍サンプル以上のオーバーサンプリングをするべきだと感じます。その方がずっと目標画像に近いです。
  

  OS/VM	サイズ	備考
  osecpu-rev2	111バイト	app0126, osecpu124d以降

(7) マンデルブロ集合対決

• 上記(6)の対決は要求スペックが高すぎるかもしれないので、もっと簡単なマンデルブロ集合画像の表示で競います。これは640x480の二値画像です。
  

  OS/VM	サイズ	備考
  osecpu-rev2	49バイト	app0127, osecpu124d以降

(8) invader対決

• OSASKでは定番のインベーダゲームでの比較です。
  

  OS/VM	サイズ	備考
  osecpu-rev2	430バイト	app0107, osecpu125d以降
  osecpu-rev1	505バイト
  MSX-DOS	985バイト	ASXXXを使用
  第一世代OSASK	1108バイト
  TownsOS	1241バイト
  はりぼてOS	1509バイト
  win32(Win9X限定)	2192バイト
  win32	2560バイト

(9) 考察みたいなもの

• はりぼてOS、第一世代OSASK、第二世代OSASK、OSECPU-VMを簡単にまとめました。

  OS/VM	APIのタイプ	一般命令コードのタイプ	開発年
  はりぼてOS	レジスタAPI	x86	(教材)
  第一世代OSASK	32ビットパケットAPI	x86	2000-2005
  第二世代OSASK	hh4パケットAPI	x86	2008-2009
  OSECPU-VM(rev1)	hh4パケットAPI	osecpu-hh4	2013
  OSECPU-VM(rev2)	hh4パケットAPI	osecpu-hh4	2014-

• 傾向としてはhh4化が進めば進むほどサイズは改善するようです。

こめんと欄