Qualcomm Demos 48-Core Centriq 2400 Server SoC in Action, Begins Sampling
anandtech.com
anandtech.com
On one meeting we had a typical discussion with ops guys:
- "why wouldn't we optimise our hardware utilisation by doing things a, b, and c."
- "hardware is crap cheap these days. If you need more capacity, just throw more servers at that"
- "is $24k a month in new servers crap cheap by your measure?"
- "comparatively to the amount of how much money these servers will make the same month, it is crap cheap. It is just a little less than an annual cost of mid-tier software dev in Russian office. We account only 12% increase in our revenue due to algorithmic improvements and almost 80 to more traffic we handle. A new server pays back the same month, and you and other devs pay off only in 2 years"
This pretty much summarises the viewpoint of a typical "big dot com ops manager" on hardware these days
The trick here is to make the new platform attractive enough it survives the stupid test, i.e. I'd be stupid not to try this out! That implies either very cheap or very fast or.. both. I presented on this at Linaro Connect USA in 2014: https://www.slideshare.net/mobile/linaroorg/leg-keynotekiko-...
However, there's a class of companies which don't buy servers individually but by the datacenter (or large parts of one).
If your company is building custom ASIC parts, FPGAs or one of the main customers of an entire chip architecture (eg Power9) then the math is different.
If Qualcomm thinks they can pull the same crap with proprietary modules in the server space and living 'off tree' they're in for a big surprise
Let's see what happens when a sysadmin can't apply a security fix or a needed upgrade to the kernel because Qualcomm's "proprietary driver" has not been updated
Qualcomm is notoriously closed with docs, about the same as Broadcom. Intel is starting to close up, but is still more open because of the x86/PC legacy.
However the points raised in this subthread are absolutely correct. Having upstream kernel support is vital so that any distro boots on any h/w and so that security fixes can be applied. Having good quality drivers is important, and documentation very helpful too.
Red Hat is taking the high road here and working with server manufacturers to make sure that upstream kernels work painlessly on ARM server hardware. We don't think that ARM in the datacenter can be a success otherwise.
This does not instill confidence of seriousness about documentation.
1) One quarter the price for equivalent performance for server task (e.g. 500 USD for 48-core Qualcomm vs 2000 USD for 16-core (32-thread) Intel). E.g. the problem of 48-core Cavium ARM chip was poor performance, that could be fixed by Qualcomm, with better IPC (big enough L3 cache, and 3 or 4 OooE).
2) One quarter the power usage
3) Reliable and affordable motherboards
4) Devices at similar price vs Intel ecosystem (high performance Ethernet, Infiniband, PCI-E SDD, etc.)
The first is very unrealistic because this is a market and ARM chip makers aren't Santa Clause, the second seems very, very unrealistic, because Intel already has the most efficient "big iron"-ish CPUs (just compare SAP benchmarks vs. power usage of Intel-based vs. POWER-based systems, for instance), and have been under continuous pressure for more than a decade to make things more efficient (because energy use and costs following from it are a major cost factor for all of Intel's biggest server customers). That alone doesn't mean that it's not possible to be better, of course, but it's a strong hint that if no one else managed to get close to Intel there that it maybe is a hard thing to pull off. In any case I think a four-fold efficiency increase is expecting way too much.
10 % better power efficiency at the same performance level per unit would already signal a huge win for ARM.
These are servers, not hypedisruptionmarkets. Not once where there 400 % efficiency increases in a single generation of anything.
I'm not sure the upfront effort/cost would be worth it for that savings alone, especially when Intel will just come along and say they'll have that savings in an x86 chip in 9 months without any software dev required.
What this could do for the big DC companies though, is provide them a lever to keep Intel on that path. That lever alone might be worth all the dev effort required to support 2 architectures in a DC for some customers - and even if it's not worth it empirically, it may make them feel like it is.
It's not surprising that Qualcomm don't publish this because they themselves probably don't know the yields from each bin in the final process.
Are there any real-life experiences? Would a different TCP stack such as mTCP[1] suffice?
Here is Linux htop with 288 hardware threads on the higher end KL:
http://www.admin-magazine.com/var/ezflow_site/storage/images...
https://xkcd.com/619/ isn't a joke.
Linux is the default operating system of huge NUMA systems with hundreds of CPUs / thousands of cores.
This chip has applications, but probably not in compute-heavy data centers. Networking gear maybe? Give each port in a switch an ARM core?
Is ARM going to hit a limit soon like x86 has?
Also in the comments of the article someone says that the x86 architecture is outdated vs SOC architecture.
Is this true? Does this mean we'll see SOC on desktop in the near future?
When it comes to the desktop, Intel is driven more by business concerns than technology. Putting the southbridge on the processor doesn't have that much advantage, but AFAIK Zen can run by itself with no external southbridge to some extent.
First there is diversity, while Intel or Atmel might announce 3 new CPUs with 2 or 3 variants each in a year, you have 10 manufacturers each with several new offerings so that it many many different CPUs.
The ARM "tax" (licensing fee) is lower then the minimum Intel "margin" (what they demand over the cost to produce) so the device maker's margins are better.
ARM is more open about its various interconnects so it is easy^h^h^h^hpossible to add features to an ARM CPU in a custom SoC. And to delete features if you don't need them. The Cortex M4 cpus without Floating Point is a good example, try to buy a Pentium processor without a built in FPU.
The thing that kept Intel in the driver's seat was software, and it was why (in my opinion) Itanium never had a chance over AMD64. Software, software, software. And once open source broke the server OS monopoly and smartphones became the computer for the masses, ARM was a good bet.
Is there a CPU saturation limit? That is an interesting question.