新纪录!谷歌 Cloud 计算出圆周率“ π” 第 100 万亿位数

简介: 新纪录!谷歌 Cloud 计算出圆周率“ π” 第 100 万亿位数

6 月 8 日,谷歌 Cloud 官方博客发文宣布了一项新纪录 —— 通过谷歌云已计算出圆周率“π”小数点后第 100 万亿位数!(文章末尾附有此次计算结果的最后 100 位数字)

image.png

相信大家都是在小学时候就知道圆周率“π”,但当时的我们只知道这个无限循环的数学常数约等于 3.14 或 3.1415926,最多能背到小数点后几位。殊不知,最近几年这个无理数已经随着技术的发展被科学家们进行了更精密的计算。

据了解,早在 2019 年谷歌就计算出“π”小数点后第 31.4 万亿位数,这在当年打破了世界纪录。然后,在 2021 年,瑞士 Grisons 应用技术大学 (University of Applied Sciences of the Grisons—UAS Grisons)的科学家们又计算了 31.4 万亿位常数,使其总数达到 62.8 万亿位小数。

此次,是谷歌云计算第二次对“π”这个数学常数的破纪录计算,且仅在三年内数字就增加了三倍,这一成就也验证了谷歌云基础设施方面的飞速发展。

谷歌 Cloud 计算背后的底层技术

据谷歌方面介绍,实现这一切其背后的底层技术,就是计算引擎 —— 谷歌云的安全和可定制的计算服务,以及它最近的几个新增和改进:包括 N2 云计算引擎系列、虚拟 NIC @ 100 Gbps 出口带宽,以及平衡持久磁盘(balanced Persistent Disks)。

下面为此次谷歌云计算在“π”小数点后第 100 万亿位数方面的工作概述:

程序:y-cruncher v0.7.8,作者:Alexander J.Yee

算法:Chudnovsky 算法

计算节点:n2-highmem-128,带 128 个 VCPU 和 864 GB RAM

开始时间:2021 UTC 10 月 14 日星期四 04:45:44

结束时间:周一至 3 月 21 日 04:16:52 2022 UTC

总运行时间:157 天 23 小时 31 分 7.651 秒

总存储大小:663 TB 可用,515 TB 已使用

总输入/输出:读取 43.5 PB,写入 38.5 PB,总计 82 PB

image.png

从过去到现在,我们可以看到由于计算机速度发展的越来越快,“π”小数点后面的位数也正在以指数方式增加。

  • 架构(Architecture)

由于“π”的计算是一种计算、存储和网络密集型任务,因此给所配置计算引擎环境的方式带来挑战。

image.png

谷歌云计算引擎提供了支持计算和 I/O 密集型工作负载的机器类型,选择了 n2-highmem-128(Intel Xeon、128 VCPU和864 GB RAM)可用内存量、网络带宽两个最重要的因素以满足高性能 CPU、大内存和 100 Gbps 出口带宽的需求。

存储方面,谷歌估计计算所需的临时存储大小约为 554 TB,并设计了一个由一个计算节点和 32 个存储节点组成的集群,用于总共 64 个 iSCSI 块存储目标。

主计算节点是一台运行 Debian Linux 11 的 n2-highmem-128 计算机,具有128 个 VCPU 和 864 GB 内存以及 100 Gbps 出口带宽支持,并采用了基于网络的共享存储体系结构。

每台存储服务器都是一台 n2-highcpu-16 计算机,配置有两个 10359 GB 分区平衡持久磁盘。N2 机器系列提供了平衡的性价比,当配置 16 个 VCPU 时,它提供了 32 Gbps 的网络带宽,且可选择使用最新的 Intel Ice Lake CPU 平台,这使其成为高性能存储服务器的良好选择。

  • 自动化解决方案

谷歌云计算采用 Terraform 来设置和管理集群,且编写了两个 shell 脚本来自动化关键任务,Terraform 脚本创建了 guest OS(来宾)策略,以帮助确保自动安装所需的软件包,guest OS 操作系统安装过程的一部分由启动脚本处理,这种方式只需几个命令就可以重新创建整个集群。

  • 100 Gbps 网络

早在 2019 年,谷歌进行“π”小数点后第 31.4 万亿位的计算时,其云计算机器出口吞吐量只有 16 Gbps。这一次,n2-highmem-128 机型支持高达 100 Gbps 的出口吞吐量,这意味着带宽在短短三年内增长了 600%。

此次,网络驱动程序也从 virtio 更改为新的谷歌虚拟 NIC(gVNIC)。gVNIC 是一种新的设备驱动程序,与谷歌的 Andromeda 虚拟网络堆栈紧密集成,以帮助实现更高的吞吐量和更低的延迟,这也是 100 Gbps 出口带宽的要求。

  • 存储设计

持久磁盘(PD)是计算引擎虚拟机的一种持久的高性能存储选项,此次谷歌选择使用 balanced PD —— 一种新型的持久性磁盘,可提供高达 1200 MB/s 的读写吞吐量和 15-80k 的 IOPS,成本约为 SSD PD 的 60%。此存储配置文件是 y-cruncher 的最佳选择,它需要高吞吐量和中等 IOPS。

综述

以上,所有这些微调和基准测试共同使得谷歌此次实现了“π”小数点后面第 100 万亿位数的计算。

image.png

计算完成后,谷歌还用另一种算法(Bailey–Borwein–Plouffe 公式)验证了最终的数字,最终该公式被验证成功。

以下是本次谷歌云计算对“π”小数点后第 100 万亿位数计算结果的最后 100 位数字:

4658718895 1242883556 4671544483 9873493812 1206904813

2656719174 5255431487 2142102057 7077336434 3095295560

如果大家想要了解此次计算的整个数字序列,可登录谷歌云计算的演示网站上查看。

参考链接:https://cloud.google.com/blog...

相关文章
|
人工智能 搜索推荐 算法
AI与未来教育:个性化学习的实践
【10月更文挑战第3天】在21世纪科技浪潮中,人工智能(AI)正重塑教育领域,尤其在个性化学习方面展现出巨大潜力。本文探讨了AI如何通过智能评估、定制化学习路径、情感识别及虚拟助教等方式,提升教育质量和效率,激发每个学生的学习潜能。尽管面临数据隐私和技术普及等挑战,AI与未来教育的融合正开启新篇章,有望实现真正的“因材施教”。
|
数据安全/隐私保护
INFO sasl.SaslDataTransferClient: SASL encryption trust check: localHostTrusted = false, remoteHostT
这篇文章描述了作者在执行HDFS操作时遇到的SASL加密信任检查日志信息问题,其中`localHostTrusted`为`false`,并且有时候这个日志信息会出现,有时候不会。
INFO sasl.SaslDataTransferClient: SASL encryption trust check: localHostTrusted = false, remoteHostT
|
存储 分布式计算 Hadoop
HadoopCPU、内存、存储限制
【7月更文挑战第13天】
657 14
|
JSON Java API
谷粒商城笔记+踩坑(7)——新增商品,请求参数转vo类
效果展示、配置、启动会员模块、获取当前分类关联的品牌(不用分页)、获取当前分类下的分组及其关联的属性、新增商品、添加复合配置、限制内存、报错loadbalancer解决
谷粒商城笔记+踩坑(7)——新增商品,请求参数转vo类
|
存储 安全 Java
Java修仙之路,十万字吐血整理全网最完整Java学习笔记(进阶篇)
本文是Java基础的进阶篇,对异常、集合、泛型、Java8新特性、I/O流等知识进行深入浅出的介绍,并附有对应的代码示例,重要的地方带有对性能、底层原理、源码的剖析。适合Java初学者。
Java修仙之路,十万字吐血整理全网最完整Java学习笔记(进阶篇)
|
人工智能 自然语言处理 机器人
谷歌将大模型集成在实体机器人中,能看、听、说执行57种任务
【9月更文挑战第17天】近年来,人工智能在多模态大模型领域取得显著进展。谷歌最新研发的Mobility VLA系统,将大模型与实体机器人结合,实现了视觉、语言和行动的融合,使机器人能理解并执行复杂多模态指令,如“我应该把这个放回哪里?”系统在真实环境测试中表现出色,但在计算资源、数据需求及伦理问题上仍面临挑战。相关论文发布于https://arxiv.org/abs/2407.07775。
250 9
|
存储 项目管理 开发工具
|
机器学习/深度学习 传感器 人工智能
探索人工智能的未来:机遇与挑战
【8月更文挑战第6天】本文深入探讨了人工智能(AI)的未来发展路径,包括技术进步、应用扩展和伦理法规等方面。文章分析了AI技术在医疗、金融、交通等领域的应用案例,讨论了AI发展过程中可能遇到的技术瓶颈、数据隐私和就业影响等挑战,并提出了相应的解决策略。最后,文章以开放性问题结束,鼓励读者思考如何平衡AI技术的利与弊。
uniapp滑动到一定的高度后固定某个元素到顶部效果demo(整理)
uniapp滑动到一定的高度后固定某个元素到顶部效果demo(整理)
|
Cloud Native 安全 Java
代码圈复杂度治理小结
我们一直在说系统很复杂,那到底什么是系统复杂度呢?作为团队的稳定性底盘负责人,也经常和大家探讨为什么会因为圈复杂度高而被扣分。那么,怎么才能写的一手可读,可扩展,可维护的好代码?本文作者尝试结合在团队内部的实践,分享下过程中心得。
代码圈复杂度治理小结