Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

clickhouse.com

Post reply on HN
Print view View original

21–30 of 53 posts

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

#21

Post by bri3d »

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…).

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.

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

#23

Post by mrits »

vlovich123 wrote: post #19

I'm generally surprised they're still using the unmaintained old version of jemalloc instead of a newer allocator like the Bazel-based TCMalloc or mimalloc which have significantly better techniques due to better OS primitives & about a decade or so of R&D behind them.

besides jemalloc also being used by other columnar databases it has a lot of control and telemetry built in. I don't closely follow tcmalloc but I'm not sure it focuses on large objects and fragmentation over months/years.

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

#24

Post by jsheard »

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…).

It is pretty wide, but 288 cores with 8x FP32 lanes each is still only about a tenth of the lanes on an RTX 5090. GPUs are really, really, really wide.

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

#25

Post by ashvardanian »

bri3d wrote: post #21
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…).

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 practical systems :(

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

#26

Post by bob1029 »

epistasis wrote: post #2

This is my favorite type of HN post, and definitely going to be a classic in the genre for me. > Memory optimization on ultra-high core count systems differs a lot from single-threaded memory management. Memory allocators themselves become contention points, memory bandwidth is divided across more cores, and allocation patterns that work fine on small systems can create cascading performance problems at scale. It is…

The most ideal arrangement is one in which you do not need to use the memory subsystem in the first place. If two threads need to communicate back-forth with each other in a very tight loop in order to get some kind of job done, there is almost certainly a much faster technique that could be ran on a single thread. Physically moving the information between the cores of processing is the most expensive part. You can totally saturate the memory bandwidth of a Zen chip with somewhere around 8-10 cores if they're all going at a shared working set really aggressively.

Core-to-Core communication across infinity fabric is on the order of 50~100x slower than L1 access. Figuring out how to arrange your problem to meet this reality is the quickest path to success if you intend to leverage this kind of hardware. Recognizing that your problem is incompatible can also save you a lot of frustration. If your working sets must be massive monoliths and hierarchical in nature, it's unlikely you will be able to use a 256+ core monster part very effectively.

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

#27

Post by pixelpoet »

nivertech wrote: post #11
pixelpoet wrote: post #3

This post looks like excellent low-level optimisation writing just in the first sections, and (I know this is kinda petty, but...) my heart absolutely sings at their use of my preferred C++ coding convention where & (ref) neither belongs to the type nor the variable name!

I think it belongs to type, but since they use “auto” it looks standalone and can be confused with the “&” operator. I personally always used * and & as a prefix of the variable name, not as a suffix in the type name, except when used to specify types in templates.

IMO it's a separate category of modifiers/decorators to the type, like how adjectives and nouns are distinguished, and the only reason we have the false-choice in C/C++ is because it's not alphanumeric (if the token were e.g. "ref" it would interfere with the type or variable name in either other convention).

If I were forced at gunpoint to choose one of the type or name, "obviously" I would also choose type.

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

#28

Post by jeffbee »

mrits wrote: post #23
vlovich123 wrote: post #19

I'm generally surprised they're still using the unmaintained old version of jemalloc instead of a newer allocator like the Bazel-based TCMalloc or mimalloc which have significantly better techniques due to better OS primitives & about a decade or so of R&D behind them.

besides jemalloc also being used by other columnar databases it has a lot of control and telemetry built in. I don't closely follow tcmalloc but I'm not sure it focuses on large objects and fragmentation over months/years.

TCMalloc has an absurd amount of bookkeeping and stats, but you have to understand the implementation deeply to make sense of the stats. https://github.com/google/tcmalloc/blob/master/docs/stats.md

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

#29

Post by lordnacho »

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.

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

#30

Post by jeffbee »

bob1029 wrote: post #26
epistasis wrote: post #2

This is my favorite type of HN post, and definitely going to be a classic in the genre for me. > Memory optimization on ultra-high core count systems differs a lot from single-threaded memory management. Memory allocators themselves become contention points, memory bandwidth is divided across more cores, and allocation patterns that work fine on small systems can create cascading performance problems at scale. It is…

The most ideal arrangement is one in which you do not need to use the memory subsystem in the first place. If two threads need to communicate back-forth with each other in a very tight loop in order to get some kind of job done, there is almost certainly a much faster technique that could be ran on a single thread. Physically moving the information between the cores of processing is the most expensive part. You can t…

Note that none of the CPUs in the article have that Zen architecture.

One of the most interesting and poorly exploited features of these new Intel chips is that four cores share an L2 cache, so cooperation among 4 threads can have excellent efficiency.

They also have user-mode address monitoring, which should be awesome for certain tricks, but unfortunately like so many other ISA extentions, it doesn't work. https://www.intel.com/content/www/us/en/developer/articles/t...

Post reply on HN