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

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

#41

Post by bigiain » Thu, Sep 18, 2025, 5:08 AM UTC

bee_rider wrote: post #4

288 cores is an absurd number of cores. Do these things have AVX512? It looks like some of the Sierra Forest chips do have AVX512 with 2xFMA… That’s pretty wide. Wonder if they should put that thing on a card and sell it as a GPU (a totally original idea that has never been tried, sure…).

> 288 cores is an absurd number of cores.

Way back in the day, I built and ran the platform for a business on Pentium grade web & database servers which gave me 1 "core" in 2 rack units.

That's 24 cores per 48 unit rack, so 288 cores would be a dozen racks or pretty much an entire aisle of a typical data center.

I guess all of Palo Alto Internet eXchange (where two of my boxen lived) didn't have much more than a couple of thousand cores back in 98/99. I'm guessing there are homelabs with more cores than that entire PAIX data center had back then.

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

#42

Post by DeathArrow » Thu, Sep 18, 2025, 5:34 AM UTC

>Intel's latest processor generations are pushing the number of cores in a server to unprecedented levels - from 128 P-cores per socket in Granite Rapids to 288 E-cores per socket in Sierra Forest, with future roadmaps targeting 200+ cores per socket.

It seems today's Intel CPU can replace yesteryear's data center.

May someone can try for fun running 1000 Red Hat Linux 6.2 in parallel on one CPU, like it's year 2000 again.

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

#43

Post by adrian_b » Thu, Sep 18, 2025, 8:01 AM UTC

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.

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

#44

Post by adrian_b » Thu, Sep 18, 2025, 8:19 AM UTC

ashvardanian wrote: post #25

bri3d wrote: post #21

Earlier quoted context omitted.

Sierra Forest (the 288-core one) does not have AVX512. Intel split their server product line in two: * Processors that have only P-cores (currently, Granite Rapids), which do have AVX512. * Processors that have only E-cores (currently, Sierra Forest), which do not have AVX512. On the other hand, AMD's high-core, lower-area offerings, like Zen 4c (Bergamo) do support AVX512, which IMO makes things easier.

Largely true, but there is always a caveat. On Zen4 and Zen4c the register is 512 bits wide. However, internally, many “datapaths” (execution units, floating-point units, vector ALUs, etc.) are 256 bits wide for much of the AVX-512 functional units… Zen5 is supposed to be different, and again, I wrote the kernels for Zen5 last year, but still have no hardware to profile the impact of this implementation difference on…

This is an often repeated myth, which is only half true.

On Zen 4 and Zen 4c, for most vector instructions the vector datapaths have the same width as in Intel's best Xeons, i.e. they can do two 512-bit instructions per clock cycle.

The exceptions where AMD has half throughput are the vector load and store instructions from the first level cache memory and the FMUL and FMA instructions, where the most expensive Intel Xeons can do two FMUL/FMA per clock cycle while Zen 4/4c can do only 1 FMUL/FMA + 1 FADD per clock cycle.

So only the link between the L1 cache and the vector registers and also the floating-point multiplier have half-width on Zen 4/4c, while the rest of the datapaths have the same width (2 x 512-bit) on both Zen 4/4c and Intel's Xeons.

The server and desktop variants of Zen 5/5c (and also the laptop Fire Range and Strix Halo CPUs) double the width of all vector datapaths, exceeding the throughput of all past or current Intel CPUs. Only the server CPUs expected to be launched in 2026 by Intel (Diamond Rapids) are likely to be faster than Zen 5, but by then AMD might also launch Zen 6, so it remains to be seen which will be better by the end of 2026.

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

#45

Post by scott_w » Thu, Sep 18, 2025, 8:33 AM 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.

Same here. I don't know if the linked title changed but it's now:

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

Which is pretty unambiguous.

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

#46

Post by lordnacho » Thu, Sep 18, 2025, 8:42 AM UTC

fibers wrote: post #35

lordnacho wrote: post #29

Clickhouse is excellent btw. I took it for a spin, loading a few TB of orderbook changes into it as entire snapshots. The double compression (type-aware and generic) does wonders. It's amazing how you get both the benefit of small size and quick querying, with minimal tweaks. I don't think I changed any system level defaults, yet I can aggregate through the entire few billion snapshots in a few minutes.

By snapshots do you mean the entire orderbook in a specific point in time or the entire history that gets instiantiated?

At each point in time, the entire orderbook at that time.

So you could replay the entire history of the book just by stepping through the rows.

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

#47

Post by sdairs » Thu, Sep 18, 2025, 9:45 AM UTC

scott_w wrote: post #45

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.

Same here. I don't know if the linked title changed but it's now: > Optimizing ClickHouse for Intel's ultra-high core count processors Which is pretty unambiguous.

Yeah "Optimizing ClickHouse for Intel's ultra-high core count processors" is the original, unchanged article title, it's just been submitted slightly differently on HN (surprised mods haven't changed it here actually)

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

#48

Post by menaerus » Thu, Sep 18, 2025, 10:01 AM UTC

    Two-character SIMD filtering improved performance significantly:
    ClickBench query Q20 sped up by 35%
    Other queries which perform substring matching saw an overall improvement of ~10%
    The geometric mean of all queries improved by 4.1%

ClickBench dataset is ~70G IIRC so I find it interesting that they measured such a substantial speedup while only using SSE4.1 (128-bit) - so, not even AVX2 and much less AVX-512. I wonder what the results would be if latter had been the case.

And I also wonder if this is (partly) an artifact of more laser-focused utilization of a CPU core ALU and memory subsystem. E.g. crunching more work into a single or pair of instructions are now leaving more space for other unrelated instructions to be retired.

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

#49

Post by bee_rider » Thu, Sep 18, 2025, 1:10 PM UTC

bigiain wrote: post #41

bee_rider wrote: post #4

288 cores is an absurd number of cores. Do these things have AVX512? It looks like some of the Sierra Forest chips do have AVX512 with 2xFMA… That’s pretty wide. Wonder if they should put that thing on a card and sell it as a GPU (a totally original idea that has never been tried, sure…).

> 288 cores is an absurd number of cores. Way back in the day, I built and ran the platform for a business on Pentium grade web & database servers which gave me 1 "core" in 2 rack units. That's 24 cores per 48 unit rack, so 288 cores would be a dozen racks or pretty much an entire aisle of a typical data center. I guess all of Palo Alto Internet eXchange (where two of my boxen lived) didn't have much more than a coup…

Oh yeah, it is not that many cores for the cluster-universe. Just neat to see the number of cores per socket increase.

A while ago I had access to an 8-socket shared memory machine… but this was the semi-olden days, so it was “only” 80 cores. It was a fun machine at the time! We’re so spoiled these days, haha.

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

#50

Post by sbarre » Thu, Sep 18, 2025, 1:40 PM UTC

mrheosuper wrote: post #39

sbarre wrote: post #34

Earlier quoted context omitted.

Damn, when I first landed on the page I saw $7,600 and thought "for 320 cores that's pretty amazing!" but that's the default configuration with 32 cores & 64GB of memory. 320 cores starts at $28,000.. $34k with 1TB of memory..

The CPU has launch price of $13k already, so $28k is a good deal imo

It's not a good deal for me though. ;-)