Polymath Collector

Natural Logarithm of 10 (Log(10))

2020-09-06T14:25:00+00:00

The Natural Logarithm of 10 (Log(10))

Please cite:
Kim, S. Normality Analysis of Current World Record Computations for Catalan’s Constant and Arc Length of a Lemniscate with a=1. arXiv Preprint arXiv:1908.08925
if this article or the calculated digits were useful.

This world record computation of 1,200,000,000,100 digits by Seungmin Kim was done from Fri Jul 31 18:13:07 2020 to Tue Aug 18 10:02:59 2020 using the Primary Machin-like Formula (4 terms) algorithm. This time again after most of my computations, I have verified the calculation using the Secondary Machin-like Formula (4 terms) algorithm from Wed Aug 19 10:48:52 2020 to Sun Sep 6 12:14:40 2020.
Validation file generated by y-cruncher v0.7.8 Build 9506 for computation, and y-cruncher v0.7.8 Build 9506 for the verification run:
Computation: https://web.archive.org/web/20200915115810/http://www.numberworld.org/y-cruncher/records/2020_8_18_log10.txt
Verification: https://web.archive.org/web/20200915075933/http://www.numberworld.org/y-cruncher/records/2020_9_6_log10.txt

\[\ln(a\cdot 10^n) = \ln a + n \ln 10\]

An important identity of $\ln 10$ enabling effective computation of natural logarithms of numbers with scientific notation (Wikipedia)

Natural logarithm of 10 is defined as the logarithm function value of 10 where the base is $e$ (of which the function is also the inverse function of the exponential function). All natural logarithms of any natural number larger than 1 are proved irrational and transcendental with the Lindemann–Weierstrass theorem. It also has the BBP-type representation $\ln 10 = \frac{1}{16} \sum_{k = 0}^\infty \left(\frac{24}{4k+1}+\frac{20}{4k+2}+\frac{6}{4k+3}+\frac{1}{4k+4}\right) \frac{1}{16^k}$ (Source), which could be useful in verifying future record computations because it does not have to compute all the digits again after the first computation.

The Machin-like formulas are based on the identity of inverse hyperbolic cotangent $coth^{-1} x = \frac{1}{2}[\ln(1 + \frac{1}{x}) - \ln(1 - \frac{1}{x})]$, as the inverse hyperbolic cotangent has a trivial series expansion formula. This is trivial to induce and is in material discussed in calculus textbooks. If such similar equations are added or subtracted as appropriate to leave only one logarithm value on the right side, that becomes the quickly converging formulas used for computations.

\[\ln 10 = 239 coth^{-1} 99 - 59 coth^{-1} 449 + 113 coth^{-1} 4801 - 33 coth^{-1} 8749 \\ = 478 coth^{-1} 251 + 180 coth^{-1} 449 - 126 coth^{-1} 4801 + 206 coth^{-1} 8749\]

Primary (4 terms) and secondary (4 terms) Machin-like formulas for $\ln 10$

Same as all other mathematical constants, I have used y-cruncher by Mr. Alexander J. Yee for this computation. This program is commonly used for stress testing and benchmarking overclocked PC builds (obviously this program performs a very rigorous computation), along with fellow mathematical computing program Prime95 and linear algebra program Linpack.
The computation was theoretically about twice as intensive as Pi and half as intensive as Apéry’s constant. Unlike other series, the natural logarithms have multiple separate inverse hyperbolic cotangent series to compute the final result so each series are quite less intensive than ordinary but there are multiple series computations and accumulations. The primary formula and the secondary formula took around the same time as both have the same 4 terms.

Computation:
System information:
Operating System: Linux 5.5.6-1.el7.x86_64 x86_64
Processor(s):
Name: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
Logical Cores: 72
Physical Cores: 36
Sockets: 2
NUMA Nodes: 2
Base Frequency: 2,299,987,856 Hz

My first computation used two Xeon CPU sockets from the Haswell era (and thus supports AVX2 SIMD vector operations that are used crucially in vector computations like y-cruncher) as I decided the Xeon Scalable Skylake Purley processors that support AVX-512 was overkill since I was gonna confront I/O bottlenecks anyways. The time would not have had much difference from using just one CPU socket. I have optimized I/O throughput further by changing the Bytes/Seek parameter and allocating more I/O Buffer to reach RAID-level performance in my file systems.

Start Date: Fri Jul 31 18:13:07 2020
End Date: Tue Aug 18 10:02:59 2020
Total Computation Time: 1470494.849 seconds
Start-to-End Wall Time: 1525791.855 seconds
CPU Utilization: 1070.37 % + 15.05 % kernel overhead
Multi-core Efficiency: 14.87 % + 0.21 % kernel overhead

The multi-core efficiency improved slightly with good Bytes/Seek optimization compared to the computation of Log(2), and of course did not reach the utilization possible by the CPUs since I was using swap storage (Dr. Ian Cutress’s Lemniscate Constant calculation had a multi-core efficiency of 94.04 % and CPU utilization of 9027.61 %, which means that the CPU was not bottlenecked by other factors). I also used the Cilk Plus Work-Stealing multiprocessing framework along with the dynamic version of y-cruncher.

Memory:
Working Memory: 696,086,196,992 ( 648 GiB)
Total Memory: 697,932,185,600 ( 650 GiB)
Logical Largest Checkpoint: 2,242,654,353,976 (2.04 TiB)
Logical Peak Disk Usage: 6,516,333,392,080 (5.93 TiB)
Logical Disk Bytes Read: 420,720,903,373,472 ( 383 TiB)
Logical Disk Bytes Written: 368,315,890,119,480 ( 335 TiB)

Disk operation was similar to the verification computation of Log(2) and was similarly less than a half compared to Apéry’s constant because the algorithm is easier and is split to smaller computations, and this contributed to a faster computation along with more RAM.
One caveat is that HDD I/O speeds are again great bottlenecks to virtually any other component, and perhaps having Optane DIMMs or even more normal RAM can help the speed of the computation speed greatly.

Verification:
System information:
Operating System: Linux 3.10.0-693.21.1.el7.x86_64 x86_64
Processor(s):
Name: Intel(R) Xeon(R) Gold 5220 CPU @ 2.20GHz
Logical Cores: 72
Physical Cores: 36
Sockets: 2
NUMA Nodes: 2
Base Frequency: 2,194,728,160 Hz

Start Date: Wed Aug 19 10:48:52 2020
End Date: Sun Sep 6 12:14:40 2020
Total Computation Time: 1520754.941 seconds
Start-to-End Wall Time: 1560348.114 seconds
CPU Utilization: 932.46 % + 37.40 % kernel overhead
Multi-core Efficiency: 12.95 % + 0.52 % kernel overhead

Memory:
Working Memory: 748,959,060,352 ( 698 GiB)
Total Memory: 751,290,873,600 ( 700 GiB)
Logical Largest Checkpoint: 2,252,980,350,032 (2.05 TiB)
Logical Peak Disk Usage: 6,533,333,252,760 (5.94 TiB)
Logical Disk Bytes Read: 426,298,248,606,512 ( 388 TiB)
Logical Disk Bytes Written: 373,070,460,848,488 ( 339 TiB)

This build has a slower filesystem than the system used for computation, and thus caused the verification computation to take more time even with two Cascade Lake Xeon CPU sockets that support AVX-512. CPU utilization was impacted because of slower disk even when the CPU was more recent. Total Computation Time and Disk R/W were slightly higher.

I hope computing and sharing the results can result in more insight that can be used by mathematicians for new mathematical knowledge.

If you want to take a look at the digits for the Natural Logarithm of 10 (Log(10)), you can download it from This Link (Almost 2 TB total but don’t worry, it will just redirect to a registry with a link to download).

Note that the digits are released under an Attribution-NonCommercial-NoDerivatives 4.0 International License, which prohibits commercial use and distribution of remixed, transformed, or built upon versions without consent. Proper attribution and indication of changes are required even if it is not a prohibited use case.

Archive for computation results in the y-cruncher website: https://web.archive.org/web/20200915070251/http://www.numberworld.org/y-cruncher/
Special thanks to Mr. Alexander J. Yee for developing and releasing y-cruncher and providing advice, and the Internet Archive for hosting the computed digits.

Natural Logarithm of 2 (Log(2))

2020-08-19T11:18:00+00:00

The Natural Logarithm of 2 (Log(2))

This world record computation of 1,200,000,000,100 digits by Seungmin Kim was done from Tue Jul 14 14:02:26 2020 to Wed Jul 29 01:09:58 2020 using the Primary Machin-like Formula (3 terms) algorithm. This time again after most of my computations, I have verified the calculation using the Secondary Machin-like Formula (4 terms) algorithm from Thu Jul 30 16:47:49 2020 to Wed Aug 19 03:00:23 2020.
Validation file generated by y-cruncher v0.7.8 Build 9506 for computation, and y-cruncher v0.7.8 Build 9506 for the verification run:
Computation: https://web.archive.org/web/20200810062417/http://www.numberworld.org/y-cruncher/records/2020_7_29_log2.txt
Verification: https://web.archive.org/web/20200915095126/http://www.numberworld.org/y-cruncher/records/2020_8_19_log2.txt

\[\ln 2 = \sum_{n=1}^\infty \frac{(-1)^{n+1}}{n}=1-\frac12+\frac13-\frac14+\frac15-\frac16+\cdots\]

An identity of $\ln 2$ called the alternating harmonic series (Wikipedia)

Natural logarithm of 2 is defined as the logarithm function value of 2 where the base is $e$ (of which the function is also the inverse function of the exponential function). All natural logarithms of any natural number larger than 1 are proved irrational and transcendental with the Lindemann–Weierstrass theorem. It is an important value for radioactive or other decay problems and the rule of 72 for continuous compounding in investment and banking. Many identities for especially Log(2) have been found because of its simplicity compared to other logarithmic values. It also has the BBP-type representation $\ln 2 = \frac{2}{3} + \frac{1}{2} \sum_{k = 1}^\infty \left(\frac{1}{2k}+\frac{1}{4k+1}+\frac{1}{8k+4}+\frac{1}{16k+12}\right) \frac{1}{16^k}$, which could be useful in verifying future record computations because it does not have to compute all the digits again after the first computation.

\[\ln 2 = 18 coth^{-1} 26 - 2 coth^{-1} 4801 + 8 coth^{-1} 8749 \\ = 72 coth^{-1} 99 - 18 coth^{-1} 449 + 34 coth^{-1} 4801 - 10 coth^{-1} 8749\]

Primary (3 terms) and secondary (4 terms) Machin-like formulas for $\ln 2$

Same as all other mathematical constants, I have used y-cruncher by Mr. Alexander J. Yee for this computation. This program is commonly used for stress testing and benchmarking overclocked PC builds (obviously this program performs a very rigorous computation), along with fellow mathematical computing program Prime95 and linear algebra program Linpack.
The computation was theoretically about twice as intensive as Pi and half as intensive as Apéry’s constant. Unlike other series, the natural logarithms have multiple separate inverse hyperbolic cotangent series to compute the final result so each series are quite less intensive than ordinary but there are multiple series computations and accumulations. The primary formula took less than 3/4 as much time as the secondary formula because of this.

Start Date: Tue Jul 14 14:02:26 2020
End Date: Wed Jul 29 01:09:58 2020
Total Computation Time: 1169940.880 seconds
Start-to-End Wall Time: 1249652.423 seconds
CPU Utilization: 907.02 % + 7.10 % kernel overhead
Multi-core Efficiency: 12.60 % + 0.10 % kernel overhead

The multi-core efficiency was similar to Apéry’s constant, and still did not reach the utilization possible by the CPUs (Dr. Ian Cutress’s Lemniscate Constant calculation had a multi-core efficiency of 94.04 % and CPU utilization of 9027.61 %, which means that the CPU was not bottlenecked by other factors). I also used the Cilk Plus Work-Stealing multiprocessing framework along with the dynamic version of y-cruncher.

Memory:
Working Memory: 685,885,657,856 ( 639 GiB)
Total Memory: 687,194,767,360 ( 640 GiB)
Logical Largest Checkpoint: 2,118,600,314,392 (1.93 TiB)
Logical Peak Disk Usage: 6,578,365,008,416 (5.98 TiB)
Logical Disk Bytes Read: 366,084,546,862,600 ( 333 TiB)
Logical Disk Bytes Written: 320,267,770,209,808 ( 291 TiB)

Disk operation was decreased to less than a half compared to Apéry’s constant because the algorithm is easier and is split to smaller computations, and this contributed to a faster computation along with more RAM.
One caveat is that HDD I/O speeds are again great bottlenecks to virtually any other component, and perhaps having Optane DIMMs or even more normal RAM can help the speed of the computation speed greatly.

Start Date: Thu Jul 30 16:47:49 2020
End Date: Wed Aug 19 03:00:23 2020
Total Computation Time: 1636391.663 seconds
Start-to-End Wall Time: 1678354.249 seconds
CPU Utilization: 672.88 % + 34.22 % kernel overhead
Multi-core Efficiency: 9.35 % + 0.48 % kernel overhead

Memory:
Working Memory: 565,140,748,928 ( 526 GiB)
Total Memory: 566,935,683,072 ( 528 GiB)
Logical Largest Checkpoint: 2,242,654,353,960 (2.04 TiB)
Logical Peak Disk Usage: 6,516,333,392,080 (5.93 TiB)
Logical Disk Bytes Read: 476,756,678,694,304 ( 434 TiB)
Logical Disk Bytes Written: 417,615,844,506,104 ( 380 TiB)

Less RAM and one extra series expansion, plus this build also having a slower filesystem caused the verification computation to take more time even with two Cascade Lake Xeon CPU sockets that support AVX-512. CPU utilization was impacted because of slower disk even when the number of cores increased. Total Computation Time and Disk R/W were over 1/3 more.

I hope computing and sharing the results can result in more insight that can be used by mathematicians for new mathematical knowledge.

If you want to take a look at the digits for the Natural Logarithm of 2 (Log(2)), you can download it from This Link (Almost 2 TB total but don’t worry, it will just redirect to a registry with a link to download).

Breaking the Pi World Record?

2020-07-28T14:00:00+00:00

Note: this post should hopefully be understandable with anyone who is a computer power user. Also, this post is meant to supplement Mr. Alexander Yee’s y-cruncher, not replace it. You have to see his website for the crucial technical details required to make world records.

Difficulties of mathematical constants: (Excerpt from y-cruncher v0.7.8.9506, Mr. Yee thankfully let me post this)

Compute a Constant: (in ascending order of difficulty to compute)

  #         Constant                      Value        Approximate Difficulty*

Fast Constants:
  0         Sqrt(n)                                         1.46
  1         Golden Ratio                = 1.618034...       1.46
  2         e                           = 2.718281...       3.88 / 3.88
Moderate Constants:
  3         Pi                          = 3.141592...       13.2 / 19.9
  4         Log(n)                                        > 35.7
  5         Zeta(3) (Apery's Constant)  = 1.202056...       62.8 / 65.7
  6         Catalan's Constant          = 0.915965...       78.0 / 105.
  7         Lemniscate                  = 5.244115...       60.4 / 124. / 154.
Slow Constants:
  8         Euler-Mascheroni Constant   = 0.577215...       383. / 574.
Other:
  9         Euler-Mascheroni Constant (parameter override)  
 10         Custom constant with user-defined formula.  

*Actual numbers will vary. Radix conversion = 1.00

If you did not read the First Post and Second Post of the significance and algorithms of mathematical constants, read them to understand algorithms and the significance of all main mathematical constants.

Note there are more mathematical constants that are defined with custom formula files available with the executable, but they are more complicated math, so if you really want to set custom formula records, you should eventually know more as you research them.

Introduction

Of the people that I have contacted related to my ongoing world record project, all of them either have set a world record for Pi or are people that definitely will set one with the highest professionalism and optimization.

Dr. Ian Cutress also did not hide his intent to pursue a world record for Pi, perhaps in a collaboration with Gaming PC reviewers LinusTechTips and Gamers Nexus. But a world record is a world record. It requires stuff to set them. If it didn’t, it wouldn’t have been called one and instead everyone would do these everyday. What is required to set these records then?

What’s Required

We are going to consider 100 trillion digits of Pi with the Chudnovsky (1988) (reduced memory) algorithm, which is a sensible next step to the current record of 50 trillion digits by Timothy Mullican as of Jan 2019.

Verification of the digits are done using the BBP spigot algorithm thus the computing resources for verification is negligible (under a week with a desktop CPU).

Mediocre relatively recent server CPUs around 28-36 cores (I mean this is still a lot but this isn't high-end, it still won't saturate these cores because of I/O bottleneck). The CPU's performance is not important, instead the maximum RAM and PCIe lanes for the secondary storage it can support is important. Thus it is normally better to use multiple sockets with smaller cores.
At least 768GB RAM at the very very minimum. At least 2-3 times if the objective is finishing in under 6 months, not over a year.
440 TiB = 483.785 TB of high-speed RAID storage and 166 TiB = 182.519 TB to store the generated digits (doesn't need to be additional).

Hardware Costs

Let’s start with simply summing up the hardware making up this specification, which is the cost of starting from scratch. This was the way the Pi world record in 2009 by biologist Shigeru Kondo and y-cruncher developer Alexander J. Yee was done; assembling computers and connecting many hard drives manually.

RAM: One 64GB DDR4 PC4-23400 ECC REG Samsung RAM stick costs about $400 in Amazon. 32 of them (if we can even stick all of them to the server motherboard) cost $12800, summing to 2.048 TB of RAM. One 128GB DDR4 PC4-21300 ECC REG RAM stick 128 GB costs around $1100. 16 of them cost $17600, summing to 2.048 TB of RAM too. Intel Optane DIMMs (only for Intel Xeon Scalable CPUs) cost minimum $2100 each per 256 GB DIMM, 8 of them plus 8 64GB DDR4 RAM cost $20000 and sums to 2.56 TB, so this also can be an option when there is a lack of RAM sockets.

CPU: Timothy Mullican used 4x Xeon E7-4880 v2 CPU sockets for the record and had around 50% multicore efficiency. The closest benchmark I could find related to this system is This (Passmark score 34472). Since the E7-4890 v2 CPU is a faster clocked version, it can be expected that the performance will be similar or even lower.
For single-processor options, Intel Xeon W-3275 (28 cores with AVX-512 and 6-channel DDR4-2933, max 1 TB and 12 DIMMs, 64 PCIe lanes) costs $4537.90. AMD EPYC 7502P (32 cores with AVX2 and 8-channel DDR4-3200, max 2 TB, 128 PCIe lanes) costs $2300. AMD EPYC 7502P theoretically works, so let’s keep it.
For multiple-processor options, two Xeon Gold 6238 CPUs, each costing $2612, sums up to $5224 and 44 cores, and two Epyc 7352 CPUs, each costing $1350, sums up to $2700 and 48 cores. If we use older-generation used CPUs it will cost less (but nevertheless doesn’t impact the cost greatly compared to other components).

Storage: If the requirement is 440 TB, we need more than that in order to do RAID 5/6, which are configurations that tolerate one or more disk failure. One WD 8 TB shuckable external hard drive costs $140 but is slower than 7200 RPM HDDs, 70 of them costs $9800. A normal 8TB HDD with a higher I/O speed costs $200. 70 of them cost $14000. We may put in NVMe SSDs for faster buffering, and a 4 TB SSD costs 800$, so prepare to break some more money. This configuration can (hopefully) get parallel I/O speeds of around 5-6 GB/s and more if the NVMe buffers are configured correctly and meaningfully.

Cost for motherboard and RAID connection: Maybe around a couple thousand plus another few thousand on motherboards and cooling, summing to maybe $4000 or upwards? Add another $1500 per additional socket.

Total for pure hardware: minimum $33700 with Epyc 7502P and 128GB DDR4 ECC DIMMs minimum $30800 with 2x EPYC 7352 and 64GB DDR4 ECC DIMMs, minimum $40524 with 2x Xeon Gold 6238 and Optane mixed with DDR4. Note that this is the bare minimum and parts costs in real life will be more for sure.

This is not including electricity. Two CPUs spend under 400W and closer to 300W. One spends under 200W. 70 HDDs spend around 560W if we assume each HDD spends 8W. If there is no GPU, it will spend around 900W total. Assuming 0.2$/kWh, running for 6 months will cost roughly $800. So the whole summed bare minimum is expected to be around $32000. I would advise to prepare around $50000 if starting from scratch. If you have no substantial experience of computer hardware, you also have to hire someone to set up all the hardware.

I don’t think many people outside some extremely rich people happening to be interested in mathematics would be willing to do this from scratch and rather people doing computing work as a job and thus have accessibility to hardware.

Cloud Computing?

I also thought about cloud computing since Google’s Emma Haruka Iwao achieved the world record of Pi using the Google Cloud Platform m1-megamem-96 (formerly n1-megamem-96) instance. The good side of cloud computing is that it is scalable and the required man-hours are hugely less if the time of whoever doing this is expensive. The downside is that we have to use the provided computing node as-is and thus cannot optimize as much as building our own systems.

We can use Ubuntu 18.04 or CentOS 8 so we don’t have to pay for the OS. For GCP the new m1-ultramem-80 looks perfect. Let’s see the pricing per month. Around $6430 per month with sustained usage discount. The sole-tenant node m1-node-96-1433 with less RAM of which is around 500$ less than m1-ultramem-80 costs around $5900 per month. If the computation lasts 6 months, that is already similar to the whole cost of buying all the hardware but you don’t get to keep or sell the hardware. The real problem doesn’t come with the compute node. Around 460 TiB a month costs $31260. Even if the real usage cost is approximately 2/3 since the peak point isn’t persistent, it still costs $20840 a month on average.

For AWS the x1e.16xlarge costs around $9800 a month. Dedicated hosts also exist, but have inadequate ratios between the CPU cores and RAM. The Amazon EBS volume has a max size of 16 TB (costing around $700 per month) so we require an average of 15 of them. Thus it costs over $20000 a month.

Both of these fees could be reduced with using a different storage surface, but it is still way over assembling a system from scratch.

You can now see that setting a Pi world record with cloud providers is a huge expenditure and is impractical unless the resources are sponsored by AWS or Google themselves. Hiring people to set up a system is clearly cheaper.

HPC Clusters

This is now the most plausible form of computing resources that could work. Distributed file systems are already deployed and already designed to handle large data at high throughput. There are so many nodes that occupying one node for a month doesn’t impact anything big. This is the case for the world record by Dr. Peter Trueb, with the HPC cluster supported by high-energy physics research instrument manufacturer Dectris. This is efficient in sense that a lot of HPC Clusters are idle and can be easily utilized for a few months, and also house distributed file systems designed for parallelization. File systems like Ceph RADOS Block Device or BeeGFS can prove a very easy solution for RAID-level parallel file I/O once deployed.

A new concept of computing frameworks for computing Pi can also work. Instead of utilizing secondary storage, connecting supercomputers using recent high-speed Mellanox InfiniBand and utilizing the required 500 TB RAM over hundreds to thousands of nodes can also work out since InfiniBand is definitely faster than SSDs or HDDs. Since supercomputers have high CPU Core/RAM GB ratios this can be inefficient for y-cruncher workloads and have a lot of idle CPU cores, but this can reduce the total compute time dramatically.

It is expected for Academic HPC Clusters to be very efficient, as long as someone is up for this task. Cost estimates are (obviously) unavailable since every clusters or supercomputers are different.

Conclusion

A world record is a world record. It wouldn’t have been called one if everyone could easily do it. I have introduced three main ways that the world record of Pi could be done, and all of these have the same problem; the I/O wall. The 4 GHz Power Wall for the CPU was once the bottleneck of numerical computations, and has been solved by multiprocessing. The bottleneck from I/O is adversely affecting a reasonable method of breaking the current barrier and it will be harder and harder to set records as long as disk speeds of economic mediums such as HDDs stay this way. SSDs are still expensive and the redundancy of SSDs are insufficient for the extreme Read/Write y-cruncher requires. This causes SSDs to potentially corrupt during the computation or be literally single-use. Technologies for storage must be improved for the plight for the world record of Pi to continue on rapidly as before.

Apéry’s Constant

2020-07-28T12:10:00+00:00

Apéry’s Constant

This world record computation of 1,200,000,000,100 digits by Seungmin Kim was done from Thu May 21 15:11:49 2020 to Mon Jun 22 08:38:33 2020 using the Wedeniwski (1998) algorithm. This time again after Catalan’s Constant, I have verified the calculation using the Amdeberhan-Zeilberger (1997) algorithm from Wed Jun 24 09:02:14 2020 to Sun Jul 26 22:22:36 2020.
Validation file generated by y-cruncher v0.7.8 Build 9506 for computation, and y-cruncher v0.7.8 Build 9506 for the verification run:
Computation: https://web.archive.org/web/20200810061235/http://www.numberworld.org/y-cruncher/records/2020_6_22_zeta3.txt
Verification: https://web.archive.org/web/20200810062529/http://www.numberworld.org/y-cruncher/records/2020_7_26_zeta3.txt

\[\zeta(3) = \sum_{n=1}^\infty\frac{1}{n^3} = \lim_{n \to \infty}\left(\frac{1}{1^3} + \frac{1}{2^3} + \cdots + \frac{1}{n^3}\right)\]

The definition of Apéry’s Constant (Wikipedia)

Apéry’s Constant is defined by the above equation, ζ is the Riemann zeta function. The zeta function is well regarded as the key to many unsolved problems in mathematics, physics, and chemistry, and I think it is learned by undergrad junior to senior students in mathematics. It has been named after Roger Apéry, the mathematician that proved that $\zeta(3)$ was irrational and generated great insight to the zeta function itself. Because Apéry’s Constant was proved as irrational, we know the digits will continue indefinitely. Take a look at this Wolfram Mathworld entry for the mathematical stuff.

Interesting fact: Dr. Sebastian Wedeniwski, the discoverer of the Wedeniwski (1998) algorithm, was the person behind ZetaGrid, which was one of the largest distributed computing projects of the early 2000s and had the purpose of finding roots of the zeta function to test if there are any counterexamples of the Riemann hypothesis. He is now the Chief Information Officer (executive position) at the Standard Chartered Bank at Singapore after 18 years at IBM, currently in charge of all informational management of the multinational banking group. Mr. Alexander Yee (the person who created y-cruncher) also works at Citadel Securities, a huge hedge fund located in Chicago, after his time at Google. I guess the people from mathematical computing academic diciplines meet in the financial industry.

Same as all other mathematical constants, I have used y-cruncher by Mr. Alexander J. Yee for this computation. This program is commonly used for stress testing and benchmarking overclocked PC builds (obviously this program performs a very rigorous computation), along with fellow mathematical computing program Prime95 and linear algebra program Linpack.
It was a complicated constant to compute based on that I have doubled the number of digits from all my computations before, but it was pretty easy compared to that messy I/O bottleneck of the Euler-Mascheroni Constant.

Computation:
System information:
Operating System: Linux 3.10.0-327.36.1.el7.x86_64 x86_64
Processor(s):
Name: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
Logical Cores: 48
Physical Cores: 24
Sockets: 2
NUMA Nodes: 2
Base Frequency: 2,299,961,280 Hz

Start Date: Thu May 21 15:11:49 2020
End Date: Mon Jun 22 08:38:33 2020
Total Computation Time: 2702135.464 seconds
Start-to-End Wall Time: 2741203.782 seconds
CPU Utilization: 997.73 % + 33.91 % kernel overhead
Multi-core Efficiency: 20.79 % + 0.71 % kernel overhead

The multi-core efficiency did improve compared to the constants before this (to a level of a high-end desktop CPU maybe, this is because there was more RAM than before), but still did not reach the utilization possible by the CPUs (Dr. Ian Cutress’s Lemniscate Constant calculation had a multi-core efficiency of 94.04 % and CPU utilization of 9027.61 %, which means that the CPU was not bottlenecked by other factors). This is also the first time I use Cilk Plus Work-Stealing multiprocessing framework along with the dynamic version of y-cruncher.

Memory:
Working Memory: 499,483,876,096 ( 465 GiB)
Total Memory: 499,786,337,280 ( 465 GiB)
Logical Largest Checkpoint: 2,295,791,263,000 (2.09 TiB)
Logical Peak Disk Usage: 7,799,479,894,560 (7.09 TiB)
Logical Disk Bytes Read: 795,796,887,749,864 ( 724 TiB)
Logical Disk Bytes Written: 696,627,866,292,616 ( 634 TiB)

Disk operation was decreased by a fourth compared to the Euler-Mascheroni Constant because the algorithm is easier, and this contributed to a faster computation along with more RAM. Disk writes were overall similar to Catalan’s Constant since there were two times the digits and half the algorithm difficulty.
One caveat is that HDD I/O speeds are again great bottlenecks to virtually any other component, and perhaps having Optane DIMMs or even more normal RAM can help the speed of the computation speed greatly.

Start Date: Wed Jun 24 09:02:14 2020
End Date: Sun Jul 26 22:22:36 2020
Total Computation Time: 2620847.662 seconds
Start-to-End Wall Time: 2812821.324 seconds
CPU Utilization: 934.98 % + 33.72 % kernel overhead
Multi-core Efficiency: 12.99 % + 0.47 % kernel overhead

Memory:
Working Memory: 536,619,505,280 ( 500 GiB)
Total Memory: 536,870,912,000 ( 500 GiB)
Logical Largest Checkpoint: 2,288,826,179,160 (2.08 TiB)
Logical Peak Disk Usage: 7,793,874,082,416 (7.09 TiB)
Logical Disk Bytes Read: 784,068,383,106,800 ( 713 TiB)
Logical Disk Bytes Written: 687,145,764,017,680 ( 625 TiB)

Changed stuff around for the verification computation. Slightly more RAM and two Cascade Lake Xeon CPU sockets that support AVX-512. CPU utilization was similar even when the number of cores increased, and this is explained by having slightly more RAM. Total Computation Time and Disk R/W were slightly less despite a more inefficient algorithm.

Overall, more RAM and better optimization based on insight of both the hardware and the software led to a better computing experience compared to before. Apéry’s Constant is a very important mathematical constant in expanding the horizon of human knowledge in mathematics. I hope computing and sharing the results can result in more insight that can be used by mathematicians for better insight.

If you want to take a look at the digits for the Apéry’s Constant, you can download it from This Link (Almost 2 TB total but don’t worry, it will just redirect to a registry with a link to download).

Archive for computation results in the y-cruncher website: https://web.archive.org/web/20200810060943/http://www.numberworld.org/y-cruncher/
Special thanks to Mr. Alexander J. Yee for developing and releasing y-cruncher and providing advice, and the Internet Archive for hosting the computed digits.

ISC High Performance 2020 Digital

2020-06-26T12:45:20+00:00

ISC High Performance 2020 Digital has been held virtually online because of COVID-19 from May 22nd to May 25th. The conference is one of the most popular and highly regarded high-performance computing conferences in the world, and you can get insight and experience from both academic and industry technologies related to HPC.

Some conclusions I want to make are the following. As Fugaku the ARM architecture supercomputer got the first place of TOP500 the energy-efficient ARM architecture has great potentials for high-performance systems. The fact that there are package managers for non x86-64 architecture supercomputers can ease the need of wasting time on debugging compilations, and that the architecture thought to be only used in smartphones and tablets now have what it has for desktops. This is strongly supported by Amazon AWS deploying ARM CPU cloud instance servers that they are set a more effective price compared to Intel and AMD x86-64 CPUs. Intel is aiming for an era beyond the distinction of CPUs and GPUs and instead merging both together which can result in a lower latency in the current computing environment. AMD is slowing up to Intel in the server CPU industry after the success of the Ryzen desktop CPU series with the new Epyc series, which provides a great advantage in terms of number of cores per socket and innovated unified memory access. NVIDIA is promoting the InfiniBand interconnect for clusters and supercomputers after acquiring the industry leader Mellanox, stressing the importance of I/O in HPC architectures. The new Tesla A100 GPU accelerator focuses on tensor processing mainly for machine learning. Fugaku has been deployed earlier than scheduled and supercomputers worldwide are being used for molecular dynamics simulation and machine learning (mainly assisted by GPU accelerators in a majority of supercomputers) to target potential candidates for COVID-19 medications. The accelerated speed assisted by parallel computing in HPC will be a game changer for sure. I have experience with protein structural bioinformatics, and I will introduce the field in a later time.

Publicly avaliable videos of the conference:

This is from 2019 but is nonetheless a very interesting keynote video:

Algorithms and Significance of Major Mathematical Constants: Part 2

2020-05-22T17:07:20+00:00

NNote: this post is appropriate for people with at least a high school mathematics or calculus background, although anyone enthusiastic about mathematics can understand this if Google and Wikipedia are your friends. I am also not a professional mathematician, so this post may include inaccuracies. Also, this post is meant to supplement Mr. Alexander Yee’s y-cruncher in easier words, not replace it. You have to see his website for the crucial technical details required to make world records.

If you are interested in actually setting a world record with y-cruncher, read This Post for an in-depth explanation of optimizing the configurations of y-cruncher as well.

If you did not read the First Post, it would help to read it first.

Difficulties of mathematical constants: (Excerpt from y-cruncher v0.7.8.9506, Mr. Yee thankfully let me post this)

Compute a Constant: (in ascending order of difficulty to compute)

  #         Constant                      Value        Approximate Difficulty*

Fast Constants:
  0         Sqrt(n)                                         1.46
  1         Golden Ratio                = 1.618034...       1.46
  2         e                           = 2.718281...       3.88 / 3.88
Moderate Constants:
  3         Pi                          = 3.141592...       13.2 / 19.9
  4         Log(n)                                        > 35.7
  5         Zeta(3) (Apery's Constant)  = 1.202056...       62.8 / 65.7
  6         Catalan's Constant          = 0.915965...       78.0 / 105.
  7         Lemniscate                  = 5.244115...       60.4 / 124. / 154.
Slow Constants:
  8         Euler-Mascheroni Constant   = 0.577215...       383. / 574.
Other:
  9         Euler-Mascheroni Constant (parameter override)  
 10         Custom constant with user-defined formula.  

*Actual numbers will vary. Radix conversion = 1.00

I will add whether your name can go on Wikipedia if you set a record for this or not, but please don’t start this from scratch for the sake of becoming famous or irrelevantly adding a line to your CV because it isn’t worth it. I just did it to test the long-term stability of the high-performance system that I use for other actually production-purpose uses in research that must not have went wrong and also assay my system administration competence, and it won’t make you famous just because you had nice hardware and a bunch of hard drives just in case you are looking at this for such purpose. I just had spare time when I did world records and I wanted to do a slightly more meaningful thing than the default stress test y-cruncher provided. This is why I upload every world record computation I do to help any mathematicians in the future.

Zeta(3) (Apery’s Constant)

Wikipedia My Post on the World Record

First, the Riemann zeta function $\zeta(s) =\sum_{n=1}^\infty\frac{1}{n^s}$. This expression converges when the real part of the complex number $s$ is larger than 1, but can be expanded beyond this range with other series and integral representations. $\zeta(2) =\sum_{n=1}^\infty\frac{1}{n^2} = \frac{1}{1^2} + \frac{1}{2^2} + \frac{1}{3^2} + \cdots$ was called the Basel problem, and was proved by Leonhard Euler as being equivalent to $\frac{\pi^{2}}{6}$.

The values of the Riemann zeta function has been involved in all kinds of unsolved problems in physical (especially in dynamics and quantum), mathematical, and chemical sciences, and thus the approximate values are used in industries and academia all the time.

Now, Apery’s Constant $\zeta(3) = \sum_{n=1}^\infty\frac{1}{n^3} = \lim_{n \to \infty}\left(\frac{1}{1^3} + \frac{1}{2^3} + \cdots + \frac{1}{n^3}\right)$ has been proved as irrational (but unknown if transcedental) by Roger Apéry in 1978. As much as the Riemann zeta function is involved in unsolved problems of science, the value of Apery’s Constant was involved in insight of many physical and mathematical problems. For example, $\frac{1}{\zeta(3)}$ is the probability of three positive integers to be relatively prime, is involved in an electron’s gyromagnetic ratio using quantum electrodynamics, random minimum spanning trees in data structures, and the Debye model and the Stefan–Boltzmann law in thermodynamics because of the constant’s nature.

It is a very interesting and significant constant to set a world record, and currently Dr. Ian Cutress has the world record for this as of May 2020.

Rapidly converging series have been found by Dr. Sebastian Wedeniwski in 1998. The series representation is less trivial compared to Pi leading to a higher intensity in computing it, resulting to be one of the more intensive constants. You will get your name on Wikipedia, but the difficulty of computing starts to rapidly elevate because these constants have more properties unknown than known and algorithms are less efficient.

Catalan’s Constant

Wikipedia

My Post on the World Record

\[G = \beta(2) = \sum_{n=0}^{\infty} \frac{(-1)^{n}}{(2n+1)^2} = \frac{1}{1^2} - \frac{1}{3^2} + \frac{1}{5^2} - \frac{1}{7^2} + \frac{1}{9^2} - \cdots\]

Related to a lot of identities in integral calculus, it is in relation to important problems in combinatorics such as the trigamma function. There are a lot in integral identities that conclude to a value that leads to Catalan’s constant, and they are all in the Wikipedia link. It is a simple series yet we know almost nothing about its properties including irregularity or transcendentality.

Since the definition itself is a pretty intuitive series expansion, the derived rapid converging series are abundant. The most efficient algorithms were discovered by Khodabakhsh Hessami Pilehrood, Tatiana Hessami Pilehrood and another by Jesús Guillera after 2010. It is slightly harder than Apéry’s constant though the only thing more special over Apery’s constant is that it has binomial coefficients inside the series. You can get your name on Wikipedia as it is important.

Lemniscate Constant

Wikipedia

My Post on the World Record

This is a lemniscate. (https://commons.wikimedia.org/wiki/File:Lemniscate_of_Booth.png) It looks like a dumbbell and has been defined by Jakob Bernoulli and first comes out in precalculus.

Cartesian Coordinates: $(x^2 + y^2)^2 = 2a^2 (x^2 - y^2)$

Polar Coordinates: $r^2 = 2a^2 \cos 2\theta$

Let’s start with Gauss’s constant to define the constant related to the lemniscate.

\[G = \frac{1}{\operatorname{agm}\left(1, \sqrt{2}\right)} = 0.8346268\dots\]

\[G = \frac{2}{\pi}\int_0^1\frac{dx}{\sqrt{1 - x^4}}\]

If you don’t know what AGM is, see the Logarithm section of this link.

This can also be expressed with the gamma function, which is a continuous extension of the factorial ($n! = n \cdot (n-1) \cdot \cdots \cdot 2 \cdot 1$) function, which originally is a natural number function.

$\Gamma(n) = (n-1)!$ for any integer $n$ and $\Gamma(z) = \int_0^\infty x^{z-1} e^{-x}\,dx, \ \qquad \Re(z) > 0$

\[G = \frac{\left[\Gamma\left( \tfrac{1}{4}\right)\right]^2}{2\sqrt{ 2\pi^3}}\]

Gauss’s constant is transcendental because of this property. It is also related to the Jacobi theta function

Then the first and second lemniscate constants are defined as the following.

$L_1 = \pi G$, $L_2 = \frac{1}{2G}$

The lemniscate constant y-cruncher calculates is actually in long name called arc length of a lemniscate with a=1 (OEIS A064853). It is the length of a lemniscate of which $a$ in Cartesian or Polar Coordinates is 1.

It is defined as $s =4\int_0^1\frac{dt}{\sqrt{1-t^4}} = 2L_1 = \frac{\pi}{L_2} = 2 \cdot \pi \cdot G = \frac{\left[\Gamma\left( \tfrac{1}{4}\right)\right]^2}{\sqrt{ 2\pi}}$ and it is arc length of a lemniscate with a=1 when $a$ is the constant you see up there in the Polar Coordinates notation.

Overall, this is an interesting mathematical constant in geometric algebra, but expect no name on Wikipedia.

The algorithm from here starts to get more complicated rather than simple series you saw until now.

The first and most recent algorithm is the AGM-Pi algorithm. Remember $G = \frac{1}{\operatorname{agm}\left(1, \sqrt{2}\right)}$. Then $s = \frac{2\pi}{\operatorname{agm}\left(1, \sqrt{2}\right)}$. So if we calculate $\pi$ and calculate the AGM value, we can get the arc length of a lemniscate with a=1. It looks simple, and it is actually the easiest one to calculate provided you calculate everyting in the RAM. Remember the AGM algorithm has bad memory locality. If we use HDD swaps, the becomes more serious and becomes slower than the traditional algorithms. I oversaw the note that computations regarding swaps could be slower than traditional algorithms and ended up spending more time by using this algorithm.

A more traditional algorithm changes the integral definition of Gauss’s constant. Recall $G = \frac{2}{\pi}\int_0^1\frac{dx}{\sqrt{1 - x^4}}$. We can change this to a series expansion using the definition of definite integral to a Riemann sum. We can use the series expansion of the inverse (arc) function of the Lemniscate sine function derived from the definition of Gauss’s constant.

Gauss Formula: $Lemniscate = 8 ArcSinlemn(\frac{1}{2}) + 4 ArcSinlemn(\frac{7}{23})$

Sebah’s Formula: $Lemniscate = 8 ArcSinlemn(\frac{2}{3}) - 4 ArcSinlemn(\frac{7}{137})$

The first formula is simpler and the second is used to verify if we aren’t using the AGM-Pi algorithm. Because it isn’t a simple series expansion, the difficulty increases.

Euler-Mascheroni Constant

Wikipedia

My Post on the World Record

Dreadful. Just dreadful. Three times harder than the next hardest mathematical constant.

\[\gamma = \lim_{n\to\infty}\left(-\ln n + \sum_{k=1}^n \frac1{k}\right) = \int_1^\infty\left(-\frac1x+\frac1{\lfloor x\rfloor}\right) dx\]

When ${\lfloor x\rfloor}$ is the floor function.

The area of the blue region converges to the Euler–Mascheroni constant. (Wikipedia)

This comes out predominantly while learning the integral test for convergence.

Third-most mathematical constant and is the hardest. the $\gamma$ in y-cruncher is the Euler-Mascheroni Constant, and Mr. Alexander Yee first made this program to compute this very constant.

There is no one AGM or series expansion equation to compute this, and it is even more complicated than Gauss Formula or Sebah’s Formula of the lemniscate. I think this was easily harder than Google’s Pi world record (50 times more digits than my Euler-Mascheroni Constant record) if we rule out the fact that they need more hard drives. It took as much as them, and it is as picky to manage as them. I asked Dr. Ian Cutress to verify this, and he got an ECC corrected error that I never saw in one of my own computations. Disk R/W is 1/3 of Google’s record while the digits are 1/50.

There are so many papers that attempt to make the Brent-McMillan algorithm computation easier, both by new algorithms and optimization of existing ones, but it is hard.

The lemniscate constant started becoming a hard computation because it was a rational arithmetic of two different series expansions. Guess what. People failed to find an algorithm better than the one developed in 1980. Because it is the limit between the harmonic series and the natural logarithm, we have to literally subtract the natural logarithm from the equivalent value of the harmonic series. This causes the computation to become three times harder than even the arc length of a lemniscate with a=1.

Brent-McMillan Algorithm:

\[\gamma = \frac{A}{B} - ln(n) + O(e^{-4n})\]

where $O(e^{-4n})$ is the rate of convergence in Big O notation, $A = \sum_{k=0}^{\infty} (\frac{n^k}{k!})^2 H(k)$, $B = \sum_{k=0}^{\infty} (\frac{n^k}{k!})^2$, and $H(n) = \zeta(1) = \sum_{k=1}^{n} \frac{1}{k}$

Further refined Brent-McMillan Algorithm to increase rate of convergence (note that the rate of convergence is not a square faster because the equation becomes more complicated):

\[\gamma = \frac{A}{B} - \frac{C}{B^2} - ln(n) + O(e^{-8n})\]

where $O(e^{-8n})$ is the rate of convergence in Big O notation, $A = \sum_{k=0}^{\infty} (\frac{n^k}{k!})^2 H(k)$, $B = \sum_{k=0}^{\infty} (\frac{n^k}{k!})^2$, $H(n) = \zeta(1) = \sum_{k=1}^{n} \frac{1}{k}$, and $C = \frac{1}{4n} \sum_{k=0}^{2n} \frac{((2k)!)^3}{(k!)^4 \cdot (16n)^{2k}}$.

It looks already hard, but it becomes even harder because it is a class of formulae that give better approximations successively, so the series is different based on setting $n$ depending on the expected precision. Because series $A$ includes the harmonic series, it is a double summation and makes it very hard to find a Binary Splitting recursion and is significantly more complicated compared to others once found. Series $A$, $B$, $C$ have non-linear irregular convergence behaviour that makes computation trickier and Series $C$ and $H$ are divergent. The only other viable algorithm is called Sweeney’s Method, which is easier but slower.

This constant has a bigger presense in mathematics than Catalan’s Constant and appears in as many unsolved problems in mathematics as Apery’s Constant, but while Apery’s Constant was proved as irrational, we know nothing about whether it is algebraic/transcendental or even irrational. This is a short list of some notable problems Euler-Mascheroni Constant appears in, and it also appears related to various definite integrals, digamma function $\gamma$, which is the derivative of the gamma function $\Gamma$ (remember we saw this in Gauss’s constant and Lemniscate), and also the Riemann zeta function $\zeta$ (remember Apery’s constant is $\zeta(3)$). So it this constant is a very important intersection in mathematics research, but we don’t know a lot about this. Lots of potential in researching this, but it is too hard to compute. That is why I think me and Dr. Ian Cutress’s endeavour counts toward mathematical advances because there are other constants people can set records cheaper and we still did it.

This record will get your name on Wikipedia as part of the history of known digits.

Series Backlinks

First Post

If you are interested in actually setting a world record with y-cruncher, read This Post for an in-depth explanation of optimizing the configurations of y-cruncher as well.

More information of algorithms used by y-cruncher: Link. This site has the equations and time complexity of all algorithms.

Optimizing y-cruncher to Actually Set World Records

2020-05-22T14:30:20+00:00

Note: this post should hopefully be understandable with anyone who is a computer power user. Also, this post is meant to supplement Mr. Alexander Yee’s y-cruncher in easier words, not replace it. You have to see his website for the crucial technical details required to make world records.

Difficulties of mathematical constants: (Excerpt from y-cruncher v0.7.8.9506, Mr. Yee thankfully let me post this)

Compute a Constant: (in ascending order of difficulty to compute)

  #         Constant                      Value        Approximate Difficulty*

Fast Constants:
  0         Sqrt(n)                                         1.46
  1         Golden Ratio                = 1.618034...       1.46
  2         e                           = 2.718281...       3.88 / 3.88
Moderate Constants:
  3         Pi                          = 3.141592...       13.2 / 19.9
  4         Log(n)                                        > 35.7
  5         Zeta(3) (Apery's Constant)  = 1.202056...       62.8 / 65.7
  6         Catalan's Constant          = 0.915965...       78.0 / 105.
  7         Lemniscate                  = 5.244115...       60.4 / 124. / 154.
Slow Constants:
  8         Euler-Mascheroni Constant   = 0.577215...       383. / 574.
Other:
  9         Euler-Mascheroni Constant (parameter override)  
 10         Custom constant with user-defined formula.  

*Actual numbers will vary. Radix conversion = 1.00

Overview

Now we get real. How do we compute actual world records with y-cruncher? The first thing we need in mind is hardware. The CPU doesn’t matter much as long as it is a comparably high-end desktop or mediocre server CPU, and that disk R/W speeds have been the bottleneck so you have to care more about the latter.

The way to decrease bottleneck is (excerpt from y-cruncher):

The “fastest storage configuration” because that’s the bottleneck.
The “largest memory configuration” because it minimizes the amount of disk I/O that is needed.
A “mediocre CPU” because that’s all you need before you hit the disk bottleneck.

Storage

As I wrote in the First Post, what is bottlenecking you is not the CPU. An 8-core 16-thread AMD Ryzen 3700X was sufficient to set a record for the lightest mathematical constants as long as you have swap RAID storage that amounts to TBs. HDDs are redundant so it can withstand massive writes but it is slow. SSDs are fast so that there is less bottleneck but such an intensive amount of writes lead it to be almost single-use, and the disk will likely fail when it does intensive operations next time. Optane SSDs are pretty redundant and fast with random R/W though not much as RAMs, but they are expensive, though not expensive as more RAM. Because of this, people mostly stick to HDDs by accelerating the overall speed using multiple arrays with RAID, and hardware reviewers like Dr. Ian Cutress have attempted a twist like Optane DIMMs that are 512GBs per DIMM, unlike 32GB maximum for ECC RAMs normally.

RAM

Memory allocation is bad in Linux compared to Windows as of now. So use Windows (preferably a server version, also turn off automatic updates…) for a meaningful increase in speed. However, some CPUs such as certain generations of AMD RYZEN Threadripper favor the Linux CPU scheduling system, so consult Mr. Alexander Yee for which OS to use if you can choose. There is also something called “Locked Pages” and “Large Pages” that increases throughput and prevents time waste on allocating and de-allocating memory, instead confining to the program. Thus having full superuser permission to enable this improves I/O time, although not crucial. I know this program is very frequently used to stress test overclocked computers, but I recommend against overclocking the CPU or RAM unlike what Mr. Alexander Yee said in his webpage for any large computation because overclocking causes loads of silent errors that don’t matter much in other casual workloads like games. This computation isn’t casual at all.

Reasons why you might need ECC pic.twitter.com/vCKI3r5vUC
— 𝐷𝑟. 𝐼𝑎𝑛 𝐶𝑢𝑡𝑟𝑒𝑠𝑠 (@IanCutress) May 18, 2020

And also, ECC is pretty important as a last method to absorb errors, although I never got an ECC corrected error for any of my computations. Overclocking ECC RAM is also very pointless.

CPU

This is the pattern of CPU utilization in a typical swap computation with 32 threads with AVX2 for a world record on y-cruncher v0.7.8.9506. I captured this from a computation of mine. You can see that at the start of the computation, the CPU is almost fully utilized since the initial steps are run on RAM, but after the program offloads to swap secondary storage, there is a clear difference between when the CPU is utilized fully, and when it is utilized less than 25% because of I/O bottlenecks. As a computation extends in time to store more digits than before, the zone where the CPU is underutilized is stretched more and more. As the time where the CPU is fully utilized is significantly less than the I/O bottlenecked time, the number of cores is not very important in conserving computation time.

An 8-core 16-thread AMD Ryzen 3700X was sufficient to set a world record for the lightest mathematical constants, but the problem with desktop (including HEDT) CPUs are that there is a maximum of total RAM, normally around 128 GB. This will contribute more to I/O bottleneck, making it impractical for more complicated constants that access the memory way more in the same number of digits. The reason people use multi-socket server/workstation CPUs are because it can house more RAM, decreasing bottleneck. More cores isn’t exactly the point that drastically increases speed. I am very interested on results shall this program was used on supercomputer or mainframe builds connected to each other using Mellanox InfiniBand I/O Fabric should such computation happens.

Configuration in Linux for Using the Optimized y-cruncher

First if you are running in Linux (the Windows version has all the features embedded inside as default and does not require additional installations), I recommend using the dynamic version (especially in multisocket environments) which requires the system dependencies in Ubuntu 18.04 (or distros based on this version, but Ubuntu 18.04 prevents unexpected errors) and also requires installing numactl as of y-cruncher v0.7.8.9506 and versions before that. CentOS 8 is also reported to work without any other tweaks as long as you installed numactl, you should be generally have no problems. This does not mean that your host requires only the Ubuntu 18.04 OS or CentOS 8 to run the dynamic version, instead you can run this on any recent Linux distros on the static version, but you have to be careful if you want to use the dynamic version.

If you do not have root permissions and thus cannot use the default package repositories, you can install numactl-devel-cos6-x86_64 which has the required libnuma.so.1 library for running the dynamic version using Miniconda, and add the directory of where libnuma.so.1 is to the system variable LD_LIBRARY_PATH (export LD_LIBRARY_PATH='/path/to/lib:$LD_LIBRARY_PATH', check the full path with find . -name "libnuma.so.1" at the directory where the conda environment is in, but you have to use the absolute path for the system variable instead of the relative path).

CentOS 7 (or any Linux distro with kernel version tested >= 3.10.0) also works (but also watch out for unexpected errors), but requires extra work; as the default libstdc++ is an incompatible version, to fix this you can install the Red Hat Developer Toolset (devtoolset-9) from the CentOS SCLo RH x86_64 repository and activate its environment (this is untested so I can’t ensure that this actually works well), or more preferably and not requiring root permissions install libstdcxx-ng in the same way as the Miniconda installation of numactl-devel-cos6-x86_64 (you can install both at the same time), and same as numactl-devel-cos6-x86_64, adding the directory of where libstdc++.so.6 is to the system variable LD_LIBRARY_PATH (export LD_LIBRARY_PATH='/conda/path/to/cpp:/conda/path/to/numa:$LD_LIBRARY_PATH', check the full path with find . -name "libstdc++.so.6" at the directory where the conda environment is in, but you have to use the absolute path for the system variable instead of the relative path).

If you get errors related to libcilkrts.so.5 and/or libtbb.so.2 when executing y-cruncher after this configuration (common if you run it as a remote command or with bash -c), add the full path of the Binaries directory of the y-cruncher download to the LD_LIBRARY_PATH, delimiting each directory with a colon also.

Using recent OS containers with light OS-level virtualization like Docker, LXC, or Singularity also works and was tested for installing the correct dependencies from package repositories without much virtualization overhead in performance, but you don’t really have to use OS-level virtualization even if you don’t have root permissions as long as your host OS has any recent kernel version. OS-level virtualization will not increase your kernel version even if you use a newly released OS container so whether y-cruncher works or not on your system is all to your host OS.

If you use the static version instead of the recommended dynamic version, you have to use the custom-coded Push Pool (this is the preferred framework for desktop level CPUs of around 16 threads) multiprocessing framework for large workloads using one or more CPU sockets summing to over 64 threads, which is less efficient than Intel’s Cilk Plus or Threading Building Blocks. Threading Building Blocks is the replacement to Cilk Plus from Intel but the performance from a past computation of the world record of Pi have been underwhelming with it so far, thus the better working Cilk Plus is used for now (but this could change later).

The y-cruncher program will then automaticaly choose the recommended frameworks for each component to be used based on the number of cores and you will not be restricted on the selections as long as you have the dynamic version.

The y-cruncher Program

Every computer is different, so they must be tuned to get its maximum throughput to decrease time dramatically. The y-cruncher program has some tools to check them. The first tool is the stress testing application, which proves that your build can initially withstand certain Fast Fourier Transform operations and other heavy computations. The second and perhaps the most important tool is the I/O Performance Analysis if you are (likely) computing with swap secondary storage like SSDs or HDDs. After getting the results you have seen with running this benchmark, you have to tweak the Far Memory Tuning configuration based on what you get. An explanation of how to do this will come up later.

For running the real world record level computations, you go in the Custom Compute a Constant menu. Note that you should run Test Swap Multiply in Advanced Options if you are running computations with huge digits that are bigger than the current record digits in Pi as advised by Mr. Yee. First choose the constant and understand the algorithms and their performances. Then you can choose whether to use swap storage or not and set how much RAM the program it should use. It will be automatically set to 90-95% of all available RAM, and this is the appropriate guideline that should be kept if you are tweaking the configurations since the remaining 5-10% should be used by the OS and other background tasks. You then have to choose the path of where the digits will be saved and for swap computations also where swap files should be stored during the computation. If you already have hardware RAID available, you can just specify the path, and if not the program can set a custom software RAID configuration if you list the paths in the program. You can even optionally set a backup command to be run automatically using the Post-Checkpoint Command in the Checkpoint menu. You can also set the I/O Memory Buffer Allocator here, and if you use the dynamic version of Linux or the Windows version and have multiple sockets, you can see it is automatically set to use libnuma version of Node Interleaving and the custom coded version of Node Interleaving if not. The Affinity configuration designates the cores or threads that are more accessible to the secondary storages than others. It is normally not changed if the OS handles everything.

Now the last configuration left is the I/O Buffer Size and Bytes/Seek parameter. Here is when the I/O Performance Analysis benchmark comes in. I will only talk about HDDs as SSDs have a whole lot different figures (I have seen Bytes/Seek parameters of over 80 MB for mixed NVMe + HDD clustered filesystem configurations and also oppositely microscopic Bytes/Seek parameter values around 128 KB for a pure NVMe RAID configuration) and you should run the I/O Performance Analysis and conclude what Bytes/Seek parameter is appropriate. The rule of thumb for I/O Buffer Size is using 64 MiB times the number of hard drives (or divide the sequential read rate shown in the results of the I/O Performance Analysis to the sequential read speed of one hard drive or SSD to infer how many hard drives are in the array). For the Bytes/Seek parameter you first have to know the logics. This is the number of bytes the hard drives can read sequentially in the time equivalent to the disk seek time. A normal hard drive has a seek time of 10ms and one hard drive normal has a sequential read rate of 100-200 MB/s, so the Bytes/Seek parameter can be around 1-2 MiB and thus we first assume it is around 2 MiB because setting this smaller can change the computation speed more dramatically than setting it larger. You should multiply this to the number of hard drives and think of this as the starting value. Then you should use the I/O Performance Analysis sequential read results directly and divide it to the disk seek time of 10 ms and additionally fine tune it in the direction that the displayed analysis results say. If you see a red texted result for one or more of the benchmark results you should definitely increase the Bytes/Seek dramatically as this can cause a big bottleneck. The Sequential Read (Write) throughput should be about three times the throughput of Threshold Strided Read (Write). You have to experiment with this multiple times to achieve optimized speed for world record sized computations and utilize your CPU as much as possible. The time invested here will really help with the computation and it can be reused in another computation with the same system configuration. If there is a big difference in Threshold Strided Read and Threshold Strided Write speeds, there unfortunately is not much remaining to do and it is not possible to tune for optimization. This happens commonly in distributed file systems and if this occurs tune Bytes/Seek so that the lower of the two is not less than 1/4 of the Sequential Speed and we can’t do much more than that. Check This Page for a more in-depth guide overall.

Miscellaneous

Now that we hopefully got a stable system with the fastest I/O throughput possible ready, we can go on and actually try setting a world record. If you set a record and your record digit output size is reasonable, please consider uploading to an open repository such as Google Drive if you have unlimited storage given to G Suite for Education/Business accounts (check This Link out too) or the Internet Archive for other researchers to utilize them when they need the digits.

If you are using your own build and you have to manage the heat, I can tell you more heat makes the parts more likely to cause silent defects to the digits. Use very good CPU coolers and case coolers. I think liquid cooling is not plausible for any professional builds that is on for a long time because of the leaks, but may work only if you are mainly using in games and don’t want noisy fans. Otherwise air cooling is normally more stable. Passive cooling in server racks are also very solid.

For more information on speed optimization and management methods to prevent any silent corruptions in y-cruncher, read everything from the Performance Tips section of y-cruncher and every link and text under that thoroughly, which includes Algorithms and Internals, the FAQ, Multi-Threading, Memory Allocation, Swap Mode, and Custom Formulas for people who need to use this function.

Algorithms and Significance of Major Mathematical Constants: Part 1

2020-05-21T12:01:50+00:00

Note: this post is appropriate for people with at least a high school mathematics or calculus background, although anyone enthusiastic about mathematics can understand this if Google and Wikipedia are your friends. I am also not a professional mathematician, so this post may include inaccuracies. Also, this post is meant to supplement Mr. Alexander Yee’s y-cruncher in easier words, not replace it. You have to see his website for the crucial technical details required to make world records.

If you are interested in actually setting a world record with y-cruncher, read This Post for an in-depth explanation of optimizing the configurations of y-cruncher as well.

I have been following y-cruncher since like 2011, which is 2 years after it was out. I calculated a few hundred million to a billion digits of Pi with my laptop back then. That was nowhere close to the world record even back then, but I got a hang of how I should operate the system in whole instead of leaving it alone to rapidly overheat and do nothing about it.

It was almost 8 years after that until I set a series of world records, and I see the Euler-Mascheroni Constant as the most significant result by myself. It is in mathematics, the most important mathematical constant that comes out first in calculus related to the integral test, next to Pi and $e$, as Pi first comes out in elementary school and the definition of $e = \lim_{n\to\infty} \left( 1 + \frac{1}{n} \right)^n$ in an earlier chapter of high school calculus.

Here, I overview mathematical constants that y-cruncher by Alexander Yee made various the world records for.

Difficulties of mathematical constants: (Excerpt from y-cruncher v0.7.8.9506, Mr. Yee thankfully let me post this)

Compute a Constant: (in ascending order of difficulty to compute)

  #         Constant                      Value        Approximate Difficulty*

Fast Constants:
  0         Sqrt(n)                                         1.46
  1         Golden Ratio                = 1.618034...       1.46
  2         e                           = 2.718281...       3.88 / 3.88
Moderate Constants:
  3         Pi                          = 3.141592...       13.2 / 19.9
  4         Log(n)                                        > 35.7
  5         Zeta(3) (Apery's Constant)  = 1.202056...       62.8 / 65.7
  6         Catalan's Constant          = 0.915965...       78.0 / 105.
  7         Lemniscate                  = 5.244115...       60.4 / 124. / 154.
Slow Constants:
  8         Euler-Mascheroni Constant   = 0.577215...       383. / 574.
Other:
  9         Euler-Mascheroni Constant (parameter override)  
 10         Custom constant with user-defined formula.  

*Actual numbers will vary. Radix conversion = 1.00

I will add whether your name can go on Wikipedia if you set a record for this or not, but I just did these computations to test the long-term stability of the high-performance system that I use for other actually production-purpose uses in research that must not have went wrong and also assay my system administration competence, and it won’t make you famous just because you had nice hardware and a bunch of hard drives just in case you are looking at this for such purpose. I just had spare time when I did world records and I wanted to do a slightly more meaningful thing than the default stress test y-cruncher provided. This is why I upload every world record computation I do to help any mathematicians in the future.

Sqrt(n)

Wikipedia

It’s easy to compute. The algorithm is very trivial as it is simply Newton’s Method ($x_{n+1} = x_n - \frac{f(x_n)}{f'(x_n)}$) to find a closer approximation per step. Not much issue even compared to radix conversion from decimal to hexadecimal. Mostly, the values used to set records are $\sqrt{2}$ or $\sqrt{3}$, the earlier one being more significant. However, the definition is not complex, and so many stuffs have been proved about the square root values such as irrationality, since $\sqrt{2}$ is simply $2^{1/2}$ and related calculations can be done by any high school student. The fact that these values are proved as real numbers degrade the value of research in approximation, and these values likely won’t provide any significant addition to mathematical advances. Only Sqrt(2) will add your name to Wikipedia, and it is a competition of how many hard drives people have.

Golden Ratio

Wikipedia

\[\varphi = \frac{1+\sqrt{5}}{2}\]

Culturally significant, mathematically not so much? It is $\sqrt{5}$, divided by 2, and adding 0.5 to it. I won’t repeat what I said in Sqrt(n). The world record values are trivial to set obviously as long as you have hard drives to store the swap so the world record is soaring as much as Pi. Also a competition of how many hard drives people have, and your name won’t be on Wikipedia unless you make your own table on the document and the moderators approve it.

e (Base of the Natural Logarithm)

Wikipedia

\[e = \sum\limits_{n = 0}^{\infty} \frac{1}{n!} = \frac{1}{1} + \frac{1}{1} + \frac{1}{1\cdot 2} + \frac{1}{1\cdot 2\cdot 3} + \cdots = \lim_{n\to\infty} \left( 1 + \frac{1}{n} \right)^n\]

As I said above, it is widely regarded as the second-most important mathematical constant. In addition to its universal significance in mathematics, its application in economics (compound interest), statistics (normal distribution and probability theory), physics (complex numbers for RLC circuits and countless applications in modern physics) is so vast. The downside is that it is very well-defined in so many ways and proved it was irrational and transcendental so that not many mathematicians take its approximate value significantly. However it has great mathematical value.

The Taylor series definition is used to set the record as it is easy to calculate how many terms are required to ensure the decimal and hexadecimal digits. The world record values are easy to set as long as you have hard drives to store the swap so the world record is soaring over the Golden Ratio. Also a competition of how many hard drives people have, and since it’s a really important mathematical constant your name can be mentioned in Wikipedia but will likely be erased when someone else renews it by seeing how the moderators set up the tables.

Pi (π)

Wikipedia

Most of you seeing this should be interested in this the most. Former Pi world record holder Dr. Peter Trueb made a blog and he has explained very deeply about the Chudnovsky Formula used to calculate Pi. I’ll just add that it was proved that Pi is irrational and transcendental and the Chudnovsky Formula is a great rapidly converging formula that made Pi computation easier after the Ramanujan–Sato series. But unlike $e$, which is basically the simplest form of Taylor series, it requires more computing power but the bottleneck for world records already went to the swap disk I/O rather than CPU. For all constants, it is required to verify the computation with another mathematically independent to set a world record, but a spigot algorithm developed under 30 years ago called the Bailey–Borwein–Plouffe (BBP) formula calculates the last few digits of Pi in hexadecimal and verifies that the computations did not have any errors. It is computationally impractical to calculate all digits in between, but since the last few digits are sufficient to verify the whole series are intact, it is a good and short verification method. Since it is pretty simple Mr. Alexander Yee does this for you when one sets a record normally.

I guess this is the whole point this “world record” concept exists and your name & face will become more famous when you set a world record. Most people who recently set the records for Pi are respected professionals in their own fields anyways however. Google have previously set a world record of Pi to promote their Cloud Platform, and they paid money to Mr. Yee to use the program proprietorially. The number of digits have soared to an astronomical figure, so it is both a challenge of keeping your system intact preventing any silent errors for almost a year and preparing a stack of hard drives.

Log(n) (Logarithm)

Wikipedia

Has similarly vast applications as $e$. $log_n (x)$ with a positive base that is not 1 and positive domain is the inverse function of $n^{x}$, so $ln(x)$ is the inverse of $e^{x}$. It is proved that the range of any logarithm function with a positive base that is not 1 and positive domain are real.

The computation is done with a Primary Machin-like Formula that can be auto-generated as a sum of a fraction multiplied by an inverse hyperbolic tangent approximate value (also generated with Taylor series but simpler) as it converges faster than the simple Taylor series of the logarithm. Proving identity of the logarithm and inverse hyperbolic tangent first comes out in calculus. I remember solving this problem on my calculus course. The difficulty of each logarithm value varies, and is considered multiple times harder than Pi of the same number of digits.

It can also be approximated by the arithmetic–geometric mean (AGM) although too inefficient to be used for the world record computations. This itself is used in precalculus algebra or olympiads for finding ranges. However, the algorithm of the same principle is actually used for the world record computations of Lemniscate Constant, coming up on my Second Post.

\[0<\frac{n}{1/x_1+1/x_2+\cdots+1/x_n}\leq\sqrt[n]{x_1x_2\cdots x_n}\leq\frac{x_1+x_2+\cdots+x_n}{n} \leq\sqrt{\frac{x_1^2+x_2^2+\cdots+x_n^2}{n}}\]

This is the Root-Mean Square-Arithmetic Mean-Geometric Mean-Harmonic Mean Inequality (RMS-AM-GM-HM) relation (largest to smallest), and we will take the middle 2 relations only.

\[\ln (x) \approx \frac{\pi}{2 M(1,2^{2-m}/x)} - m \ln (2)\]

$M(a,b)$ here or $agm(a, b)$ generally denotes the arithmetic–geometric mean of $a$ and $b$ and is repeatedly calculated by computing the arithmetic mean $\frac{a+b}{2}$ and geometric mean $\sqrt{ab}$ and making them the new $a$ and $b$. This rapidly converges as there are more steps $m$ to make more digits.

This method may be presumed to be faster than series expansion because AGM has a time complexity of $O(n log(n)^2)$ instead of $O(n log(n)^3)$ of most series with the Big O notation, but because each term of AGM is multitudes more complex (which is the constant in Big O notation) than series and that AGM has bad memory locality, a series expansion incorporating Binary Splitting is faster. This is the same reason AGM algorithms for Pi are not used. Also note that the bottleneck of HPC computations is no longer the CPU. It is the storage. If there is not enough RAM to house all the generated data used for computation, an external swap storage must be used, and they are so slow they throttle what the CPU and RAM can process. Refer more Here.

I wish I could go deeper on the binary splitting method but to fully explain from the basics I have to give an example of expanding long expressions, so I replace my explanation with the First Link, Second Link, and Third Link.

Like Sqrt(n), each approximate values itselves are mainly symbolic rather than mathematical, although the algorithms are in rapid research. You will only get your name on Wikipedia for Log(2).

Series Backlinks

I will overview the hardest mathematical constants Apery’s Constant, Catalan’s Constant, Lemniscate, and Euler-Mascheroni Constant in more detail also as all of these are constants I made world records for.

Second Post

If you are interested in actually setting a world record with y-cruncher, read This Post for an in-depth explanation of optimizing the configurations of y-cruncher as well.

More information of algorithms used by y-cruncher: Link. This site has the equations and time complexity of all algorithms.

Euler-Mascheroni Constant

2020-02-15T11:46:20+00:00

The Euler-Mascheroni Constant

Update: To people who came here from Dr. Ian Cutress’s Twitter or TechTechPotato Youtube: Welcome. I am the very person that asked Dr. Ian to compute this dreadful mathematical constant for over 3 months to verify my initial computation. But I guess we did it. I give big credit to Dr. Ian Cutress because without him, my computation would have never become official. This website is meant to provide additional information about computing world records in addition to the information in the y-cruncher website, so have some more look. Thank you.

Another update:

Start-to-End Wall Time: 8994062.448 seconds (104.1 days)

Finally have the record! 🥳🎉🎉

But

Logical Disk Bytes Read: 2,548,639,747,841,704 (2.26 PiB)

Logical Disk Bytes Written: 2,163,049,114,475,792 (1.92 PiB)

I need to check if these SSDs are working
— 𝐷𝑟. 𝐼𝑎𝑛 𝐶𝑢𝑡𝑟𝑒𝑠𝑠 (@IanCutress) May 26, 2020

Reasons why you might need ECC pic.twitter.com/vCKI3r5vUC
— 𝐷𝑟. 𝐼𝑎𝑛 𝐶𝑢𝑡𝑟𝑒𝑠𝑠 (@IanCutress) May 18, 2020

And also, ECC is pretty important yes, although I never got an ECC corrected error for any of my computations.

Please cite this webpage if my world record of the Euler-Mascheroni Constant were useful and also the below citation if you used computations from my other posts or the digit analysis methodologies:
Kim, S. Normality Analysis of Current World Record Computations for Catalan’s Constant and Arc Length of a Lemniscate with a=1. arXiv Preprint arXiv:1908.08925

Out of all the mathematical constants that I have set a world record computation for until now, the Euler-Mascheroni Constant is so far the most mathematically significant constant (the only ones more significant are probably π and e).

This world record computation of 600,000,000,100 digits by Seungmin Kim was done from Mon Aug 19 17:21:44 2019 to Sat Jan 11 18:06:11 2020 using the Brent-McMillan with Refinement ( n = 2^38 ) algorithm. Verification calculation has been done by Dr. Ian Cutress using the Brent-McMillan ( n = 2^39 ) algorithm from Wed Feb 12 09:34:27 2020 to Tue May 26 12:55:30 2020.

Validation file generated by y-cruncher v0.7.7 Build 9501 for computation, and y-cruncher v0.7.8 Build 9503 for the verification run:
Computation: https://web.archive.org/web/20200215075907/http://www.numberworld.org/y-cruncher/records/2020_1_27_gamma.txt
Verification by Dr. Ian Cutress: https://web.archive.org/web/20200528081821/http://www.numberworld.org/y-cruncher/records/2020_5_26_gamma.txt

\[\gamma = \lim_{n\to\infty}\left(-\ln n + \sum_{k=1}^n \frac1{k}\right) = \int_1^\infty\left(-\frac1x+\frac1{\lfloor x\rfloor}\right) dx\]

The definition of Euler–Mascheroni constant (Wikipedia)

Euler–Mascheroni constant is defined by the above equation and denoted as the symbol γ. The definition itself will be familiar to many freshmen studying calculus, as it is the infinite limit difference of the harmonic series and the logarithm, and can be converted to the area of the blue region in the figure below. I am pretty sure this figure is in a calculus textbook related to the integral test for convergence. Even though it looks irrational in a numerical scope, it is unproven if it is transcendental, or even irrational. Take a look at this Wolfram Mathworld entry for the mathematical stuff.

The area of the blue region converges to the Euler–Mascheroni constant. (Wikipedia)

Same as all the other constants, I have used y-cruncher by Mr. Alexander J. Yee, basically the only program that can do this task for this computation. This program is commonly used for stress testing and benchmarking overclocked PC builds (obviously this program performs a very rigorous computation), along with fellow mathematical computing program Prime95. Compared to the earlier constants, this constant is very intensive to compute since it is not just one series expansion. The time to compute and disk writes went basically out of bounds compared to the earlier constants.

Computation:
System information:
Operating System: Linux 3.10.0-693.21.1.el7.x86_64 x86_64 (CentOS 7)
Processor(s):
Name: Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
Logical Cores: 72
Physical Cores: 36
Sockets: 2
NUMA Nodes: 2
Base Frequency: 2,294,552,832 Hz

I have used two CPUs that are compatible with AVX-512 operations that are used crucially in vector operations like y-cruncher. However, y-cruncher had an even more severe I/O bottleneck in this computation as the required read/writes were more intensive than any of my computations, so the number of cores did not assist my operation well. It was better than the Lemniscate Constant but worse than Catalan’s Constant. I have used RAID scratch storage for my operations, but the speed of the disk was very slow compared to the required read/write operations.

Start Date: Mon Aug 19 17:21:44 2019
End Date: Sat Jan 11 18:06:11 2020
Total Computation Time: 11899422.659 seconds
Start-to-End Wall Time: 12534266.770 seconds
CPU Utilization: 451.31 % + 191.22 % kernel overhead
Multi-core Efficiency: 6.27 % + 2.66 % kernel overhead

The computation took roughly 5 times more than Catalan’s Constant with about 80-90% efficiency to it, so the disk writes were the fundamental issue. I definitely cannot do this computation one more time.

Memory:
Usable Memory: 201,226,489,856 ( 187 GiB)
Logical Peak Disk Usage: 4,380,033,959,120 (3.98 TiB)
Logical Disk Bytes Read: 3,146,383,900,360,116 (2.79 PiB)
Logical Disk Bytes Written: 2,755,641,530,520,684 (2.45 PiB)

Looks like we have a new unit called PiB. This is the first computation that I have done that exceeds 1 Pebibyte. HDD I/O speeds are still great bottlenecks to virtually any other component, and thus having Optane DIMMs, SSDs with modules that tolerate a huge amount of read/writes, or more normal RAM can help the speed of the computation speed greatly.

For verification results, check the link at the start of the post.

To view the digits for the Euler–Mascheroni constant, you can download it from This Link (note that the total size is over 1 TB, but the link will simply redirect to a registry with a download link).

Archive for computation results in the y-cruncher website:
https://web.archive.org/web/20200528093605/http://www.numberworld.org/y-cruncher/
Special thanks to Mr. Alexander J. Yee for developing and releasing y-cruncher and providing advice, AnandTech.com Senior Editor Dr. Ian Cutress for verifying my computation, and the Internet Archive for hosting the computed digits.

Catalan’s Constant

2019-07-23T05:11:35+00:00

Catalan’s Constant

This world record computation of 600,000,000,100 digits was done from Sat May 25 22:37:01 2019 to Tue Jun 18 18:59:44 2019 using the Pilehrood (2010-short) algorithm. This time, I have also verified the calculation using the Guillera (2008) algorithm from Fri Jun 7 11:13:58 2019 to Tue Jul 16 10:29:12 2019. Validation file generated by y-cruncher v0.7.7 Build 9501 for computation, and y-cruncher v0.7.7 Build 9499 for the verification run:
Computation: https://web.archive.org/web/20190724102605/http://www.numberworld.org/y-cruncher/records/2019_6_18_catalan.txt
Verification: https://web.archive.org/web/20190724102625/http://www.numberworld.org/y-cruncher/records/2019_7_16_catalan.txt

\[G = \beta(2) = \sum_{n=0}^{\infty} \frac{(-1)^{n}}{(2n+1)^2} = \frac{1}{1^2} - \frac{1}{3^2} + \frac{1}{5^2} - \frac{1}{7^2} + \frac{1}{9^2} - \cdots\]

The definition of Catalan’s constant (Wikipedia)

Catalan’s constant is defined by the above equation, where β is the Dirichlet beta function, which is closely related to the Riemann zeta function (I think both of them are learned by undergrad students in mathematics). Even though it looks irrational in a numerical scope, it is unproven if it is transcendental, or even irrational. For more information on Catalan’s constant, see this Wolfram Mathworld entry.

Same as the Lemniscate Constant, I have used y-cruncher by Mr. Alexander J. Yee for this computation. This program is commonly used for stress testing and benchmarking overclocked PC builds (obviously this program performs a very rigorous computation), along with fellow mathematical computing program Prime95.
Maintaining server stability was challenging, as the computation pushed all components of the computer to their limits.

I have used two CPUs that are compatible with AVX-512 operations that are used crucially in vector operations like y-cruncher. However, y-cruncher has severe I/O bottlenecks (although I managed to select a better algorithm than the Lemniscate Constant and optimized some important aspects of the computation), so the number of cores did not assist my operation well. I have used RAID scratch storage for my operations, but the speed of the disk was very slow compared to the required R/W operations.

Start Date: Sat May 25 22:37:01 2019
End Date: Tue Jun 18 18:59:44 2019
Total Computation Time: 2028121.582 seconds
Start-to-End Wall Time: 2060562.370 seconds
CPU Utilization: 564.31 % + 151.19 % kernel overhead
Multi-core Efficiency: 7.84 % + 2.10 % kernel overhead

Although the multi-core efficiency improved slightly compared to the Lemniscate Constant, it still did not reach optimal efficiency (Dr. Ian Cutress’s Lemniscate Constant calculation had an efficiency of 94.04 % and CPU utilization of 9027.61 %, which means that the CPU was not bottlenecked by other factors).

Memory:
Usable Memory: 201,159,380,992 ( 187 GiB)
Logical Peak Disk Usage: 3,962,541,437,992 (3.60 TiB)
Logical Disk Bytes Read: 543,482,162,425,752 ( 494 TiB)
Logical Disk Bytes Written: 474,688,611,298,000 ( 432 TiB)

The use of a more efficient algorithm reduced disk operations by half compared to the Lemniscate Constant, resulting in a faster computation.
It is worth noting that HDD I/O speeds can be a bottleneck for virtually any other component, and using Optane DIMMs or more RAM may greatly improve computation speed.

Verification:
System information:
Operating System: Linux 3.10.0-693.21.1.el7.x86_64 x86_64 (CentOS 7)
Processor(s):
Name: Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
Logical Cores: 72
Physical Cores: 36
Sockets: 2
NUMA Nodes: 2
Base Frequency: 2,294,527,776 Hz

Start Date: Fri Jun 7 11:13:58 2019
End Date: Tue Jul 16 10:29:12 2019
Total Computation Time: 3218837.554 seconds
Start-to-End Wall Time: 3366914.430 seconds
CPU Utilization: 639.34 % + 150.50 % kernel overhead
Multi-core Efficiency: 8.88 % + 2.09 % kernel overhead

Memory:
Usable Memory: 201,226,489,856 ( 187 GiB)
Logical Peak Disk Usage: 3,986,470,844,768 (3.63 TiB)
Logical Disk Bytes Read: 947,069,197,181,784 ( 861 TiB)
Logical Disk Bytes Written: 829,531,225,016,496 ( 754 TiB)

A less efficient algorithm led to substantially more disk I/O, resulting to be similar R/W to the Lemniscate Constant.

Overall, the simpler series of Catalan’s constant, compared to the AGM-Pi algorithm of the Lemniscate Constant, allowed for a faster computation with less I/O bottleneck.

To view the digits for the Catalan’s constant, you can download it from This Link (note that the total size is over 1 TB, but the link will simply redirect to a registry with a download link).

Archive for computation results in the y-cruncher website:
https://web.archive.org/web/20190722034426/http://www.numberworld.org/y-cruncher/
Special thanks to Mr. Alexander J. Yee for developing and releasing y-cruncher and providing advice, and the Internet Archive for hosting the computed digits.