(Last updated: February 4, 2019)
Back To:
General:
Large Number Arithmetic:
Implementation (as of v0.7.7):
General Information:
Libraries and Dependencies:
ycruncher has no other nonsystem dependencies. No Boost. No GMP. Pretty much everything that isn't provided by C++ is built from ground up.
Furthermore, the Cilk and TBB dependencies can be trivially removed without affecting the core functionality of the program.
Compilers:
Other Internal Requirements:
Code Organization:
ycruncher's root source tree is (roughly) broken up into the following subdirectories. They are listed in order of build dependency.
Module  Files  Lines of Code  Open Sourced?  Description 
Public Libs  142  13,820  Yes  The public portion of the support libraries. 
Private Libs  371  44,112  No  The private portion of the support libraries. 
Dynamic Linking  3  213  No  Nothing here yet. 
Launcher  10  844  Yes  The CPU dispatcher that picks the optimal binary to run. It's the module that builds the ycruncher(.exe) binary. 
Digit Viewer 2  91  11,350  Yes  The new Digit Viewer. 
BBPv2  32  4,384  No  The bundled BBP digit extraction app for Pi. 
Modules 
1,958  313,666  No  Lowlevel arbitraryprecision arithmetic: Addition, subtraction, multiplication, singleword division, and checksum hashing. 
Objects  84  16,311  Partial  Large number objects. (BigInt, BigFloat, etc...) 
Functions  327  49,988  No  Highlevel mathematical code. Implementations for all functions and all the constants. 
YMP Library  14  2,223  Headers Only  A public interface to the internal large number library. 
Number Factory  31  3,417  Yes  Research infrastructure and test app for the YMP library. 
ycruncher  267  37,458  No  ycruncher itself. Toplevel code that includes all the UI menus. 
Experimental  98  14,244  No  Sandboxes for experimental code. 
Misc.  9  1,183  No  Settings, versioning, and development sandbox. 
Total:  3,437  513,213  Software bloat anyone? 
Notes:
ycruncher didn't become this bloated to compile until around 2014 when it started using template metaprogramming. But for now, the compilation problem can still be solved by throwing bigger hardware at it. As of 2018, ycruncher can still be compiled on the highestend of laptops. But doing so takes a long time and it cannot all be done at once.
Like most other programs, there are theoretical limits to ycruncher. Most of these limits are enforced by the program.
32bit  64bit  Comments  
Ram Usage 
~1.8 GiB  ~ 1 EiB (10^{18} bytes)  Limited by memory address space. 
Disk Usage 
~ 1 EiB  Limited by 64bit address space. 

Task Decomposition 
65,536  Arbitrary limit. 

RAID  Level 1 
8 paths 


RAID  Level 2 
64 x Level 1 RAID groups  Limited by the # of bits in largest integer. Will likely be increased in the future. 

Largest Multiplication 
(2.02 * 10^{18}) x (2.02 * 10^{18}) bits (6.7 * 10^{17}) x (6.7 * 10^{17}) decimal digits 
Small Primes NumberTheoretic Transform:


Convolution Length 
4.03 * 10^{18} bits 1.34 * 10^{18} decimal digits 

Computation Size (for all constants) 
10^{15} decimal digits  Limited by doubleprecision floatingpoint.* 

BBP Hexadecimal Offset 
2^{46}  1  Implementationspecific limitation. 
*ycruncher uses doubleprecision floatingpoint for things such as:
The result of these calculations are generally rounded to integers and must be accurate to +/ 1 for the program to operate correctly. The problem is that doubleprecision floatingpoint only has 53 bits of precision which will run out at around 9 * 10^{15}. Since there is roundoff error, the limit will certainly be lower. The exact limit is unknown and will vary with the different constants. Therefore ycruncher arbitrarily caps it to 10^{15} decimal digits. Colloquially, I call this the "floatindexing limit".
There are currently no plans to raise this limit since it is already well beyond the capability of current hardware (as of 2015).
It is worth mentioning that the floatindexing limit is the only thing left that prevents ycruncher from going all the way up to the 64bit limit. Without it, it should be possible to reach 6.7 * 10^{17} decimal digits (the limit of the Small Primes NTT).
Getting rid of the floatindexing limit will require a floatingpoint type with at least a 64bit mantissa. A viable option is to use 80bit extendedprecision via the x87 FPU although some compilers don't support it. But since "float indexing" isn't exactly a performance bottleneck, any sort of software emulation will probably work as well.