Oui, je suis d’accord sur le principe, mais dans la pratique, le coût non négligeable de te baser sur 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,
La prédiction de branchement sera plus efficace,
Le cache sera plus gros et tout tiendra dedans.
n’est pas intéressant. 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.
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.
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. 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.
Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances... mais pour de l’applicatif, ce n’est pas généralisable.
Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. 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. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)
Sur certains projets, on peut même diminuer une contrainte temporelle si on sent qu’elle risque de coûter trop cher.
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . En réponse à la dépêche OpenBSD 5.6. Évalué à 1.
Oui et non.
Oui, je suis d’accord sur le principe, mais dans la pratique, le coût non négligeable de te baser sur des euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération, car :
n’est pas intéressant. 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.
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.
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. 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.
Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances... mais pour de l’applicatif, ce n’est pas généralisable.
Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. 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. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)
Sur certains projets, on peut même diminuer une contrainte temporelle si on sent qu’elle risque de coûter trop cher.