Cyan4973 / Cyan4973/xxHash

Suggestions list for future evolutions

Open
#458 17 comments 4 reactions 1 assignee Claimed by @Cyan4973 View on GitHub
Long-term
Dominant language
C
Stars
11.2k
Forks
913
Avg merge
10h 9m
Merged PRs (30d)
4

Description

## Objectives for v0.8.3
- Update `cmake` minimum version to `v3.10` (#988) - **completed**
- Non-BSD format for XXH3-64bit (#645) - **completed**
- Ship `xxhsum` with `DISPATCH` enabled by default (#986) - **completed**
- Salvage #802 of interesting parts - **completed**

## Objectives for v0.9.0
+ Stabilize `XXH_generateSecret()`
+ Split `xxhash.h` into multiple smaller files, and ship an ability to create a single amalgamated file from them ? (tentative)
* Complete that with an ability to be selective about which part of the library is actually included in the amalgamated artifact, for source and binary size control.
* provide a more direct way to selectively compile each algorithm, such as `XXH_ENABLE_XXH32`, `XXH_ENABLE_XXH64` and `XXH_ENABLE_XXH3`
* Currently, it's possible to compile _only_ `XXH32` (with `XXH_NO_LONG_LONG`), or `XXH32` + `XXH64` (with `XXH_NO_XXH3`) or everything. It's not possible to compile selectively only `XXH64` for example.
+ Consider `libxxhash` dynamic library with runtime vector extension detection enabled by default (`xxh_x64dispatch`) ? (tentative)
* But in this case, the objective would be to remain transparent for user applications. `DISPATCH` must therefore substitute its symbols to original ones.
+ Consider an `arm64dispatch` variant, for SVE/NEON dispatch (tentative, based on #762)
+ Requires a runtime SVE vector width detector
+ Remove legacy `XXH_OLDNAME` (or maybe v1.0 ?)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.