Crush v1.3

**suryakandau@yahoo.co.id** · 13th January 2020, 18:14

this is crush v1.3 based on v1.1 with amazing compression ratio improvements.

**Entai44** · 13th January 2020, 18:20

you still have my thanks, great job

**suryakandau@yahoo.co.id** · 14th January 2020, 17:06

improve compression ratio for enwik9 file n decompression time is still fast

**suryakandau@yahoo.co.id** · 15th January 2020, 02:12

Originally Posted by Entai44

you still have my thanks, great job

Thank you

**xezz** · 15th January 2020, 15:12

do you know https://github.com/jibsen/bcrush ?

**suryakandau@yahoo.co.id** · 15th January 2020, 16:01

Originally Posted by xezz

do you know https://github.com/jibsen/bcrush ?

let me check later

**suryakandau@yahoo.co.id** · 15th January 2020, 17:31

Originally Posted by suryakandau@yahoo.co.id

let me check later

this is the result of silesia benchmark, compression time is very fast

**suryakandau@yahoo.co.id** · 16th January 2020, 17:56

improve compression ratio from crush v1.0 size 279491430 bytes to 257210635 bytes (7.97%)

**suryakandau@yahoo.co.id** · 18th January 2020, 18:21

Originally Posted by suryakandau@yahoo.co.id

improve compression ratio from crush v1.0 size 279491430 bytes to 257210635 bytes (7.97%)

this is Crush v1.6 with small compression ratio improvement from crush v1.5

**xezz** · 19th January 2020, 14:59

small file compression is worse.

**suryakandau@yahoo.co.id** · 19th January 2020, 15:02

Originally Posted by xezz

small file compression is worse.

compared to bcrush or crush v1.1 ? which small file ?
crush v1.6 beat bcrush on webster file (silesia benchmark)

**jibz** · 19th January 2020, 15:44

Originally Posted by suryakandau@yahoo.co.id

compared to bcrush or crush v1.1 ? which small file ?
crush v1.6 beat bcrush on webster file (silesia benchmark)

Is your version compatible with the original crush format? bcrush with --optimal flag was supposed to be bit-optimal for that format, so if you are beating it with the same data format there must be a bug in bcrush.

**suryakandau@yahoo.co.id** · 19th January 2020, 15:53

Originally Posted by jibz

Is your version compatible with the original crush format? bcrush with --optimal flag was supposed to be bit-optimal for that format, so if you are beating it with the same data format there must be a bug in bcrush.

i don't test it with original crush format so i don't know it compatible or not.
from bcrush webpage there is the result for silesia benchmark . is it use --optimal flag ? if yes so there is a bug in bcrush because crush v1.6 can beat bcrush on webster file.

**suryakandau@yahoo.co.id** · 19th January 2020, 16:14

very small improvements, but compression and decompression speed is very fast. decompression time for webster file only 1.17s. is it still pareto frontier ?

**suryakandau@yahoo.co.id** · 19th January 2020, 16:23

Originally Posted by suryakandau@yahoo.co.id

very small improvements, but compression and decompression speed is very fast. decompression time for webster file only 1.17s. is it still pareto frontier ?

this is the result for enwik8

**suryakandau@yahoo.co.id** · 19th January 2020, 16:42

Originally Posted by suryakandau@yahoo.co.id

this is the result for enwik8

crush v1.7 beat osdb file too compared to bcrush

**algorithm** · 19th January 2020, 22:16

An other test with enwik8 for bcrush

Code:

30017634 bytes
221m18.11s real   220m57.49s user     0m11.91s system

Speed is like 7.5KB/s. I looked into the code and i have to admit bcrush's code is very beautiful. The problem is that it uses hash chains which are very slow. It is better to use trees like other compressors.

EDIT: Also tested crush 1.7. Not compatible with original crush.

**suryakandau@yahoo.co.id** · 21st January 2020, 03:07

-improve compression ratio
-compression time fast
- decompression time fast

**suryakandau@yahoo.co.id** · 21st January 2020, 03:15

this is the result of enwik8 using crush v1.9

**xezz** · 21st January 2020, 15:11

compared with v1.3 and v1.6.test file is http://corpus.canterbury.ac.nz/resou...antrbry.tar.gz

alice29.txt 55671 57655
asyoulik.txt 51400 53759
cp.html 9124 9570
fields.c 3548 3829
lcet10.txt 137865 140757
plrabn12.txt 191857 196300
sum 14099 15244
xargs.1 2095 2266

**suryakandau@yahoo.co.id** · 21st January 2020, 15:31

Originally Posted by xezz

compared with v1.3 and v1.6.test file is http://corpus.canterbury.ac.nz/resou...antrbry.tar.gz

alice29.txt 55671 57655
asyoulik.txt 51400 53759
cp.html 9124 9570
fields.c 3548 3829
lcet10.txt 137865 140757
plrabn12.txt 191857 196300
sum 14099 15244
xargs.1 2095 2266

i improve it just for big file

**suryakandau@yahoo.co.id** · 22nd January 2020, 17:22

Originally Posted by suryakandau@yahoo.co.id

i improve it just for big file

this is the silesia benchmark result using crush v1.9
now it can beat nci file beside osdb n webster file.
btw @xezz what means by file corrupted: s=-2032 ?

**xezz** · 23rd January 2020, 17:33

may be bad offset. it is larger than current position.

Thread: Crush v1.3

Thread Tools

Search Thread

Display

Crush v1.3

Thanks (3):

crush v1.4

Thanks:

crush v1.5

Crush v1.6

Crush v1.7

Thanks (2):

Crush v1.9

Thanks:

Similar Threads

CRUSH 0.01 is here!

Crush v1.2

crush v1.1

Posting Permissions