En général, on optimise pour atteindre un objectif. Si c’est juste pour le sport (passer 1 mois à gagner 3 requêtes par seconde), le code devient crade.
Je ne parle pas de ça, je parle de facteurs 10 à 30. Dans un code intensif en mémoire, c'est-à-dire dès que les données ne tiennent pas dans les caches, le schéma d'accès à la mémoire a une influence cruciale sur les performances. Alors que la puissance normale d'un cœur intel est de l'ordre de 6 Gflop/s (une addition et une multiplication par cycle d'horloge), un code naïf sur l'accès mémoire récupère au mieux du 600 Mflop/s, voire seulement 200 Mflop/s. C'est pourquoi il est indispensable pour du code numérique d'utiliser une implémentation compliquée. Dans un langage de très haut niveau comme le C++, tout est caché dans des expressions templates, ce qui permet de faire du calcul matriciel lisible à très hautes performances. Dans des langages de très bas niveau comme le C, il faut faire les optimisations à la main, ce qui rend les bibliothèques très difficiles à lire.
Dans le contexte du web, on peut aussi gagner des facteurs de l'ordre de 10. Par exemple Varnish utilise des techniques sophistiqués pour faire ça, cf l'article de ACM queue à ce sujet.
Le fond de l'histoire est que pour utiliser vraiment bien le matériel moderne, il faut modifier les algorithmes pour qu'ils respectent les caches, ce qui rend les programmes plus complexes directement au niveau algorithmique, sans parler de l'implémentation.
C'est aussi vrai pour le multithread : pour avoir des structures de données efficaces en multithread, il faut des algorithmes d'une sophistication assez effrayante. Et de nouveau, on n'est pas dans l'optimisation d'une requête de plus ou de moins, mais bien d'un facteur 10. Je conseille vivement à ce sujet le bouquin the art of multiprocessor programming écrit par des pontes du sujet.
[^] # Re: suppressions ?!
Posté par boubou . En réponse à la dépêche OpenBSD 5.6. Évalué à 7.
Je ne parle pas de ça, je parle de facteurs 10 à 30. Dans un code intensif en mémoire, c'est-à-dire dès que les données ne tiennent pas dans les caches, le schéma d'accès à la mémoire a une influence cruciale sur les performances. Alors que la puissance normale d'un cœur intel est de l'ordre de 6 Gflop/s (une addition et une multiplication par cycle d'horloge), un code naïf sur l'accès mémoire récupère au mieux du 600 Mflop/s, voire seulement 200 Mflop/s. C'est pourquoi il est indispensable pour du code numérique d'utiliser une implémentation compliquée. Dans un langage de très haut niveau comme le C++, tout est caché dans des expressions templates, ce qui permet de faire du calcul matriciel lisible à très hautes performances. Dans des langages de très bas niveau comme le C, il faut faire les optimisations à la main, ce qui rend les bibliothèques très difficiles à lire.
Dans le contexte du web, on peut aussi gagner des facteurs de l'ordre de 10. Par exemple Varnish utilise des techniques sophistiqués pour faire ça, cf l'article de ACM queue à ce sujet.
Le fond de l'histoire est que pour utiliser vraiment bien le matériel moderne, il faut modifier les algorithmes pour qu'ils respectent les caches, ce qui rend les programmes plus complexes directement au niveau algorithmique, sans parler de l'implémentation.
C'est aussi vrai pour le multithread : pour avoir des structures de données efficaces en multithread, il faut des algorithmes d'une sophistication assez effrayante. Et de nouveau, on n'est pas dans l'optimisation d'une requête de plus ou de moins, mais bien d'un facteur 10. Je conseille vivement à ce sujet le bouquin the art of multiprocessor programming écrit par des pontes du sujet.