Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Alain Vittali a écrit :
Bonjour,
Dans le post "Re: SQL 2005 x64 Fr ou US" du dimanche 18 mars 2007 16:31, Fred Brouard écrivait :
"[...] l'otpimisation d'une base 32 n'est pas la même en 64 bits."
Qu'entendait-il par là ?
trois exemples parmi d'autres :
1) en 32 bits un entier 64 bits (bigint) coute en traitement deux passes dans le processeur. En 64 bits un entier 64 bits coute en traitement une seule passe. Il va donc deux fois plus vite. Autrement dit si vous utilisez des clefs autoinc, il vaut donc mieux du INT en 32 bits et du BIGINT en 54 bits
2) les disques sont encore en stockage 32 bits. Donc pour l'écriture de données (comme pour la lecture depuis le disque) il faut une conversion. Ces opérations sont donc plus lentes en 64 bits quen 32 bits. Si votre optimisation est basée sur le lecture donc beaucoup de RAM (cas du DW) alors préférez le 64 bits. Si votre appli est OLTP mieux vaut le 32 bits
3) la gestion du cache est différent en 32 et 64. Mieux vaut avoir BEAUCOUP de RM en 64 bits, beaucoup plus que le même solution en 32 bits, bien que ce problème d'explosion du cache ait en partie été rectifié avec SP2
A +
A quel niveau les différences peuvent-elles bien se trouver ? Au niveau de la gestion de la mémoire ?
Fred, si tu nous écoutes... !
Merci.
Alain.
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Alain Vittali a écrit :
Bonjour,
Dans le post "Re: SQL 2005 x64 Fr ou US" du dimanche 18 mars 2007 16:31,
Fred Brouard écrivait :
"[...] l'otpimisation d'une base 32 n'est pas la même en 64 bits."
Qu'entendait-il par là ?
trois exemples parmi d'autres :
1) en 32 bits un entier 64 bits (bigint) coute en traitement deux passes
dans le processeur. En 64 bits un entier 64 bits coute en traitement une
seule passe. Il va donc deux fois plus vite. Autrement dit si vous
utilisez des clefs autoinc, il vaut donc mieux du INT en 32 bits et du
BIGINT en 54 bits
2) les disques sont encore en stockage 32 bits. Donc pour l'écriture de
données (comme pour la lecture depuis le disque) il faut une conversion.
Ces opérations sont donc plus lentes en 64 bits quen 32 bits. Si votre
optimisation est basée sur le lecture donc beaucoup de RAM (cas du DW)
alors préférez le 64 bits. Si votre appli est OLTP mieux vaut le 32 bits
3) la gestion du cache est différent en 32 et 64. Mieux vaut avoir
BEAUCOUP de RM en 64 bits, beaucoup plus que le même solution en 32
bits, bien que ce problème d'explosion du cache ait en partie été
rectifié avec SP2
A +
A quel niveau les différences peuvent-elles bien se trouver ?
Au niveau de la gestion de la mémoire ?
Fred, si tu nous écoutes... !
Merci.
Alain.
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Dans le post "Re: SQL 2005 x64 Fr ou US" du dimanche 18 mars 2007 16:31, Fred Brouard écrivait :
"[...] l'otpimisation d'une base 32 n'est pas la même en 64 bits."
Qu'entendait-il par là ?
trois exemples parmi d'autres :
1) en 32 bits un entier 64 bits (bigint) coute en traitement deux passes dans le processeur. En 64 bits un entier 64 bits coute en traitement une seule passe. Il va donc deux fois plus vite. Autrement dit si vous utilisez des clefs autoinc, il vaut donc mieux du INT en 32 bits et du BIGINT en 54 bits
2) les disques sont encore en stockage 32 bits. Donc pour l'écriture de données (comme pour la lecture depuis le disque) il faut une conversion. Ces opérations sont donc plus lentes en 64 bits quen 32 bits. Si votre optimisation est basée sur le lecture donc beaucoup de RAM (cas du DW) alors préférez le 64 bits. Si votre appli est OLTP mieux vaut le 32 bits
3) la gestion du cache est différent en 32 et 64. Mieux vaut avoir BEAUCOUP de RM en 64 bits, beaucoup plus que le même solution en 32 bits, bien que ce problème d'explosion du cache ait en partie été rectifié avec SP2
A +
A quel niveau les différences peuvent-elles bien se trouver ? Au niveau de la gestion de la mémoire ?
Fred, si tu nous écoutes... !
Merci.
Alain.
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Alain Vittali
Merci pour ces éclaircissements !
"Fred BROUARD" a écrit dans le message de news:
Alain Vittali a écrit :
Bonjour,
Dans le post "Re: SQL 2005 x64 Fr ou US" du dimanche 18 mars 2007 16:31, Fred Brouard écrivait :
"[...] l'otpimisation d'une base 32 n'est pas la même en 64 bits."
Qu'entendait-il par là ?
trois exemples parmi d'autres :
1) en 32 bits un entier 64 bits (bigint) coute en traitement deux passes dans le processeur. En 64 bits un entier 64 bits coute en traitement une seule passe. Il va donc deux fois plus vite. Autrement dit si vous utilisez des clefs autoinc, il vaut donc mieux du INT en 32 bits et du BIGINT en 54 bits
2) les disques sont encore en stockage 32 bits. Donc pour l'écriture de données (comme pour la lecture depuis le disque) il faut une conversion. Ces opérations sont donc plus lentes en 64 bits quen 32 bits. Si votre optimisation est basée sur le lecture donc beaucoup de RAM (cas du DW) alors préférez le 64 bits. Si votre appli est OLTP mieux vaut le 32 bits
3) la gestion du cache est différent en 32 et 64. Mieux vaut avoir BEAUCOUP de RM en 64 bits, beaucoup plus que le même solution en 32 bits, bien que ce problème d'explosion du cache ait en partie été rectifié avec SP2
A +
A quel niveau les différences peuvent-elles bien se trouver ? Au niveau de la gestion de la mémoire ?
Fred, si tu nous écoutes... !
Merci.
Alain.
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Merci pour ces éclaircissements !
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de news:
460AD520.1040006@club-internet.fr...
Alain Vittali a écrit :
Bonjour,
Dans le post "Re: SQL 2005 x64 Fr ou US" du dimanche 18 mars 2007 16:31,
Fred Brouard écrivait :
"[...] l'otpimisation d'une base 32 n'est pas la même en 64 bits."
Qu'entendait-il par là ?
trois exemples parmi d'autres :
1) en 32 bits un entier 64 bits (bigint) coute en traitement deux passes
dans le processeur. En 64 bits un entier 64 bits coute en traitement une
seule passe. Il va donc deux fois plus vite. Autrement dit si vous
utilisez des clefs autoinc, il vaut donc mieux du INT en 32 bits et du
BIGINT en 54 bits
2) les disques sont encore en stockage 32 bits. Donc pour l'écriture de
données (comme pour la lecture depuis le disque) il faut une conversion.
Ces opérations sont donc plus lentes en 64 bits quen 32 bits. Si votre
optimisation est basée sur le lecture donc beaucoup de RAM (cas du DW)
alors préférez le 64 bits. Si votre appli est OLTP mieux vaut le 32 bits
3) la gestion du cache est différent en 32 et 64. Mieux vaut avoir
BEAUCOUP de RM en 64 bits, beaucoup plus que le même solution en 32 bits,
bien que ce problème d'explosion du cache ait en partie été rectifié avec
SP2
A +
A quel niveau les différences peuvent-elles bien se trouver ?
Au niveau de la gestion de la mémoire ?
Fred, si tu nous écoutes... !
Merci.
Alain.
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Dans le post "Re: SQL 2005 x64 Fr ou US" du dimanche 18 mars 2007 16:31, Fred Brouard écrivait :
"[...] l'otpimisation d'une base 32 n'est pas la même en 64 bits."
Qu'entendait-il par là ?
trois exemples parmi d'autres :
1) en 32 bits un entier 64 bits (bigint) coute en traitement deux passes dans le processeur. En 64 bits un entier 64 bits coute en traitement une seule passe. Il va donc deux fois plus vite. Autrement dit si vous utilisez des clefs autoinc, il vaut donc mieux du INT en 32 bits et du BIGINT en 54 bits
2) les disques sont encore en stockage 32 bits. Donc pour l'écriture de données (comme pour la lecture depuis le disque) il faut une conversion. Ces opérations sont donc plus lentes en 64 bits quen 32 bits. Si votre optimisation est basée sur le lecture donc beaucoup de RAM (cas du DW) alors préférez le 64 bits. Si votre appli est OLTP mieux vaut le 32 bits
3) la gestion du cache est différent en 32 et 64. Mieux vaut avoir BEAUCOUP de RM en 64 bits, beaucoup plus que le même solution en 32 bits, bien que ce problème d'explosion du cache ait en partie été rectifié avec SP2
A +
A quel niveau les différences peuvent-elles bien se trouver ? Au niveau de la gestion de la mémoire ?
Fred, si tu nous écoutes... !
Merci.
Alain.
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
