(Last updated: January 16, 2017)
There is currently no reliable place to get the digits. Due to the large sizes of the data, it simply isn't feasible to move them around.
Personally, I have an archive of some of the digits including the first 12.1 trillion digits of Pi. But because I'm on a consumer internet connection with rate and possibly bandwidth limits, it simply isn't possible for me to upload them. When I was still in school, I was able to seed some torrents since university connections are very fast. But that isn't possible anymore.
To answer the question directly, your best bet at getting the digits is to:
Under extreme circumstances (if you're a famous professor trying to do research), I may make special arrangements to run research code locally on my machine. But this has happened only once and I was dealing with some pretty amazing professors which I didn't want to let down.
In short no. Not because I don't want to, but because I can't. 13 trillion digits is a lot of digits. It takes several days just to read all of it. So searching requires too much time and computational resources. I'm not Google and I don't have the ability to search index something that large.
In short no. The goal of y-cruncher is not to be the jack of all trades, but to focus on a small number of major constants and take them to the extreme.
Because of this emphasis on specialization, adding a new constant is not as simple as plugging in a new formula and pushing a button. In other words, there are technical and practical barriers to adding support for arbitrary constants or functions.
From the technical perspective, all constants need to be computable to N digits in quasi-linear time and linear memory. This automatically rules out a large number of requests that I get for new constants. Hard to compute things like Khinchin's Constant will never be computable to billions of digits unless someone discovers a suitable algorithm for it. For stuff like this, the y-cruncher project is the wrong tool for the job since it's specialized for billions and trillions of digits.
From the practical side, the issue is mostly a matter implementation and maintainance costs. The more stuff there is, the more you need to do. Furthermore, most of the constants that are currently supported by y-cruncher are computable using a very small number of specially optimized subroutines. Anything that needs more than that will be a lot of work. This is why the Lemniscate constant uses the ArcSinlemn formulas instead of the AGM. The AGM is faster, but y-cruncher has no support for a fully generic square root function. And Lemniscate is "not important enough" to justify adding such support.
As far as "plugging in formulas" goes, the easiest way is to use something like Mathematica since it's literally built for this purpose. If you need more performance, or if you need to reach sizes that are larger than what Mathematica can handle, you can try out the NumberFactory/YMP project. It's a partially open-sourced C++ project that exposes y-cruncher's parallelized bignum arithmetic. But of course, you'll need experience in C++ to be able to use it.
If you're seeing this on the standard benchmark sizes, then your system is not as stable as you think it is.
This error is most commonly seen on Haswell processors that are overclocked. y-cruncher makes heavy use of AVX instructions if the processor supports them. So in order to successfully run a y-cruncher benchmark, your system needs to be AVX-stable.
If you search around overclocking forums, you'll find out that Haswell processors are notorious for generating a tremendous amount of heat when running AVX workloads like the latest Prime95. And for that reason, many overclockers will skip these stress-tests calling them "unrealistic". While this allows for significantly higher overclocks, it sacrifices stability for AVX-optimized applications. So it's common for overclocked systems to be perfectly stable for months, and then immediately crash and burn when attempting to run y-cruncher or the latest Prime95.
If you fall into this category, lower your overclock. While this is most commonly seen on Haswell, it has also been observed on Skylake as well as any system with unstable cache or memory.
While y-cruncher isn't quite as stressful as latest Prime95, the workload is very similar. So if you cannot pass Prime95 small FFTs (with AVX) for at least a few seconds, you stand no chance of running any large benchmark or computation with y-cruncher.
As of 2016, y-cruncher runs more than 2x faster on the latest Intel processors (Haswell/Skylake) than the latest AMD processors (Bulldozer). While Intel processors have had the edge since 2006-ish, a difference of more than 2x at the same clock speeds is "too much".
It boils down to the raw SIMD throughput. Intel processors have 256-bit wide vector units while AMD processors are only 128-bits wide. While Intel processors can natively run 256-bit AVX instructions, AMD processors need to split them into a pair of 128-bit ops.
y-cruncher is one of the few applications that can utilize the AVX instructions to get the full benefit of the vector units. So this gives Intel processors an automatic 2x advantage. Combine that with Intel's architectural advantages and you end up with a performance gap of more than 2x.
Here's a data dump of the performance throughput of various vector operations. Higher is better.
For unreleased processors, the pink entries are educated guesses based on publicly released information at the time of writing.
|Hardware||Throughput Per Cycle|
|Processor||Year||Unit||Vector Width||Vector Units||Floating-Point||Integer|
|Add||Mul||Add or Mul||FMA||Add||Mul||Logic|
|Intel Sandy Bridge||2011||1 core||256 bit||3||1 x 256||1 x 256||2 x 256||2 x 128||1 x 128||3 x 128|
|Intel Ivy Bridge||2012|
|Intel Haswell||2013||1 core||256 bit||3||1 x 256||2 x 256||2 x 256||2 x 256||2 x 256||1 x 256||3 x 256|
|Intel Skylake||2015||1 core||256 bit||3||2 x 256||2 x 256||2 x 256||2 x 256||3 x 256||2 x 256||3 x 256|
|Intel Kaby Lake||2017|
|Intel Knights Landing||2016||1 core||512 bit||2||2 x 512||2 x 512||2 x 512||2 x 512||2 x 512||2 x 512||2 x 512|
|Intel Skylake Purley||2017||1 core||512 bit||3||2 x 512||2 x 512||2 x 512||2 x 512||3 x 512||2 x 512||3 x 512|
|AMD Bulldozer||2011||1 module||128 bit||2||2 x 128||2 x 128||2 x 128||2 x 128||2 x 128||1 x 128||2 x 128|
|AMD Zen||2017||1 core||128 bit||4||2 x 128||2 x 128||4 x 128||2 x 128||?||?||?|
There really isn't much that needs to be said. Intel chips currently have much better SIMD throughput.
Looking forward to AMD Zen, things are better. But likely still not good enough.
This is still a no-go for current generation GPUs. But things may get more interesting with Xeon Phi.
To expand on the severity of the communication bottleneck:
The only possible option is to utilize GPU onboard memory as a cache for main memory in a manner similar to how y-cruncher currently uses main memory as a cache for disk. But this is an additional level of design complexity that will not be easy to do.
Fundamental issues aside, the biggest practical barrier would be the need to rewrite the entire program using GPU programming paradigms. And for a project of this size that's merely a side hobby, it simply isn't feasible.
But before we slam the door on GPUs, it's worth mentioning the Xeon Phi processor line. While these aren't exactly GPUs, they are still massively parallelized and have large SIMD vectors. Preliminary benchmarks on Knights Landing are somewhat disappointing even with the AVX512 binaries. But it's difficult to draw any conclusions without access to the hardware and without the ability to tune the program for the hardware.
No for more or less the same reasons that GPUs aren't useful.
No, but it is a current research topic.
For now, the best thing you can do is to interleave memory. In Linux, this can be done by running: numactl --interleave=all "./y-cruncher.out"
Some systems have a BIOS options that do something similar.
While the rest of the world is trending towards more parallelism, computations of Pi seems to have gone the other way.
The only recent Pi record which has "gone the other way" is Fabrice Bellard's computation of 2.7 trillion digits back in 2009. That was the major leap from supercomputer to... a single desktop computer. But since then, all the records have been done using increasingly larger (commodity) server hardware. Nevertheless, the hardware used in these computations are still pretty far removed from actual supercomputers.
So the real question is: Why aren't we using supercomputers anymore?
Unfortunately, I don't have a good answer for it. Sure y-cruncher has been dominating the recent Pi records using single-node computer systems. But that doesn't explain why nobody from the supercomputer field has joined in. Some possible contributing factors are:
Yes. But it isn't as stable as a library should be. Support only exists for 64-bit Windows and backwards compatibility breaks on a regular basis.
y-cruncher itself is closed source. But some of the related side-projects like the Digit Viewer and the Number Factory app are open-sourced.
"Total Computation Time" is the total time required to compute the constant. It does not include the time needed to write the digits to disk nor does it include the time needed to verify the base conversion. "Total Time" is the end-to-end time of the entire computation which includes everything.
The CPU utilization measurements cover the same thing as the "Total Computation Time". It does not include the output or the base convert verify.
For benchmarking, it's better to use the "Total Computation Time". A slow disk that takes a long time to write out the digits will affect neither the computation time nor the CPU utilization measurements. Most other Pi-programs measure time the same way, so y-cruncher does the same for better comparability. All the benchmark charts on this website as well as any forum threads run by myself will use the "Total Computation Time".
For world record size computations, we use the "Total Time" since everything is relevant - including down time. If the computation was done in several phases, the run-time that is put in the charts is the difference between the start and end dates.
There's currently no "standard" for extremely long-running computations that are neither benchmarks nor world record sized.
Privilege elevation is needed to work-around a security feature that would otherwise hurt performance.
In Swap Mode, y-cruncher creates large files and writes to them non-sequentially. When you create a new file and write to offset X, the OS will zero the file from the start to X. This zeroing is done for security reasons to prevent the program from reading data that has been leftover from files that have been deleted.
The problem is that this zeroing incurs a huge performance hit - especially when these swap files could be terabytes large. The only way to avoid this zeroing is to use the SetFileValidData() function which requires privilege elevation.
Linux doesn't have this problem since it implicitly uses sparse files.
For small computations, there isn't much that can be parallelized. In fact, spawning N threads for an N core machine may actually take longer than the computation itself! In these cases, the program will decide not to use all available cores. Therefore, parallelism is really only helpful when there is a lot of work to be done.
For those who prefer academic terminology, y-cruncher has weak scalability, but not strong scalability. For a fixed computation size, is it not possible to sustain a fixed efficiency while increasing the number of processors. But it is possible if you increase the computation size as well.
Short answer: Not right now. There's little to gain for a lot of effort.
While it would be nice to have y-cruncher running everywhere, the time and resource commitment is simply too high. So the best I can do is cover the most important platforms and call it day.
y-cruncher currently supports 3 platforms, Windows/x86, Windows/x64, and Linux/x64. Either of the x64 platforms is sufficient for y-cruncher's purpose. Windows/x86 is there because the program started that way and it's easy to maintain it alongside Windows/x64. On the other hand, Linux/x64 is a completely different platform with different compilers and system APIs. For this reason, it takes a signifcant amount of time and effort to keep y-cruncher working on Linux/x64.
My experience with just Linux has basically convinced me to stay away from any additional platforms for the time being.
What about Mac/x64?
I'm not going to spend my time figuring out Hackintosh installs nor am I going to buy certified Mac hardware. It's messy enough just to dual-boot Windows/Linux on all my boxes. Triple boot Windows/Linux/Mac? Um...
What about ARM?
ARM is not yet competitive with x64 on the high-end server market - let alone mainstream. So there's little to gain from it. Furthermore, I have no experience or expertise on ARM development. As far as having the hardware, I have a smartphone...
Even if y-cruncher were open-sourced with willing contributors, this wouldn't be easy. For one, there are no ARM/NEON-optimized code-paths. And even if someone were to do it, the code goes through way too many large and breaking changes.