Disons que je m'attachais plus particulièrement à un des avantages de l'encapsulation, qui est la généricité
L'encapsulation n'apporte pas la généricité. Réciproquement tu peux bien écrire une fonction générique qui n'encapsule rien du tout.
(c'est-à-dire l'indépendance du code client par rapport à la structure interne des données).
Ca c'est l'encapsulation. Enfin c'est comme ça que je comprends les choses.
-- Alain
Jean-Marc Desperrier
Alain Gaillard wrote:
Et le compilateur ne fait pas tilt en voyant qu'on divise par 8?
Normalement le compilateur va générer un décalage de bit au lieu d'un intruction div.
Parfois sur Intel, il va générer un div *parceque* c'est plus rapide que le décalage (le div libère une place dans le pipeline pour une autre opération entière).
Alain Gaillard wrote:
Et le compilateur ne fait pas tilt en voyant qu'on divise par 8?
Normalement le compilateur va générer un décalage de bit au lieu d'un
intruction div.
Parfois sur Intel, il va générer un div *parceque* c'est plus rapide que
le décalage (le div libère une place dans le pipeline pour une autre
opération entière).
Et le compilateur ne fait pas tilt en voyant qu'on divise par 8?
Normalement le compilateur va générer un décalage de bit au lieu d'un intruction div.
Parfois sur Intel, il va générer un div *parceque* c'est plus rapide que le décalage (le div libère une place dans le pipeline pour une autre opération entière).
Alain Gaillard
Alain Gaillard wrote:
Et le compilateur ne fait pas tilt en voyant qu'on divise par 8?
Normalement le compilateur va générer un décalage de bit au lieu d'un intruction div.
Parfois sur Intel, il va générer un div *parceque* c'est plus rapide que le décalage (le div libère une place dans le pipeline pour une autre opération entière).
Houlà... considération pointue... Des mauvaises langues disent que le Pentium 4 2000 MHz qui est doté d'un pipeline long comme un jour sans pain est moins rapide qu'un Athon XP 1600 MHz à cause de sa mauvaise stratégie d'anticipation qui conduit à trop souvent recharger le pipeline, mais bon je m'égare :-)
Pour en revenir au sujet, ma compréhension est que dans le pipeline les instructions sont décomposées en micro-instructions. L'exécution de ses micro-instructions étant plus rapide que l'exécution des instructions normales (sous réserve que le pipeline ne soit pas à recharger) Bref instructions de décalage ou de division sont toutes deux des instructions et je vois mal pour mon instruction de décalage ne libérerait pas elle aussi une place dans le pipeline.
Quoi qu'il en soit, je me demande si les compilos partent dans des considération pareilles pour générer le code. D'un autre côté, il m'est arrivé (il y a quelques années il est vrai) de désassembler du code et j'ai toujours constaté que les instructions de décalage étaient priviligées (mes compilos seraient-ils mauvais ?).
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
-- Alain
Alain Gaillard wrote:
Et le compilateur ne fait pas tilt en voyant qu'on divise par 8?
Normalement le compilateur va générer un décalage de bit au lieu d'un
intruction div.
Parfois sur Intel, il va générer un div *parceque* c'est plus rapide que
le décalage (le div libère une place dans le pipeline pour une autre
opération entière).
Houlà... considération pointue...
Des mauvaises langues disent que le Pentium 4 2000 MHz qui est doté d'un
pipeline long comme un jour sans pain est moins rapide qu'un Athon XP
1600 MHz à cause de sa mauvaise stratégie d'anticipation qui conduit à
trop souvent recharger le pipeline, mais bon je m'égare :-)
Pour en revenir au sujet, ma compréhension est que dans le pipeline les
instructions sont décomposées en micro-instructions. L'exécution de ses
micro-instructions étant plus rapide que l'exécution des instructions
normales (sous réserve que le pipeline ne soit pas à recharger) Bref
instructions de décalage ou de division sont toutes deux des
instructions et je vois mal pour mon instruction de décalage ne
libérerait pas elle aussi une place dans le pipeline.
Quoi qu'il en soit, je me demande si les compilos partent dans des
considération pareilles pour générer le code. D'un autre côté, il m'est
arrivé (il y a quelques années il est vrai) de désassembler du code et
j'ai toujours constaté que les instructions de décalage étaient
priviligées (mes compilos seraient-ils mauvais ?).
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
Et le compilateur ne fait pas tilt en voyant qu'on divise par 8?
Normalement le compilateur va générer un décalage de bit au lieu d'un intruction div.
Parfois sur Intel, il va générer un div *parceque* c'est plus rapide que le décalage (le div libère une place dans le pipeline pour une autre opération entière).
Houlà... considération pointue... Des mauvaises langues disent que le Pentium 4 2000 MHz qui est doté d'un pipeline long comme un jour sans pain est moins rapide qu'un Athon XP 1600 MHz à cause de sa mauvaise stratégie d'anticipation qui conduit à trop souvent recharger le pipeline, mais bon je m'égare :-)
Pour en revenir au sujet, ma compréhension est que dans le pipeline les instructions sont décomposées en micro-instructions. L'exécution de ses micro-instructions étant plus rapide que l'exécution des instructions normales (sous réserve que le pipeline ne soit pas à recharger) Bref instructions de décalage ou de division sont toutes deux des instructions et je vois mal pour mon instruction de décalage ne libérerait pas elle aussi une place dans le pipeline.
Quoi qu'il en soit, je me demande si les compilos partent dans des considération pareilles pour générer le code. D'un autre côté, il m'est arrivé (il y a quelques années il est vrai) de désassembler du code et j'ai toujours constaté que les instructions de décalage étaient priviligées (mes compilos seraient-ils mauvais ?).
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
-- Alain
Fabien LE LEZ
On Tue, 08 Aug 2006 21:10:23 +0200, Alain Gaillard :
Quoi qu'il en soit, je me demande si les compilos partent dans des considération pareilles pour générer le code.
Ceux qui font du code pour un processeur particulier, sans doute. Intéresse-toi au compilateur Intel.
Mais si tu veux un exécutable qui doit tourner sur Intel (>=Pentium 1) et AMD, je vois mal comment le compilo pourrait faire ce genre d'optimisation.
On Tue, 08 Aug 2006 21:10:23 +0200, Alain Gaillard
<alain_gaillard28@hotmail.fr>:
Quoi qu'il en soit, je me demande si les compilos partent dans des
considération pareilles pour générer le code.
Ceux qui font du code pour un processeur particulier, sans doute.
Intéresse-toi au compilateur Intel.
Mais si tu veux un exécutable qui doit tourner sur Intel (>=Pentium 1)
et AMD, je vois mal comment le compilo pourrait faire ce genre
d'optimisation.
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
A+
Laurent.
Alain Gaillard
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
Bonne remarque :-)
C'était, je crois me souvenir de petites valeurs entières (type int) avec X connu à la compilation, l'optimiseur pouvait donc savoir que la limite du type ne serait pas dépassée.
-- Alain
Aye, quand tu arrives aux limites des données du type de X, ça doit
faire des surprises ce genre d'astuce...
Bonne remarque :-)
C'était, je crois me souvenir de petites valeurs entières (type int)
avec X connu à la compilation, l'optimiseur pouvait donc savoir que la
limite du type ne serait pas dépassée.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
Bonne remarque :-)
C'était, je crois me souvenir de petites valeurs entières (type int) avec X connu à la compilation, l'optimiseur pouvait donc savoir que la limite du type ne serait pas dépassée.
-- Alain
Alain Gaillard
Quoi qu'il en soit, je me demande si les compilos partent dans des considération pareilles pour générer le code.
Ceux qui font du code pour un processeur particulier, sans doute. Intéresse-toi au compilateur Intel.
Quand je disais je me demande c'était une façon de parler :-) Je suis convaincu que les compilos prennent en compte les cycles d'horloges des instructions hors pipeline pour générer le code machine.
Mais si tu veux un exécutable qui doit tourner sur Intel (>=Pentium 1) et AMD, je vois mal comment le compilo pourrait faire ce genre d'optimisation.
C'est tout à fait clair.
-- Alain
Quoi qu'il en soit, je me demande si les compilos partent dans des
considération pareilles pour générer le code.
Ceux qui font du code pour un processeur particulier, sans doute.
Intéresse-toi au compilateur Intel.
Quand je disais je me demande c'était une façon de parler :-)
Je suis convaincu que les compilos prennent en compte les cycles
d'horloges des instructions hors pipeline pour générer le code machine.
Mais si tu veux un exécutable qui doit tourner sur Intel (>=Pentium 1)
et AMD, je vois mal comment le compilo pourrait faire ce genre
d'optimisation.
Quoi qu'il en soit, je me demande si les compilos partent dans des considération pareilles pour générer le code.
Ceux qui font du code pour un processeur particulier, sans doute. Intéresse-toi au compilateur Intel.
Quand je disais je me demande c'était une façon de parler :-) Je suis convaincu que les compilos prennent en compte les cycles d'horloges des instructions hors pipeline pour générer le code machine.
Mais si tu veux un exécutable qui doit tourner sur Intel (>=Pentium 1) et AMD, je vois mal comment le compilo pourrait faire ce genre d'optimisation.
C'est tout à fait clair.
-- Alain
espie
In article <ebc5vr$gp3$, Laurent Pointal wrote:
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
Si c'est un type non signe, ca fonctionne toujours, par contre.
Ca peut meme etre une des raisons d'utiliser des types non signes...
In article <ebc5vr$gp3$1@upsn250.cri.u-psud.fr>,
Laurent Pointal <laurent.pointal@limsi.fr> wrote:
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction
mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit
faire des surprises ce genre d'astuce...
Si c'est un type non signe, ca fonctionne toujours, par contre.
Ca peut meme etre une des raisons d'utiliser des types non signes...
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
Si c'est un type non signe, ca fonctionne toujours, par contre.
Ca peut meme etre une des raisons d'utiliser des types non signes...
Sylvain
Laurent Pointal wrote on 09/08/2006 10:22:
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
généralement non car les opérations intermédiaires utilisent, pour le résultat, un (des) registre(s) de taille double des opérandes (par exemple stockage du résultat dans 2 registres 32 bits pour une mul entre 2 reg. 32 bits pour un proc 32 bits).
Sylvain.
Laurent Pointal wrote on 09/08/2006 10:22:
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction
mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit
faire des surprises ce genre d'astuce...
généralement non car les opérations intermédiaires utilisent, pour le
résultat, un (des) registre(s) de taille double des opérandes (par
exemple stockage du résultat dans 2 registres 32 bits pour une mul entre
2 reg. 32 bits pour un proc 32 bits).
Je me rapelle même avoir vu une multiplication par 7 ainsi trannsformée
7*X = 8*X - X
La multiplication par 8 étant un décalage de bit et non une instruction mul.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
généralement non car les opérations intermédiaires utilisent, pour le résultat, un (des) registre(s) de taille double des opérandes (par exemple stockage du résultat dans 2 registres 32 bits pour une mul entre 2 reg. 32 bits pour un proc 32 bits).
Sylvain.
Cyrille
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
Bonne remarque :-)
C'était, je crois me souvenir de petites valeurs entières (type int) avec X connu à la compilation, l'optimiseur pouvait donc savoir que la limite du type ne serait pas dépassée.
Si X est connu à la compilation, un bon compilateur mettrait le résultat de 7*X directement au lieu d'optimiser la multiplication...
-- C'est ma signature qu'elle est la mieux. Pas la vôtre.
Aye, quand tu arrives aux limites des données du type de X, ça doit
faire des surprises ce genre d'astuce...
Bonne remarque :-)
C'était, je crois me souvenir de petites valeurs entières (type int)
avec X connu à la compilation, l'optimiseur pouvait donc savoir que la
limite du type ne serait pas dépassée.
Si X est connu à la compilation, un bon compilateur mettrait le résultat
de 7*X directement au lieu d'optimiser la multiplication...
--
C'est ma signature qu'elle est la mieux. Pas la vôtre.
Aye, quand tu arrives aux limites des données du type de X, ça doit faire des surprises ce genre d'astuce...
Bonne remarque :-)
C'était, je crois me souvenir de petites valeurs entières (type int) avec X connu à la compilation, l'optimiseur pouvait donc savoir que la limite du type ne serait pas dépassée.
Si X est connu à la compilation, un bon compilateur mettrait le résultat de 7*X directement au lieu d'optimiser la multiplication...
-- C'est ma signature qu'elle est la mieux. Pas la vôtre.
