btw, in russian compression forum grzip author described idea of extra-fast bwt compression: http://forum.compression.ru/viewtopic.php?t=1948
btw, in russian compression forum grzip author described idea of extra-fast bwt compression: http://forum.compression.ru/viewtopic.php?t=1948
msufsort also seems quite good
bulat:
that's non deterministic algorithm. the output is usually not valid due to hash collisions. therefore it's not used in practice.
black_fox:
i know about it. afair divsufsort is currently faster than msufsort.
on my system szip -o4 has almost identical speed as rings and szip also uses bwt (of limited order - it's called shindler transform).
rings is more modern so it has better compression (of about 2 - 3 % with same block size).
on 64- bit computers it would be possible to do szip -o8 or -o7 with same speed. it would then have better compression.
donkey7, we know that's ST![]()
so why are you pointing to full bwt solutions? st works best with simple one- pass quicksort.
because Nania said about bwt. and i'm not sure that simple sorting may be used for fast ST4 algorithms. afaik, grzip use itw own algorithm
well, i'm partially mistaken. i thought that st4 doesn't need stable sorting algo. but there is a workaround - make uint64 by:
[4 bytes of context] << 32 + [3 bytes of index] << 8 + [1 byte of last column - st4 output]
and then apply simple sort on uint64s.
the problem is that some sorting procedure specialized for ST4 may run faster and definitely will use less amount of memory
RINGS 1.5 released
- UNREAL COMPRESSION!
Warning: Only for testing
Copyright ® 2007 by Nania Francesco Antonio (Italy).
All rights reserved.
link:
http://www.winturtle.netsons.org/rings.zip
Thanks Francesco!
Mirror: Download
Quick test...
RINGS c 9
A10.jpg > 819,150
AcroRd32.exe > 1,493,652
english.dic > 566,326
FlashMX.pdf > 3,752,097
FP.LOG > 486,886
MSO97.DLL > 1,872,766
ohs.doc > 884,912
rafale.bmp > 799,867
vcfiu.hlp > 716,177
world95.txt > 527,124
Total = 11,918,957 bytes
ENWIK8 > 21,848,093 bytes
Compression speed is still quick!![]()
Very good results Francesco! Now, text compression is really great - thanks to its BWT nature I think.
Can you confirm that your "fast BWT" is using limited key lengths? Have you extended the length limit with each version?
![]()
Christian
Yes ! but for I apply only now it to some types of file (txt,log,bin) but an a little slower has become!
RINGS 1.5b released
- More stable !
- Corrected more bugs!
Warning: Only for testing
Copyright ® 2007 by Nania Francesco Antonio (Italy).
All rights reserved.
link:
http://www.winturtle.netsons.org/rings.zip
I tested it on a couple of files. What was wrong?Originally Posted by Nania Francesco Antonio
the prototype of fast bwt coder that use on file of few byte goes to crash!
CREATED NEW
RINGS HOME PAGE
http://www.winturtle.netsons.org/RINGS/rings.htm
UNREAL!
Mirror: Download
RINGS 1.5c released
- Full compatible!
Warning: Only for testing
Copyright ® 2007 by Nania Francesco Antonio (Italy).
All rights reserved.
link:
http://www.winturtle.netsons.org/rings.zip
Thanks Francesco!
Mirror: Download
Quick test...
A10.jpg > 819,150
AcroRd32.exe > 1,493,652
english.dic > 566,326
FlashMX.pdf > 3,752,097
FP.LOG > 486,886
MSO97.DLL > 1,872,766
ohs.doc > 884,912
rafale.bmp > 799,867
vcfiu.hlp > 716,177
world95.txt > 527,124
Total = 11,918,957 bytes
ENWIK8 > 21,848,093 bytes
Compression time for ENWIK8 was 80.61s on my P3 @750MHz.
Compression speed is impressive even on my old P3 @750MHz machine.![]()
Thanks LovePimple Hi! At moment rings is not entirely stable !
Why?Originally Posted by Nania Francesco Antonio
I guess "not stable" as in "still under heavy development"![]()
YES ! still under heavy development ! HI!
That statment covers almost ALL archivers and compressors.Originally Posted by Black_Fox
![]()