Live data from Hacker News

Viewing profile — Cyan4973

Cyan4973

HN member
Joined
Fri, May 29, 2015, 9:44 AM UTC
HN karma
30
Public activity
19 items

About Cyan4973

No profile information was provided.

Recent public activity

  1. 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…

  2. 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…

  3. 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…

  4. 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.…

  5. 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…

  6. 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 …

  7. 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…

  8. 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…

  9. 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 …

  10. comment
    Comment #19403793

    wyhash is a close relative to mumhashv2, and feature approximately the same performance strength and weaknesses.

  11. comment
    Comment #18720456

    On Windows, I'm using Chocolatey package manager : https://chocolatey.org/ zstd is among the available packages.

  12. comment
    Comment #18720090

    zstd availability is becoming more and more common nowadays. See for example this tracker : https://repology.org/metapackage/zstd/versions

  13. comment
    Comment #18720013

    There is a zlib wrapper included in the project : https://github.com/facebook/zstd/tree/master/zlibWrapper

  14. comment
    Comment #12410383

    There is now a pzstd implementation, if you wish to compare it to pigz

  15. comment
    Comment #12410369

    The decompressor can receive a parameter to refuse compressed frames requiring more than a selected amount of memory.

  16. comment
    Comment #12405004

    Zstd pass faster over incompressible data. Expect something > 1 GB/s

  17. comment
    Comment #12402202

    zstd goes at > 1 GB/s on uncompressible data. It has some fast heuristics for such cases too.

  18. 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…

  19. 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.