Si ton optimisation n'est pas celle du compilo. y'a des chances pour que tu te sois foiré quelque part.
Pour avoir appris sur mon temps libre l'assembleur, je peux dire qu'il n'est pas si difficile d'optimiser un code. La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU (y compris les questions de latence sur les IO car ces accès sont explicites - et on distingue bien un accès en lecture et en écriture).
À partir de là :
L'exercice consiste à étudier la sortie d'un compilo sur du code simple.
Par obligation on est amené à réimplémenter des fonctionnalités très simple. Autre exercice : étudier comment la libc ou autres fait ça.
Spoiler alert : il y'a quantité d'optimisations qui ne sont pas déléguées au compilo. Alors à moins de considérer que les devs de la libc sont des branques...
Trois trucs avec le compilo :
Tu ne le maîtrises pas ni le contrôle. Alors à moins de délivrer qu'un binaire final, tu ne peux préjuger des optimisations appliquées. Les compilos modernes sont devenus horriblement complexes... et LENTS !
À force de déléguer on finit par avoir des CPUs complètement troués parce qu'on pense que la prédiction de branche automatique c'est bien plutôt que de prendre 5s pour signifier au CPU que ce code-ci sera l'exception et l'autre la règle (donc non optimiser un code nécessite pas d'avoir forcément un bagage technique de fou). Sur ce point la causalité est inversée : si c'est le foutoir dans les CPU à tel point qu'un dev n'est pas capable de prédire à l'avance quel code sera performant sur telle machine (manque de prédictibilité du matériel et absence de modèle simple du comportement d'un CPU), c'est bien parce que les concepteurs de CPU y vont chacun de leur petites trouvailles pour obtenir les meilleures perf. malgré du code claqué au sol. On retrouve la même blague sur le nombre de cycle horloge par instructions. Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que... "c'est trop compliqué un CPU".
Ce qui nous amène au dernier point : le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait. Seul l'usager sait ce qu'il va en faire et le boulot d'un dev. c'est aussi d'optimiser son temps, savoir quand et où il a intérêt à lever les automatismes et prendre en charge lui-même les micro-optimisations (car faut-il encore le rappeler une énième fois la micro-optimisation c'est que dalle en terme de gain de performance face aux choix de conception - sélection des algorithmes, arbitrage entre le besoin et les moyens, etc.) C'est pas la compilo qui va te dire si ton algo de tri doit être économe en espace ou en temps, si t'es données sont presque triées ou totalement aléatoire, etc. Il pourra toujours essayer de le deviner mais cela impliquera une surcharge qui ne sera pertinente que sur de gros volumes (information que le compilo ne connaît pas...).
[^] # Re: Who's that guy ?
Posté par Nicolas . En réponse au lien Software is Way Less Performant Today. Évalué à 3.
Si ton optimisation n'est pas celle du compilo. y'a des chances pour que tu te sois foiré quelque part.
Pour avoir appris sur mon temps libre l'assembleur, je peux dire qu'il n'est pas si difficile d'optimiser un code. La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU (y compris les questions de latence sur les IO car ces accès sont explicites - et on distingue bien un accès en lecture et en écriture).
À partir de là :
L'exercice consiste à étudier la sortie d'un compilo sur du code simple.
Par obligation on est amené à réimplémenter des fonctionnalités très simple. Autre exercice : étudier comment la libc ou autres fait ça.
Spoiler alert : il y'a quantité d'optimisations qui ne sont pas déléguées au compilo. Alors à moins de considérer que les devs de la libc sont des branques...
Trois trucs avec le compilo :
Tu ne le maîtrises pas ni le contrôle. Alors à moins de délivrer qu'un binaire final, tu ne peux préjuger des optimisations appliquées. Les compilos modernes sont devenus horriblement complexes... et LENTS !
À force de déléguer on finit par avoir des CPUs complètement troués parce qu'on pense que la prédiction de branche automatique c'est bien plutôt que de prendre 5s pour signifier au CPU que ce code-ci sera l'exception et l'autre la règle (donc non optimiser un code nécessite pas d'avoir forcément un bagage technique de fou). Sur ce point la causalité est inversée : si c'est le foutoir dans les CPU à tel point qu'un dev n'est pas capable de prédire à l'avance quel code sera performant sur telle machine (manque de prédictibilité du matériel et absence de modèle simple du comportement d'un CPU), c'est bien parce que les concepteurs de CPU y vont chacun de leur petites trouvailles pour obtenir les meilleures perf. malgré du code claqué au sol. On retrouve la même blague sur le nombre de cycle horloge par instructions. Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que... "c'est trop compliqué un CPU".
Ce qui nous amène au dernier point : le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait. Seul l'usager sait ce qu'il va en faire et le boulot d'un dev. c'est aussi d'optimiser son temps, savoir quand et où il a intérêt à lever les automatismes et prendre en charge lui-même les micro-optimisations (car faut-il encore le rappeler une énième fois la micro-optimisation c'est que dalle en terme de gain de performance face aux choix de conception - sélection des algorithmes, arbitrage entre le besoin et les moyens, etc.) C'est pas la compilo qui va te dire si ton algo de tri doit être économe en espace ou en temps, si t'es données sont presque triées ou totalement aléatoire, etc. Il pourra toujours essayer de le deviner mais cela impliquera une surcharge qui ne sera pertinente que sur de gros volumes (information que le compilo ne connaît pas...).