New World Records on a Gaming Computer

Euler-Mascheroni Constant - 14.9 billion digits

Natural Log of 2 - 15.5 billion digits

By Alexander J. Yee and Raymond Chan

Department of Electrical Engineering and Computer Science

Northwestern University, Evanston, IL, 60201

(Last updated: March 7, 2011)

(Update: 3/13/2009 - The records have been improved to 29.8 billion digits and 31.0 billion digits.)

No more puny laptops... This time... we step it up a bit...

In January 2009, Raymond Chan and I (Alexander J. Yee) set new records for decimal (and hexadecimal) digits of Log(2) and the Euler-Mascheroni Constant.
The first 10 billion digits we computed agree with Shigeru Kondo and Steve Pagliarulo's previous records of 10 billion digits for both constants. The remaining digits were verified using separate computations.

It has come to my attention that Shigeru Kondo and Steve Pagliarulo already had 2 billion digits of Euler's Constant before I claimed world record for my 116 million digit computation on a laptop in 2006. (I'm not sure if the 2 billion digits were verified at the time. Verification is required to claim world record.)

This mix-up was because all the respectable records lists (Wikipedia and Xavier Gourdon's List) were not updated at the time so I had no knowledge of this previous run.
Hopefully this time, it won't happen again.

The digits can be downloaded from the download page.

Computation Statistics - All times are Central Standard Time (CST).

Log(2) Computation 12 hours, 34 minutes Start : 5:00 PM January 6, 2009 Log(2) Verification 8 hours, 20 minutes Finish: 1:40 PM January 7, 2009
Euler-Mascheroni Constant Computation ~96 hours of actual run-time* Start : 3:30 PM January 7, 2009 Finish: 12:00 AM January 13, 2009 Euler-Mascheroni Constant Verification 133 hours, 41 minutes Start : 2:30 AM January 13, 2009 Finish: 4:16 PM January 18, 2009

*The computation was not done in a single contiguous run.
A hardware error occurred near the very end of the computation which caused the program to fail a redundency check and terminate.
However, the program was restarted afterwards to finish the computation which matched verification.
This will be explained later.

The computations were done on a gaming "computer" that we built:

Computer:

Main Page: Nagisa - My Gaming Computer of 2008 - 2009

Name: "Nagisa", "Nagisa Workstation" (from the Anime Series "Clannad"), or simply, "The Heater".
Processors: Dual 3.2 GHz Intel Quad-core Xeon X5482 Harpertown; (Not overclocked, this needed to be stable! And it's locked...)
Memory: 64 GB DDR2 FB-DIMM @ 800 MHz (quad channel)
Motherboard: Tyan Tempest S5397
Graphics: GeForce 9800 GTX+ 512 MB GDDR3 ram
Hard Drives: 750 GB SATA II Seagate (Boot drive); 4 x 1 TB SATA II Seagate (No raiding)
Operating System: 64-bit Windows Vista Ultimate SP1
Built By: Mostly by my friend/roommate Raymond Chan - in a static and humidity controlled laboratory.; Raymond, being more of a computer enthusiast than me, has much more experience building computers than I do.
Purpose: Middle/High-end Gaming; High-Definition Movie and Anime player; 64-bit Parallel Programming; Number Crunching
Future Upgrades: Better Video Card...
Other Thoughts: It runs Crysis pretty smoothly on max settings if we don't set the resolution too high. We'll need a better video card for it to handle it on max resolution as well.
It also keeps us nice and warm during Chicago winters...

Program:

Main Page: y-cruncher - The Multi-Threaded Pi-Program

Name: y-cruncher v0.1.0 Alpha (Builds 5397 - 5872)
Build Version: x64 SSE3 (Author's Version)
Language: C/C++ with Intel SSE intrinsics and WinAPI threading and I/O. The program is 99% C and 1% C++ (all compiled in C++). No assembly or inline assembly.
Currently Supported Constants: Pi; Log(2); Euler-Mascheroni Constant
Notable Features
Performance: Between 1 - 100 million digits, y-cruncher (running 1 thread) can compute Pi slightly faster than PiFast 4.3, but since y-cruncher requires a base conversion to decimal, y-cruncher is actually slower at generating decimal digits of Pi.
A similar situation exists between QuickPi 4.5 and y-cruncher for dual-core systems (running with 2 threads) at the 100 million digit range.

y-cruncher's strength is that it parallels very well:
- With 2 threads (on Pentium D), it beats PiFast 4.3 even with base conversion factored in.
- With 4 threads (on Core 2 Quad), it usually beats multi-threaded QuickPi 4.5 with base conversion factored in.
- Above 1 billion digits, with 4+ cores, and 64-bit: The true power of the multi-threaded Hybrid Number-Theoretic Transform starts to reveal itself... At these sizes, y-cruncher decisively beats multi-threaded QuickPi 4.5 - often by more than a factor of 2 for computing Pi (with base conversion factored in).

Author: Alexander J. Yee (me)
Other Thoughts: y-cruncher is great for torture testing 64-bit systems with lots of ram. (especially after the hardware incident which will be explained later)

Prime95 is still better, but it can't test ALL your ram because it is 32-bit and is restricted to only 2GB of memory. Besides, at least you get some digits to look at! PiFast and QuickPi can do it and are more reputable, but PiFast 4.3 doesn't parallel and QuickPi 4.5 doesn't parallel very well so neither of them can sustain 100% CPU on multi-core systems for any extended period of time. y-cruncher can't "really" sustain 100% CPU, but for larger computations, it comes pretty close to it. It can easily average 90+% total processor utilization for large ram-only computations.

So if you want a Pi program that can max out CPU regardless of how many cores you have, y-cruncher may be the closest thing to what you're looking for. It parallels very well for sufficiently large computations. 100 million digits should be large enough to see it max out CPU. Though if you have a lot of cores, you may need to go higher.

Just understand that computing Pi and other constants, by its very nature, is very difficult to parallel efficiently without drastically increasing memory usage. This is why there are very few multi-threaded Pi programs that exist.


Download: Get the latest version here.

Formulas used for computation

For Log(2), the following two formulas (by Pascal Sebah) were used:

Log(2) = 18*ArcCoth(26) - 2*ArcCoth(4801) + 8*ArcCoth(8749)

Log(2) = 144*ArcCoth(251) + 54*ArcCoth(449) - 38*ArcCoth(4801) + 62*ArcCoth(8749)

The values from the two formulas agreed to 15,500,000,000 decimal digits and 12,872,471,368 hexadecimal digits.

For the Euler-Mascheroni Constant, the Brent-McMillan Formula with refinement was used. The computation was done using a cutting parameter of n = 2³² and verified using n = 2³³. The two results agreed to 14,922,244,771 decimal digits and 12,392,656,036 hexadecimal digits.

Two base conversions were performed for each constant using different cutting parameters. Each conversion was further verified by checking its modulus over a 61-bit prime number before and after the conversion.

The available downloads are truncated to 15,000,000,000 and 14,900,000,000 decimal digits and 12,457,230,356 and 12,374,182,154 hexadecimal digits respectively.

What Happenned During Computation?

Approximately 90 hours into the computation run (which was near the very end of the computation), an error occurred which triggered the program's internal error-detection to stop the computation and terminate the program. However, enough of the internal variables were swapped out to disk so that computation could be resumed from the 83-hour mark - despite the program terminating and losing all that was in memory. The program was restarted from the 83-hour mark to finish the computation. Therefore, no accurate timings can be provided. However, the computation did take a total of roughly 96 hours of actual run-time. (not including the 7 hours that were lost due to the error.) The verification run (which took even longer), ran through without any problems.

Note that the 96 hours does NOT include the time needed to compute Log(2) (which is part of the formula). Since the computation had to be manually finished anyway, we re-used the existing 15.5 billion digits of Log(2) that we had computed a few days earlier. So the total run-time should be roughly 108 hours. In the future, I shall re-run this computation run to get an accurate timing.

The error was later confirmed to be a hardware error. Immediately after the failure, I re-ran that part of the program hoping to reproduce the error and "fix whatever bug was causing it". But it ran through with no problems. Then while the computation was being "manually finished", that part of the program was run again, and still no error. So it seems to be a hardware anomaly. Assuming it is, I already have my guesses at what caused it... mainly due to our lack of experience in building workstations... We've built a few computers before, but nothing like this...

After that hardware error, I installed a full-system temperature monitor - and during CPU and ram intensive computation...

80F room temperature - (Why so hot? Blame this computer...)

70C for the hottest core - (The X5482 Harpertown is rated for 65C.)

60 - 80C for all the ram - (FB-DIMMs are rated for 105C.)

95C for the Northbridge - (The 5400 Seaburg Chipset is rated at 84C... this bothered us...)

70C for CPU is probably okay. I've seen people overclock the Core 2 Extreme QX9775 (which is essentially the same chip but with an unlocked multiplier) to 5+ GHz, sustain 90C+, and survive Prime95. FB-DIMM ram is rated for 105C so they are fine. So it's probably the Northbridge. But enough speculation, now we're blowing a room fan into the case. It's loud as hell, but it keeps the Northbridge under 85C.

I've always kept a close eye on CPU and ram temperatures since those are the things that everyone looks at. But I never even considered the possibility that the Northbridge could get out of hand like that. I've seen plenty of warnings about FB-DIMMs running hot and that ram cooling is a must (so we have a fancy layout of ram fans), but there were absolutely no warnings about the Northbridge!

The fact that y-cruncher is multi-threaded and had sustained 100% CPU across all cores for much of the 90 hours probably didn't help the situation.