From 84875b297c50e329966522b432f60ba418f79e88 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Viktor=20S=C3=B6derqvist?= Date: Wed, 2 Apr 2025 13:02:04 +0200 Subject: [PATCH] Fixes to the blog posts about 8.1.0 release and hash table MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Viktor Söderqvist --- content/blog/2025-03-28-new-hash-table/index.md | 2 +- content/blog/2025-04-02-valkey-8-1-0-ga.md | 5 ++++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/content/blog/2025-03-28-new-hash-table/index.md b/content/blog/2025-03-28-new-hash-table/index.md index ac8f6410..aa48c1bb 100644 --- a/content/blog/2025-03-28-new-hash-table/index.md +++ b/content/blog/2025-03-28-new-hash-table/index.md @@ -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. diff --git a/content/blog/2025-04-02-valkey-8-1-0-ga.md b/content/blog/2025-04-02-valkey-8-1-0-ga.md index 9608bbfb..696bcdbc 100644 --- a/content/blog/2025-04-02-valkey-8-1-0-ga.md +++ b/content/blog/2025-04-02-valkey-8-1-0-ga.md @@ -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.