Windows binaries about c-blosc HOT 6 CLOSED

Hmm, C-Blosc does not distribute any bin/ directory, so this should be a result of your compilation.

And sorry, but we cannot promise creating binaries for any platform, and this should be the responsibility of the users or other packagers. But if you are willing to sponsor us this could be done on a regular basis.

from c-blosc.

CMake creates a PACKAGE project, and its output contains bin, include, and lib folders.

from c-blosc.

In MinGW makefiles, -msse2 should be -mavx2, e.g. here https://github.com/Blosc/c-blosc/blob/master/bench/Makefile.mingw#L3.

BTW, I have built MinGW x64 version with GCC 4.9.2 and compared it to VS2015RC, and VS2015 performance wins on average on my benchmarks (with compression fixed at level 9 on different types of data, CPU i5-3427U, only supports AVX, not AVX2). Will try to run the built-in benchmark later.

And I could also confirm that #84 is ok with 1.7 and MinGW on x64.

from c-blosc.

Good point. However, I have just tested the bench/ Makefile and it fails. This is expected as I do not maintain them for quite a long time, so I think the best is to remove them and promote cmake as the only supported way to compile C-Blosc (much more flexible and with discovery capabilities for SSE2 and AVX2).

And I am certainly interested in having a look at your VS2015 benchmarks (specially compared with MinGW-w64 4.9.x), so please share them when you can :)

from c-blosc.

Just have tested this on a fresh Windows 8.1 install, both VS CMake and MinGW builds fail without MSVCR120.dll. It is strange that MinGW version requires it, given that the dll is several times larger in size than the VS's version.

from c-blosc.

Closing this because redistributing msvcrt became inevitable and CMake build with MSVC is very easy on any machine compared to Makefile with MinGW. Any performance differences between MSVC and MinGW are not relevant, both are fast.

Just FYI, I use Blosc in my Spreads project and it is very good and stable! In .NET, there is a decimal data type that takes 128 bits. The cool and funny thing is that if I convert double to decimal arrays, which are 2x larger, and then compress them, the resulting size is significantly lower than the size of compressed double arrays (and without precision loss). This is due to byte representation of decimal, and shuffling shines here. Thanks again for this nice library!

from c-blosc.