Ampere Altra Announced - Offering Up To 80 Cores Per Socket

I'm quoting this so you can come back and read it after you've tried to parallize even a non-trivial application to scale to 80 cores.

If I was trying to parallelize an application, then I would go for multi-instance/scaling/load-balancing support. I wouldn't use/depend on some internal locking mechanism, but would somehow externalize it (e.g. database locks, or dedicated service,...). Also, I would design an architecture to support scale-out/horizontal-scaling,...

The applications I'm talking about are already existing, and running,... for example JIRA didn't support to have more than one server instance for the long time. However, it is/was native Java application utilizing as many threads as there are available. Currently, JIRA starts to support multi-instance deployments, because it's a product software. However, for existing custom-developed software, it might not be worth to add multi-instance support, e.g. scale-up or rewrite from scratch.

[willmore]

Depends on application type... Web servers can utilize many cores, as basically each request is handled separately. Only "serialized" execution is modification of same data (which is handled by databases/locks which are already paralelized, or by other synchronization system). Also, the vast majority of request are for reading data. And, some web application products don't support clustering (as they maybe depend on internal serialization, and DB based locks aren't enough), so getting more performance by having more cores is very useful.

I'm quoting this so you can come back and read it after you've tried to parallize even a non-trivial application to scale to 80 cores.

[willmore]

You don't have to recompile for the arm architecture. Almost all open source projects have ready-made arm architecture versions. The arm server is not a novelty either. It started to appear in 2013.

If you're trying to tune for all of the architectural features of a specific CPU, then you have to recompile for *any* architecture variation--even amongst x86_64.

If by 'ready-made' you mean they compile with little difficulty and actually run, then you're right, but that's not what someone looking at benchmarks of a high end system like this is asking when they look to see if their software supports that architecture. They're asking if it takes advantage of instruction extensions and other features of it--by including assembly paths for important sections of code, etc. Just saying "it compiles" doesn't address the question.

Absolutely , parallelizing even simple tasks can be surprisingly difficult and with more cores you got more overhead for simply managing the darn thing, cache locality and that kind of stuff plays a huge role , but as I/O get more and more parallelized with blk-mq and when filesystems such as btrfs (eventually) scales to utilize CPU's and multiple disks better then all in all more (slightly) slower cores may be a bit benefit compared to a superfast single thread performance. It all depends on your workload of course. Case closed

Depends on application type... Web servers can utilize many cores, as basically each request is handled separately. Only "serialized" execution is modification of same data (which is handled by databases/locks which are already paralelized, or by other synchronization system). Also, the vast majority of request are for reading data. And, some web application products don't support clustering (as they maybe depend on internal serialization, and DB based locks aren't enough), so getting more performance by having more cores is very useful.

[maxmadzz]

80 cores vs 64 cores and just eeking out a win in one of the easiest multi-core benchmarks? That's not much of an endorsement. The TCO graphs are notorious for BS as well as the 'T' is often not very total. Even if the processors were free, a big machine stuffed full of solid state drives and TBs of DRAM would see little improvement.

I do appreciate more entrants in the server market. It's been clear what even one competetive alternative to Intel has done for performance and performance/cost. A second should help some more. But it's too soon to say if they're competetive in any real sense. I'm quite willing to recompile the world and retune software for a completely different architecture, but that comes with different costs for different workloads. I'm lucky enough to run most of my software from well maintained open source projects. Not everyone shares similar benefits.

You don't have to recompile for the arm architecture. Almost all open source projects have ready-made arm architecture versions. The arm server is not a novelty either. It started to appear in 2013.

[willmore]

It all depends on your workload of course. Case closed

Exactly. People, if it really matters (you're going to make some kind of financial commitment), *test your own application*. Don't just follow some benchmarks at a website--no matter how much you like it.

[waxhead]

If work parallelized that well, then you would be right. But it so rarely does. Even embarrasingly parallel tasks end up fighting over some resource--memory I/O, heat dissipation. Of course, you pick the processor that is better for your workload. Amdahl always comes in to take his cut after all.

Absolutely , parallelizing even simple tasks can be surprisingly difficult and with more cores you got more overhead for simply managing the darn thing, cache locality and that kind of stuff plays a huge role , but as I/O get more and more parallelized with blk-mq and when filesystems such as btrfs (eventually) scales to utilize CPU's and multiple disks better then all in all more (slightly) slower cores may be a bit benefit compared to a superfast single thread performance. It all depends on your workload of course. Case closed

[willmore]

Well given your example yes, but consider 2 cores at the speed of 1.2 and 1 core at the speed of 2 for example... 2x1.2=2.4, and 1x2=2.0
Also 10 cores at speed 1 beats 8 cores at speed 1.2 if the workload is parallelized. 10x1=10, 8x1.2=8=9.6

If work parallelized that well, then you would be right. But it so rarely does. Even embarrasingly parallel tasks end up fighting over some resource--memory I/O, heat dissipation. Of course, you pick the processor that is better for your workload. Amdahl always comes in to take his cut after all.

[waxhead]

Unless you're renting out cores and charge the same for all cores, I don't know of a time this would be true. You can always have one core do two jobs, but you can't always have two cores do one job faster. Given 2 cores at speed 1 or 1 core at speed 2, you're a fool to pick the 2 cores. The only exception may be latency sensitive jobs or when dealing with realtime activities--not likely something you'd see machine like this used for.

Well given your example yes, but consider 2 cores at the speed of 1.2 and 1 core at the speed of 2 for example... 2x1.2=2.4, and 1x2=2.0
Also 10 cores at speed 1 beats 8 cores at speed 1.2 if the workload is parallelized. 10x1=10, 8x1.2=8=9.6

[willmore]

this works both ways - you can't get half of core when fast core is faster than you need

Have you never heard of multitasking? We've been using fractional cores for decades.