FibSec

Background to this project

I watched One second to compute the largest Fibonacci number I can, I like comparing approaches and wanted to learn/ practice my design patterns for modern C++. Thought it would be a fun project to recreate. As usual, this is a toy-project aimed at being learning-friendly, demonstrating real-world C++ design patterns — dynamic extensibility, static initialization, and runtime polymorphism — all applied in a self-contained, enjoyable thing.

C++ Design

┌──────────────────────────────┐ │main.cpp │ │ - Program entry point │ │ - Lists available solvers │ │ - Benchmarks and runs them │ └────────────┬─────────────────┘ │ ┌────────────▼─────────────────┐ │GenericSolverFactory │ │ - Manages all solver types │ │ - Unified interface for main │ └────────────┬─────────────────┘ │ ┌────────────▼──────────────────────────────────────┐ │SolverFactory | │ - Per-type factory | │ - Knows how to construct solvers of IFibSolver │ │ - Registered via static or explicit code │ └────────────┬──────────────────────────────────────┘ │ ┌────────────▼─────────────────────────┐ │IFibSolver Interface │ │ - Abstract base class │ │ - Each solver implements compute() │ └──────────────────────────────────────┘

C++ Solvers

• Naive (recursive)
• Naive (recursive memoized)
• Iterative (big int)
  • Boost's cpp_int
• Matrix Exponentiation
  • SIMD-ed with ARM NEON
• Matrix Fast Doubling

Limitations

I haven't handled data-types particularly well... I noticed in the NEON implementation, expected values diverge after F(92), it should just be a representation/ printing issue.

Factory fun

Generic factory pattern for creating different solver instances. Tried to minimize duplicative code, ended up duplicating registration.

Contributing?

Wouldn't bother. But, more solvers and approaches would be great to see :).