Repository navigation
analyse_problemes_v7_v8
Auteur : hprzeta · Date : 11 juin 2026 Benchmark complet prec_fast/prec_full + W=4 vs W=8
v7 (prec_fast=64 bits, SIMD) atteint 30,9 min à prec_full) et
nombre de workers. Résultat : gain marginal ×1,06, plancher hardware atteint
sur i7-7500U (dual-core HT, 4 threads logiques).
illinois_refine_adaptive utilise deux phases :
| Phase | Itérations | Précision | Limbes mpfr |
|---|---|---|---|
| 1 (rapide) | 64 bits | 1 — SIMD AVX2 | |
| 2 (précise) | 116 bits | 2 |
Le gain v6→v7 (×3,7) vient entièrement de la phase 1 : prec_fast=64 bits → 1 limbe.
La phase 2 (116 bits, 2 limbes) reste le seul levier non exploité.
500 brackets sur
| Config (fast, full) | Limbes ph1+ph2 | ms/appel | Gain | |
|---|---|---|---|---|
| (64, 116) | 1+2 | 0,443 ms | ×1,00 | référence v7 |
| (48, 116) | 1+2 | 0,559 ms | ×0,79 | ❌ |
| (32, 116) | 1+2 | 0,875 ms | ×0,51 | ❌ |
| (64, 96) | 1+2 | 0,476 ms | ×0,93 | ❌ |
| (64, 80) | 1+2 | 0,416 ms | ×1,06 | ✅ optimal |
Précision finale (
mpfr alloue toujours un minimum de 64 bits par limbe. prec=32 déclenche des
conversions d'arrondi supplémentaires (downcast 64→32 bits) sans réduire
la taille mémoire. L'overhead est pire, pas meilleur.
Les deux ont 2 limbes. La différence vient du nombre d'opérations internes
des fonctions transcendantes mpfr (mpfr_cos, mpfr_log) :
Avec
| Workers | Durée | z/s | Gain |
|---|---|---|---|
| W=4 | — | 2 505,8 z/s | ×1,00 (référence) |
| W=8 | — | 2 474,0 z/s | ×0,99 ❌ |
i7-7500U : 2 cœurs physiques, HT → 4 threads logiques (nproc=4).
W=8 > nproc → context-switching → perte nette de 1,2%.
L'overhead de création de processus (8 forks, 8 .so chargés, 8 segments
de mémoire partagée) dépasse le bénéfice HT.
compute_zeros_v7.py (nommage intermédiaire de test) puis compute_zeros_v8.py :
| Paramètre | v7 (ref) | v8 |
|---|---|---|
prec_fast |
64 bits | 64 bits (inchangé) |
prec_full |
116 bits | 80 bits |
ITER_SWITCH |
8 | 8 (inchangé) |
MAX_ITER |
50 | 50 (inchangé) |
| Durée T=100k estimée | 30,9 min | ~29 min |
| Gain | — | ×1,06 |
Borne inférieure théorique de durée sur i7-7500U :
Cette borne est inatteignable en pratique (scan, Turing, I/O). La durée réaliste plancher est ~29 min — c'est ce que v8 atteint.
Conclusion : les optimisations algorithmiques sur ce CPU sont épuisées. Les prochains gains nécessitent du matériel différent.
| Version | Durée T≈100k | Gain cumulé | Levier principal |
|---|---|---|---|
| v1 | 21h | ×1 | Newton scalaire |
| v2 | 2h | ×10 | Illinois bracket |
| v3 | 45min | ×28 | Parallèle W=4 |
| v4.1 | 9min | ×140 | Illinois C/libmpfr |
| v5 | ~1min* | ×1 260* | Arb hardy_z |
| v6 | ~130min | — | STEP=0.010 + scan_arb.c |
| v7 | 30,9min | ×4,2 vs v6 | prec_fast=64 bits → SIMD |
| v8 | ~29min | ×1,06 vs v7 | prec_full=80 bits |
*v5 mesuré sur T=10k uniquement.
Gain total v1 → v8 : ×5 628 (21h → ~29 min)
| Option | Description | Gain estimé | Difficulté |
|---|---|---|---|
| A | CPU 8 cœurs physiques (i9, Ryzen 9, M3 Pro) | ×2 | Matériel |
| B |
Arb acb_dirichlet_hardy_z pour affinage |
à benchmarker | Moyen |
| C | GPU CUDA détection Z_double (GTX 960M) | ×100 détection mais 0,2% du temps | Élevée |
| D | Termes RS d'ordre supérieur ( |
réduit biais, pas la vitesse | Très élevée |
Option A est la plus directe : passer de 4 à 8 workers réels divise la durée par ×2.
La progression v1→v7 (×5 292 de gain) a atteint la limite architecturale du i7-7500U. Chaque optimisation algorithmique restante donne moins que la précédente. La loi des rendements décroissants s'applique.
Voir aussi : Formules_zeta · analyse_problemes_v6_v7 · STACK
Fichier : analyse_problemes_v7_v8.md · Dossier : wiki master Auteur : hprzeta · MAJ : 11 juin 2026 · 12 septembre 2026 (correction rendu KaTeX : _ et # — GitHub retirait le backslash en mode math) · ~120 lignes