profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Cyan4973/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Yann Collet Cyan4973 @facebook Menlo Park, USA http://fastcompression.blogspot.fr/ data compression

lz4/lz4 6205

Extremely Fast Compression algorithm

Cyan4973/xxHash 5317

Extremely fast non-cryptographic hash algorithm

Cyan4973/FiniteStateEntropy 989

New generation entropy codecs : Finite State Entropy and Huff0

Cyan4973/Writing_Safer_C_code 156

Collection of articles on good practices and tools to improve C code quality

Bulat-Ziganshin/FA 115

FreeArc'Next

Cyan4973/RygsDXTc 59

Real-time DXT1/DXT5 texture compressor

Cyan4973/mmc 16

Automatically exported from code.google.com/p/mmc

Cyan4973/smhasher 9

Improved fork of https://code.google.com/p/smhasher/

Cyan4973/Behemoth-Rank-Coding 1

Fast and Strong Burrows Wheeler Model

Cyan4973/LZD 1

Compressor for HP48 calculator

issue closedlz4/lz4

makefile echo problem

https://github.com/lz4/lz4/blob/bdc9d3b0c10cbf7e1ff40fc6e27dad5f693a00e7/lib/Makefile#L201

doest not take into account the DESTDIR variable so this:

@echo Installing headers in $(includedir) should be @echo Installing headers in $(DESTDIR)$(includedir)

closed time in 8 hours

tkiraly

issue commentlz4/lz4

makefile echo problem

fixed by @eloj in #1012

tkiraly

comment created time in 8 hours

push eventlz4/lz4

Eddy Jansson

commit sha eba110ad5b52dcd7f8cfcfddae03cc7fb9207781

Print target directories during 'make install'. This takes #975 to its logical conclusion.

view details

Yann Collet

commit sha 4de56b3da3f709e61301d65cf67e068bc650d9eb

Merge pull request #1012 from eloj/print-install-dirs Print target directories during 'make install'.

view details

push time in 8 hours

PR merged lz4/lz4

Print target directories during 'make install'.

This takes #975 to its logical conclusion.

+4 -4

1 comment

2 changed files

eloj

pr closed time in 8 hours

push eventlz4/lz4

Eddy Jansson

commit sha c1f514f3dbc22e56b2d6821f461aa058bd3104c3

Expand use of pkg-config variables. Change pkg-config generation such that the path variables, not their values, are used in the definitions of Libs and Cflags, and that $prefix is substituted into libdir and includedir iff they start with its value. This makes it easier to modify the already installed file if necessary.

view details

Yann Collet

commit sha 7be503964858691951320f13a9b5d28e450e3fad

Merge pull request #1011 from eloj/improve-pkgconfig Expand use of pkg-config variables.

view details

push time in 8 hours

PR merged lz4/lz4

Expand use of pkg-config variables.

Change pkg-config generation (liblz4.pc) such that the path variables, not their values, are used in the definitions of Libs and Cflags, and that $prefix is substituted into libdir and includedir iff they start with its value.

To make the changes more clear, here's the the original output (excl. comments):

prefix=/usr/local
libdir=/usr/local/lib
includedir=/usr/local/include

Name: lz4
Description: extremely fast lossless compression algorithm library
URL: http://www.lz4.org/
Version: 1.9.3
Libs: -L/usr/local/lib -llz4
Cflags: -I/usr/local/include

The new output is:

prefix=/usr/local
libdir=${prefix}/lib
includedir=${prefix}/include

Name: lz4
Description: extremely fast lossless compression algorithm library
URL: http://www.lz4.org/
Version: 1.9.3
Libs: -L${libdir} -llz4
Cflags: -I${includedir}
+3 -2

1 comment

2 changed files

eloj

pr closed time in 8 hours

PullRequestReviewEvent

pull request commentlz4/lz4

Expand use of pkg-config variables.

Thanks @eloj ! Great improvement !

eloj

comment created time in 8 hours

pull request commentlz4/lz4

Print target directories during 'make install'.

Thanks @eloj !

eloj

comment created time in 8 hours

PullRequestReviewEvent

startedmizt/zpng

started time in 12 hours

issue commentfacebook/zstd

Maximum possible compression settings

I would use --ultra -22 --long=31 --zstd=hlog=30,clog=30,slog=29,tlen=9999.

Merculous

comment created time in 2 days

pull request commentCyan4973/xxHash

Use `alignas()` in C++11

Thanks @felixhandte . Your PR looks good to me.

Before merging it, I was hoping I could find some time to create a test scenario which would fail, as in #543. This would help determine if this PR is good enough to fix it, or if there's more to it.

felixhandte

comment created time in 2 days

PullRequestReviewEvent

issue commentCyan4973/xxHash

Easier implementation for software running on "normal" architectures

Yes that's a good suggestion. I did not realized that the issue could be triggered when compiling the source code in C++ mode.

fcorbelli

comment created time in 3 days

issue commentCyan4973/xxHash

.NET implementation of XXH3

There is this one : https://github.com/Zhentar/xxHash3.NET

Unfortunately, it's outdated, and doesn't run as fast as XXH64.

Yet, it could be a useful inspiration for anyone trying to achieve an equivalent objective.

gabriele-ricci-kyklos

comment created time in 4 days

issue commentCyan4973/xxHash

Easier implementation for software running on "normal" architectures

That looks like a correct workaround. Note that XXH3_createState() is essentially doing the same thing, guaranteeing that the allocated space for the state is correctly aligned.

Indeed, aligning a member of a struct to 64-bytes has consequences for the encompassing structure. The rules regarding structure alignment are pretty clear, so it should be a straightforward application. However, given that aligning on 64-bytes is not common, this could be a case which is not tested, hence could be missed. Given that the issue happens on a specific compiler version, on a specific OS, using a specific set of flags, a compiler bug issue is not excluded at this stage.

fcorbelli

comment created time in 4 days

issue commentCyan4973/xxHash

Easier implementation for software running on "normal" architectures

I wish there was a simplified implementation of xxhash, in a single cpp file, without #ifdef, a ~6KB file

I wish it too. I like Stefan's variants.

Problem is, it would violate one of the rules of this repository, which is "one xxhash.h file for all", on the ground that it's easier to integrate.

The objective is not all lost though. We could consider smaller specialized files, which are then aggregated into a single xxhash.h file. This way, both approaches (small specialized files + single file for all) would be possible.

However, this is a complex goal, and I don't see that happening on short term. For your immediate needs, better consider a fix.

I'm having trouble with a software that compiles and works fine with gcc on Windows and FreeBSD but not Linux, due to XXH3_state_t

Could you please describe your issue ?

XXH3 is supposed to work fine on Linux. It's actually continuously tested on Linux.

fcorbelli

comment created time in 4 days

startedChenJianyunp/Hardware-Zstd-Compression-Unit

started time in 5 days

Pull request review commentfacebook/zstd

[bug-fix] Fix a determinism bug with the DUBT

 ZSTD_checkDictValidity(const ZSTD_window_t* window,  MEM_STATIC void ZSTD_window_init(ZSTD_window_t* window) {     ZSTD_memset(window, 0, sizeof(*window));-    window->base = (BYTE const*)"";-    window->dictBase = (BYTE const*)"";-    window->dictLimit = 1;    /* start from 1, so that 1st position is valid */-    window->lowLimit = 1;     /* it ensures first and later CCtx usages compress the same */-    window->nextSrc = window->base + 1;   /* see issue #1241 */+    window->base = (BYTE const*)" ";

for my understanding : why " " ? avoiding UB pointer arithmetic ?

terrelln

comment created time in 9 days

PullRequestReviewEvent

push eventfacebook/zstd

makise-homura

commit sha d4ad02c7210b4b2936cee45b426db9e8e78a7bc4

Add support for MCST LCC compiler

view details

makise-homura

commit sha a5f518ae273ff0000bfd4c50689663f690f95d24

Change zstdcli's main() declaration due to -Wmain on some compilers

view details

makise-homura

commit sha 3cd085cec3cc805f19e52ec98bfe60e7f1543672

Clarify no-tree-vectorize usage for ICC and LCC

view details

Yann Collet

commit sha b18febe52c098198531643feacb15609a04f05e3

Merge pull request #2725 from makise-homura/mcst-lcc-support Add support for MCST LCC compiler

view details

push time in 10 days

PR merged facebook/zstd

Add support for MCST LCC compiler CLA Signed

I'd like to introduce support for MCST LCC compiler based on EDG front end. It is primarily used to build software for computers based on Russian Elbrus CPUs.

The main two fixes I introduce here, are:

  • there is no optimize("no-tree-vectorize") support in said compiler;
  • it generates a -Wmain warning (or error on -Werror) while testing zstd because of argc is specified as const in main() of zstdcli.

Contribution guidelines followed:

  • CLA is signed.
  • Tests (both shortest and test) performed successfully, both on x86_64 with gcc-9 and e2k (Elbrus) with lcc 1.25.
  • Travis build is OK.
  • AppVeyor build failed in mingw tasks: looks like it isn't properly configured (The system cannot find the path specified. while preparing the build environment).
  • Static analyzer (scan-build from clang-tools-10) found 59 bugs, but somehow 71 were found for current dev upstream branch. No one of them, by the way, related to parts of code I modified.
+4 -3

4 comments

2 changed files

makise-homura

pr closed time in 10 days

pull request commentfacebook/zstd

Add support for MCST LCC compiler

I can do it today or tomorrow, or in August after I'm back.

No need to rush this topic. We can certainly wait for August.

The difficulty will be in automating this test, and making sure that it doesn't generate too much noise in CI results, such as failures for reasons different than the code itself. Better take the time to do it well.

makise-homura

comment created time in 10 days

PullRequestReviewEvent

PR closed Cyan4973/xxHash

Release

yaxibot

+0 -0

1 comment

0 changed file

tatwe

pr closed time in 11 days

pull request commentfacebook/zstd

Add support for MCST LCC compiler

I agree with the general objective of this PR. I made a couple of comments, mostly focused on improving maintainability.

Speaking of which : would there be any way to test this capability (elbrus support) in (public) CI ? The objective would be to ensure that this capability remains supported in the future. Otherwise, it's too easy for any future contributor to break it without noticing it. That being said, I get it that elbrus compiler is not exactly commonplace. So this is more a "bonus" topic.

makise-homura

comment created time in 12 days

Pull request review commentfacebook/zstd

Add support for MCST LCC compiler

  /* vectorization  * older GCC (pre gcc-4.3 picked as the cutoff) uses a different syntax */-#if !defined(__INTEL_COMPILER) && !defined(__clang__) && defined(__GNUC__)+#if !defined(__INTEL_COMPILER) && !defined(__clang__) && defined(__GNUC__) && !defined(__LCC__)

Could you please add a comment explaining the presence of this test ? This is for future contributors, that may only access the code, not the PR.

makise-homura

comment created time in 12 days

PullRequestReviewEvent