Code Monkey home page Code Monkey logo

density's Introduction

DENSITY

Superfast compression library

DENSITY is a free C99, open-source, BSD licensed compression library.

It is focused on high-speed compression, at the best ratio possible. All three of DENSITY's algorithms are currently at the pareto frontier of compression speed vs ratio (cf. here for an independent benchmark).

DENSITY features a simple API to enable quick integration in any project.

Branch Linux & MacOS Windows
master Build Status Build status
dev Build Status Build status

Why is it so fast ?

One of the biggest assets of DENSITY is that its work unit is not a byte like other libraries, but a group of 4 bytes.

When other libraries consume one byte of data and then apply an algorithmic processing to it, DENSITY consumes 4 bytes and then applies its algorithmic processing.

That's why DENSITY's algorithms were designed from scratch. They have to alleviate for 4-byte work units and still provide interesting compression ratios.

Speed pedigree traits

  • 4-byte work units
  • heavy use of registers as opposed to memory for processing
  • avoidance of or use of minimal branching when possible
  • use of low memory data structures to favor processor cache Lx accesses
  • library wide inlining
  • specific unrollings
  • prefetching and branching hints
  • restricted pointers to maximize compiler optimizations

A "blowup protection" is provided, dramatically increasing the processing speed of incompressible input data. Also, the output, compressed data size will never exceed the original uncompressed data size by more than 1% in case of incompressible, reasonably-sized inputs.

Benchmarks

Quick benchmark

DENSITY features an integrated in-memory benchmark. After building the project (see build), a benchmark executable will be present in the build directory. If run without arguments, usage help will be displayed.

File used : enwik8 (100 MB)

Platform : MacBook Pro, MacOS 10.13.3, 2.3 GHz Intel Core i7, 8Gb 1600 MHz DDR, SSD, compiling with Clang/LLVM 9.0.0

Timing : using the time function, and taking the best user output after multiple runs. In the case of density, the in-memory integrated benchmark's best value (which uses the same usermode CPU timing) is used.

Library Algorithm Compress Decompress Size Ratio Round trip
density 0.14.2 Chameleon 0.092s (1085 MB/s) 0.059s (1684 MB/s) 61 524 084 61,52% 0.151s
lz4 r129 -1 0.468s (214 MB/s) 0.115s (870 MB/s) 57 285 990 57,29% 0.583s
lzo 2.08 -1 0.367s (272 MB/s) 0.309s (324 MB/s) 56 709 096 56,71% 0.676s
density 0.14.2 Cheetah 0.170s (587 MB/s) 0.126s (796 MB/s) 53 156 668 53,16% 0.296s
density 0.14.2 Lion 0.303s (330 MB/s) 0.288s (347 MB/s) 47 817 692 47,82% 0.591s
lz4 r129 -3 1.685s (59 MB/s) 0.118s (847 MB/s) 44 539 940 44,54% 1.803s
lzo 2.08 -7 9.562s (10 MB/s) 0.319s (313 MB/s) 41 720 721 41,72% 9.881s

Other benchmarks

Here are a few other benchmarks featuring DENSITY (non exhaustive list) :

  • squash is an abstraction layer for compression algorithms, and has an extremely exhaustive set of benchmark results, including density's, available here.

  • lzbench is an in-memory benchmark of open-source LZ77/LZSS/LZMA compressors.

  • fsbench is a command line utility that enables real-time testing of compression algorithms, but also hashes and much more. A fork with density releases is available here for easy access. The original author's repository can be found here.

Build

DENSITY can be built on a number of platforms, via the provided makefiles.

It was developed and optimized against Clang/LLVM which makes it the preferred compiler, but GCC and MSVC are also supported. Please use the latest compiler versions for best performance.

MacOS

On MacOS, Clang/LLVM is the default compiler, which makes things simpler.

  1. Get the source code :
    git clone https://github.com/k0dai/density.git
    cd density
  1. Build and test :
    make
    build/benchmark -f

Alternatively, thanks to the Homebrew project, DENSITY can also be installed with a single command on MacOS:

    brew install density

Linux

On Linux, Clang/LLVM is not always available by default, but can be easily added thanks to the provided package managers. The following example assumes a Debian or Ubuntu distribution with apt-get.

  1. From the command line, install Clang/LLVM (optional, GCC is also supported if Clang/LLVM can't be used) and other prerequisites.
    sudo apt-get install clang git
  1. Get the source code :
    git clone https://github.com/k0dai/density.git
    cd density
  1. Build and test :
    make

or

    make CC=gcc-... AR=gcc-ar-...

or

    make CC=clang-... AR=llvm-ar-...

to choose alternative compilers. For a quick test of resulting binaries, run

    build/benchmark -f

Windows

Please install git for Windows to begin with.

On Windows, density can be built in different ways. The first method is to use mingw's gcc compiler; for that it is necessary to download and install mingw-w64.

  1. Once mingw-w64 is installed, get the source :
    git clone https://github.com/k0dai/density.git
    cd density
  1. Build and test :
    mingw32-make.exe
    build/benchmark.exe -f

As an alternative, MSYS2 also offers a linux-like environment for Windows.

The second method is to download and install Microsoft's Visual Studio IDE community edition. It comes with Microsoft's own compilers and is free.

  1. Once Visual Studio is installed, open a developer command prompt and type :
    git clone https://github.com/k0dai/density.git
    cd density\msvc
  1. Build and test :
    msbuild Density.sln
    bin\Release\benchmark.exe -f

An extra recommended step would be to install Clang/LLVM for Windows. It is downloadable from this link. Once installed, open the Visual Studio IDE by double-clicking on Density.sln, then right-click on project names and change the platform toolsets to LLVM. Rebuild the solution to generate binaries with Clang/LLVM.

Output format

DENSITY outputs compressed data in a simple format, which enables file storage and optional parallelization for both compression and decompression.

A very short header holding vital informations (like DENSITY version and algorithm used) precedes the binary compressed data.

APIs

DENSITY features a straightforward API, simple yet powerful enough to keep users' creativity unleashed.

For advanced developers, it allows use of custom dictionaries and exportation of generated dictionaries after a compression session. Although using the default, blank dictionary is perfectly fine in most cases, setting up your own, tailored dictionaries could somewhat improve compression ratio especially for low sized input datum.

Please see the quick start at the bottom of this page.

About the algorithms

Chameleon ( DENSITY_ALGORITHM_CHAMELEON )

Chameleon is a dictionary lookup based compression algorithm. It is designed for absolute speed and usually reaches a 60% compression ratio on compressible data. Decompression is just as fast. This algorithm is a great choice when main concern is speed.

Cheetah ( DENSITY_ALGORITHM_CHEETAH )

Cheetah was developed with inputs from Piotr Tarsa. It is derived from chameleon and uses swapped double dictionary lookups and predictions. It can be extremely good with highly compressible data (ratio reaching 10% or less). On typical compressible data compression ratio is about 50% or less. It is still extremely fast for both compression and decompression and is a great, efficient all-rounder algorithm.

Lion ( DENSITY_ALGORITHM_LION )

Lion is a multiform compression algorithm derived from cheetah. It goes further in the areas of dynamic adaptation and fine-grained analysis. It uses multiple swapped dictionary lookups and predictions, and forms rank entropy coding. Lion provides the best compression ratio of all three algorithms under any circumstance, and is still very fast.

Quick start (a simple example using the API)

Using DENSITY in your application couldn't be any simpler.

First you need to include this file in your project :

  • density_api.h

When this is done you can start using the DENSITY API :

    #include <string.h>
    #include "density_api.h"

    char* text = "This is a simple example on how to use the simple Density API.  This is a simple example on how to use the simple Density API.";
    uint64_t text_length = (uint64_t)strlen(text);

    // Determine safe buffer sizes
    uint_fast64_t compress_safe_size = density_compress_safe_size(text_length);
    uint_fast64_t decompress_safe_size = density_decompress_safe_size(text_length);

    // Allocate required memory
    uint8_t *outCompressed   = malloc(compress_safe_size * sizeof(char));
    uint8_t *outDecompressed = malloc(decompress_safe_size * sizeof(char));
    density_processing_result result;

    // Compress
    result = density_compress(text, text_length, outCompressed, compress_safe_size, DENSITY_COMPRESSION_MODE_CHAMELEON_ALGORITHM);
    if(!result.state)
        printf("Compressed %llu bytes to %llu bytes\n", result.bytesRead, result.bytesWritten);

    // Decompress
    result = density_decompress(outCompressed, result.bytesWritten, outDecompressed, decompress_safe_size);
    if(!result.state)
        printf("Decompressed %llu bytes to %llu bytes\n", result.bytesRead, result.bytesWritten);

    // Free memory_allocated
    free(outCompressed);
    free(outDecompressed);

And that's it ! We've done a compression/decompression round trip with a few lines !

Related projects

density's People

Contributors

danatkinson avatar g1mv avatar lsb avatar manticoresearch avatar nemequ avatar stefanoschaliasos avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

density's Issues

Possible issues with lion

I updated the Squash plugin to the dev branch, and I have a couple problems with lion. These may be bugs in the Squash plugin—I tried the dev branch of sharc and everything stalls during decompression (also, you need to include <sys/resource.h> for RUSAGE_SELF and struct rusage), so I can't really be sure, but I thought you would want to check before rolling a release.

osdb (from silesa) crashes during decompression:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6d9492c in density_lion_decode_read_signature_from_memory (in=<optimized out>, state=0x7ffff6b44010)
    at /home/nemequ/local/src/squash/plugins/density/density/src/kernel_lion_decode.c:77
77      state->signature = DENSITY_LITTLE_ENDIAN_64(*(density_lion_signature *) (in->pointer));
Missing separate debuginfos, use: debuginfo-install glibc-2.20-8.fc21.x86_64
(gdb) bt
#0  0x00007ffff6d9492c in density_lion_decode_read_signature_from_memory (in=<optimized out>, state=0x7ffff6b44010)
    at /home/nemequ/local/src/squash/plugins/density/density/src/kernel_lion_decode.c:77
#1  density_lion_decode_read_1bit_from_signature (state=0x7ffff6b44010, in=0x60c140) at /home/nemequ/local/src/squash/plugins/density/density/src/kernel_lion_decode.c:130
#2  density_lion_decode_read_form (state=0x7ffff6b44010, in=0x60c140) at /home/nemequ/local/src/squash/plugins/density/density/src/kernel_lion_decode.c:390
#3  density_lion_decode_process_unit (state=0x7ffff6b44010, out=0x60c1a0, in=0x60c140) at /home/nemequ/local/src/squash/plugins/density/density/src/kernel_lion_decode.c:419
#4  density_lion_decode_finish (in=0x60e8b0, out=0x60c1a0, state=0x7ffff6b44010) at /home/nemequ/local/src/squash/plugins/density/density/src/kernel_lion_generic_decode.h:80
#5  0x00007ffff6d8aeb8 in density_block_decode_finish (in=in@entry=0x60e8b0, out=out@entry=0x60c1a0, state=state@entry=0x61172c, mem_free=mem_free@entry=0x7ffff726a440 <free>)
    at /home/nemequ/local/src/squash/plugins/density/density/src/block_decode.c:315
#6  0x00007ffff6d9fbe4 in density_decode_finish (in=0x60e8b0, out=0x60c1a0, state=0x611708, mem_free=0x7ffff726a440 <free>)
    at /home/nemequ/local/src/squash/plugins/density/density/src/main_decode.c:152
#7  0x00007ffff6da0a5b in density_stream_decompress_finish (stream=0x60e750) at /home/nemequ/local/src/squash/plugins/density/density/src/stream.c:246
#8  0x00007ffff6d8a140 in squash_density_process_stream (stream=0x604090, operation=SQUASH_OPERATION_FINISH)
    at /home/nemequ/local/src/squash/plugins/density/squash-density.c:372
#9  0x00007ffff7bd60f3 in squash_stream_process_internal (stream=0x604090, operation=SQUASH_OPERATION_FINISH) at /home/nemequ/local/src/squash/squash/stream.c:545
#10 0x00007ffff7bd628b in squash_stream_finish (stream=0x604090) at /home/nemequ/local/src/squash/squash/stream.c:647
#11 0x00007ffff7bd15fa in squash_codec_process_file_with_options (codec=0x60e7a0, stream_type=SQUASH_STREAM_DECOMPRESS, output=0x6113d0, output_length=0, input=0x611180, 
    options=0x611620) at /home/nemequ/local/src/squash/squash/codec.c:1107
#12 0x00007ffff7bd16e9 in squash_codec_decompress_file_with_options (codec=0x60e7a0, decompressed=0x6113d0, decompressed_length=0, compressed=0x611180, options=0x611620)
    at /home/nemequ/local/src/squash/squash/codec.c:1162
#13 0x0000000000401efc in main (argc=5, argv=0x7fffffffd868) at /home/nemequ/local/src/squash/utils/squash.c:292

sao (also from silesa) decompresses to a file which is 2 bytes smaller than the input.

Both of these happen on x86_64 (Fedora 21). I've put the compressed files up at http://code.coeusgroup.com/osdb.lion and http://code.coeusgroup.com/sao.lion though the problem could be on the compression side, too—in which case both files are available at http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia

The same code works for chameleon and cheetah, as well as all the other benchmark files I am using (see https://github.com/quixdb/squash-benchmark for a list).

Use of unnamed union

There was an issue compiling the squash density plugin, which I believe might be due to the use of an unnamed union in src/main_header.h. Support for this was not added until C11, but many versions of GCC supports it as an extension. If you compile density with -pedantic, you get the following warning:

../src/main_header.h:55:6: warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]

Memory leak on decompression failure

I have some unit tests which intentionally causes the decoder to fail, and I have noticed that if the stream is left in some states (such as STALL_ON_OUTPUT) then there will be a memory leak even if I call density_stream_decompress_finish, since that function will only free memory from certain states.

Ideally, I don't think I should have to call density_stream_decompress_finish; density_stream_destroy should take care of everything. If I want to abort decoding I should just be able to destroy the stream and be done with it, regardless of what state the stream is in.

I don't think you really need it, but here is a trace from asan:

Direct leak of 262200 byte(s) in 1 object(s) allocated from:
    #0 0x7ff61cf7ea0a in malloc (/lib64/libasan.so.2+0x98a0a)
    #1 0x7ff6186d9ae9 in density_decode_init /home/nemequ/local/src/squash/plugins/density/density/src/main_decode.c:84
    #2 0x7ff6186e0ceb in density_stream_decompress_init /home/nemequ/local/src/squash/plugins/density/density/src/stream.c:189
    #3 0x7ff6184e1d33 in squash_density_process_stream /home/nemequ/local/src/squash/plugins/density/squash-density.c:328
    #4 0x7ff61ccd20e3 in squash_stream_process_internal /home/nemequ/local/src/squash/squash/stream.c:608
    #5 0x7ff61ccd283a in squash_stream_process /home/nemequ/local/src/squash/squash/stream.c:718
    #6 0x7ff61cca956f in squash_codec_decompress_with_options /home/nemequ/local/src/squash/squash/codec.c:734
    #7 0x401cb3 in check_codec /home/nemequ/local/src/squash/tests/bounds.c:42
    #8 0x7ff61c777b92  (/lib64/libglib-2.0.so.0+0x6fb92)

On Linux, clang is not selected as a compiler.

Hello,

I tried to build density under Linux environment, but I cannot choose clang as a compiler even if clang is installed properly. It seems that following trick in premake5 does not work no longer on Linux.

if os.execute("clang -v") == 0 then
  premake.cc  = 'clang'
  premake.cxx = 'clang++'
elseif os.execute("gcc -v") == 0 then
  premake.cc  = 'gcc'
  premake.cxx = 'g++'

Any result Makefile does not contain something like "CC=clang" or "CXX=clang++"

~/workspace/density/density/build$ ./premake5 gmake  && grep clang * -r
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Selected multilib: .;@m64
git version 1.9.1
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating spookyhash.make...
Generating density.make...
Generating benchmark.make...
Done.
Binary file premake5 matches
premake5.lua:if os.execute("clang -v") == 0 then
premake5.lua:   premake.cc  = 'clang'
premake5.lua:   premake.cxx = 'clang++

If it is not specified, CC indicates cc, CXX indicates c++. They are symbolic links to gcc, and g++, respectively by default. Therefore, although you recommend to use clang, clang is not selected and gcc is used by default.

My Linux is Ubuntu 14.04
$ uname -a
Linux neo-work 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Memory leaks in dev branch

During compression:

==32661== 4,096 bytes in 1 blocks are definitely lost in loss record 21 of 22
==32661==    at 0x482E364: malloc (vg_replace_malloc.c:292)
==32661==    by 0x4D8F63F: density_memory_teleport_allocate (memory_teleport.c:40)
==32661==    by 0x4D8FD93: density_stream_create (stream.c:40)
==32661==    by 0x4D8095F: squash_density_create_stream (squash-density.c:213)
==32661==    by 0x486264F: squash_codec_create_stream_with_options (codec.c:507)
==32661==    by 0x4862F4B: squash_codec_process_file_with_options (codec.c:1064)
==32661==    by 0x486308D: squash_codec_compress_file_with_options (codec.c:1137)
==32661==    by 0x9879: main (squash.c:290)
==32661== 
==32661== 262,172 bytes in 1 blocks are possibly lost in loss record 22 of 22
==32661==    at 0x482E364: malloc (vg_replace_malloc.c:292)
==32661==    by 0x4D8F35D: density_encode_init (main_encode.c:87)
==32661==    by 0x4D8FE81: density_stream_compress_init (stream.c:98)
==32661==    by 0x4D805F1: squash_density_process_stream (squash-density.c:406)
==32661==    by 0x4866125: squash_stream_process_internal (stream.c:515)
==32661==    by 0x48662CF: squash_stream_process (stream.c:621)
==32661==    by 0x4862FC5: squash_codec_process_file_with_options (codec.c:1087)
==32661==    by 0x486308D: squash_codec_compress_file_with_options (codec.c:1137)
==32661==    by 0x9879: main (squash.c:290)

And decompression:

==629== 4,096 bytes in 1 blocks are definitely lost in loss record 21 of 21
==629==    at 0x482E364: malloc (vg_replace_malloc.c:292)
==629==    by 0x4D8F63F: density_memory_teleport_allocate (memory_teleport.c:40)
==629==    by 0x4D8FD93: density_stream_create (stream.c:40)
==629==    by 0x4D8095F: squash_density_create_stream (squash-density.c:213)
==629==    by 0x486264F: squash_codec_create_stream_with_options (codec.c:507)
==629==    by 0x4862F4B: squash_codec_process_file_with_options (codec.c:1064)
==629==    by 0x48630B9: squash_codec_decompress_file_with_options (codec.c:1162)
==629==    by 0x988D: main (squash.c:292)

mailing list

might be nice to provide a mailing list so that we can have chats more easily.
Cheers!

Mode reversion support

Issue by gpnuma from Thursday Sep 12, 2013 at 23:38 GMT
Originally opened as https://github.com/centaurean/sharc/issues/15


Enable SHARC to revert to a lower compression mode on the fly when it decides the current one is not performing well enough. As an example, incompressible files should be copied for the most part because in that case the "copying" overhead size is most likely less than the "compressing" one.

add extern "C" to density_api.h

Can we add:

if defined (__cplusplus)

extern "C" {

endif

to density_api.h so that we can use density with C++ applications without having to add this to the file ?

Problems with the density_context by multiple uses

I ran a profiling test which showed that calloc is the top CPU consumer. I saw in density_allocate_context, there is a line:

memset(context->dictionary, 0, context->dictionary_size);

(It turned out that gcc optimized the combination of x=malloc(y) and memset(x,0,y) into single calloc(x) call.)

So the problem was that every time I use the compress or decompress routine, density must clear (1<<16)*(2+1)*4 = 786432 bytes. That is quite a burden for all machines.

I see there is a density_compress_with_context function which seems to allow a pre-allocated context to be used by multiple times, but since the dictionary inside the context has been changed, the output (compressed buffer) cannot be decompressed correctly.

type qualifier on return type is meaningless

Spotted in a Travis build of Squash with ICC:

density/src/kernel_lion_form_model.h(88): error #858: type qualifier on return type is meaningless

  DENSITY_WINDOWS_EXPORT const DENSITY_LION_FORM density_lion_form_model_increment_usage(density_lion_form_data *const, density_lion_form_node *const restrict);

                         ^

FWIW I'm pretty sure this is a warning by default, not an error, but I like to build with -Werror on CI…

Crash in density_memory_teleport_read_reserved

My density plugin is crashing on ARM. I do

density_stream_create (NULL, NULL); // returns 0xb5200640
density_stream_prepare (0xb5200640, 0xb35ff800, 102171, 0xb34fd800, 1048576); // returns 0
density_stream_decompress_continue (0xb5200640);

Density allocates 1024 at 0xb480b980 (memory_teleport.c:37), then tries to memcpy(0xb480b980, 0xb35ff810, 102155).

And I end up with a crash in density_memory_teleport_read_reserved:

==3054==ERROR: AddressSanitizer: unknown-crash on address 0xb480b980 at pc 0xb3ce9445 bp 0xbef2fd88 sp 0xbef2fd8c
WRITE of size 102155 at 0xb480b980 thread T0
    #0 0xb3ce9443 in memcpy /usr/include/arm-linux-gnueabihf/bits/string3.h:51
    #1 0xb3ce9443 in density_memory_teleport_read_reserved /home/nemequ/squash/plugins/density/density/src/memory_teleport.c:132
    #2 0xb3cd155b in density_chameleon_decode_continue /home/nemequ/squash/plugins/density/density/src/kernel_chameleon_decode.c:173
    #3 0xb3cc9ef5 in density_block_decode_continue /home/nemequ/squash/plugins/density/density/src/block_decode.c:218
    #4 0xb3ce6a3b in density_decode_continue /home/nemequ/squash/plugins/density/density/src/main_decode.c:110
    #5 0xb3cf548f in density_stream_decompress_continue /home/nemequ/squash/plugins/density/density/src/stream.c:223
    #6 0xb3cc7781 in squash_density_process_stream /home/nemequ/squash/plugins/density/squash-density.c:369
    #7 0xb6a6a7cb in squash_stream_process_internal /home/nemequ/squash/squash/stream.c:515
    #8 0xb6a6add7 in squash_stream_process /home/nemequ/squash/squash/stream.c:619
    #9 0xb6a5eff9 in squash_codec_process_file_with_options /home/nemequ/squash/squash/codec.c:1087
    #10 0xb6a5f22d in squash_codec_decompress_file_with_options /home/nemequ/squash/squash/codec.c:1162
    #11 0xad71 in main /home/nemequ/squash/utils/squash.c:292
    #12 0xb6966631 in __libc_start_main (/lib/arm-linux-gnueabihf/libc.so.6+0x17631)

0xb480bd80 is located 0 bytes to the right of 1024-byte region [0xb480b980,0xb480bd80)
allocated by thread T0 here:
    #0 0xb6abd343 in __interceptor_malloc (/usr/lib/arm-linux-gnueabihf/libasan.so.1+0x43343)
    #1 0xb3ce7c69 in density_memory_teleport_allocate /home/nemequ/squash/plugins/density/density/src/memory_teleport.c:37
    #2 0xb3cf4809 in density_stream_create /home/nemequ/squash/plugins/density/density/src/stream.c:40
    #3 0xb3cc8d81 in squash_density_stream_init /home/nemequ/squash/plugins/density/squash-density.c:193
    #4 0xb3cc8d81 in squash_density_stream_new /home/nemequ/squash/plugins/density/squash-density.c:179
    #5 0xb3cc8d81 in squash_density_create_stream /home/nemequ/squash/plugins/density/squash-density.c:222
    #6 0xb6a5d20d in squash_codec_create_stream_with_options /home/nemequ/squash/squash/codec.c:507
    #7 0xb6a5ee83 in squash_codec_process_file_with_options /home/nemequ/squash/squash/codec.c:1064
    #8 0xb6a5f22d in squash_codec_decompress_file_with_options /home/nemequ/squash/squash/codec.c:1162
    #9 0xad71 in main /home/nemequ/squash/utils/squash.c:292
    #10 0xb6966631 in __libc_start_main (/lib/arm-linux-gnueabihf/libc.so.6+0x17631)

SUMMARY: AddressSanitizer: unknown-crash /usr/include/arm-linux-gnueabihf/bits/string3.h:51 memcpy
Shadow bytes around the buggy address:
  0x369016e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x369016f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36901700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36901710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36901720: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x36901730:[00]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x36901740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x36901750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x36901760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x36901770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x36901780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==3054==ABORTING

MSVC compiler port

Hi.Very impressive lib,based on the benchmarks I have seen!
I have got a question.What should it take to port this codebase to Microsoft compiler?Besides some compiler specific changes ,are there any special preprocessor defs,( vectorization or asm code) one should be aware of when trying to build with a different compiler than Clang?

Extremely large compiled size

[See http://encode.ru/threads/2313-Brotli?p=45406&viewfull=1#post45406 for more background]

I just checked the sizes of all the Squash plugins, and density is more than thrice the size of the next largest plugin (brotli):

3.3M density/libsquash0.8-plugin-density.so
780K brotli/libsquash0.8-plugin-brotli.so
296K lzham/libsquash0.8-plugin-lzham.so
284K zpaq/libsquash0.8-plugin-zpaq.so
276K lzo/libsquash0.8-plugin-lzo.so
228K bsc/libsquash0.8-plugin-bsc.so
212K lzma/libsquash0.8-plugin-lzma.so
116K zlib/libsquash0.8-plugin-zlib.so
112K lz4/libsquash0.8-plugin-lz4.so
112K zstd/libsquash0.8-plugin-zstd.so
 96K zlib-ng/libsquash0.8-plugin-zlib-ng.so
 92K bzip2/libsquash0.8-plugin-bzip2.so
 76K gipfeli/libsquash0.8-plugin-gipfeli.so
 72K ms-compress/libsquash0.8-plugin-ms-compress.so
 56K zling/libsquash0.8-plugin-zling.so
 48K snappy/libsquash0.8-plugin-snappy.so
 24K yalz77/libsquash0.8-plugin-yalz77.so
 24K wflz/libsquash0.8-plugin-wflz.so
 24K heatshrink/libsquash0.8-plugin-heatshrink.so
 24K fastlz/libsquash0.8-plugin-fastlz.so
 20K lzg/libsquash0.8-plugin-lzg.so
 20K crush/libsquash0.8-plugin-crush.so
 20K pithy/libsquash0.8-plugin-pithy.so
 20K lzf/libsquash0.8-plugin-lzf.so
 20K ncompress/libsquash0.8-plugin-ncompress.so
 16K quicklz/libsquash0.8-plugin-quicklz.so
 16K brieflz/libsquash0.8-plugin-brieflz.so
 16K fari/libsquash0.8-plugin-fari.so
 16K lzjb/libsquash0.8-plugin-lzjb.so
 12K copy/libsquash0.8-plugin-copy.so

I haven't done any research, but I'm pretty confident the massive amount of inlining is to blame. Perhaps it may be time to take a serious look at which plugins really need to be inlined and which don't; this might even improve performance since more of the code could fit in the CPU cache.

One idea could also be a two-level system, where if someone defines something in the preprocessor density becomes a bit more conservative in what it inlines (e.g., have DENSITY_INLINE and DENSITY_ALWAYS_INLINE, and define the former as "" if DENSITY_DONT_ALWAYS_INLINE is defined). In this case, you could also add __attribute__((__hot__)) (for GCC at least, other compilers may have something similar) to DENSITY_ALWAYS_INLINE.

Performance drop on low end / mobile architectures

Issue by gpnuma from Tuesday Aug 13, 2013 at 22:33 GMT
Originally opened as https://github.com/centaurean/sharc/issues/10


According to these benchmarks from @nemequ (https://github.com/quixdb/squash) :
http://quixdb.github.io/squash/benchmarks/core-i5-2400.html#enwik8
http://quixdb.github.io/squash/benchmarks/atom-d525.html#enwik8
SHARC seems to have a significant performance drop in comparison with other algorithms on the Atom platform, while being way ahead in compression speed on an Intel Core i5.

Conditional jump or move depends on uninitialised value(s)

I'm having trouble getting a squash plugin working because it keeps segfaulting. My backtrace is similar enough to what I see from valgrind when running sharc that I think it's the same issue. valgrind:

nemequ@hoplite:~/local/src/sharc/src$ valgrind --tool=memcheck ./sharc -c1 iliad
==8985== Memcheck, a memory error detector
==8985== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8985== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==8985== Command: ./sharc -c1 iliad
==8985== 
==8985== Conditional jump or move depends on uninitialised value(s)
==8985==    at 0x40258E: ssc_block_encode_finish (block_encode.c:226)
==8985==    by 0x409732: ssc_encode_finish (main_encode.c:200)
==8985==    by 0x409EDB: ssc_stream_compress_finish (stream.c:150)
==8985==    by 0x412D22: main (client.c:197)
==8985== 
==8985== Conditional jump or move depends on uninitialised value(s)
==8985==    at 0x4A0752A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8985==    by 0x409745: ssc_encode_finish (main_encode.c:201)
==8985==    by 0x409EDB: ssc_stream_compress_finish (stream.c:150)
==8985==    by 0x412D22: main (client.c:197)
==8985== 
Compressed iliad (1,308,638 bytes) to iliad.sharc (776,904 bytes), Ratio out / in = 59.4%, Time = 0.417 s, Speed = 3 MB/s
==8985== 
==8985== HEAP SUMMARY:
==8985==     in use at exit: 504 bytes in 1 blocks
==8985==   total heap usage: 5 allocs, 4 frees, 263,896 bytes allocated
==8985== 
==8985== LEAK SUMMARY:
==8985==    definitely lost: 504 bytes in 1 blocks
==8985==    indirectly lost: 0 bytes in 0 blocks
==8985==      possibly lost: 0 bytes in 0 blocks
==8985==    still reachable: 0 bytes in 0 blocks
==8985==         suppressed: 0 bytes in 0 blocks
==8985== Rerun with --leak-check=full to see details of leaked memory
==8985== 
==8985== For counts of detected and suppressed errors, rerun with: -v
==8985== Use --track-origins=yes to see where uninitialised values come from
==8985== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)

FWIW, here is my backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x637561206973696e) at malloc.c:2892
2892      if (chunk_is_mmapped(p))                       /* release mmapped memory. */
(gdb) bt
#0  __GI___libc_free (mem=0x637561206973696e) at malloc.c:2892
#1  0x00007ffff6106665 in ssc_encode_finish (out=0x620770, state=0x6207d0) at /home/nemequ/local/src/squash/plugins/ssc/libssc/src/main_encode.c:201
#2  0x00007ffff6106aa1 in ssc_stream_compress_finish (stream=0x620750) at /home/nemequ/local/src/squash/plugins/ssc/libssc/src/stream.c:150
#3  0x00007ffff6102c17 in squash_ssc_process_stream_compress (operation=SQUASH_SSC_OPERATION_FINISH, stream=0x6204b0)
    at /home/nemequ/local/src/squash/plugins/ssc/squash-ssc.c:325
#4  squash_ssc_process_stream_internal (operation=SQUASH_SSC_OPERATION_FINISH, stream=0x6204b0)
    at /home/nemequ/local/src/squash/plugins/ssc/squash-ssc.c:491
#5  squash_ssc_finish_stream (stream=0x6204b0) at /home/nemequ/local/src/squash/plugins/ssc/squash-ssc.c:517
#6  0x00007ffff7df729b in squash_stream_finish (stream=0x6204b0) at /home/nemequ/local/src/squash/squash/stream.c:474
#7  0x00007ffff7df172b in squash_codec_compress_with_options (codec=0x619250, compressed=0x6224e0 "", compressed_length=0x7fffffffdba0, 
    uncompressed=0x4018c8 "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed vulputate lectus nisl, vitae ultricies justo dictum nec. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia C"..., uncompressed_length=2725, options=0x0)
    at /home/nemequ/local/src/squash/squash/codec.c:529
#8  0x0000000000401640 in check_codec (codec=0x619250) at /home/nemequ/local/src/squash/tests/buffer.c:11
#9  0x0000003bbf26d5a1 in test_case_run (tc=0x611cf0) at gtestutils.c:2067
#10 g_test_run_suite_internal (suite=suite@entry=0x610a80, path=path@entry=0x3bbf2e369e "") at gtestutils.c:2127
#11 0x0000003bbf26d766 in g_test_run_suite_internal (suite=suite@entry=0x610480, path=path@entry=0x3bbf2e369e "") at gtestutils.c:2138
#12 0x0000003bbf26d766 in g_test_run_suite_internal (suite=suite@entry=0x610460, path=path@entry=0x3bbf2e369e "") at gtestutils.c:2138
#13 0x0000003bbf26dadb in g_test_run_suite (suite=0x610460) at gtestutils.c:2189
#14 0x00000000004015d0 in main (argc=1, argv=0x7fffffffe038) at /home/nemequ/local/src/squash/tests/test-codecs.c:80

I can post the code if it would help, but it's a bit of a mess right now because of all the stuff I tried to fix this before realizing the issue can be reproduced by sharc, too (although it doesn't segfault, but that may just be luck).

Update spookyhash

I get a bunch of "incompatible implicit declaration of built-in function ‘memset’" warnings—it would be great to get rid of those so I can add -Werror to CI.

provide test(s)

Hi!

I am trying to compile density cross platform using cmake and it does compile with minor modifications. however I am missing some tests which ensure the validity of you library. If you had at least one which you could commit (simple program which returns 0 or 1 depending on test outcome and is cross platform)

Questions to my changes:

Could you tell me if the includes utime.h and unistd.h are really required? because there does not seem to be a detrimental effect if I comment them out and MSVC does not support them.

Another Question: the structs density_block_header and density_main_footer are empty which causes the compile error C2016 on MSVC. A quick fix for me was to insert a short dummy variable however I do not know the consequences of that action.

I am not really in any hurry here as I am just trying to build you lib with cmake (as an experiment) and I currently do not plan to use it. However if everything works I can create a pull request for the cmake build. (you can see it at https://github.com/toeb/density)

Cheers

Tobi

Fallback to 1-bit tags for selected blocks

There are two algorithms in SHARC:

  • one with 1-bit tags which is faster and usually compress worse,
  • one with 2-bit tags which is slower and usually compress better,

The issue is that not every time the second one compresses better and that is due to the fact that overhead the tags are causing is not always offseted by reduction of other parts of compressed stream.

An example is on Silesia corpus: http://mattmahoney.net/dc/silesia.html - file 'sao'

My proposal is to do fallback to 1-bit tags when we detect that 2-bit tags cause too much overhead causing compression ratio deterioration.

How to detect if 2-bit tags do too much overhead?
One solution would be to compress each block twice - once with 1-bit tags and once with 2-bit tags, but that would be detrimental to compression speed. So a better solution would be to prepare a histogram of tags. Since in 2-bit tags mode there are only 4 different tag values it shouldn't bring too much speed overhead to compute the histogram. Once computed you can do simulation of what would happen if you do compression with 1-bit tags. Since it seems it couldn't be done exactly and super quickly, an probabilistic method should be used. You can eg assume that:

  • repetition would be coded as match 90% of time and as literals 10% of time (values to be tuned),
  • match to first slot in dictionary would be coded as match 95% of the time and as literals 5% of the time (that values also should be tuned),
  • match to second slot in dictionary would be coded as literals (always),
    That way you could estimate the compressed size in 1-bit tags mode very quickly from the histogram.

How to do switching between 1-bit tags mode and 2-bit tags mode?
I think both modes should share the dictionaries. For example the 1-bit tags mode could use the first slots from dictionary and also update (but don't use) the prediction array. Or use the second slots only and don't touch the prediction array. Or use only first slots from dictionary for doing matches but update both slots as in 2-bit tags mode. Or some other combination. It should be manually tested which solution is the best.
Another thing is that for fallback we would need to do some sort of backup of dictionaries on every block boundary. I think that with big enough blocks and use of some special instruction that don't pollute caches it could be pretty fast. Or do something different - don't do backups unless we detected that the last block could've been compressed better in 1-bit tags mode and stop doing backups when in two blocks in a row the 1-bit tags mode doesn't bring improvement.

Enhanced windows support

Use cmake to build density, favoring clang as the preferred compiler
Add the required __declspec(dllexport) to link on windows

Issues when using density inside the Blosc meta-compressor

Hi, I am trying to add support for DENSITY into the Blosc meta-compressor. So, right now, my attempt lives here: https://github.com/FrancescAlted/c-blosc/tree/density, and in particular, you can see how DENSITY is called here: https://github.com/FrancescAlted/c-blosc/blob/density/blosc/blosc.c#L504

However, I am running into issues when selecting the DENSITY codec:

$ bench/bench density
Blosc version: 1.7.0.dev ($Date:: 2015-05-27 #$)
List of supported compressors in this build: blosclz,lz4,lz4hc,snappy,zlib,density
Supported compression libraries:
  BloscLZ: 1.0.5
  LZ4: 1.7.0
  Snappy: 1.1.1
  Zlib: 1.2.8
  DENSITY: 0.12.5
Using compressor: density
Running suite: single
--> 4, 2097152, 8, 19, density
********************** Run info ******************************
Blosc version: 1.7.0.dev ($Date:: 2015-05-27 #$)
Using synthetic data with 19 significant bits (out of 32)
Dataset size: 2097152 bytes     Type size: 8 bytes
Working set: 256.0 MB           Number of threads: 4
********************** Running benchmarks *********************
memcpy(write):            515.7 us, 3878.2 MB/s
memcpy(read):             247.1 us, 8095.3 MB/s
Compression level: 0
comp(write):      339.5 us, 5890.4 MB/s   Final bytes: 2097168  Ratio: 1.00
decomp(read):     252.4 us, 7925.2 MB/s   OK
Compression level: 1
comp(write):     13871.5 us, 144.2 MB/s   Final bytes: 1204240  Ratio: 1.74
decomp(read):     143.1 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 2
comp(write):     10653.2 us, 187.7 MB/s   Final bytes: 1204240  Ratio: 1.74
decomp(read):     230.5 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 3
comp(write):     10549.5 us, 189.6 MB/s   Final bytes: 1204240  Ratio: 1.74
decomp(read):     149.4 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 4
comp(write):     7510.8 us, 266.3 MB/s    Final bytes: 1159184  Ratio: 1.81
decomp(read):     143.1 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 5
comp(write):     5459.7 us, 366.3 MB/s    Final bytes: 1159184  Ratio: 1.81
decomp(read):     149.7 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 6
comp(write):     3324.9 us, 601.5 MB/s    Final bytes: 1136656  Ratio: 1.85
decomp(read):     148.9 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 7
comp(write):     2294.0 us, 871.8 MB/s    Final bytes: 1125520  Ratio: 1.86
decomp(read):     152.4 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 8
comp(write):     2570.4 us, 778.1 MB/s    Final bytes: 1125520  Ratio: 1.86
decomp(read):     174.4 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 9
comp(write):     1798.7 us, 1111.9 MB/s   Final bytes: 1119824  Ratio: 1.87
decomp(read):     252.0 us, -0.0 MB/s     FAILED.  Error code: -1
OK

Round-trip compr/decompr on 7.5 GB
Elapsed time:      23.4 s, 721.2 MB/s

The above is with 'master' branch (refreshed some minutes ago). With the 'dev' of DENSITY, I get somewhat better results:

$ bench/bench density
Blosc version: 1.7.0.dev ($Date:: 2015-05-27 #$)
List of supported compressors in this build: blosclz,lz4,lz4hc,snappy,zlib,density
Supported compression libraries:
  BloscLZ: 1.0.5
  LZ4: 1.7.0
  Snappy: 1.1.1
  Zlib: 1.2.8
  DENSITY: 0.12.5
Using compressor: density
Running suite: single
--> 4, 2097152, 8, 19, density
********************** Run info ******************************
Blosc version: 1.7.0.dev ($Date:: 2015-05-27 #$)
Using synthetic data with 19 significant bits (out of 32)
Dataset size: 2097152 bytes     Type size: 8 bytes
Working set: 256.0 MB           Number of threads: 4
********************** Running benchmarks *********************
memcpy(write):            511.3 us, 3911.4 MB/s
memcpy(read):             246.3 us, 8121.1 MB/s
Compression level: 0
comp(write):      282.7 us, 7074.0 MB/s   Final bytes: 2097168  Ratio: 1.00
decomp(read):     213.6 us, 9365.2 MB/s   OK
Compression level: 1
comp(write):     10286.4 us, 194.4 MB/s   Final bytes: 1206288  Ratio: 1.74
decomp(read):    10408.2 us, 192.2 MB/s   OK
Compression level: 2
comp(write):     10418.7 us, 192.0 MB/s   Final bytes: 1206288  Ratio: 1.74
decomp(read):    11595.9 us, 172.5 MB/s   OK
Compression level: 3
comp(write):     10521.3 us, 190.1 MB/s   Final bytes: 1206288  Ratio: 1.74
decomp(read):    10770.5 us, 185.7 MB/s   OK
Compression level: 4
comp(write):     5685.5 us, 351.8 MB/s    Final bytes: 1160208  Ratio: 1.81
decomp(read):    6010.8 us, 332.7 MB/s    OK
Compression level: 5
comp(write):     5879.1 us, 340.2 MB/s    Final bytes: 1160208  Ratio: 1.81
decomp(read):    6056.7 us, 330.2 MB/s    OK
Compression level: 6
comp(write):     3476.0 us, 575.4 MB/s    Final bytes: 1137168  Ratio: 1.84
decomp(read):    3381.0 us, 591.5 MB/s    OK
Compression level: 7
comp(write):     2396.0 us, 834.7 MB/s    Final bytes: 1125776  Ratio: 1.86
decomp(read):     194.8 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 8
comp(write):     2266.4 us, 882.5 MB/s    Final bytes: 1125776  Ratio: 1.86
decomp(read):     164.7 us, -0.0 MB/s     FAILED.  Error code: -1
OK
Compression level: 9
comp(write):     2056.3 us, 972.6 MB/s    Final bytes: 1119952  Ratio: 1.87
decomp(read):    1559.9 us, 1282.1 MB/s   OK

Round-trip compr/decompr on 7.5 GB
Elapsed time:      40.1 s, 421.2 MB/s

So, I suppose DENSITY is still in beta, but please consider c-blosc as a another testing bench. Second, I wonder why the speed is so low. For example, by using the LZ4 codec I am getting this:

$ bench/bench lz4
Blosc version: 1.7.0.dev ($Date:: 2015-05-27 #$)
List of supported compressors in this build: blosclz,lz4,lz4hc,snappy,zlib,density
Supported compression libraries:
  BloscLZ: 1.0.5
  LZ4: 1.7.0
  Snappy: 1.1.1
  Zlib: 1.2.8
  DENSITY: 0.12.5
Using compressor: lz4
Running suite: single
--> 4, 2097152, 8, 19, lz4
********************** Run info ******************************
Blosc version: 1.7.0.dev ($Date:: 2015-05-27 #$)
Using synthetic data with 19 significant bits (out of 32)
Dataset size: 2097152 bytes     Type size: 8 bytes
Working set: 256.0 MB           Number of threads: 4
********************** Running benchmarks *********************
memcpy(write):            536.8 us, 3725.7 MB/s
memcpy(read):             250.7 us, 7978.5 MB/s
Compression level: 0
comp(write):      328.2 us, 6093.7 MB/s   Final bytes: 2097168  Ratio: 1.00
decomp(read):     244.8 us, 8170.1 MB/s   OK
Compression level: 1
comp(write):      499.4 us, 4005.2 MB/s   Final bytes: 554512  Ratio: 3.78
decomp(read):     268.6 us, 7445.3 MB/s   OK
Compression level: 2
comp(write):      472.6 us, 4231.5 MB/s   Final bytes: 498960  Ratio: 4.20
decomp(read):     278.4 us, 7184.0 MB/s   OK
Compression level: 3
comp(write):      449.4 us, 4450.4 MB/s   Final bytes: 520824  Ratio: 4.03
decomp(read):     323.2 us, 6188.7 MB/s   OK
Compression level: 4
comp(write):      440.6 us, 4539.6 MB/s   Final bytes: 332112  Ratio: 6.31
decomp(read):     321.1 us, 6227.8 MB/s   OK
Compression level: 5
comp(write):      421.8 us, 4741.8 MB/s   Final bytes: 327112  Ratio: 6.41
decomp(read):     309.7 us, 6458.5 MB/s   OK
Compression level: 6
comp(write):      465.4 us, 4297.5 MB/s   Final bytes: 226308  Ratio: 9.27
decomp(read):     395.4 us, 5058.2 MB/s   OK
Compression level: 7
comp(write):      631.9 us, 3165.3 MB/s   Final bytes: 211880  Ratio: 9.90
decomp(read):     564.4 us, 3543.5 MB/s   OK
Compression level: 8
comp(write):      602.6 us, 3318.9 MB/s   Final bytes: 220464  Ratio: 9.51
decomp(read):     568.9 us, 3515.8 MB/s   OK
Compression level: 9
comp(write):      645.2 us, 3099.9 MB/s   Final bytes: 132154  Ratio: 15.87
decomp(read):     694.6 us, 2879.3 MB/s   OK

Round-trip compr/decompr on 7.5 GB
Elapsed time:       3.8 s, 4497.0 MB/s

which is roughly 10x faster.

In case you want to experiment by yourself, the support for DENSITY in c-blosc is via a shared library for now (requiring C99 is not supported right now in c-blosc because it has to have support for other codecs that are non-C99 compliant code). So, in case the shared libraries for DENSITY are installed in the system (say /usr/local/lib and /usr/local/include for headers), here it is how to compile c-blosc:

$ mkdir build
$ cd build
$ CC="clang-3.5" CXX="clang++-3.5" CFLAGS="-O3" cmake ..
$ CC="clang-3.5" CXX="clang++-3.5" CFLAGS="-O3" make
$ bench/bench density    # bench executable ready to be used

Thanks!

Mode reversion support

Enable SHARC to revert to a lower compression mode on the fly when it decides the current one is not performing well enough. As an example, incompressible files should be copied for the most part because in that case the "copying" overhead size is most likely less than the "compressing" one.

Decompression error with dev branch

Quoting @191919 :

@gpnuma

My compiler:

$ clang -v
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

It is the decompression routine that crashed, not the compression routine.

My test code is simple:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "density/density_api.h" 

int main() {
	uint8_t *cbuf = malloc(100000);
	uint8_t *dbuf = malloc(100000);
	FILE* fp = fopen("1.buf", "rb");
	fread(cbuf, 1, 22520, fp);
	fclose(fp);

	density_decompress(cbuf, 22520, dbuf, density_decompress_safe_size(65536));
	return 0;
}

Compiled with:

$ cc -O0 -g -o 1 1.c density/*.c

Then

$ lldb ./1
(lldb) target create "./1"
Current executable set to './1' (x86_64).
(lldb) r
Process 8868 launched: './1' (x86_64)
Process 8868 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1007ffff0)
    frame #0: 0x00007fff7b93b620 libsystem_platform.dylib`_platform_memmove$VARIANT$Nehalem + 544
libsystem_platform.dylib`_platform_memmove$VARIANT$Nehalem:
->  0x7fff7b93b620 <+544>: movaps xmm4, xmmword ptr [rsi - 0x40]
    0x7fff7b93b624 <+548>: sub    rsi, 0x40
    0x7fff7b93b628 <+552>: sub    rdx, 0x40
    0x7fff7b93b62c <+556>: ja     0x7fff7b93b600            ; <+512>
Target 0: (1) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1007ffff0)
  * frame #0: 0x00007fff7b93b620 libsystem_platform.dylib`_platform_memmove$VARIANT$Nehalem + 544
    frame #1: 0x0000000100013ea1 1`density_chameleon_decode(state=0x00007ffeefbff828, in=0x00007ffeefbff848, in_size=22512, out=0x00007ffeefbff840, out_size=65792) at chameleon_decode.c:208
    frame #2: 0x00000001000011a0 1`density_decompress_with_context(input_buffer="", input_size=22512, output_buffer="", output_size=65792, context=0x00000001002001f0) at buffer.c:180
    frame #3: 0x000000010000148f 1`density_decompress(input_buffer="", input_size=22520, output_buffer="", output_size=65792) at buffer.c:207
    frame #4: 0x000000010000071c 1`main at 1.c:14
    frame #5: 0x00007fff7b6ba115 libdyld.dylib`start + 1

(BTW, you can see why the flattening of directory hierarchy is so helpful either in command line or a Makefile.)

Cannot decompress to a buffer exactly the right size

#define LOREM_IPSUM                                                     \
  "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed vulputate " \
  "lectus nisl, vitae ultricies justo dictum nec. Vestibulum ante ipsum " \
  "primis in faucibus orci luctus et ultrices posuere cubilia Curae; "  \
  "Suspendisse suscipit quam a lectus adipiscing, sed tempor purus "    \
  "cursus. Vivamus id nulla eget elit eleifend molestie. Integer "      \
  "sollicitudin lorem enim, eu eleifend orci facilisis sed. Pellentesque " \
  "sodales luctus enim vel viverra. Cras interdum vel nisl in "         \
  "facilisis. Curabitur sollicitudin tortor vel congue "                \
  "auctor. Suspendisse egestas orci vitae neque placerat blandit.\n"    \
  "\n"                                                                  \
  "Aenean sed nisl ultricies, vulputate lorem a, suscipit nulla. Donec " \
  "egestas volutpat neque a eleifend. Nullam porta semper "             \
  "nunc. Pellentesque adipiscing molestie magna, quis pulvinar metus "  \
  "gravida sit amet. Vestibulum mollis et sapien eu posuere. Quisque "  \
  "tristique dignissim ante et aliquet. Phasellus vulputate condimentum " \
  "nulla in vulputate.\n"                                               \
  "\n"                                                                  \
  "Nullam volutpat tellus at nisi auctor, vitae mattis nibh viverra. Nunc " \
  "vitae lectus tristique, ultrices nibh quis, lobortis elit. Curabitur " \
  "at vestibulum nisi, nec facilisis ante. Nulla pharetra blandit lacus, " \
  "at sodales nulla placerat eget. Nulla congue varius tortor, sit amet " \
  "tempor est mattis nec. Praesent vitae tristique ipsum, rhoncus "     \
  "tristique lorem. Sed et erat tristique ligula accumsan fringilla eu in " \
  "urna. Donec dapibus hendrerit neque nec venenatis. In euismod sapien " \
  "ipsum, auctor consectetur mi dapibus hendrerit.\n"                   \
  "\n"                                                                  \
  "Phasellus sagittis rutrum velit, in sodales nibh imperdiet a. Integer " \
  "vitae arcu blandit nibh laoreet scelerisque eu sit amet eros. Aenean " \
  "odio felis, aliquam in eros at, ornare luctus magna. In semper "     \
  "tincidunt nunc, sollicitudin gravida nunc laoreet eu. Cras eu tempor " \
  "sapien, ut dignissim elit. Proin eleifend arcu tempus, semper erat et, " \
  "accumsan erat. Praesent vulputate diam mi, eget mollis leo "         \
  "pellentesque eget. Aliquam eu tortor posuere, posuere velit sed, "   \
  "suscipit eros. Nam eu leo vitae mauris condimentum lobortis non quis " \
  "mauris. Nulla venenatis fringilla urna nec venenatis. Nam eget velit " \
  "nulla. Proin ut malesuada felis. Suspendisse vitae nunc neque. Donec " \
  "faucibus tempor lacinia. Vivamus ac vulputate sapien, eget lacinia " \
  "nisl.\n"                                                             \
  "\n"                                                                  \
  "Curabitur eu dolor molestie, ullamcorper lorem quis, egestas "       \
  "urna. Suspendisse in arcu sed justo blandit condimentum. Ut auctor, " \
  "sem quis condimentum mattis, est purus pulvinar elit, quis viverra " \
  "nibh metus ac diam. Etiam aliquet est eu dui fermentum consequat. Cras " \
  "auctor diam eget bibendum sagittis. Aenean elementum purus sit amet " \
  "sem euismod, non varius felis dictum. Aliquam tempus pharetra ante a " \
  "sagittis. Curabitur ut urna felis. Etiam sed vulputate nisi. Praesent " \
  "at libero eleifend, sagittis quam a, varius sapien."
#define LOREM_IPSUM_LENGTH 2725

#include <assert.h>
#include <stddef.h>

#include "src/density_api.h"

int main(int argc, char *argv[]) {
  uint8_t compressed[4096];
  size_t compressed_length = sizeof(compressed);
  uint8_t decompressed[LOREM_IPSUM_LENGTH];
  size_t decompressed_length = sizeof(decompressed);
  density_buffer_processing_result res;

  res = density_buffer_compress (LOREM_IPSUM, LOREM_IPSUM_LENGTH,
                                 compressed, compressed_length,
                                 DENSITY_COMPRESSION_MODE_CHAMELEON_ALGORITHM, DENSITY_BLOCK_TYPE_DEFAULT,
                                 NULL, NULL);

  assert (res.state == DENSITY_BUFFER_STATE_OK);

  compressed_length = res.bytesWritten;

  res = density_buffer_decompress (compressed, compressed_length,
                                   decompressed, decompressed_length,
                                   NULL, NULL);

  assert (res.state == DENSITY_BUFFER_STATE_OK);
  assert (res.bytesWritten == LOREM_IPSUM_LENGTH);
  assert (memcmp (decompressed, LOREM_IPSUM, LOREM_IPSUM_LENGTH) == 0);

  return 0;
}

Windows compilation

compilation fails with message
Linking benchmark obj/Release/benchmark/benchmark.o : fatal error LNK1107: invalid or corrupt file: cannot read at 0x4B70 clang.exe: error: linker command failed with exit code 1107 (use -v to see invocation) make[1]: *** [bin/Release/benchmark.exe] Fehler 83 make: *** [benchmark] Fehler 2

Allow use of external dictionary

Right now, density adds (I believe) 16 bytes of header data to each block of compressed data. For larger pieces of data this obviously isn't much of an issue and, while for most cases it's nice to have this information with each piece of data, there are applications where 16 bytes is a lot of data.

For example, one use case I'm interested in is compressing small pieces of data, such as rows (or cells) in a database, a blob of JSON/protobuf/thrift data, etc. In such cases, it would be preferable to communicate everything you can out of band in order to reduce duplication. In the case of a database, this information could be stored once per database instead of once per row/cell. In other cases it could be hard-coded per application.

I don't think the stream API would be very useful for such use cases, but if there is a good way to expose a simple buffer API for this sort of thing, I think there could be a market for it. I think this would just require a simple function which just uses DENSITY_ENCODE_OUTPUT_TYPE_WITHOUT_HEADER_NOR_FOOTER, in which case I'll add codecs to Squash for this, but given how simple (I think) it is, I thought you might be interested in including it in density, too.

Improve efficiency for small files

It takes a certain amount of data for density's algorithms to be running optimally (ratio wise).
Adding an intermediary processing could be interesting before routing data to the bigger and faster algorithms.
It would also enable preparation of the main algorithm's data structures, while ensuring a good compression ratio immediately thus greatly benefiting smaller files.
As a side effect, #10 would be probably unnecessary as the compression process would be instantly efficient.

Checksum-style data verification

Issue by gpnuma from Monday Sep 02, 2013 at 00:43 GMT
Originally opened as https://github.com/centaurean/sharc/issues/13


Add a checksum-style data verification system in the byte format. Design a very fast data checksumming algorithm (at least 10-20 times faster than the compression algorithm so it has a negligible impact on performance).
It would enable the algorithm to stop decompression, for example, as soon as invalid data is detected. It would also enable a fast "validity check" of a compressed file.
The question mark is due to the fact that although this looks like a good idea, some important use cases could be needed before implementing any "performance-impacting" modifications.

MSFT build ?

Does density build with Microsoft VS ?
I see:

if !defined(clang) && !defined(GNUC)

error Unsupported compiler.

endif

but then many checks for _WIN ...

change include paths for spookyhash files

Can we change the include paths for spookyhash includes in

block_encode.h
block_decode.h

to not have the hardcoded

spookyhash/src

directory ? We can add to the compiler -I path to find these files. This makes for adding density to an existing application easier as we do not have to edit the files for each new release.

Diffucult to use as submodule for build systems other than make and autotools

It's currently a pain to use libssc as a submodule with build systems other than simple makefiles since there is magic for building 1p/2p versions of some files. If you want to push people to use the shared library I think this issue can be ignored, but I don't think you do.

FWIW, this is causing problems for squash (which uses CMake), but similar issues should pop up for virtually every build system other than simple makefiles (or autotools). Basically, people will have to re-implement that logic in whatever build system they're using (scons, waf, nmake, etc., as well as IDE-specific stuff like Visual Studio project files, xcode, etc. The CMake documentation lists a subset of the possibilities).

Warning about density_lion_decode_bitmasks

kernel_lion_decode.c:90:47: warning: ‘density_lion_decode_bitmasks’ is static but used in inline function ‘density_lion_decode_read_4bits_from_signature’ which is not static
                 result |= (state->signature & density_lion_decode_bitmasks[overflowBits]) << (density_bitsizeof(density_lion_signature) - state->shift);   // Add bits from the new signature
                                               ^

Unaligned stores/loads

ubsan detects a lot of undefined stores/loads:

/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff52 for type 'density_byte', which requires 4 byte alignment
0x00000206ff52: note: pointer points here
 69 70  0e 3f 39 90 98 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  01 00 00 00 06 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff56 for type 'density_byte', which requires 4 byte alignment
0x00000206ff56: note: pointer points here
 70 72 69 6d 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  01 00 00 00 06 00 00 00  04 00
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff5a for type 'density_byte', which requires 4 byte alignment
0x00000206ff5a: note: pointer points here
 69 73  20 69 00 00 00 00 00 00  00 00 00 00 00 00 00 00  01 00 00 00 06 00 00 00  04 00 00 00 04 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff5e for type 'density_byte', which requires 4 byte alignment
0x00000206ff5e: note: pointer points here
 6e 20 66 61 00 00  00 00 00 00 00 00 00 00  01 00 00 00 06 00 00 00  04 00 00 00 04 00 00 00  00 00
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff62 for type 'density_byte', which requires 4 byte alignment
0x00000206ff62: note: pointer points here
 75 63  69 62 00 00 00 00 00 00  01 00 00 00 06 00 00 00  04 00 00 00 04 00 00 00  00 00 00 00 b7 73
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff66 for type 'density_byte', which requires 4 byte alignment
0x00000206ff66: note: pointer points here
 75 73 20 6f 00 00  01 00 00 00 06 00 00 00  04 00 00 00 04 00 00 00  00 00 00 00 b7 73 e4 b2  00 00
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff6a for type 'density_byte', which requires 4 byte alignment
0x00000206ff6a: note: pointer points here
 72 63  69 20 00 00 06 00 00 00  04 00 00 00 04 00 00 00  00 00 00 00 b7 73 e4 b2  00 00 00 00 00 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff6e for type 'density_byte', which requires 4 byte alignment
0x00000206ff6e: note: pointer points here
 6c 75 63 74 00 00  04 00 00 00 04 00 00 00  00 00 00 00 b7 73 e4 b2  00 00 00 00 00 00 00 00  00 00
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000206ff72 for type 'density_byte', which requires 4 byte alignment
0x00000206ff72: note: pointer points here
 75 73  20 65 00 00 04 00 00 00  00 00 00 00 b7 73 e4 b2  00 00 00 00 00 00 00 00  00 00 00 00 00 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207007a for type 'density_byte', which requires 4 byte alignment
0x00000207007a: note: pointer points here
 76 65  72 72 00 00 00 00 00 00  c8 41 73 90 98 7f 00 00  c8 41 73 90 98 7f 00 00  70 00 07 02 00 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207007e for type 'density_byte', which requires 4 byte alignment
0x00000207007e: note: pointer points here
 61 2e 20 43 00 00  c8 41 73 90 98 7f 00 00  c8 41 73 90 98 7f 00 00  70 00 07 02 00 00 00 00  70 00
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x000002070082 for type 'density_byte', which requires 4 byte alignment
0x000002070082: note: pointer points here
 72 61  73 20 73 90 98 7f 00 00  c8 41 73 90 98 7f 00 00  70 00 07 02 00 00 00 00  70 00 07 02 00 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x000002070086 for type 'density_byte', which requires 4 byte alignment
0x000002070086: note: pointer points here
 69 6e 74 65 00 00  c8 41 73 90 98 7f 00 00  70 00 07 02 00 00 00 00  70 00 07 02 00 00 00 00  79 e9
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207008a for type 'density_byte', which requires 4 byte alignment
0x00000207008a: note: pointer points here
 72 64  75 6d 73 90 98 7f 00 00  70 00 07 02 00 00 00 00  70 00 07 02 00 00 00 00  79 e9 0d a3 75 c0
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207008e for type 'density_byte', which requires 4 byte alignment
0x00000207008e: note: pointer points here
 20 76 65 6c 00 00  70 00 07 02 00 00 00 00  70 00 07 02 00 00 00 00  79 e9 0d a3 75 c0 8d d4  84 f2
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x000002070092 for type 'density_byte', which requires 4 byte alignment
0x000002070092: note: pointer points here
 20 6e  69 73 07 02 00 00 00 00  70 00 07 02 00 00 00 00  79 e9 0d a3 75 c0 8d d4  84 f2 35 bf 79 df
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x000002070096 for type 'density_byte', which requires 4 byte alignment
0x000002070096: note: pointer points here
 6c 20 69 6e 00 00  70 00 07 02 00 00 00 00  79 e9 0d a3 75 c0 8d d4  84 f2 35 bf 79 df a2 f6  3d 5e
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207009a for type 'density_byte', which requires 4 byte alignment
0x00000207009a: note: pointer points here
 20 66  61 63 07 02 00 00 00 00  79 e9 0d a3 75 c0 8d d4  84 f2 35 bf 79 df a2 f6  3d 5e 6a cc 51 da
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207009e for type 'density_byte', which requires 4 byte alignment
0x00000207009e: note: pointer points here
 69 6c 69 73 00 00  79 e9 0d a3 75 c0 8d d4  84 f2 35 bf 79 df a2 f6  3d 5e 6a cc 51 da 51 c3  9f 56
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700a2 for type 'density_byte', which requires 4 byte alignment
0x0000020700a2: note: pointer points here
 69 73  2e 20 0d a3 75 c0 8d d4  84 f2 35 bf 79 df a2 f6  3d 5e 6a cc 51 da 51 c3  9f 56 07 7d 4b 00
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700a6 for type 'density_byte', which requires 4 byte alignment
0x0000020700a6: note: pointer points here
 43 75 72 61 8d d4  84 f2 35 bf 79 df a2 f6  3d 5e 6a cc 51 da 51 c3  9f 56 07 7d 4b 00 2d 06  b6 78
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700aa for type 'density_byte', which requires 4 byte alignment
0x0000020700aa: note: pointer points here
 62 69  74 75 35 bf 79 df a2 f6  3d 5e 6a cc 51 da 51 c3  9f 56 07 7d 4b 00 2d 06  b6 78 64 8b d2 e2
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700ae for type 'density_byte', which requires 4 byte alignment
0x0000020700ae: note: pointer points here
 72 20 73 6f a2 f6  3d 5e 6a cc 51 da 51 c3  9f 56 07 7d 4b 00 2d 06  b6 78 64 8b d2 e2 c2 d9  a4 9b
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700b2 for type 'density_byte', which requires 4 byte alignment
0x0000020700b2: note: pointer points here
 6c 6c  69 63 6a cc 51 da 51 c3  9f 56 07 7d 4b 00 2d 06  b6 78 64 8b d2 e2 c2 d9  a4 9b e8 ee 63 94
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700b6 for type 'density_byte', which requires 4 byte alignment
0x0000020700b6: note: pointer points here
 69 74 75 64 51 c3  9f 56 07 7d 4b 00 2d 06  b6 78 64 8b d2 e2 c2 d9  a4 9b e8 ee 63 94 2a a5  33 a6
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700ba for type 'density_byte', which requires 4 byte alignment
0x0000020700ba: note: pointer points here
 69 6e  20 74 07 7d 4b 00 2d 06  b6 78 64 8b d2 e2 c2 d9  a4 9b e8 ee 63 94 2a a5  33 a6 63 ad d1 2f
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700be for type 'density_byte', which requires 4 byte alignment
0x0000020700be: note: pointer points here
 6f 72 74 6f 2d 06  b6 78 64 8b d2 e2 c2 d9  a4 9b e8 ee 63 94 2a a5  33 a6 63 ad d1 2f 8b 2e  e5 f0
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700c2 for type 'density_byte', which requires 4 byte alignment
0x0000020700c2: note: pointer points here
 72 20  76 65 64 8b d2 e2 c2 d9  a4 9b e8 ee 63 94 2a a5  33 a6 63 ad d1 2f 8b 2e  e5 f0 1c ef d4 ac
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700c6 for type 'density_byte', which requires 4 byte alignment
0x0000020700c6: note: pointer points here
 6c 20 63 6f c2 d9  a4 9b e8 ee 63 94 2a a5  33 a6 63 ad d1 2f 8b 2e  e5 f0 1c ef d4 ac 41 87  54 c2
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:109:33: runtime error: store to misaligned address 0x00000206ffc4 for type 'density_chameleon_signature', which requires 8 byte alignment
0x00000206ffc4: note: pointer points here
  20 73 65 64 00 00 00 00  00 00 00 00 20 74 65 6d  70 6f 72 20 70 75 72 75  73 20 63 75 72 73 75 73
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700d2 for type 'density_byte', which requires 4 byte alignment
0x0000020700d2: note: pointer points here
 2a a5  33 a6 63 ad d1 2f 8b 2e  e5 f0 1c ef d4 ac 41 87  54 c2 46 e2 4f 8c db 44  84 3c 1a 13 f1 4f
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700d6 for type 'density_byte', which requires 4 byte alignment
0x0000020700d6: note: pointer points here
 20 61 75 63 8b 2e  e5 f0 1c ef d4 ac 41 87  54 c2 46 e2 4f 8c db 44  84 3c 1a 13 f1 4f 5f 8e  eb b8
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x0000020700da for type 'density_byte', which requires 4 byte alignment
0x0000020700da: note: pointer points here
 74 6f  72 2e 1c ef d4 ac 41 87  54 c2 46 e2 4f 8c db 44  84 3c 1a 13 f1 4f 5f 8e  eb b8 07 d2 07 b6
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode.c:126:38: runtime error: store to misaligned address 0x00000207089a for type 'density_byte', which requires 4 byte alignment
0x00000207089a: note: pointer points here
 8b 39  f0 21 20 65 75 69 73 6d  6f 64 2c 20 6e 6f 6e 20  76 61 72 69 75 73 20 66  65 6c 69 73 20 64
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_encode_template.h:117:25: runtime error: store to misaligned address 0x00000207082a for type 'density_chameleon_signature', which requires 8 byte alignment
0x00000207082a: note: pointer points here
 75 73  20 66 75 65 74 20 65 73  74 20 e3 f9 20 64 69 63  74 75 6d 2e 65 f6 29 f5  6b 9a 70 75 73 20
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff52 for type 'density_byte', which requires 4 byte alignment
0x00000206ff52: note: pointer points here
 69 70  0e 3f 70 72 69 6d 69 73  20 69 6e 20 66 61 75 63  69 62 75 73 20 6f 72 63  69 20 6c 75 63 74
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff56 for type 'density_byte', which requires 4 byte alignment
0x00000206ff56: note: pointer points here
 70 72 69 6d 69 73  20 69 6e 20 66 61 75 63  69 62 75 73 20 6f 72 63  69 20 6c 75 63 74 75 73  20 65
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff5a for type 'density_byte', which requires 4 byte alignment
0x00000206ff5a: note: pointer points here
 69 73  20 69 6e 20 66 61 75 63  69 62 75 73 20 6f 72 63  69 20 6c 75 63 74 75 73  20 65 74 20 75 6c
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff5e for type 'density_byte', which requires 4 byte alignment
0x00000206ff5e: note: pointer points here
 6e 20 66 61 75 63  69 62 75 73 20 6f 72 63  69 20 6c 75 63 74 75 73  20 65 74 20 75 6c 3a 6d  65 73
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff62 for type 'density_byte', which requires 4 byte alignment
0x00000206ff62: note: pointer points here
 75 63  69 62 75 73 20 6f 72 63  69 20 6c 75 63 74 75 73  20 65 74 20 75 6c 3a 6d  65 73 20 70 6f 73
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff66 for type 'density_byte', which requires 4 byte alignment
0x00000206ff66: note: pointer points here
 75 73 20 6f 72 63  69 20 6c 75 63 74 75 73  20 65 74 20 75 6c 3a 6d  65 73 20 70 6f 73 75 65  72 65
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff6a for type 'density_byte', which requires 4 byte alignment
0x00000206ff6a: note: pointer points here
 72 63  69 20 6c 75 63 74 75 73  20 65 74 20 75 6c 3a 6d  65 73 20 70 6f 73 75 65  72 65 20 63 75 62
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x00000206ff6e for type 'density_byte', which requires 4 byte alignment
0x00000206ff6e: note: pointer points here
 6c 75 63 74 75 73  20 65 74 20 75 6c 3a 6d  65 73 20 70 6f 73 75 65  72 65 20 63 75 62 69 6c  69 61
             ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:85:24: runtime error: load of misaligned address 0x00000206ffc4 for type 'density_byte', which requires 8 byte alignment
0x00000206ffc4: note: pointer points here
  20 73 65 64 00 00 00 00  80 00 00 00 20 74 65 6d  70 6f 72 20 70 75 72 75  73 20 63 75 72 73 75 73
              ^ 
/home/nemequ/local/src/squash/plugins/density/density/src/kernel_chameleon_decode.c:97:14: runtime error: load of misaligned address 0x000002071cda for type 'density_byte', which requires 4 byte alignment
0x000002071cda: note: pointer points here
 00 00  e3 f9 20 64 69 63 74 75  6d 2e 65 f6 29 f5 6b 9a  70 75 73 20 13 23 72 a7  b4 b9 65 20 61 20
              ^

I only tested chameleon there, but it's probably a good bet that cheetah and lion have similar issues.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.