Posté par jyes .
En réponse à la dépêche OpenBSD 5.6.
Évalué à 5.
Dernière modification le 06 novembre 2014 à 10:30.
c’est de la masturbation intellectuelle. C’est ce que je disais dans un autre commentaire, c’est intéressant pour le sport, pour le défi, mais ça n’a aucune importance pour ça.
Tu n’as vraiment pas l’air de bosser dans le domaine. Dans ce que décrit Boubou, un facteur 30, c’est ce que tu obtiens en réécrivant tes algos sous une forme « cache friendly » ce qui les rend déjà beaucoup moins lisible mais n’est pas encore au niveau des optimisations d’implémentation. C’est bien l’algo qui est réécrit et les données qui sont réorganisées. Une telle optimisation fonctionne plus ou moins efficacement selon la taille des lignes de cache, c’est à dire que le coefficient gagné sera facilement compris entre 5 et 100, mais il est toujours très significatif indépendamment du processeur 1, au prix d’une modification souvent profonde des algos qui peut entraîner une compréhension bien plus difficile du code. Et à ce stade, on n’a pas optimisé de façon spécifique à une architecture, et encore moins à un processeur.
Pour le reste je suis bien d’accord avec toi que la course à l’optimisation est sans intérêt pratique au delà d’un certain niveau, mais le fait est que certaines écritures qui compliquent la compréhension d’un code peuvent avoir des effets suffisamment importants pour ne pas rentrer dans la case masturbation intellectuelle.
Peut-être pas un Z80 ou un truc vraiment pas adapté au calcul de toute façon, mais tous les processeurs courants ont un rapport entre leur performance brute et leur latence d’accès à la mémoire tellement effarant que l’optimisation des caches est toujours significative. ↩
[^] # Re: suppressions ?!
Posté par jyes . En réponse à la dépêche OpenBSD 5.6. Évalué à 5. Dernière modification le 06 novembre 2014 à 10:30.
Tu n’as vraiment pas l’air de bosser dans le domaine. Dans ce que décrit Boubou, un facteur 30, c’est ce que tu obtiens en réécrivant tes algos sous une forme « cache friendly » ce qui les rend déjà beaucoup moins lisible mais n’est pas encore au niveau des optimisations d’implémentation. C’est bien l’algo qui est réécrit et les données qui sont réorganisées. Une telle optimisation fonctionne plus ou moins efficacement selon la taille des lignes de cache, c’est à dire que le coefficient gagné sera facilement compris entre 5 et 100, mais il est toujours très significatif indépendamment du processeur 1 , au prix d’une modification souvent profonde des algos qui peut entraîner une compréhension bien plus difficile du code. Et à ce stade, on n’a pas optimisé de façon spécifique à une architecture, et encore moins à un processeur.
Pour le reste je suis bien d’accord avec toi que la course à l’optimisation est sans intérêt pratique au delà d’un certain niveau, mais le fait est que certaines écritures qui compliquent la compréhension d’un code peuvent avoir des effets suffisamment importants pour ne pas rentrer dans la case masturbation intellectuelle.
Peut-être pas un Z80 ou un truc vraiment pas adapté au calcul de toute façon, mais tous les processeurs courants ont un rapport entre leur performance brute et leur latence d’accès à la mémoire tellement effarant que l’optimisation des caches est toujours significative. ↩