続サイズ対決
(0)
- かつてKは、サイズ対決と称して、同じ内容のアプリをさまざまなOS向けに書き直した場合の最小サイズの比較をやっていました。
- あれから月日もたったので、もう一度やろうと思います。
- なお、MS-DOSのCOMファイルのようにシグネチャを含まない実行ファイルはペナルティとして2バイトを加算します。
- シグネチャが1バイトの場合は、1バイトのペナルティです。
- このルールは、私たちがシグネチャを削って判定にしくくなった実行ファイルの流行を望んでいないためです。
- おことわり:
- そもそもこんな小規模なアプリでは実際のユースケースを反映していないという指摘は十分すぎるほど説得力があります。しかし規模が大きくなればなるほど、作り比べるのが大変になります。ですからまずこの辺りから始めるのは、十分に合理的であるとKは考えます。
(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対決
(3) hexdump対決
- 指定されたファイルの16進数ダンプを画面に表示します。
(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には「コルモゴロフ複雑性」というページがあり、そこにマンデルブロ集合の画像があります。
- その画像にはキャプションがあり、以下のように書かれています。
- この画像はフラクタル図形であるマンデルブロ集合の一部である。この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化が進めば進むほどサイズは改善するようです。
こめんと欄
|