| |
iAN CooG
Registered: May 2002
Posts: 3201 |
Release id #165080 : NuCrunch 1.0.0
Just a test of modern cross-crunchers (so no charpackers involved here) to confirm NuCrunch is really superfast. Still hard to beat exomizer, especially 3.0 got a significant speedup. ALZ64 here added just for the giggles, we all know it's good at crunching but the geological decrunch time makes it useful for 4k prgs only =)
Tested program:
Commando Arcade IFFL loader ($0800-$57c6, 20425 bytes)
Crunchers tested | cycles to enter depacker + cycles to unpack&jmp | size |
------------------------------------------------------------------------------
NuCrunch/ChristopherJam v1.0 | 17506 + 930588 = 948094 | 10229 |
NuCrunch/ChristopherJam v1.0 /compact | 13746 + 1169590 = 1183336 | 10106 |
Doynamite v1.1 | 169341 + 1214990 = 1384331 | 9972 |
T.L.R. Subsizer 0.6 / dirty | 16176 + 1697194 = 1713370 | 9764 |
ByteBoozer v2.0 | 2390 + 1891207 = 1893597 | 9932 |
Crush / Taboo | 152802 + 1765952 = 1918754 | 10207 |
Exomizer v3.0 | 15291 + 1908936 = 1924227 | 9703 |
T.L.R. Subsizer 0.6 | 19524 + 2277169 = 2296693 | 9753 |
ByteBoozer v1.1C | 817 + 2317028 = 2317845 | 10184 |
Bongo Cruncher | 159120 + 2178246 = 2337366 | 10469 |
Exomizer v2.0.11 | 16130 + 2776032 = 2792162 | 9687 |
PUCrunch | 177397 + 2926345 = 3103742 | 10113 |
LZMPi/MartinPiper v1.x | 6777 + 4318773 = 4325550 | 10187 |
ALZ64/Kabuto | 152598 +20549394 =20701992 | 9384 |
------------------------------------------------------------------------------
Tested program:
Enforcer2 demo ($0801-$e891, 57491 bytes)
Crunchers tested | cycles to enter depacker + cycles to unpack&jmp | size |
------------------------------------------------------------------------------
NuCrunch/ChristopherJam v1.0 | 17753 + 3292526 = 3310279 | 34393 |
NuCrunch/ChristopherJam v1.0 /compact | 14525 + 4192968 = 4207493 | 34270 |
Doynamite v1.1 | 572875 + 4317341 = 4890216 | 34889 |
T.L.R. Subsizer 0.6 / dirty | 16254 + 5655594 = 5671848 | 32884 |
Exomizer v3.0 | 14875 + 6301935 = 6316810 | 32483 |
Crush / Taboo | 527344 + 6365208 = 6892552 | 35981 |
ByteBoozer v2.0 | 2390 + 7084099 = 7086489 | 35000 |
T.L.R. Subsizer 0.6 | 19602 + 7757446 = 7777048 | 32873 |
Bongo Cruncher | 513474 + 7781493 = 8294967 | 35425 |
ByteBoozer v1.1C | 817 + 8618624 = 8619441 | 35863 |
Exomizer v2.0.11 | 15911 + 9301428 = 9317339 | 32507 |
PUCrunch | 599301 +10194559 =10793860 | 35856 |
LZMPi/MartinPiper v1.x | 6777 +14269565 =14276342 | 33566 |
ALZ64/Kabuto | 484054 +75151934 =75635988 | 30856 |
------------------------------------------------------------------------------
all timing taken with unp64 v2.34. |
|
... 2 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2982 |
And i'd say if you put unrolled loops in your binary and expect some cruncher to fix that mistake for you, you're doing it wrong. :) |
| |
Raistlin
Registered: Mar 2007
Posts: 688 |
@Krill: while I agree that self-generating code on C64 side is -usually- best, and what I've previously used for most of my demos (in the 80s), there are some advantages to unrolling code pre-compile that are too time-consuming to do on a C64. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
I'd wager that even then, you can distill the pre-compiled code to something that is both space-efficient and quickly inflatable to native machine code. But yes, then the line becomes somewhat blurry between this very custom encoding and something slightly more generic like Rowscruncher. :) |
| |
TheRyk
Registered: Mar 2009
Posts: 2265 |
of course code generators SHOULD be first choice.
what keeps making me use unrolled stuff time and again is mostly mere laziness and 64k being far too much RAM in many situations
And what's more, experience often showed: yeah, I'm a super coder and wrote a code generator and saved so-and-so-much RAM which makes me feel mighty 1337 \o/
but when you crunch the unrolled stuff and the stuff with the fancy code generator that twisted your brain for some hours, there's quite often not one block difference in crunched size which makes you go meh... (unless you're really in a situation where you make good use of the target area of RAM where your stuff is generated) |
| |
Raistlin
Registered: Mar 2007
Posts: 688 |
Exactly. But it goes even further than that .. when you're using something like an IRQ loader, loading of that code in a trackmo is usually done in the background of another demo part anyway... so the balance there just comes down to disk space vs time taken to code... is it best to spend time writing a great code-generator or to write more demo effects..?
Coding intros is a different matter of course. |
| |
TheRyk
Registered: Mar 2009
Posts: 2265 |
yup, and especially in trackmo parts the cycles wasted to generate whatever code are not significantly less than decrunching time |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
you are not using enough CPU for your effect when that is true :=) |
| |
Raistlin
Registered: Mar 2007
Posts: 688 |
True - but that’s why we make filler parts :-p ... bounce a triangle across the screen, move some raster bars around for a bit... anything to detract the viewer from the whirring of their disk drive :-) |
| |
Raistlin
Registered: Mar 2007
Posts: 688 |
I come back after 27 years of abandoning the C64 and use the term “we” as though i’m still a proper scener :-p |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Nah, you're the proper scener Raistlin. I'm just some upstart with only one release that came out earlier than 2004, with NFI about scene etiquette.
(imposter syndrome is everywhere) |
| Previous - 1 | 2 - Next |
