Add optimization attempts section to README - document why optimizations failed

This commit is contained in:
Ein Anderssono
2026-04-24 02:08:44 +02:00
parent ea42089441
commit e93dbd5206
+43
View File
@@ -63,6 +63,49 @@ Detailed performance reports are available for each decimal precision level:
- **[1000 Decimals](reports/run_1000_output.txt)** - Fast test results - **[1000 Decimals](reports/run_1000_output.txt)** - Fast test results
- **[2000 Decimals](reports/run_2000_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) ## 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. **Important:** These results use a two-step measurement method to eliminate the ~10ms overhead from measurement tools. This gives accurate timing for fast programs.