Skip to content

Fixes to the blog posts about 8.1.0 release and hash table #232

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 2, 2025
Merged

Fixes to the blog posts about 8.1.0 release and hash table #232

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/blog/2025-03-28-new-hash-table/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ When the CPU loads some data from the main memory into the CPU cache, it does so
in fixed size blocks called cache lines. The cache-line size is 64 bytes on
almost all modern hardware. Recent work on hash tables, such as [Swiss
tables](https://abseil.io/about/design/swisstables), are highly optimized to
store and access data within a single cache line. If the key you're not looking
store and access data within a single cache line. If the key you're looking
for isn't found where you first look for it (due to a hash collision), then it
should ideally be found within the same cache line. If it is, then it's found
very fast once this cache line has been loaded into the CPU cache.
Expand Down
5 changes: 4 additions & 1 deletion content/blog/2025-04-02-valkey-8-1-0-ga.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,10 @@ The fork copy-on-write memory overhead is reduced by up to [47%](https://github.

### Sorted set and hyperloglog and bitcount optimizations

`ZRANK` command, which serves a popular usecase in operating Leaderboards, was optimized to perform up to [45%](https://github.com/valkey-io/valkey/pull/1389) faster, depending on the sorted set size. This optimization requires a C++ compiler, and is currently an opt-in feature.
`ZRANK` command, which serves a popular usecase in operating Leaderboards, was optimized to perform up to [45%](https://github.com/valkey-io/valkey/pull/1389) faster, depending on the sorted set size.

`ZADD` and other commands that involve floating point numbers are optimized by [`fast_float`](https://github.com/valkey-io/valkey/pull/1260) to parse floats using SIMD instructions.
This optimization requires a C++ compiler, and is currently an opt-in feature at compile time.

The probabilistic hyperloglog is another great data type, used for counting unique elements in very large datasets whilst using only 12KB of memory regardless of the amount of elements. By using the modern CPUs Advanced Vector Extensions of x86, Valkey 8.1 can achieve a [12x](https://github.com/valkey-io/valkey/pull/1293) speed for the operations like `PFMERGE` and `PFCOUNT` on hyperloglog data types.

Expand Down