(Last updated: March 7, 2011)
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).
*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:
Main Page: Nagisa - My Gaming Computer of 2008 - 2009
Main Page: y-cruncher - The Multi-Threaded Pi-Program
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 = 232 and verified using n = 233. 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...
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.
Below are some pages that describe some of the algorithms and programming techniques that I used to write y-cruncher. (When I finish writing them...)
Comparison to Two Years Ago...
y-cruncher has come a long way in two years. Back then (when I had named it "BigNumber"), it was just some horrifically slow java code that I had knocked up in high school and optimized during Fall Quarter my freshman year. I didn't know anything... I didn't understand what I was doing... I just "followed the book" and implemented everything exactly as they were stated without any thought...
Now, y-cruncher can match my 116 million digit run in only 5 hours on that same laptop using only 1/3 of the memory. (From 38.5 hours and 1.8 GB of ram down to 5 hours and 550 MB of ram.)
I would like to thank all my friends who gave me moral support: Kevin Sue, Colleen Lee, Heidi Yu, et... (just to name a few) And the professor who taught me everything I needed to know about computer hardware, Robert Dick.
We knew from the beginning that this time wasn't going to be easy as last time...
Two years ago...
But with, better hardware, better programming, and continual moral support... We did it! - even with the record raised to a whopping 10 billion!
As with last time, I do not expect this record to last very long. It's only a matter of time before somebody with a lot of resources, will get their hands on an even better computer and crush this record.
Two years ago, I pushed the limits of a laptop to get 116 million digits. This time, I needed to push the limits of a workstation we built, to take that record back - probably for just a short while.
Time to go back to using what the computer was meant for... That's right! Gaming... I hope I don't lag. :)
Questions or Comments
Contact me via e-mail. I'm pretty good with responding unless it gets caught in my school's junk mail filter.