| L-Packer by Oxygene [web] | ||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 51% |
|||||||
alltime top: #25545 |
|
|||||||
|
||||||||
added on the 2025-11-08 16:20:43 by leonard  |
||||||||
popularity helper
comments
Thank you Leonard!
rulez added on the 2025-11-08 17:32:39 by Depeche 
L-Packer is a new Atari & Amiga executable compressor! Optimized for 64K-style demos, it balances high compression ratios with decent decompression speed. To sum up it stands right in the middle between Shrinkler and Cranker/UPX. Currently support both inflate & ZX0 algorithms. More technical details here: https://github.com/arnaud-carre/L-Packer
Testing & feedback are welcome!
Testing & feedback are welcome!
Nice work
Thanks. Here is the mandatory thumb up!
Cool
Super!
Yep
Nice !
So I tested it for my 3 intros :
original shrinkler l-packer
Yes! 134248 60984 66968
The pixalated world 163220 64196 70524
Magical OCS 147596 61856 67808
It's a little over 64kb, but not by much, so it can probably be improved.
The problem is that the exe files no longer work: I get a crash while the cursor is flashing.
The three intros are in Amos, so they have a similar structure.
If you want, I can provide you with the uncompressed exe files.
So I tested it for my 3 intros :
original shrinkler l-packer
Yes! 134248 60984 66968
The pixalated world 163220 64196 70524
Magical OCS 147596 61856 67808
It's a little over 64kb, but not by much, so it can probably be improved.
The problem is that the exe files no longer work: I get a crash while the cursor is flashing.
The three intros are in Amos, so they have a similar structure.
If you want, I can provide you with the uncompressed exe files.
Nice to have a new packer for Amiga. Tested with no particular problem here. I'm waiting for the no-flash option :)
nice one !
Quote:
Nice ! It's a little over 64kb, but not by much, so it can probably be improved.
Yes, nothing could beat arithmetic coder of shrinkler (or STrinkler on atari). L-Packer is made when you can't afford too long depacking time with large exe such as 64KiB or more. So it's expected to be bigger than shrinkler, but should be smaller than any other amiga exe packers ( I hope :) )
Quote:
The three intros are in Amos, so they have a similar structure. If you want, I can provide you with the uncompressed exe files.
Yes I know Amiga bootstrap is not fully compatible right now (doesn't work with C compiled stuff). Probably same issue with AMOS exe. I have to investigate that for future v1.0. Ok you can provide an uncompressed AMOS exe so I can have a look
Quote:
I'm waiting for the no-flash option :)
I just added the option, please download again :)
Hey! This cruncher is great, but it would be even better if there was a Linux version (like there are Linux versions of Shrinkler and Cranker).
Just think about that, Leonard. :]
Just think about that, Leonard. :]
Definitely fills a - left empty for too long - space. Depacking time is very fast.
@leonard
Post in the eab forum thread
Post in the eab forum thread
just updated to v0.92. Now Amiga version also supports depack-in-place
This sounds great - quick(er) depack time, good ratio, muli-algo, working in-place. Surely will test it with the next prod. Thank you for releasing it to public, respect!
fast and tight packing
+1 for continuing to mess with packers :)
Some remarks and questions, summary:
- Shrinkler depack time is overstated by (at least) 15%
- Licensing
- Charts, I love charts:
- Including shrinkler file size in the chart
- Including depack time in the chart
- Including depacker disk overhead in bytes for Amiga and Atari
- Including depacker mem overhead in bytes for Amiga and Atari
- Including the pareto front, a simple log log chart with:
- X axis speed (KB/s) vs Y axis size (bytes)
It would be nice to see some more algorithms (Titanics, PowerPacker, PackFire, Doynamite, lha) in the charts.
Can you clarify how does the license apply to code packed with L-Packer? Do you have expectations of being credited in the prods using it?
As far as shrinkler goes, Shrinkler decompression routine does around 350 clocks per compressed bit on an Amiga 500. With standard 2bpl hires DMA interference, we're looking at around 2.5KB/s, so 26 seconds, unless you are having something like 1000 relocs in your hunks (but why do that in a 64k intro?). Probably more than 10% faster on Atari ST, so 23 seconds, but I don't know Atari..
If you have a 64k file that takes 30 secs with shrinkler, please lmk, I'd love to take a look at it..
Thanks for continuing to innovate, I love seeing your work pop up everywhere :)
Some remarks and questions, summary:
- Shrinkler depack time is overstated by (at least) 15%
- Licensing
- Charts, I love charts:
- Including shrinkler file size in the chart
- Including depack time in the chart
- Including depacker disk overhead in bytes for Amiga and Atari
- Including depacker mem overhead in bytes for Amiga and Atari
- Including the pareto front, a simple log log chart with:
- X axis speed (KB/s) vs Y axis size (bytes)
It would be nice to see some more algorithms (Titanics, PowerPacker, PackFire, Doynamite, lha) in the charts.
Can you clarify how does the license apply to code packed with L-Packer? Do you have expectations of being credited in the prods using it?
As far as shrinkler goes, Shrinkler decompression routine does around 350 clocks per compressed bit on an Amiga 500. With standard 2bpl hires DMA interference, we're looking at around 2.5KB/s, so 26 seconds, unless you are having something like 1000 relocs in your hunks (but why do that in a 64k intro?). Probably more than 10% faster on Atari ST, so 23 seconds, but I don't know Atari..
If you have a 64k file that takes 30 secs with shrinkler, please lmk, I'd love to take a look at it..
Thanks for continuing to innovate, I love seeing your work pop up everywhere :)
Many questions!
I didn't added charts comparative time & size about Shrinkler because it's so different (timing chart with shrinkler,l-packer,cranker and upx would have weird scale ). I like the X speed vs Y size chart idea. But takes time to build such a chart (including the two platforms). If anyone want to do it, feel free :)
Regarding license, I select MIT by habit in github. Obviously you're not required ot credit L-Packer in a prod, no worry!
About depack mem and exe overhead you can use the verbose (-v) option to get more details about that.
Shrinkler estimated time depends on the exe obviously, but some 64KiB takes 30 sec to depack. One coming in mind is the great Coda by Abyss ( 32 seconds on A500) https://www.pouet.net/prod.php?which=80998
Finally about adding algorithms, Titanics, Powerpack, Doynamite are same league regarding speed, but slightly worst regarding packing ratio, so I won't include them. I plan to include LZ4 because it doesn't pack well for sure, but it's really fast to depack. So if your prod still fit the target size and LZ4 could be used, it's even better.
Hope it helps! Thanks for your nice feedback!
I didn't added charts comparative time & size about Shrinkler because it's so different (timing chart with shrinkler,l-packer,cranker and upx would have weird scale ). I like the X speed vs Y size chart idea. But takes time to build such a chart (including the two platforms). If anyone want to do it, feel free :)
Regarding license, I select MIT by habit in github. Obviously you're not required ot credit L-Packer in a prod, no worry!
About depack mem and exe overhead you can use the verbose (-v) option to get more details about that.
Shrinkler estimated time depends on the exe obviously, but some 64KiB takes 30 sec to depack. One coming in mind is the great Coda by Abyss ( 32 seconds on A500) https://www.pouet.net/prod.php?which=80998
Finally about adding algorithms, Titanics, Powerpack, Doynamite are same league regarding speed, but slightly worst regarding packing ratio, so I won't include them. I plan to include LZ4 because it doesn't pack well for sure, but it's really fast to depack. So if your prod still fit the target size and LZ4 could be used, it's even better.
Hope it helps! Thanks for your nice feedback!
Thanks for the clarifications, just my 5 cents here.
Coda by Abyss is written in (well optimized) C and does indeed have close to a thousand relocs. As I mentioned this is the only case I imagine in which things will take 30 seconds.
I just want to correct the record here about the reason Shrinkler is so good and if you evaluate it against bzip2, bzip3, zstd, etc. you will see that there's more to it than "just" arithmetic coding.
- it uses bit-by-bit adaptive probabilistic modeling like Matt Mahoney's FPAQ,etc.
- it creates a super efficient adaptive probabilstic model for Elias Gamma coded LZ backreferences and lengths
- it improves the LZ codestream to allow for reusing the previous backreference
and
(and here's the bit of why Abyss Coda takes so long)
it also employs a special Elias Gamma probabilistic context for decoding the delta packed relocs. This is not a part of the easy-to-read data decompression routine that you ported.
If you try adding that to your ST port of Shrinkler, you will likely see the executables get even smaller.
That all of this fits in so few bytes of decompression routine is an absolute masterpiece. What's even better the clock per clock instruction usage is actually pretty well tuned for 68000 and the tradeoffs made are such that there is no obvious way to substantially improve the performance.
For instance, the actual arithmetic decoding is a masterpiece. It uses high precision range coding, incredibly well tuned for 68000. The "slowdown" among other things come from adaptive probabilistic context.
What can be ported over from, say, ZX0 is using interlaced Elias Gamma coding as this could get you some more wins in the decompression routine size (as if Shrinkler is not in a league of its own already).
And I haven't even begun talking about the cruncher, which tries to find LZ Optimal encoding, which, for adaptive entropy coding is an open research problem..
Coda by Abyss is written in (well optimized) C and does indeed have close to a thousand relocs. As I mentioned this is the only case I imagine in which things will take 30 seconds.
I just want to correct the record here about the reason Shrinkler is so good and if you evaluate it against bzip2, bzip3, zstd, etc. you will see that there's more to it than "just" arithmetic coding.
- it uses bit-by-bit adaptive probabilistic modeling like Matt Mahoney's FPAQ,etc.
- it creates a super efficient adaptive probabilstic model for Elias Gamma coded LZ backreferences and lengths
- it improves the LZ codestream to allow for reusing the previous backreference
and
(and here's the bit of why Abyss Coda takes so long)
it also employs a special Elias Gamma probabilistic context for decoding the delta packed relocs. This is not a part of the easy-to-read data decompression routine that you ported.
If you try adding that to your ST port of Shrinkler, you will likely see the executables get even smaller.
That all of this fits in so few bytes of decompression routine is an absolute masterpiece. What's even better the clock per clock instruction usage is actually pretty well tuned for 68000 and the tradeoffs made are such that there is no obvious way to substantially improve the performance.
For instance, the actual arithmetic decoding is a masterpiece. It uses high precision range coding, incredibly well tuned for 68000. The "slowdown" among other things come from adaptive probabilistic context.
What can be ported over from, say, ZX0 is using interlaced Elias Gamma coding as this could get you some more wins in the decompression routine size (as if Shrinkler is not in a league of its own already).
And I haven't even begun talking about the cruncher, which tries to find LZ Optimal encoding, which, for adaptive entropy coding is an open research problem..
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !