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 ]