Optimizing ClickHouse for Intel's ultra-high core count processors • Hacker News Board

Re: Optimizing ClickHouse for Intel's ultra-high core count processors

#51

Post by kwillets » Thu, Sep 18, 2025, 4:33 PM UTC

The SIMD string matching optimization unfortunately missed a trick -- it's more selective to match the first and last characters of a pattern than the first two, and it's the same cost.

Credit to Muła for this one: http://0x80.pl/notesen/2016-11-28-simd-strfind.html#generic-... .

Re: Optimizing ClickHouse for Intel's ultra-high core count processors

#52

Post by tomhow » Thu, Sep 18, 2025, 5:48 PM UTC

adrian_b wrote: post #43

Due to a typo, the title is confusing, at the first glance I thought that "Intel 280" might be some kind of Arrow Lake CPU (intermediate between Intel 275 and Intel 285), but the correct title should have said "Intel's 288-core processors", making clear that this is about the server CPUs with 288 E-cores, Sierra Forest and the future Clearwater Forest.

Thanks, we've just changed the title to match the article's title, which the guidelines ask us to do.

Re: Optimizing ClickHouse for Intel's ultra-high core count processors

#53

Post by fuy » Fri, Sep 19, 2025, 9:10 AM UTC

Looking at first optimization, I wonder if double-checking after acquiring exclusive lock brings any performance benefits. The whole premise is that cache access is read-heavy, so not acquiring exclusive locks for reads eliminates by far the biggest problem.

Rare (I presume) cases of overlapping updates from different threads (considering updates themselves are also infrequent) don't seem like a big deal compared to lock elimination. Would be interesting to see benchmark numbers for those optimizations separately.