48 Core ARM-64 processors from Cavium to challenge Xeons?

> If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases

Only if the tasks are trivially parallelizable. Any sequential dependencies among those tasks limit the effectiveness of parallelization. This is exactly what Amdahl's Law says.

> my humble laptop can do 8 threads at once, it's about time we started building office suites and browsers to take advantage of these processors.

Multiple browser tabs or open office documents are trivially parallelizable (eg, processes). The work within those tabs or documents is not linearly parallelizable -- running JS/macros, handling input, rendering, etc. Existing browser/office suites already do a pretty good job of splitting these tasks up, but they can't be split up arbitrarily into $core_count chunks.

There is a lots of interesting work on building office suites and browsers that can take advantage of parallelism. But the general consensus is that we need to invent new lower level tools first. See Rust + Servo and MSFT + M#

This whole thread is talking past each other.

Servers absolutely can have sequential dependencies, especially if there is a shared resource (eg, databases, IO, etc). If your application can make full use of all your cores without any inter-dependencies, great -- but that is not always the case.

"But from a whole datacenter perspective, I believe having servers with more cores is more efficient than having more servers with fewer cores, since data travels faster between more of the cores."

How are you looking at this?

From limited CompE background, my understanding was that moving data around core -> core burned a significant amount of power, even on the same die. (Using the comparison of one core vs two equally performing but separate cores)

n.b. I wasn't very clear in my comment; my experience was on the original Niagara 1 & 2, this was about 7-8 years ago, I'd guess. Hopefully things have improved since :)

If you narrow the statement down to "the highest performance network gear don't use Xeons", I suppose you get to be right. Almost all of my data-center security and packet inspection devices have a Xeon or two in them. The Cisco ASAs, Fireeye APT probes, Imperva WAFs, F5 load balancers, Sourcefire IDS. A couple of them also have packet processing support hardware (Endace cards, mostly), but that's mostly for taking the packet processing off the Xeons and letting them do just the inspection. But hey, we're only doing a couple of gig sustained, so we aren't the cool kids.

> Because this is Cavium's niche and biggest asset, and all their customers are doing networking.

That's their current niche. They're trying to get out of that niche, as the article clearly shows. (Let's be clear here -- the article might be a PR fluff piece, but it hasn't been written in an ignorance of the position of Cavium in networking). If they try to market this stuff for general purpose servers, they need to have an answer to the problem of parallelizing general purpose workloads. I don't see why this is such an offensive thing to point out.

I work at a company making networking equipment (mainly for telecoms), targeting the 20Gbps range at the top end, with Xeons. We could scale much higher for trivial workloads like switching, but the bottleneck is in actual processing where the wimpy MIPS cores aren't particularly tempting. The offerings of companies like Cavium have really not looked compelling compared to standard Xeons during the last 4 years or so.

Maybe if we'd started before that, we'd have started with a network processor and would naturally stick to it. But many of the more established telecom suppliers we've interacted with are likewise doing significant amounts of stuff with Xeons (standard hardware, or ATCA blades at the most exotic end). The only Cavium card I remember anyone using was doing 10Gbps of traffic that was so trivial, that even the low-spec 1U Xeon server the card was installed in could have handled it with the proper userspace NIC drivers.

This was also a flaw with AMD Bulldozer, no?