Mais un code ne peut pas être « trop » optimisé, dans le sens où une optimisation qui provoque des résultats incorrects n'en est pas une, par définition.
Certes, mais ce n'est pas ce qu'ils disent, comme tu le résumes bien, d'ailleurs. Ils parlent bien sûr de code compréhensible.
As-tu déjà lu un code de calcul matriciel optimisé ? Le produit de deux matrices, c'est vraiment le code plon plon par excellence : une bête triple boucle, rien de plus simple. Sauf que pour que ça fonctionne efficacement, il faut respecter les caches, ce qui demande de faire du « blocking ». En gros, tu calcules le produit des matrices par sous-blocs, ce qui rend le programme nettement moins clair. Ensuite, on ajoute du respect de l'alignement, celui de la TLB (voire de NUMA), les threads, les instructions SSE et autres, et ça devient incompréhensible. L'excellent article de Drepper à ce sujet est plein d'exemples édifiants : le code standard en page 49 et celui un peu optimisé en page 50, puis la version hardcore en page 97. Les écarts de performances entre la version simple et la version optimisée sont incroyables.
Je ne sais pas si ngix utilise du code optimisé à ce niveau de sophistication, mais si c'est le cas, je comprends la frousse des gars d'OpenBSD et l'idée que c'est trop optimisé. Les algos qui respectent les caches sont souvent impanables, ce qui pourrait bien être une source de complexité parmi d'autres dans ngix.
[^] # Re: suppressions ?!
Posté par boubou . En réponse à la dépêche OpenBSD 5.6. Évalué à 9.
Certes, mais ce n'est pas ce qu'ils disent, comme tu le résumes bien, d'ailleurs. Ils parlent bien sûr de code compréhensible.
As-tu déjà lu un code de calcul matriciel optimisé ? Le produit de deux matrices, c'est vraiment le code plon plon par excellence : une bête triple boucle, rien de plus simple. Sauf que pour que ça fonctionne efficacement, il faut respecter les caches, ce qui demande de faire du « blocking ». En gros, tu calcules le produit des matrices par sous-blocs, ce qui rend le programme nettement moins clair. Ensuite, on ajoute du respect de l'alignement, celui de la TLB (voire de NUMA), les threads, les instructions SSE et autres, et ça devient incompréhensible. L'excellent article de Drepper à ce sujet est plein d'exemples édifiants : le code standard en page 49 et celui un peu optimisé en page 50, puis la version hardcore en page 97. Les écarts de performances entre la version simple et la version optimisée sont incroyables.
Je ne sais pas si ngix utilise du code optimisé à ce niveau de sophistication, mais si c'est le cas, je comprends la frousse des gars d'OpenBSD et l'idée que c'est trop optimisé. Les algos qui respectent les caches sont souvent impanables, ce qui pourrait bien être une source de complexité parmi d'autres dans ngix.