Hacker News Reader

Comment by panini-grammar | Hacker News Reader

Please note at the processors under the study -

Ampere processor has 128 cores ($5.8K or $45 per core), AMD processor has 64 cores ($7.9K or $123 per core), Intel processor has 40 cores ($8.1K or $202 per core),

Still Ampere's cost is 50% less than AMD/Intel's cost 'in per core' price. So, I think, article used correct word 'fraction'.

Yes, there may other advantages in Intel/AMD, which I do not have knowledge of the below ex: - clk speed, - L1/L2/L3 cache size and speed, - peripherals ... - etc (I tend to feel, Ampere is better in these too. Question is about chipset, SW base etc )

View on HN

are the cores equivalent though?

Good point. Intel's 40 cores are basically 80 cores due to hyper threading. Some people don't like hyperthreading for various reasons but it would be better to say the comparison is between 128 cores of Ampere and 80 cores of Intel.

But then again, number of cores is really a crude measure. We need to measure what those machines can really do...

P.S. Surprised I am being downvoted. If you only want to compare number of cores then I was implying that 80 is a better number than 40 to compare with 128. It gives you a rough idea of parallelism even though obviously HT does not give you 2x available cores all the time.

I also added a caveat that that number of cores is a crude measure anyways.

Last time I checked a hyper thread is ~75% slower than a normal one, so it’s roughly a 50 core cpu.

This depends heavily on your memory access patterns.

If you're chasing dependent loads around memory, like traversing a long fragmented linked list due to garbage code, you will get an absolutely perfect 100% speed up.

If you're already saturating the ALU on one thread, adding another to the core will probably slow you down with context switching and cache contention, and indeed well written numeric simulations on supercomputers often turn it off entirely.

However, most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety.

> most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety.

To be fair, crappy pointer-heavy data structures is not the only possible reason. Some useful algorithms are inherently serial.

For instance, all streaming parsers, compressors, or cryptography are inherently serial algorithms. An implementation gonna be relatively slow not because of RAM latency, but due to continuous chain of data dependencies between sequential instructions.

It’s technically possible to implement single-threaded code to handle multiple streams concurrently. Practically, more often that not it’s prohibitively complicated to achieve. However, doing that in hardware with two hardware threads running on the same core is way more manageable in terms of software complexity.

Yeah, garbage code was a little unfair.

I actually experimented with parallel fetching of multiple values out of a large persistent vector years ago, and saw nearly linear speed up for up to four fetches in parallel.

The code was awful and it would need to be a compiler generated thing for sure.

> The code was awful and it would need to be a compiler generated thing for sure.

C++ templates technically work, Eigen [1] is made entirely of them and the performance is pretty good. However, writing and debugging code in that style is hard, and the code is unreadable.

I tried T4 [2] to generate AVX intrinsics-heavy C++ code. At least the programming language is sane as opposed to C++ template metaprogramming. However, the code generation adds friction. Also, IDE integration is less than ideal, apparently Microsoft only cared about consuming T4 from C# projects.

I basically gave up, and usually writing normal C-like code with SIMD intrinsics, with just a few preprocessor macros, and no template metaprogramming. Unrolling things manually when necessary. At least the code is readable this way, and not too hard to debug. The compilers have these non-standard keywords/attributes to forcefully inline functions, they allow to reuse code instead of copy-pasting.

[1] https://eigen.tuxfamily.org/index.php?title=Main_Page

[2] https://en.wikipedia.org/wiki/Text_Template_Transformation_T...

That's interesting, thanks. TIL about T4/Eigen.

Actually, for my specific use case using AVX512 gather intrinsics would probably have worked OK and been cleaner - although I've heard they're pretty slow.

Once mitigations for Spectre, Meltdown, and whatnot are enabled, is hyper threading still a real gain?

Newer generation Intel CPUs deal with some of these issues on a hardware level.

See https://www.intel.com/content/www/us/en/developer/topic-tech...

So the level at which your Intel CPU is "crippled" would depend on how old it is, I guess.

Are these hardware fixes just bandaids or are the actual architectural flaws really fixed? Because didn't other processors that did speculative execution besides Intel's also have similar vulnerabilities?

A lot of expert level folks on here were saying that the architecture surrounding speculative execution would need a total removal or reengineering to fix it.

That isn't how hyperthreading works... It's completely dependent on the workload.

If your using the CPU core as efficiently as possible, you'd see no benefit from hyperthreading.

If your using it very poorly, you'd see a massive 2~x benefit.

When doing C++ compiles and also renders I see a 2x benefit generally. It is rare that I do not see something close to 1.5 to 2x speed ups.

That said I did switch from Intel over to an Apple M1 anyway.

Most compilers are one of the prime cases of inefficient architecture, the worse the larger the project gets. There is an awful lot of time lost waiting on I/O for hundreds to thousands of files (even assuming that there is enough RAM for the OS to cache all the files and metadata, every file that is read has at least three syscall context switches for open/read/close, dito for intermediate writes) and for process creation and destruction.

What I would find really, really interesting: a "single-process" compiler that has a global in-RAM cache for all source contents and intermediate outputs and can avoid the overhead of child processes... basically a model like Webpack or Parcel that has an inotify watcher and is constantly running. The JS world had no other choice with NodeJS/npm all but forcing the tooling to adapt to a lot of incredibly small source files, it's time for the "classic" world to adapt.

> If your using it very poorly, you'd see a massive 2~x benefit.

I find this statement tough to agree with. It depends on the kind of work your processors are doing: it is IO heavy work or are you running Math computations? There are other axes basically related to how much work can be done by the current thread while the other thread stalls waiting for data to be fetched (or other non-parallelizable dependencies to be available).

So if you're getting a high benefit you shouldn't necessarily feel embarrassed!

In benchmarks amperes cores are roughly as fast as a hyperthread on current gen Epyc. Sometimes more on heavily execution bound workloads, sometimes less.

Reply on news.ycombinator.com