Viewing profile — Cyan4973
Cyan4973
HN member- Joined
- Fri, May 29, 2015, 9:44 AM UTC
- HN karma
- 30
- Public activity
- 19 items
- HN profile
- View on Hacker News ↗
About Cyan4973
No profile information was provided.
Recent public activity
-
comment
Comment #21086132
> Please be aware that this will significantly impact compression ratio. Is this a continuation from previous message ? Because multithreading mode of zstd doesn't impact its compr…
-
comment
Comment #19429042
I'm afraid I don't follow. Is there any code source that could be read ? The way to force the hash algorithm to actually wait for input is to use the previous hash to determine the…
-
comment
Comment #19417824
Following your suggestion, I went ahead and modified the scrambling formula. The crux of the problem is that the secret is allowed to be absolutely anything (it's user provided). A…
-
comment
Comment #19416272
Actually, making the next hash dependent on previous hash through the `seed` doesn't work for benchmarking latency. Several hashes only use the seed at the very end of calculation.…
-
comment
Comment #19414633
Thanks for suggestions @dragontamer. We are genuine when saying the algorithm is opened to suggestions, and can still change to improve its properties. Let's review yours : > my go…
-
comment
Comment #19407497
> Why not optimize the function, and aim for only 256-bits of internal state (with 256-bits of entropy) ?? It's a lot more difficult to ensure that accumulators contain full-width …
-
comment
Comment #19407323
Well, if you believe a better scrambling operation is possible, you are certainly welcomed to suggest one. Considering feedbacks on the algorithm is one of the objectives of the te…
-
comment
Comment #19405334
It's not exactly "losing information". We are not trying to regenerate original data, just make sure that all source bits can fairly influence the result. It's more a question of b…
-
comment
Comment #19404842
According to the UMAC paper, the 32x32=>64 multiplication only contains 32-bit of entropy, even though it uses 64-bit space. That's understandable : most of the entropy will be in …
-
comment
Comment #19403793
wyhash is a close relative to mumhashv2, and feature approximately the same performance strength and weaknesses.
-
comment
Comment #18720456
On Windows, I'm using Chocolatey package manager : https://chocolatey.org/ zstd is among the available packages.
-
comment
Comment #18720090
zstd availability is becoming more and more common nowadays. See for example this tracker : https://repology.org/metapackage/zstd/versions
-
comment
Comment #18720013
There is a zlib wrapper included in the project : https://github.com/facebook/zstd/tree/master/zlibWrapper
-
comment
Comment #12410383
There is now a pzstd implementation, if you wish to compare it to pigz
-
comment
Comment #12410369
The decompressor can receive a parameter to refuse compressed frames requiring more than a selected amount of memory.
-
comment
Comment #12405004
Zstd pass faster over incompressible data. Expect something > 1 GB/s
-
comment
Comment #12402202
zstd goes at > 1 GB/s on uncompressible data. It has some fast heuristics for such cases too.
-
comment
Comment #9623622
MetroHash source code is impressively close to xxHash one, to the point that it seems to be a tweaked version of it. Yet, the author never mentions a single word about it in its so…
-
comment
Comment #9623608
In all tests I know, xxh64 should be about 2x faster than xxh32 on x86_64 systems. Surprisingly, it doesn't match with the readme table.