Cranker by The Electronic Knights
_____________ __________ _____ _____
( \ \ | / /
\___ ____) ____/ | / /
| | | \ | | ( (__
| \ | ___/_| \ \ \
| \ | \ \ \ \
\______/ \___________/_____/ \_____/
. T h e E l e c t r o n i c K n i g h t s .
---------------------------------------------
-- CRANKER 0.1 -- EXECUTABLE CRUNCHER --
The Electronic Knights - Cranker 0.1
---------------------------------------------------------------------
Early beta, feedback welcome
Cranker is an Amiga executable cruncher.
It decrunches while loading and decrunching requires no additional
memory. Cranker is by far the fastest way to run large executables
from disk on old, unexpanded Amigas like Amiga 500, 600, and 2000.
Rationale:
Large OCS demos (onefilers) often reserve most available memory in
their executable sections. This is best practice and recommended.
Crunching them with most crunchers like Imploder, Powerpacker or
Shrinkler is not an option, because all crunched data plus all
sections must fit into memory at the same time, so the demo will
fail to run in the minimal configuration (typically 512k+512k).
Titanics cruncher was 30 years ahead of its time in that it includes
a decruncher that loads from an overlay hunk, thus requiring little
or no additional memory. Unfortunately Titanics is very slow and the
crunch ratio is bad. It is often faster to even start the uncrunched
executable. (I think that Titanics does not really load and decrunch
at the same time, but alternates between loading and decrunching.)
Cranker addresses all this, and more. It certainly does load and
decrunch at the same time, it uses no additional memory, it has a
solid crunch ratio, and it is blazingly fast. It is possibly the
only Amiga decruncher that does real asynchronous I/O.
Some benchmarks:
Rebels Retrodentro, crunched size:
----------------------------------
Original : 499768 Bytes
Titanics : 236388 Bytes
Cranker : 217408 Bytes
Imploder : 213332 Bytes - does not work with 1mb
Shrinkler: 179724 Bytes - does not work with 1mb
Starting time, Kick 1.3:
----------------------------------
Cranker : 20s
Imploder : 28s - does not work with 1mb
Titanics : 35s
Original : 41s
Shrinkler: 87s - does not work with 1mb
Starting time, Kick 2.04:
----------------------------------
Cranker : 14s
Imploder : 24s - does not work with 1mb
Original : 33s
Titanics : 46s
Shrinkler: 86s - does not work with 1mb
Usage:
$ cranker <infile> <outfile>
The Amiga version requires a 68020 and FPU.
I expect bugs and problems, and you should too. Feedback is welcome.
More technical info:
Cranker does not allocate memory. All allocations are made by the
OS loader. Hence it is decided right at the beginning if the
executable fits into memory and will be loaded at all.
Cranker uses a combination of techniques, hunk overlay, asynchronous
and buffered I/O, and overlapping, in-place decrunching with one of
the fastest decrunchers in existence. A small logic allows to switch
between async and buffered loading, for coping with reloc tables
efficiently. Relocs are packed into 1, 2, and 4 bytes entities.
Due to its complexity, the decrunch header is large (1100 bytes),
but I guess that it can be further optimized for size. Room for the
decrunch header is the only memory that adds to the requirements of
the executable. It will be freed by the OS at exit, like all other
sections.
Side notes, enhancements:
Cranker executables can be started via dos.library/LoadSeg().
With Shrinkler, this is not possible, Execute() must be used instead.
This is a pity, because on Kick 1.x Execute() requires the DOS
command 'run', an extra stack, process and CLI structure etc., which
all adds to the required memory.
The Cranker decruncher is so fast that I suspect that the construct
is I/O bound under all practical circumstances, even if asynchronoucy
kicks in just a little. In other words, there is probably some time
left for more time-consuming compression algorithms before I/O
catches up with the CPU.
Download:
http://neoscientists.org/~bifat/binarydistillery/cranker-0.1.lha
Author:
Coding by Bifat/TEK
<bifat at neoscientists.org>
[ back to the prod ]