Huawei unveils bigger iron KunLun server at CeBIT

Re: Dell M1000e Chassis Specs

I was going to say the same thing - saying "Cisco don't have a server like this", and then claiming Dell do when you are just describing a blade enclosure with 2 or 4-socket blades is disingenuous at best.

Re: How does cache coherency work on such a system

All of the up to 8-socket (glueless) designs just use standard Intel UPI (was QPI) connections between the processors - same as in a 4-socket box, except you get extra NUMA latency domains as you don't have enough UPI links to direct connect all CPUs together.

For the boxes that scale over 8S (like the KunLun and HPE's Superdome Flex), typically one of the UPI links to each processor is connected to custom silicon (think FPGAs) that act as agents/proxies to filter the coherency protocols and in some cases cache data as well. This is why these systems can typically use Gold Intel CPUs as well as Platinum CPUs - the limit of 4 UPI device IDs per group of processors in Gold CPUs isn't a problem as they access others via the agent/proxy silicon.

Re: Big Iron vs. Software

You're thinking about CPU here a lot more than memory - memory is the key on these types of system - the ability to ingest huge amounts of data and process it without having to go through complex data partitioning processes is what differentiates them - in many cases they only have the amount of CPUs they do because they have to be there to provide that much memory (i.e. constrained by current x86 processor design) - as we move into the world of persistent memory (3d x-point etc) combined with new memory semantic interconnects (like GenZ) we'll see these sorts of systems focus much more on delivering many 000s of TB of memory with the right quantity and type of SoCs composed from a fabric to fit specific workloads. Much more interesting that stitching 2-socket systems together with software (and all the constraints that brings).

Re: Big Iron vs. Software

I realise your point is about more than bloat, but bloat is still one of the key issues here.

'Big Iron' is a manifestation of something seen all the way up from the phone in your pocket, through tablets and laptops and desktops up to workstations: fantastic amounts of CPU power, memory and storage compensating for the fact that so much modern software, whether it's a phone app to take notes, a Windows program to edit images or a big red database running across a datacentre, is badly written, obscenely bloated and grotesquely inefficient.

I feel sure there is a computer science thesis brewing somewhere for a postgrad team prepared to take a couple of widely-used application systems at each current hardware point, refactor them from the ground up with a view to compactness, speed and efficiency, and demonstrate that it's possible to do all the same stuff with the same data just as fast—on kit that's three years old (or runs at a tenth the speed with a hundredth of the RAM).

Sometimes it's as if there is a kind of bizarre "waste race" going on, to see how much unnecessarily colossal computing power is needed for the latest generation of morbidly obese, unfit code.

But I'm realist enough to know that it all depends upon incentives. If computing power continues to get more bang for buck, and cheap second- and third-rate coders can knock out stuff that sort-of just about works, no matter that 100Mb of logic is delivered in a 10Gb fatberg of shonky code and endless libraries, with their many sins obscured by freakishly quick computing—who, if anyone, has a reason to seek efficiency?

As a one-time Ada practitioner (doing what you'd expect with Ada in the early 90s), I wonder how the kind of code found in, say, modern commercial aircraft systems compares with the stuff written for the corporate world's CRM, ERP systems and others. Obviously, I personally suspect that the efficiency of the former is orders of magnitude beyond that of the latter.

Maybe that's another thesis for someone?