Hacker News Reader

Comment by jakuboboza | Hacker News Reader

I think Ampere doesnt support hyper threading. That means this 128 cores is comparable to 64 cores on EPYC/Xeon. Also there is the L2/L3 cache that is important and ofc arch. Arm still has low adoption because code has to be recompiled. While "web" targets are easy things like financial software that gains benefits from AVX-512 instructions might be harder because Neoverse doesn't have this instructions.

On the other side, massively concurrent solutions might benefit much more from this new 128/256 arms chips. So for sure there is room for this type of solutions and im happy we are adding on top of x86/amd64.

Last but not the least x86/amd64 unless something changed were locked to AMD and Intel so regions like EU can't rely on them if they want to be independent in terms of silicon production/design. So Arm and maybe RISC-V are the only real paths right now.

View on HN

My impression of Arm-world SMT is that it was added in duress because people kept asking for it despite the word-of-God being that it was better just to add additional cores (I wonder if their license structure influences that claim?). Today SMT Arm cores are still very much the minority, so either the fashion sustained or their customers/implementors agree that more cores are better than fewer cores with SMT.

There are no AVX-512 instructions. But that's the x86 branding of the vector instructions that you can only implement with the right x86 licence. So it's tautological. Arm can have vector instructions and languages are even beginning to make portable interfaces for vectors on multiple architectures.

A hyperthread is only worth ~30% of a full core back of the napkin.

Can be closer to 40% in my experience with Intel when things are memory/cache bound (i.e. one thread is regularly stalled waiting for data), and I've seen above 55% in some cases with AMD's Zen microarch's SMT (Zen3).

Hyperthreading works by putting multiple arithmetic logical units such as an Adder bit shifter, or mux to work in parallel during some clock cycles where the executing code can utilize more ALUs. If the code executing was simply using the same ALU over and over again, such as repetitive summations, no additional performance gain will be possible from hyperthreading. A hyperthread doesn't necessarily have priority of the ALUs a normal core thread does

You seem to be confusing SMT (the formal term for hyperthreading) with superscalar. It's superscalar (and out-of-order which builds on it) which works by using multiple ALUs in parallel when possible. SMT then builds on that by allowing the unused ALUs to be used by other thread(s). If a single thread was simply using the same ALU over and over again, you'd have a large additional performance gain from SMT, since all the other ALUs would be available for the second thread.

What if the 2nd thread also needed the same ALU? What if the threads require synchronization and instructions cant be reordered? In both cases you would get no performance gain. Were talking about the same thing though which is effectively using parts of a core more efficiently when possible.

What a hyperthread brings to the table has huge variability. It can even be a net negative in certain cases. For the software ray-tracer I worked on, it brought 7-80% of a single core.

And security people hate them because side-channels.

It really depends on the core. An SMT8 POWER8 core might see an 80% throughput increase going from 1 to 2 threads but those have been accused of being two SMT4 cores standing on each other's shoulders wearing a trenchcoat. 30% for a mainstream x86 consumer core is a good average expected value but it'll tend to vary a lot by workload with lower IPC tasks tending to get better results.

Many years ago enabling hyperthreading on a single core PCs of my clients had doubled performance. It was multi-threaded multimedia type application.

Reply on news.ycombinator.com