y-cruncher - Language and Algorithms

By Alexander J. Yee


(Last updated: November 22, 2015)



Back To:


Expanded Articles:




Large Number Arithmetic:


Implementation (as of v0.6.9):


General Information:


Libraries and Dependencies:

y-cruncher has no other non-system dependencies. No Boost. No GMP. Pretty much everything that isn't provided by C++ is built from ground up.

Furthermore, the Cilk Plus dependency is not a hard dependency. It can be trivially removed with the only impact being performance.





Other Internal Requirements:


Code Organization:


y-cruncher's root source tree is (roughly) broken up into the following subdirectories:

Module Files Lines of Code Open Sourced? Description
Public Libs 50 5,360 Yes

The public portion of the common support library. It provides a common interface for stuff like time, file I/O, and colored console output.

Private Libs 75 9,642 No

The private portion of the common support library. It has stuff like the memory manager, the parallel framework, and the multi-layer raid-file.

Digit Viewer 71 9,811 Yes

The bundled Digit Viewer.

BBPv2 32 4,313 No

The bundled BBP digit extraction app for Pi.

Objects 40 9,444 Partial

Large number objects. (BigInt, BigFloat, etc...)

Functions 25 3,439 No

Non-trivial math functions. (division, square root, etc...)

YMP Library 15 2,099 Headers Only

A public interface to the internal large number library.

Number Factory 31 3,346 Yes

Research infrastructure and test app for the YMP library.

Launcher 8 582 No

The CPU dispatcher that picks the optimal binary to run.

It's the module that builds the y-cruncher(.exe) binary.

y-cruncher 192 35,489 No

y-cruncher itself. This has most of the console UI and the implementations for all the constants.

Modules 1,179 195,418 No

All the low-level arbitrary-precision arithmetic.

Misc. 9 1,506 No

Settings, versioning, and sandboxes for unfinished work.

Total: 1,716 280,449  

Software bloat anyone?

It takes about 20 minutes and 30 GB of ram to simultaneously compile all of y-cruncher on a Core i7 5960X @ 4 GHz (8 core Haswell).

This is actually quite excessive for only 280,000 lines of code. But there's a multiplier effect with the number of build targets and processor-specific binaries.




Like most other programs, there are theoretical limits to y-cruncher. Most of these limits are enforced by the program.

  32-bit 64-bit Comments

Ram Usage

~1.8 GiB ~ 1 EiB (1018 bytes)

Limited by memory address space.

Disk Usage

~ 1 EiB

Limited by 64-bit address space.

Task Decomposition


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 * 1018) x (2.02 * 1018) bits
(6.7 * 1017) x (6.7 * 1017)
decimal digits

Small Primes Number-Theoretic Transform:

  • 5 x 63-bit primes
  • Transform Length: 7 * 252

Convolution Length

4.03 * 1018 bits
1.34 * 1018 decimal digits

Computation Size

(for all constants)

1015 decimal digits

Limited by double-precision floating-point.*

BBP Hexadecimal Offset

246 - 1

Implementation-specific limitation.

*y-cruncher uses double-precision floating-point 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 double-precision floating-point only has 53 bits of precision which will run out at around 9 * 1015. Since there is round-off error, the limit will certainly be lower. The exact limit is unknown and will vary with the different constants. Therefore y-cruncher arbitrarily caps it to 1015 decimal digits. Colloquially, I call this the "float-indexing 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 float-indexing limit is the only thing left that prevents y-cruncher from going all the way up to the 64-bit limit. Without it, it should be possible to reach 6.7 * 1017 decimal digits (the limit of the Small Primes NTT).


Getting rid of the float-indexing limit will require a floating-point type with at least a 64-bit mantissa. A viable option is to use 80-bit extended-precision 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.