It seems a bit high-level, kind of skimming over a bunch of architecture concepts with a couple references to the fact that this might be duplicated when hypert

It seems a bit high-level, kind of skimming over a bunch of architecture concepts with a couple references to the fact that this might be duplicated when hyperthreading, this might not… IMO a blog post should be more actionable. This isn’t a textbook chapter. For example we go through the frontend. When discussing the trace cache we have: > … Instruction decoding is an expensive operation and some instructions need to be executed frequently. Having this cache helps the processor cut down the instruction execution latency. … > Trace cache is shared dynamically between the two logical processors on an as needed basis. … > Each entry in the cache is tagged with the thread information to distinguish the instructions of the two threads. The access to the trace cache is arbitrated between the two logical processors each cycle. So the threads share a trace cache, but keep track of which hyperthread used which instructions—but we don’t really know, practically, if we prefer threads that are running very similar computations or if that is a non-issue (that is, does the fact that they share the trace cache mean one thread can benefit from things the other has cached? Or does the tagging keep them separated?). In general, often they say “this is split equally between the two threads” or “this is shared,” which makes me wonder “if I disable SMT does the now single-thread get access to twice as much of this resource, and are there cases where that matters.” This is somewhat covered in: > As we have seen, enabling SMT on a CPU core requires sharing many of the buffers and execution resources between the two logical processors. Even if there is only one thread running on an SMT enabled core, these resources remain unavailable to that thread which reduces its potential performance. But this seems a bit fuzzy to me, I mean, we talk about caches which are shared dynamically between the two threads so at least some resources will be more readily available if only a single thread is running. It also could be interesting—if the author is an expert, perhaps they could share their experience as to which pipeline stages are often bottlenecks that get tighter with hyperthreads on, and which aren’t? We have a sort of even focus on each stage without many hints as to which practically matter. Or how we can help them out. Also it is largely based on a 2002 whitepaper so I guess the specific pipeline stages must have evolved a bit since then. Or maybe they could share some battle stories, favorite tools, some examples of applications and why they put pressure on particular stages, things which surprisingly didn’t scale when hyperthreads were enabled (I’m not asking for all these things, just any would be good).