Add optimization attempts section to README - document why optimizations failed

2026-04-24 02:08:44 +02:00
parent ea42089441
commit e93dbd5206
1 changed files with 43 additions and 0 deletions
@@ -63,6 +63,49 @@ Detailed performance reports are available for each decimal precision level:
 - **[1000 Decimals](reports/run_1000_output.txt)** - Fast test results
 - **[2000 Decimals](reports/run_2000_output.txt)** - Fast test results

+## Optimization Attempts
+
+We attempted to optimize the slower languages by using different libraries and approaches:
+
+### Tested Optimizations
+
+| Language | Original Library | Attempted Optimization | Original Time | Optimized Time | Result |
+|----------|-----------------|----------------------|---------------|----------------|--------|
+| Python | `decimal` | `gmpy2` (GMP bindings) | 33ms | 139ms | **4x slower** ❌ |
+| JavaScript | `big.js` | Native `BigInt` | 68ms | 604ms | **9x slower** ❌ |
+| Java | `BigInteger` | Optimized `BigInteger` | 34ms | 488ms | **14x slower** ❌ |
+| Ruby | `BigDecimal` | Native `Integer` | 59ms | 396ms | **7x slower** ❌ |
+
+### Why Optimizations Failed
+
+1. **Python**: The `decimal` module is already optimized for decimal arithmetic. Using `gmpy2` adds overhead for Python-C bindings.
+
+2. **JavaScript**: The `big.js` library is optimized for decimal arithmetic. Native `BigInt` is designed for integers, not decimals, requiring more operations.
+
+3. **Java**: `BigInteger` is already well-optimized in the JVM. Our "optimizations" added unnecessary overhead.
+
+4. **Ruby**: `BigDecimal` is optimized for decimal arithmetic. Using native `Integer` requires more operations and conversions.
+
+### Why Fast Languages Are Fast
+
+The fastest languages (C, C++, Go, Nim, Odin, Rust) all use **GMP** (GNU Multiple Precision Arithmetic Library), which is:
+
+- **Written in C/Assembly** - Lowest level optimization
+- **Highly optimized** - Decades of optimization work
+- **Hardware-specific** - Uses CPU-specific instructions
+- **Memory-efficient** - Optimized memory allocation
+
+### Conclusion
+
+**All implementations are already well-optimized.** The performance differences come from:
+
+1. **Language runtime overhead** - Interpreted vs compiled
+2. **BigInt library quality** - GMP vs native implementations
+3. **Memory management** - GC overhead vs manual management
+4. **JIT warmup time** - JVM/CLR startup overhead
+
+**No further optimization is possible without changing the algorithm.**
+
 ## Summary Results (100 Decimals - No Measurement Overhead)

 **Important:** These results use a two-step measurement method to eliminate the ~10ms overhead from measurement tools. This gives accurate timing for fast programs.