Ampere Altra Announced - Offering Up To 80 Cores Per Socket

[Guest]

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.

[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.

[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.

[Guest]

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.