Live data from Hacker News

TOP500 at ISC’26: We have a New Number 1 Supercomputer

chipsandcheese.com

21–30 of 90 posts

Re: TOP500 at ISC’26: We have a New Number 1 Supercomputer

#21

> Why aren’t these AI companies submitting to the TOP500 to show off their computing prowess? my knowledge is 10+ years out of date, but once upon a time if they'd chosen to, Google could have had _several_ entries in the top 10 of the TOP500 list It's just poker, they didn't want to tip their hand

Cloud computing is not a supercomputer. Different architecture, bandwitch, interconnectivity and latencies.

[deleted]

Re: TOP500 at ISC’26: We have a New Number 1 Supercomputer

#22
post #11

Earlier quoted context omitted.

Cloud computing is not a supercomputer. Different architecture, bandwitch, interconnectivity and latencies.

That's not nearly as true when you look at AI training clusters. They're basically supercomputers but without an FP64 focus. (These are the systems to which GP was referring at Google.)

Even before AI training clusters became important, Google has had an outstanding custom fabric (there's papers about it) together with the ability to tune NICs for their own cases, and "their own cases" meant nearly everything engineered within Google. Ethernet hardware has had low kernel latency and DMA for a long time; it's the rest of the stack that hurts. But as far back as the early 2010s (if not further back, that goes beyond my knowledge horizon), you could just make it not hurt, if you had the software engineers to do it.

Re: TOP500 at ISC’26: We have a New Number 1 Supercomputer

#23

TOP500 hasn't been a particularly useful measure of practical computing power in modern systems for many years because what it measures isn't a significant bottleneck in most real systems. It has become a measure of how much money someone is willing to spend for bragging rights. (HPCG is better in that it is a bit more bandwidth focused but still pretty narrow.) Most companies with huge systems don't participate.

I wonder if there would have been an opportunity to generate some finer-grained benchmarks with something like BiCGStab+ILU (or maybe CG+incomplete cholesky). Instead of CG+Gauss Seidel. The pitch being, you might have made different memory vs compute trade-offs with designing your cluster, but you should be able to select a fill-in factor for the preconditioner to suit it.

Re: TOP500 at ISC’26: We have a New Number 1 Supercomputer

#26

> Why aren’t these AI companies submitting to the TOP500 to show off their computing prowess? my knowledge is 10+ years out of date, but once upon a time if they'd chosen to, Google could have had _several_ entries in the top 10 of the TOP500 list It's just poker, they didn't want to tip their hand

I’ve worked on several systems that had enough flop/s to make it in the top 5-10, but for which we never submitted benchmarks. Sometimes their backend network layout technically would make them several smaller clusters for an HPL run, sometimes it’s because the cluster is too heterogeneous to get a good benchmark result, and sometimes it’s because the employer wants to keep a low profile.

Most of the time, it just that it’s a hassle. It takes a while to prep and tune a big hero run for benchmarking, and if you spend a billion dollars on a cluster, it’s making you a lot more than that. Taking it down for a day or two stops the money printers.

Re: TOP500 at ISC’26: We have a New Number 1 Supercomputer

#27
post #13

> Two cores are disabled per cluster. I’m sure there is a good reason for this, which is..?

Yield. Some fraction of cores had a speck of dust or something, but at 38/40 good cores per chip they got economical yield

Couldn't some chips have 40 good cores, while others have only 36? Do they all need to be exactly 38?

Re: TOP500 at ISC’26: We have a New Number 1 Supercomputer

#28
post #13

> Two cores are disabled per cluster. I’m sure there is a good reason for this, which is..?

Yield. Some fraction of cores had a speck of dust or something, but at 38/40 good cores per chip they got economical yield

And then even if some nodes had 40/40 "good" cores, it would make load balancing a lot more complicated if core counts vary. Easier to turn them off at the hardware level.
Post reply on HN