Et avoir un kernel démarré en 64 bits, ça va apporter quoi ?
En tant que tel, rien, c'est juste une question d'image.
Genre, j'en ai une plus grosse ?
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Éric Lévénez
Le 10/02/10 10:39, Laurent Pertois a écrit :
Éric Lévénez wrote:
Oui, tu as raison, je suis allé trop vite à chercher de bonnes raisons à passer au 64-bits... Reste la vitesse qui doit être amélioré (plus de commutation de contexte 32/63 bits).
s/63/64/
Peut-être mais encore faut-il avoir de la RAM pour que ce soit valable. Par exemple, sur un Xserve (et peut-être les Mac Pro), Mac OS X Server n'active le noyau 64 bits que s'il y a plus de 4Go (ce qui est logique).
Pas forcément. J'ai trouvé cette page <http://macperformanceguide.com/SnowLeopard-Performance.html> où l'on voit ce qu'apporte un noyau 64 bits.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 10/02/10 10:39, Laurent Pertois a écrit :
Éric Lévénez<usenet@levenez.com> wrote:
Oui, tu as raison, je suis allé trop vite à chercher de bonnes raisons à
passer au 64-bits... Reste la vitesse qui doit être amélioré (plus de
commutation de contexte 32/63 bits).
s/63/64/
Peut-être mais encore faut-il avoir de la RAM pour que ce soit valable.
Par exemple, sur un Xserve (et peut-être les Mac Pro), Mac OS X Server
n'active le noyau 64 bits que s'il y a plus de 4Go (ce qui est logique).
Pas forcément. J'ai trouvé cette page
<http://macperformanceguide.com/SnowLeopard-Performance.html> où l'on
voit ce qu'apporte un noyau 64 bits.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Oui, tu as raison, je suis allé trop vite à chercher de bonnes raisons à passer au 64-bits... Reste la vitesse qui doit être amélioré (plus de commutation de contexte 32/63 bits).
s/63/64/
Peut-être mais encore faut-il avoir de la RAM pour que ce soit valable. Par exemple, sur un Xserve (et peut-être les Mac Pro), Mac OS X Server n'active le noyau 64 bits que s'il y a plus de 4Go (ce qui est logique).
Pas forcément. J'ai trouvé cette page <http://macperformanceguide.com/SnowLeopard-Performance.html> où l'on voit ce qu'apporte un noyau 64 bits.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
laurent.pertois
Jerome Lambert wrote:
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt, mais bon...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jerome Lambert <jerome.lambert@swing.be> wrote:
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas
pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt, mais bon...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt, mais bon...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Éric Lévénez wrote:
Pas forcément. J'ai trouvé cette page <http://macperformanceguide.com/SnowLeopard-Performance.html> où l'on voit ce qu'apporte un noyau 64 bits.
Sur cette page il s'agit d'un Mac Pro avec 12 Go de RAM, ça revient à ce que je disais...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Éric Lévénez <usenet@levenez.com> wrote:
Pas forcément. J'ai trouvé cette page
<http://macperformanceguide.com/SnowLeopard-Performance.html> où l'on
voit ce qu'apporte un noyau 64 bits.
Sur cette page il s'agit d'un Mac Pro avec 12 Go de RAM, ça revient à ce
que je disais...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Pas forcément. J'ai trouvé cette page <http://macperformanceguide.com/SnowLeopard-Performance.html> où l'on voit ce qu'apporte un noyau 64 bits.
Sur cette page il s'agit d'un Mac Pro avec 12 Go de RAM, ça revient à ce que je disais...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Éric Lévénez
Le 10/02/10 14:25, Laurent Pertois a écrit :
Jerome Lambert wrote:
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt, mais bon...
Les commutations entre mode 64 bits des applis et 32 bits du noyau ne peuvent que ralentir. Il faudrait avoir des résultats de benchs là dessus pour avoir des chiffres quantifiables. Et je ne pense vraiment pas que cela soit directement lié à la limite de 4 Go. Je ne peux pas faire de bench sur ma machine en bootant en 32 puis en 64 bits car j'ai plus de 4 Go de RAM et on ne saurait pas si le gain de vitesse est dû à la RAM ou au mode du noyau... Avec un noyau 32 bits, je pense que le mode PAE d'Intel est toujours activé, et rien que par ce fait, le noyau 32-bits est plus lent que s'il n'utilisait pas ce mode en 32 bits. En 64 bits, il n'y a plus de PAE, et cela doit aussi permettre d'aller plus vite (sans compter la commutation de contexte). Ensuite il y a les drivers 64 bits, et là aussi, en particulier à cause du nouveau mode de passage des arguments entre fonction, cela peut entraîner des gains de vitesse.
J'ai trouvé ce bench <http://scripts.mit.edu/~birge/blog/benchmark-results-for-snow-leopard-32-versus-64-bit-kernel/>, mais il n'y a pas la taille de RAM, mais je suppose que c'est inférieur à 4 Go.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 10/02/10 14:25, Laurent Pertois a écrit :
Jerome Lambert<jerome.lambert@swing.be> wrote:
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas
pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt, mais bon...
Les commutations entre mode 64 bits des applis et 32 bits du noyau ne
peuvent que ralentir. Il faudrait avoir des résultats de benchs là
dessus pour avoir des chiffres quantifiables. Et je ne pense vraiment
pas que cela soit directement lié à la limite de 4 Go. Je ne peux pas
faire de bench sur ma machine en bootant en 32 puis en 64 bits car j'ai
plus de 4 Go de RAM et on ne saurait pas si le gain de vitesse est dû à
la RAM ou au mode du noyau... Avec un noyau 32 bits, je pense que le
mode PAE d'Intel est toujours activé, et rien que par ce fait, le noyau
32-bits est plus lent que s'il n'utilisait pas ce mode en 32 bits. En 64
bits, il n'y a plus de PAE, et cela doit aussi permettre d'aller plus
vite (sans compter la commutation de contexte). Ensuite il y a les
drivers 64 bits, et là aussi, en particulier à cause du nouveau mode de
passage des arguments entre fonction, cela peut entraîner des gains de
vitesse.
J'ai trouvé ce bench
<http://scripts.mit.edu/~birge/blog/benchmark-results-for-snow-leopard-32-versus-64-bit-kernel/>,
mais il n'y a pas la taille de RAM, mais je suppose que c'est inférieur
à 4 Go.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt, mais bon...
Les commutations entre mode 64 bits des applis et 32 bits du noyau ne peuvent que ralentir. Il faudrait avoir des résultats de benchs là dessus pour avoir des chiffres quantifiables. Et je ne pense vraiment pas que cela soit directement lié à la limite de 4 Go. Je ne peux pas faire de bench sur ma machine en bootant en 32 puis en 64 bits car j'ai plus de 4 Go de RAM et on ne saurait pas si le gain de vitesse est dû à la RAM ou au mode du noyau... Avec un noyau 32 bits, je pense que le mode PAE d'Intel est toujours activé, et rien que par ce fait, le noyau 32-bits est plus lent que s'il n'utilisait pas ce mode en 32 bits. En 64 bits, il n'y a plus de PAE, et cela doit aussi permettre d'aller plus vite (sans compter la commutation de contexte). Ensuite il y a les drivers 64 bits, et là aussi, en particulier à cause du nouveau mode de passage des arguments entre fonction, cela peut entraîner des gains de vitesse.
J'ai trouvé ce bench <http://scripts.mit.edu/~birge/blog/benchmark-results-for-snow-leopard-32-versus-64-bit-kernel/>, mais il n'y a pas la taille de RAM, mais je suppose que c'est inférieur à 4 Go.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Jerome Lambert
Laurent Pertois a écrit :
Jerome Lambert wrote:
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt
Que tu crois: plus de registres, des registres de plus grande taille, possibilité de manipuler des nombres bien plus grand et/ou précis, et j'en oublie certainement. La limite à 4Go est la "tarte à la crême" que l'on sort généralement pour le grand public, mais on n'a pas attendu d'arriver à cette limite pour utiliser les possibilités des CPU 64 bits.
Il est d'ailleurs assez amusant de lire l'introduction à cette technologie sur le site d'Apple: http://www.apple.com/fr/macosx/technology/ "Longtemps le traitement 64 bits a été la chasse gardée des scientifiques et des ingénieurs. Mais cette évolution dans le monde informatique met désormais à la portée de tous les utilisateurs des outils permettant d'exploiter la puissance 64 bits pour accélérer aussi bien les applications bureautiques les plus simples que les calculs scientifiques les plus complexes. Bien que Mac OS X dispose déjà de capacités 64 bits, Snow Leopard passe à la vitesse supérieure en recodant presque toutes les applications système en 64 bits, permettant ainsi au Mac de gérer d'énormes quantités de mémoire. Mac OS X est maintenant plus rapide, plus sûr et parfaitement armé face aux enjeux de demain."
La limite mémoire est juste une allusion en fin d'introduction, bien après les autres bénéfices, et non le principal intérêt. ;-)
Laurent Pertois a écrit :
Jerome Lambert <jerome.lambert@swing.be> wrote:
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas
pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt
Que tu crois: plus de registres, des registres de plus grande taille,
possibilité de manipuler des nombres bien plus grand et/ou précis, et
j'en oublie certainement. La limite à 4Go est la "tarte à la crême" que
l'on sort généralement pour le grand public, mais on n'a pas attendu
d'arriver à cette limite pour utiliser les possibilités des CPU 64 bits.
Il est d'ailleurs assez amusant de lire l'introduction à cette
technologie sur le site d'Apple:
http://www.apple.com/fr/macosx/technology/
"Longtemps le traitement 64 bits a été la chasse gardée des
scientifiques et des ingénieurs. Mais cette évolution dans le monde
informatique met désormais à la portée de tous les utilisateurs des
outils permettant d'exploiter la puissance 64 bits pour accélérer aussi
bien les applications bureautiques les plus simples que les calculs
scientifiques les plus complexes. Bien que Mac OS X dispose déjà de
capacités 64 bits, Snow Leopard passe à la vitesse supérieure en
recodant presque toutes les applications système en 64 bits, permettant
ainsi au Mac de gérer d'énormes quantités de mémoire. Mac OS X est
maintenant plus rapide, plus sûr et parfaitement armé face aux enjeux de
demain."
La limite mémoire est juste une allusion en fin d'introduction, bien
après les autres bénéfices, et non le principal intérêt. ;-)
Non, genre ma machine a cette possibilité (64 bits), donc je ne vois pas pourquoi je ne pourrais pas l'utiliser.
Mais à moins de 4 Go, aucun intérêt
Que tu crois: plus de registres, des registres de plus grande taille, possibilité de manipuler des nombres bien plus grand et/ou précis, et j'en oublie certainement. La limite à 4Go est la "tarte à la crême" que l'on sort généralement pour le grand public, mais on n'a pas attendu d'arriver à cette limite pour utiliser les possibilités des CPU 64 bits.
Il est d'ailleurs assez amusant de lire l'introduction à cette technologie sur le site d'Apple: http://www.apple.com/fr/macosx/technology/ "Longtemps le traitement 64 bits a été la chasse gardée des scientifiques et des ingénieurs. Mais cette évolution dans le monde informatique met désormais à la portée de tous les utilisateurs des outils permettant d'exploiter la puissance 64 bits pour accélérer aussi bien les applications bureautiques les plus simples que les calculs scientifiques les plus complexes. Bien que Mac OS X dispose déjà de capacités 64 bits, Snow Leopard passe à la vitesse supérieure en recodant presque toutes les applications système en 64 bits, permettant ainsi au Mac de gérer d'énormes quantités de mémoire. Mac OS X est maintenant plus rapide, plus sûr et parfaitement armé face aux enjeux de demain."
La limite mémoire est juste une allusion en fin d'introduction, bien après les autres bénéfices, et non le principal intérêt. ;-)
laurent.pertois
Éric Lévénez wrote:
Les commutations entre mode 64 bits des applis et 32 bits du noyau ne peuvent que ralentir. Il faudrait avoir des résultats de benchs là dessus pour avoir des chiffres quantifiables. Et je ne pense vraiment pas que cela soit directement lié à la limite de 4 Go. Je ne peux pas faire de bench sur ma machine en bootant en 32 puis en 64 bits car j'ai plus de 4 Go de RAM et on ne saurait pas si le gain de vitesse est dû à la RAM ou au mode du noyau... Avec un noyau 32 bits, je pense que le mode PAE d'Intel est toujours activé, et rien que par ce fait, le noyau 32-bits est plus lent que s'il n'utilisait pas ce mode en 32 bits. En 64 bits, il n'y a plus de PAE, et cela doit aussi permettre d'aller plus vite (sans compter la commutation de contexte). Ensuite il y a les drivers 64 bits, et là aussi, en particulier à cause du nouveau mode de passage des arguments entre fonction, cela peut entraîner des gains de vitesse.
Ca se défend sauf qu'au quotidien, donc en-dehors d'un bench, j'aimerais voir si c'est vraiment intéressant.
Bon, je viens de passer ma machine en noyau 64 bits, on verra bien (je ne cherche pas à mesurer quoi que ce soit, je regarde s'il y a des choses qui peuvent être embêtantes).
J'ai trouvé ce bench <http://scripts.mit.edu/~birge/blog/benchmark-results-for-snow-leopard-3 2-versus-64-bit-kernel/>, mais il n'y a pas la taille de RAM, mais je suppose que c'est inférieur à 4 Go.
Bah, rien ne l'indique, donc supposons :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Éric Lévénez <usenet@levenez.com> wrote:
Les commutations entre mode 64 bits des applis et 32 bits du noyau ne
peuvent que ralentir. Il faudrait avoir des résultats de benchs là
dessus pour avoir des chiffres quantifiables. Et je ne pense vraiment
pas que cela soit directement lié à la limite de 4 Go. Je ne peux pas
faire de bench sur ma machine en bootant en 32 puis en 64 bits car j'ai
plus de 4 Go de RAM et on ne saurait pas si le gain de vitesse est dû à
la RAM ou au mode du noyau... Avec un noyau 32 bits, je pense que le
mode PAE d'Intel est toujours activé, et rien que par ce fait, le noyau
32-bits est plus lent que s'il n'utilisait pas ce mode en 32 bits. En 64
bits, il n'y a plus de PAE, et cela doit aussi permettre d'aller plus
vite (sans compter la commutation de contexte). Ensuite il y a les
drivers 64 bits, et là aussi, en particulier à cause du nouveau mode de
passage des arguments entre fonction, cela peut entraîner des gains de
vitesse.
Ca se défend sauf qu'au quotidien, donc en-dehors d'un bench, j'aimerais
voir si c'est vraiment intéressant.
Bon, je viens de passer ma machine en noyau 64 bits, on verra bien (je
ne cherche pas à mesurer quoi que ce soit, je regarde s'il y a des
choses qui peuvent être embêtantes).
J'ai trouvé ce bench
<http://scripts.mit.edu/~birge/blog/benchmark-results-for-snow-leopard-3
2-versus-64-bit-kernel/>, mais il n'y a pas la taille de RAM, mais je
suppose que c'est inférieur à 4 Go.
Bah, rien ne l'indique, donc supposons :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Les commutations entre mode 64 bits des applis et 32 bits du noyau ne peuvent que ralentir. Il faudrait avoir des résultats de benchs là dessus pour avoir des chiffres quantifiables. Et je ne pense vraiment pas que cela soit directement lié à la limite de 4 Go. Je ne peux pas faire de bench sur ma machine en bootant en 32 puis en 64 bits car j'ai plus de 4 Go de RAM et on ne saurait pas si le gain de vitesse est dû à la RAM ou au mode du noyau... Avec un noyau 32 bits, je pense que le mode PAE d'Intel est toujours activé, et rien que par ce fait, le noyau 32-bits est plus lent que s'il n'utilisait pas ce mode en 32 bits. En 64 bits, il n'y a plus de PAE, et cela doit aussi permettre d'aller plus vite (sans compter la commutation de contexte). Ensuite il y a les drivers 64 bits, et là aussi, en particulier à cause du nouveau mode de passage des arguments entre fonction, cela peut entraîner des gains de vitesse.
Ca se défend sauf qu'au quotidien, donc en-dehors d'un bench, j'aimerais voir si c'est vraiment intéressant.
Bon, je viens de passer ma machine en noyau 64 bits, on verra bien (je ne cherche pas à mesurer quoi que ce soit, je regarde s'il y a des choses qui peuvent être embêtantes).
J'ai trouvé ce bench <http://scripts.mit.edu/~birge/blog/benchmark-results-for-snow-leopard-3 2-versus-64-bit-kernel/>, mais il n'y a pas la taille de RAM, mais je suppose que c'est inférieur à 4 Go.
Bah, rien ne l'indique, donc supposons :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Jerome Lambert wrote:
Que tu crois: plus de registres, des registres de plus grande taille, possibilité de manipuler des nombres bien plus grand et/ou précis, et j'en oublie certainement.
Ok, donc mettons de côté les 4Go. J'ai des applis 64 bits (la denière en date est d'ailleurs Aperture). Là je vois bien l'intérêt avec ce que tu indiques, quid donc de mon noyau, que va-t-il gagner ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jerome Lambert <jerome.lambert@swing.be> wrote:
Que tu crois: plus de registres, des registres de plus grande taille,
possibilité de manipuler des nombres bien plus grand et/ou précis, et
j'en oublie certainement.
Ok, donc mettons de côté les 4Go. J'ai des applis 64 bits (la denière en
date est d'ailleurs Aperture). Là je vois bien l'intérêt avec ce que tu
indiques, quid donc de mon noyau, que va-t-il gagner ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Que tu crois: plus de registres, des registres de plus grande taille, possibilité de manipuler des nombres bien plus grand et/ou précis, et j'en oublie certainement.
Ok, donc mettons de côté les 4Go. J'ai des applis 64 bits (la denière en date est d'ailleurs Aperture). Là je vois bien l'intérêt avec ce que tu indiques, quid donc de mon noyau, que va-t-il gagner ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jerome Lambert
Le 10/02/2010 23:01, Laurent Pertois a écrit :
Jerome Lambert wrote:
Que tu crois: plus de registres, des registres de plus grande taille, possibilité de manipuler des nombres bien plus grand et/ou précis, et j'en oublie certainement.
Ok, donc mettons de côté les 4Go. J'ai des applis 64 bits (la denière en date est d'ailleurs Aperture). Là je vois bien l'intérêt avec ce que tu indiques, quid donc de mon noyau, que va-t-il gagner ?
En utilisant toutes les possibilités offertes par le CPU, p.ex. en terme de registres, il va y gagner de meilleures performances. Bon, ça va pas les doubler non plus, hein, mais l'idée est là.
Le 10/02/2010 23:01, Laurent Pertois a écrit :
Jerome Lambert<jerome.lambert@swing.be> wrote:
Que tu crois: plus de registres, des registres de plus grande taille,
possibilité de manipuler des nombres bien plus grand et/ou précis, et
j'en oublie certainement.
Ok, donc mettons de côté les 4Go. J'ai des applis 64 bits (la denière en
date est d'ailleurs Aperture). Là je vois bien l'intérêt avec ce que tu
indiques, quid donc de mon noyau, que va-t-il gagner ?
En utilisant toutes les possibilités offertes par le CPU, p.ex. en terme
de registres, il va y gagner de meilleures performances. Bon, ça va pas
les doubler non plus, hein, mais l'idée est là.
Que tu crois: plus de registres, des registres de plus grande taille, possibilité de manipuler des nombres bien plus grand et/ou précis, et j'en oublie certainement.
Ok, donc mettons de côté les 4Go. J'ai des applis 64 bits (la denière en date est d'ailleurs Aperture). Là je vois bien l'intérêt avec ce que tu indiques, quid donc de mon noyau, que va-t-il gagner ?
En utilisant toutes les possibilités offertes par le CPU, p.ex. en terme de registres, il va y gagner de meilleures performances. Bon, ça va pas les doubler non plus, hein, mais l'idée est là.
laurent.pertois
Jerome Lambert wrote:
En utilisant toutes les possibilités offertes par le CPU, p.ex. en terme de registres, il va y gagner de meilleures performances. Bon, ça va pas les doubler non plus, hein, mais l'idée est là.
Tout en perdant au passage la compatibilité avec les drivers 32 bits...
Après on se demande pourquoi Apple a été conservatrice dans ce choix ;-)
Merci des infos, ça confirme cependant ce que je pense, ne pas attendre de miracles en passant le noyau en 64 bits, ça profite quand même largement plus aux applis.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jerome Lambert <jerome.lambert@swing.be> wrote:
En utilisant toutes les possibilités offertes par le CPU, p.ex. en terme
de registres, il va y gagner de meilleures performances. Bon, ça va pas
les doubler non plus, hein, mais l'idée est là.
Tout en perdant au passage la compatibilité avec les drivers 32 bits...
Après on se demande pourquoi Apple a été conservatrice dans ce choix ;-)
Merci des infos, ça confirme cependant ce que je pense, ne pas attendre
de miracles en passant le noyau en 64 bits, ça profite quand même
largement plus aux applis.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
En utilisant toutes les possibilités offertes par le CPU, p.ex. en terme de registres, il va y gagner de meilleures performances. Bon, ça va pas les doubler non plus, hein, mais l'idée est là.
Tout en perdant au passage la compatibilité avec les drivers 32 bits...
Après on se demande pourquoi Apple a été conservatrice dans ce choix ;-)
Merci des infos, ça confirme cependant ce que je pense, ne pas attendre de miracles en passant le noyau en 64 bits, ça profite quand même largement plus aux applis.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
