Pourquoi calculer 10 000 zéros précis de $\zeta$ coûte des heures — et où sont (et ne sont pas) les vrais leviers d'optimisation.
Dans le cours n°1, on a vu que chercher un zéro de $\zeta$ revient à chercher un changement de signe de la fonction réelle $Z(t)$ de Hardy. Mais localiser précisément ce zéro a un coût caché. Ce coût forme un mur : on peut le contourner, jamais le percer à mains nues.
La factorisation sur la droite critique donne une fonction réelle :
On l'évalue par la formule de Riemann-Siegel — une somme de $N$ termes plus un reste :
avec la phase asymptotique
Trouver un zéro précis n'est pas une opération : c'est une chaîne d'environ 27 évaluations de $Z$ qui doivent se faire l'une après l'autre (chaque itération a besoin du résultat de la précédente). Et chaque évaluation est elle-même une somme de $N$ termes multi-précision. Regarde la chaîne tourner :
siegelz en chaîne — strictement séquentielsMathématiquement, trois niveaux s'emboîtent :
Niveau 1 — un appel. Une opération multi-précision à $\text{dps}$ chiffres coûte $O(\text{dps}^2)$, et il y a $N$ termes :
Niveau 2 — un zéro. L'affinage est une récurrence (méthode de la sécante / Illinois) : chaque pas dépend du précédent, donc aucun parallélisme interne possible.
Niveau 3 — le run complet. Les $n$ zéros, eux, sont indépendants → parallélisables sur $W$ cœurs :
| Grandeur | Calcul | Valeur |
|---|---|---|
| Nombre de termes $N$ | $\lfloor\sqrt{9000/2\pi}\rfloor=\lfloor 37{,}85\rfloor$ | 37 |
Coût d'un appel siegelz | mesuré, dps≈30 | ≈ 296 ms |
| Itérations par zéro | findroot Illinois | ≈ 27 |
| Coût d'un zéro $c_{\text{zéro}}$ | $27\times 296\,$ms | ≈ 8,0 s |
| Débit (4 workers) | $4/8{,}0$ | ≈ 0,5 z/s |
| Run $T=10000$ | $\approx 10\,142/0{,}5$ (queue plus lente) | ≈ 5–7 h |
Pousse les curseurs : tu verras que le temps ne passe sous 30 min ni avec le GPU, ni avec la RAM (absents de la formule), mais seulement avec ~56 cœurs (irréaliste) ou un changement de librairie (Arb à la place de mpmath).
Le module C affine sur la série tronquée $Z_{\text{mpfr}}=Z+R$, pas sur le vrai $Z$. Il converge donc vers $\gamma_{\text{mpfr}}$ tel que $Z(\gamma_{\text{mpfr}})=-R(\gamma_{\text{mpfr}})$. Un développement de Taylor au premier ordre autour du vrai zéro $\gamma$ donne l'erreur de position :
À $t\approx 350$ : $N=7$, $|R|\sim 10^{-3}$, croisement plat → écart mesuré 0,016 — très loin de $10^{-10}$. C'est structurel, pas un bug. Pour des positions précises il faut un polish final sur le vrai $Z$ via siegelz — et c'est lui le goulot du niveau 2.
De plus, la précision absolue requise grandit avec la hauteur :
ce qui fixe un plancher de précision (~dps 25) : on ne peut pas baisser dps librement.
Pour passer de ~7 h à < 30 min il faut un gain ×14. Voici où chaque levier agit dans $T_{\text{total}}=\dfrac{n\cdot n_{\text{itér}}\cdot t_{\text{appel}}}{W}$ :
| Levier | Effet | Sur cette machine ? |
|---|---|---|
| Cœurs $W$ (dénominateur) | linéaire ; ×14 ⇒ ~56 cœurs | ✗ 4 cœurs |
| GPU GTX 960M | n'agit que sur la détection (10–20 %) ; mpmath non portable GPU | ✗ nul sur le polish |
| RAM / swap | absents de la formule ; toucher le swap ≈ ×1000 plus lent | ✗ aucun effet |
| Itérations $n_{\text{itér}}$ (Newton) | réfuté par la mesure (le goulot n'est pas le nombre d'appels) | ✗ |
Précision dps ($\propto\text{dps}^2$) | plancher ~25 ; gain modeste ×1,4 | ~ marginal |
| Librairie : Arb au lieu de mpmath | $t_{\text{appel}}$ ÷10–20 à précision égale | ✓ ~20–25 min sur 4 cœurs |
Le vrai levier est logiciel, pas matériel. Et si l'objectif n'est que de vérifier HR jusqu'à T (comptage de Turing $n_{\text{calc}}=N(T)$, sans positions précises), on saute tout le niveau 2 : Illinois_C pur ≈ 41 z/s ≈ 4 min. Le mur n'existe que pour le catalogue de positions $<10^{-10}$ — lequel existe déjà (CSV v2, 10 142 zéros, 50 dps).