每月 5 美元的虚拟机可以跻身 1993 年的超算前三
超算 TOP500
![](/data/attachment/album/202311/16/000750tl6lelevnlxlxn8e.png)



> 
> 当然，如果你真的关注性能，市面上自然有更出色的选择。
> 
> 
> 


今年是 TOP500 公开排名全球最快超级计算机 30 周年。


为纪念这个重要的里程碑，也因应科罗拉多州正在举行的年度超级计算大会，我们想弄个有趣但稍显愚蠢的实验：看看以今天技术，我们能以多低的成本重现 1993 年超级计算机十强的性能。于是，我们在云上运行了几台虚拟机，并对 HPLinpack 基准进行了编译测试。这里简单透露一下：我们这项实验的结果，你可能并不会太震惊。


到 1993 年年末，最快的超级计算机是日本国家航空实验室的富士通数值风洞。这台装备了 140 个 CPU 核心的系统，能够实现 124 GigaFLOPS 的双精度（FP64）计算能力。


如今，我们的系统已经 [突破](https://www.theregister.com/2022/05/30/us_frontier_supercomputer_ousts_japans/) 了 exaFLOPS 的难关，然而在 [1993 年 11 月](https://www.top500.org/lists/top500/1993/11/)，如何在功率最高的十个系统中占据一席之地呢？只要你的 FP64 性能超过了美国 [CM-5/544](https://www.top500.org/system/167021/) 机型的 15.1 GigaFLOPS。因此，我们设定的目标是让云虚拟机超过 15 GigaFLOPS 的性能。


在我们分析结果之前，有几点值得一提。如果我们选用了支持 GPU 的实例，我们知道我们能够达到更高的性能。不过，云端的 GPU 实例租赁并不便宜，并且在 2000 年年中至年底，GPU 才真正开始广泛出现在 TOP500 的超级计算机中。此外，在 CPU 上运行 Linpack 比在 GPU 上运行要容易得多。


这些测试只是为了纪念 30 周年，只是稍微有点新颖，决不具有科学严谨或详尽无遗的特征。


### 一台 5 美元的云虚拟机对比一部 30 年前的 TOP500 超级计算机


但在开始测试前，我们需要开启一对 VPC。在本次测试中，我们选择在 Vultr 上运行 Linpack，但其实在 AWS，Google Cloud，Azure，Digital Ocean 或者是你喜欢的任何云服务商上，这都同样适用。


首先，我们启动了一个月费 5 美元的虚拟机实例，它具备了一个共享的 vCPU，1GB 的内存和 25GB 的存储。准备就绪后，我们便启动了 Linpack 的编译。


在这，事情可能会有些复杂，因为我们实际上可以对系统进行一些调优，挤出一些额外的 FLOPS。然而，考虑到这只是一个测试，也为了尽可能保持简单，我们选择了依照 [这个指南](https://gist.github.com/Levi-Hope/27b9c32cc5c9ded78fff3f155fc7b5ea) 进行操作。此份操作手册是基于 Ubuntu 18.04 编写的，但是我们发现在 20.04 LTS 上运行也一切正常。


为了产生我们的 HPL.dat 文件，我们利用了一个巧妙的 [表单](https://www.advancedclustering.com/act_kb/tune-hpl-dat-file/)，它会自动产生一个优化版的 Linpack 运行配置。


我们对几种不同类型的虚拟机进行了三次基准测试，并从每次运行中挑选出最高的得分。以下就是我们的发现：




| 实例类型 | vCPU | RAM (MB) | 存储 (GB) | Rmax GFLOPS | 每月费用 (美元) |
| --- | --- | --- | --- | --- | --- |
| Regular shared | 1 | 1024 | 25 | 31.21 | 5 |
| Premium shared | 1 | 1024 | 25 | 51.85 | 6 |
| Premium shared | 2 | 2048 | 60 | 87.46 | 18 |
| Premium shared | 4 | 8192 | 180 | 133.42 | 48 |


从我们的测试结果可以看出，一个单一的共享 vCPU 在与 1993 年 11 月十大超级计算机的比较中表现出颇为出色的性能。


我们通过一个 CPU 线程就获得了 31.21 GigaFLOPS 的 FP64 性能，这使得我们的虚拟机与 1993 年排名第三的超级计算机 —— 明尼苏达超级计算中心的 30.4 GigaFLOPS [CM-5/554](https://www.top500.org/system/167059/) Thinking Machines 系统相提并论。这确实令人吃惊，因为那台系统拥有 544 个 SuperSPARC 处理器，而我们的系统只有一个 CPU 线程，虽然我们的系统运行在更高的时钟速度下。


如你从上面的图表中所见，每月多花 1 美元，我们的性能跃升至 51.85 GigaFLOPS，而选择一个价值 18 美元的“高级”共享 CPU 实例，双线程使我们进一步接近 87.46 GigaFLOPS 的性能。


然而，要超过 [富士通的数值风洞](https://www.top500.org/system/173279/)，我们需要升级到四个 vCPU 的虚拟机，由此我们抓取到了 133 GigaFLOPS 的 FP64 性能。然而不幸的是，升级到四个线程的费用跳到了每月 48 美元。达到这个价格，Vultr 实际上是在销售部分 GPU，我们预计如果采用 GPU，性能应会有显著提升，效率也会更高。


### 更好的选择


我们需要明确的是，这些都是我们选择的共享类型实例。一般来说，共享实例意味着在一定程度上进行了超额配置。


由于共享实例可能会受到其他租户的影响，这也使得性能有时难以预知，甚至每次运行的性能都可能略有不同，这主要取决于云区域中主机系统的载荷状态。


在我们的非常不科学的测试中，我们并未观察到太多的性能变化。我们想这可能是因为核心并未处在过高的负载下。在专有 CPU 实例上进行同样的测试，结果与我们每月 6 美元的共享实例相若，但成本高达五倍。


但是，除了这场小实验的新奇趣味之外，这没太多实际意义。如果你需要在短时间内获得大量 FLOPS，有许多已优化的 CPU 和 GPU 实例可供选择。它们的成本无法与每月 5 美元的实例相媲美，然而大多数实例是按小时账单的，因此实际成本将取决于你完成工作的迅速程度。


此外，让我们不要忘记，你的智能手机与这些存在已久的 30 年老计算系统相比，又会有怎样的对比呢？


*（题图：MJ/16cf957e-a4e4-43b1-99b2-df0574a064dc）*




---


via: <https://www.theregister.com/2023/11/14/five_dollar_supercomputer/>


作者：[Tobias Mann](https://www.theregister.com/Author/Tobias-Mann) 译者：[ChatGPT](https://linux.cn/lctt/ChatGPT) 校对：[wxy](https://github.com/wxy)


OK
# As the Top500 celebrates its 30th year, with a $5 VM you too can get into the top 10 ... of 1993

## But if you really care about performance, there are better options out there, natch

SC23 This year marks the 30th anniversary of the Top500 ranking of the world's publicly known fastest supercomputers.

In celebration of this fact and with the annual Supercomputing event underway in Colorado, we thought it'd be fun, if a bit silly, to see how cheaply we could achieve the performance of a top-ten supercomputer from 1993. So, we spun up a few virtual machines in the cloud and compiled the HPLinpack benchmark. Spoiler alert: you may not be too shocked by this experiment of ours.

At the end of 1993, the fastest supercomputer on record was Fujitsu's Numerical Wind Tunnel, located at Japan's National Aerospace Lab. With a whopping 140 CPU cores, the system managed 124 gigaFLOPS of double-precision (FP64) performance.

Today we have systems [breaking](https://www.theregister.com/2022/05/30/us_frontier_supercomputer_ousts_japans/) the exaFLOPS barrier, but [in November 1993](https://www.top500.org/lists/top500/1993/11/), all you needed to do to claim a spot among the 10 most powerful systems was to manage better than the US [CM-5/544](https://www.top500.org/system/167021/)'s 15.1 gigaFLOPs of FP64 performance. So, the target for our cloud virtual machine to beat was 15 gigaFLOPS.

Before we dig into the results, a few notes. We know we could have achieved much, much higher performance if we'd opted for a GPU-enabled instance, however these aren't exactly cheap to rent in the cloud, and GPUs didn't really start appearing in Top500 supercomputers until the mid to late 2000s. It's also much simpler to get Linpack running on a CPU than on a GPU.

These tests were run for the novelty of it, to mark the 30th anniversary, and are by no means scientific or exhaustive.

### A $5 cloud VM versus a 30-year-old Top500 super?

But before we could get to testing, we needed to spin up a couple VPCs. For this run we opted to run Linpack in Vultr but this would just as well in AWS, Google Cloud, Azure, Digital Ocean, or whatever cloud provider you prefer.

To start off, we spun up a $5/mo virtual machine instance with a single shared vCPU, 1GB of RAM and a 25GB of storage. With that out of the way, it was time to compile Linpack.

This is where things can get a little complicated since there's actually a fair bit of tweaking and optimization that can be done to eke out a few extra FLOPS. However, for the purposes of this test and in the interest of keeping things as simple as possible, we opted for this guide [here](https://gist.github.com/Levi-Hope/27b9c32cc5c9ded78fff3f155fc7b5ea). That documentation was written for Ubuntu 18.04 though we found it worked just fine in 20.04 LTS.

To generate our HPL.dat file we used this nifty [form](https://www.advancedclustering.com/act_kb/tune-hpl-dat-file/) that automatically generates an optimized configuration for a Linpack run.

We ran the benchmark three times for a few different VM types and selected the highest score from each run. Here are our findings:

Instance type | vCPUs | RAM (MB) | Storage (GB) | Rmax GFLOPS | $/month |
---|---|---|---|---|---|

Regular shared | 1 | 1024 | 25 | 31.21 | 5 |

Premium shared | 1 | 1024 | 25 | 51.85 | 6 |

Premium shared | 2 | 2048 | 60 | 87.46 | 18 |

Premium shared | 4 | 8192 | 180 | 133.42 | 48 |


As you can see, our totally unscientific test results showed a single shared vCPU compares quite favorably to November 1993's ten most power supers.

A single CPU thread netted us 31.21 gigaFLOPS of FP64 performance, putting our VM in contention for the number-three ranked supercomputer in 1993, the Minnesota Supercomputing Center's 30.4 gigaFLOPS [CM-5/554](https://www.top500.org/system/167059/) Thinking Machines system. Not bad considering that system had 544 SuperSPARC processors while ours had a single CPU thread, albeit running at much higher clock speeds, of course.

As you can see from the chart above, an extra $1/mo saw performance leap to 51.85 gigaFLOPS, while stepping up to an $18 "premium" shared CPU instance with two threads got us closer to 87.46 gigaFLOPS.

However, to beat Fujitsu's [Numerical Wind Tunnel](https://www.top500.org/system/173279/) required stepping up to a four vCPU VM from which we squeezed 133 gigaFLOPS of FP64 goodness. Unfortunately, jumping up to four threads wasn't nearly as cheap at $48/mo. At that price, Vultr actually sells fractional GPUs which we expect would perform comically better, and will be quite a bit more efficient.

### Better options out there

Something we should mention is these were all shared instances, which usually means they've been over provisioned to some degree.

This can lead to unpredictable performance that could vary from run to run depending how heavily loaded the host system is in its cloud region.

In our highly unscientific runs we didn't see much variation. We think this is because the cores just weren't that heavily loaded. Running the same test on a dedicated CPU instance rendered near identical results as our $6/mo instance but at 5x the cost.

But beyond the novelty of this little experiment, there's not really much point. If you need to get your hands on a bunch of FLOPS on short notice, there are plenty of CPU and GPU instances optimized for this kind of work. They won't be anywhere as cheap as a $5/mo instance, but most these are actually billed by the hour so for real-world workloads the actual cost is going to be determined by how quickly you can get the job done.

And never mind how your smartphone compares to these 30-year-old systems.

In any case, *The Register* will be on the ground in Denver this for [SC23](https://search.theregister.com/?q=sc23) where we'll be bringing you the latest insights into the world of high-performance computing and AI. And for more analysis and commentary, don't forget our pals [at The Next Platform](https://www.nextplatform.com/), who have the conference covered too. ®

24