Posté par X345 .
En réponse à la dépêche OpenBSD 5.6.
Évalué à 10.
Je sais pas si je me suis progressivement transformé en vieux con, mais qu'est-ce qu'on peut lire comme c*nn*eries sur linuxfr (excusez le terme).
des euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération, car :
Les lignes de cache ne feront plus la même taille,
Je passe sur l'utilisation douteuse du mot heuristique, qui paraîtrait ici très avantageusement remplacé par hypothèse ou propriété.
Haswell, cache line size (2013) : 64o (p. 2-5)
Sandy Bridge, cache line size (2011) : 64o (p. 2-17)
Nehalem, cache line size (2008) : 64o (p. 2-43)
Core, cache line size (2006): 64o (p. 2-36)
Référence : Intel 64 and IA-32 Architectures Optimization Reference Manual (March 2014), les numéros de pages sont donnés pour chaque architecture.
Donc bon, ça fait quand même au moins 4 générations (8 ans) que les lignes de cache font 64 octets. Certes il arrive que la taille des lignes de cache change, mais c'est bien loin d'être "à chaque génération". Pour information, le Pentium 4 avait des lignes de caches de 64o (aussi) pour le L1 et des lignes de caches de 128o pour le L2.
La prédiction de branchement sera plus efficace,
Si on veut, je peux difficilement te contredire là dessus vu qu'Intel ne publie pas les spécifications complètes de ses prédicteurs de branchements.
Nehalem, misprediction penalty : ~17 cycles
Sandy Bridge, misprediction penalty : ~15 cycles
Haswell, misprediction penalty : 15-20 cycles
Référence : The microarchitecture of Intel, AMD and VIA CPUs, Agner Fog http://www.agner.org/optimize/microarchitecture.pdf
De là a dire que les changements au niveau du predicteur de branchement vont mettre en l'air tes optimisations, ça me parait carrément péremptoire.
Là encore, pas très significatif comme différences...
Il vaut mieux se concentrer sur les structures de données, et faire des algo compréhensible par les compilateurs de façon à se qu’ils optimisent. Par expérience, à moins d’investir énormément, le choix de l’algo et son codage simple permet au compilateur de donner de très bon résultat.
C'est effectivement la base de la base d'utiliser les bonnes structures de données, mais on se tue à t'expliquer qu'entre une implémentation naïve et une implémentation optimisée, y'a parfois de gros speedups : 10 fois, 100 fois dans certains cas.
De plus, tu occultes le fait que tout le monde n’a pas une puce Intel et que dans ce cas, il faut aussi optimiser pour AMD, faire un algo spécial pour chaque ARM, etc.
[...]
Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €
Vive la contradiction. Donc d'un côté t'as des contraintes budgétaires et de l'autre tu t'amuses à optimiser ton code pour 40 architectures différentes. Dans l'"industrie" comme tu dis, la manière raisonnable de procéder serait d'optimiser ton code pour qu'il tourne sur des Xeon Ivy Bridge (ou ce que tu as comme machines) et point. Tu vas pas t'amuser à l'optimiser pour toute la planète si t'as des contraintes budgétaires. Et si t'as deux générations de processeurs en production, bah tu optimises pour les deux générations et basta (et comme je le montrais plus haut, ça ne varie pas forcément énormément).
C’est envisageable quand tu fais de l’embarqué, que tu connais ta cible pour de l’applicatif PC, c’est de la masturbation intellectuelle
Wow ! de l'applicatif PC ! Il ne t'a pas échappé à l'esprit de l'applicatif PC, ben, ça ne représente pas un marché énorme. On est plus en 1995 hein. Et c'est toi qui parle de masturbation intellectuelle. On se dirige beaucoup vers un modèle de service donc le code s'exécute de plus en plus sur des serveurs. Et code plus performant = moins de serveurs = moins de coûts d'exploitation. 10 machines c'est moins cher que 100.
Dans l'applicatif PC, je pense que les jeux vidéos et les logiciels d'ingénierie doivent représenter une bonne partie du marché (MATLABS, Comsol etc.). Justement du code qui demande d'être optimisé !
Mais il ne faut pas tomber dans le travers inverse à chasser la dernière ns en dépensant 30 jours de développement.
Je vois que tu es universitaire d’après ton lien page perso. Ce qui explique cela.
Mais personne ne passe 30 jours pour une nano-seconde. Personne. On se tue à t'expliquer que si on passe 30 jours, c'est pour avoir un speedup de 10. Et puis parfois, c'est rentable, Facebook paye des ingés à optimiser son code et dès qu'ils gagnent 0.5%, ça part en prod. Parce 0.5% de performance en plus, c'est x € économisés en serveurs (https://www.youtube.com/watch?v=Qq_WaiwzOtI)
Sinon, tu peux aussi embaucher des ingés compétents qui ont pas besoin de 30 jours pour écrire du SIMD et faire du cache blocking...
Bon, et merci pour bashing gratuit des universitaires qui passeraient leur temps à faire des choses pas très utiles et à faire du sport et de la masturbation intellectuelle. Tu sais si tu veux que ton papier passe dans une bonne conf, t'as intérêt à démontrer que ton axe de recherche et tes résultats sont utiles.
Plus généralement, tu nous ressors le poncif classique répété à loisir jusqu'à l'écœurement en école d'ingénieur "ça sert à rien d'optimiser", "premature optimization is the root of all evil" mais c'est ça la masturbation intellectuelle. Refuser de sortir de ses idées préconçues et de sa zone de confort intellectuelle pour aller voir ce qu'il en est en réalité. Ça ne sert pas toujours à quelquechose mais ça ne sert pas toujours à rien.
[^] # Re: suppressions ?!
Posté par X345 . En réponse à la dépêche OpenBSD 5.6. Évalué à 10.
Je sais pas si je me suis progressivement transformé en vieux con, mais qu'est-ce qu'on peut lire comme c*nn*eries sur linuxfr (excusez le terme).
Je passe sur l'utilisation douteuse du mot heuristique, qui paraîtrait ici très avantageusement remplacé par hypothèse ou propriété.
Haswell, cache line size (2013) : 64o (p. 2-5)
Sandy Bridge, cache line size (2011) : 64o (p. 2-17)
Nehalem, cache line size (2008) : 64o (p. 2-43)
Core, cache line size (2006): 64o (p. 2-36)
Référence : Intel 64 and IA-32 Architectures Optimization Reference Manual (March 2014), les numéros de pages sont donnés pour chaque architecture.
Donc bon, ça fait quand même au moins 4 générations (8 ans) que les lignes de cache font 64 octets. Certes il arrive que la taille des lignes de cache change, mais c'est bien loin d'être "à chaque génération". Pour information, le Pentium 4 avait des lignes de caches de 64o (aussi) pour le L1 et des lignes de caches de 128o pour le L2.
Si on veut, je peux difficilement te contredire là dessus vu qu'Intel ne publie pas les spécifications complètes de ses prédicteurs de branchements.
Nehalem, misprediction penalty : ~17 cycles
Sandy Bridge, misprediction penalty : ~15 cycles
Haswell, misprediction penalty : 15-20 cycles
Référence : The microarchitecture of Intel, AMD and VIA CPUs, Agner Fog
http://www.agner.org/optimize/microarchitecture.pdf
De là a dire que les changements au niveau du predicteur de branchement vont mettre en l'air tes optimisations, ça me parait carrément péremptoire.
Xeon X5560 (Nehalem) : LLC 2MB/core, L2 256KiB/core
Xeon E5-2660 (Sandy Bridge) : LLC 2.5MB/core, L2 256KiB/core
Xeon E5-2660 v3 (Haswell) : LLC 2.5MB/core, L2 256KiB/core
Référence : https://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors
Là encore, pas très significatif comme différences...
C'est effectivement la base de la base d'utiliser les bonnes structures de données, mais on se tue à t'expliquer qu'entre une implémentation naïve et une implémentation optimisée, y'a parfois de gros speedups : 10 fois, 100 fois dans certains cas.
Vive la contradiction. Donc d'un côté t'as des contraintes budgétaires et de l'autre tu t'amuses à optimiser ton code pour 40 architectures différentes. Dans l'"industrie" comme tu dis, la manière raisonnable de procéder serait d'optimiser ton code pour qu'il tourne sur des Xeon Ivy Bridge (ou ce que tu as comme machines) et point. Tu vas pas t'amuser à l'optimiser pour toute la planète si t'as des contraintes budgétaires. Et si t'as deux générations de processeurs en production, bah tu optimises pour les deux générations et basta (et comme je le montrais plus haut, ça ne varie pas forcément énormément).
Wow ! de l'applicatif PC ! Il ne t'a pas échappé à l'esprit de l'applicatif PC, ben, ça ne représente pas un marché énorme. On est plus en 1995 hein. Et c'est toi qui parle de masturbation intellectuelle. On se dirige beaucoup vers un modèle de service donc le code s'exécute de plus en plus sur des serveurs. Et code plus performant = moins de serveurs = moins de coûts d'exploitation. 10 machines c'est moins cher que 100.
Dans l'applicatif PC, je pense que les jeux vidéos et les logiciels d'ingénierie doivent représenter une bonne partie du marché (MATLABS, Comsol etc.). Justement du code qui demande d'être optimisé !
Mais personne ne passe 30 jours pour une nano-seconde. Personne. On se tue à t'expliquer que si on passe 30 jours, c'est pour avoir un speedup de 10. Et puis parfois, c'est rentable, Facebook paye des ingés à optimiser son code et dès qu'ils gagnent 0.5%, ça part en prod. Parce 0.5% de performance en plus, c'est x € économisés en serveurs (https://www.youtube.com/watch?v=Qq_WaiwzOtI)
Sinon, tu peux aussi embaucher des ingés compétents qui ont pas besoin de 30 jours pour écrire du SIMD et faire du cache blocking...
Bon, et merci pour bashing gratuit des universitaires qui passeraient leur temps à faire des choses pas très utiles et à faire du sport et de la masturbation intellectuelle. Tu sais si tu veux que ton papier passe dans une bonne conf, t'as intérêt à démontrer que ton axe de recherche et tes résultats sont utiles.
Plus généralement, tu nous ressors le poncif classique répété à loisir jusqu'à l'écœurement en école d'ingénieur "ça sert à rien d'optimiser", "premature optimization is the root of all evil" mais c'est ça la masturbation intellectuelle. Refuser de sortir de ses idées préconçues et de sa zone de confort intellectuelle pour aller voir ce qu'il en est en réalité. Ça ne sert pas toujours à quelquechose mais ça ne sert pas toujours à rien.