j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et
les machines 64 bits, et, d'une manière général, sur les machines 64 bits.
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire
passer les registres du prcesseur de 32 à 64 bits. Ca peut sembler être
une Lapalissade, mais c'est bon de le préciser. Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme, c'est l'augmentation de
l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce
marketing ?
De plus, il faut en toute logique que les applications soit compilées
par un gcc en "mode 64bits" (?): ce mode "est il au point" ? Ne
change-t-il vraiment rien d'autre que quelques broutilles concernant
l'addressage ?
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup
d'applications Linux compatible 64bits ? Une liste existe-t-elle ?
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel
"compilé en mode 64 bits", et cela ralentit-il l'application ? Notez que
je préferrerais utiliser Debian (ma station de travail actuelle en 32
bits), mais qu'en est-il de l'avancement des distributions Linux par
rapport "au 64 bit" ?
Vous l'aurez compris,si je post ici et maintenant ce message, c'est pour
me décider à l'achat d'un futur et hypothètique ordinateur portable. Je
pensais me porter vers un Intel Core 2 Duo. Quelques remarques par
rapport à ce type de processeur ?
Pour finir, je tiens à préciser que je n'ai trouvé que des sujets (pas
tellement réjouissant) datant de 2004/2005/2006 sur internet, très peu
de (fin) 2007.
Et toi tu ne sais pas de quoi tu parles. peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
remy
JKB
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Sors les moi que je rigoles.
J'ai autre chose à faire que fouiller google groups. Ça tournait autour du fait que le C ne permettrait pas d'écrire portablement.
Tu coupes encore. Il manque encore une hypothèse.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant de l'architecture i386/amd64.
Quand la discussion porte précisément sur ces deux architectures, c'est la moindre des choses.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Que vient foutre perl ici ?
Ah, oui, j'avais pris vim comme exemple et pas perl comme j'en avais l'intention au début.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_ de la vitesse, simplement que si le processeur le permettait, cela éviterait d'en _perdre_. Ce n'est pas exactement la meme chose. <snip>
En d'autres termes, les gens chez intel et AMD sont des abrutis, tu sais tout mieux qu'eux.
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité. Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier du fait.
J'ai assez de ce petit jeu. Soit tu énonces clairement la comparaison que tu faisais, soit tu admets implicitement que tu as dit une connerie.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales. Et cette comparaison n'a d'objet que lorsqu'on fait tourner plus de threads que de processeurs. Cela permet de voir l'overhead rajouté par la gestion multipro (contre l'overhead rajouté par le multitâche).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 08-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnfgkbq0.3at.knatschke@fermat.systella.fr>, a
écrit :
Sors les moi que je rigoles.
J'ai autre chose à faire que fouiller google groups. Ça tournait autour du
fait que le C ne permettrait pas d'écrire portablement.
Tu coupes encore. Il manque encore une hypothèse.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant
de l'architecture i386/amd64.
Quand la discussion porte précisément sur ces deux architectures, c'est la
moindre des choses.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Que vient foutre perl ici ?
Ah, oui, j'avais pris vim comme exemple et pas perl comme j'en avais
l'intention au début.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_
de la vitesse, simplement que si le processeur le permettait, cela
éviterait d'en _perdre_. Ce n'est pas exactement la meme chose.
<snip>
En d'autres termes, les gens chez intel et AMD sont des abrutis, tu sais
tout mieux qu'eux.
Non, je dis simplement qu'on traîne un truc idiot pour raison de
compatibilité et qu'on paie cette compatibilité. Et qu'en cela le
fait de dire que le code obtenu n'est pas deux fois plus gros est
une argutie.
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier
du fait.
J'ai assez de ce petit jeu. Soit tu énonces clairement la comparaison que tu
faisais, soit tu admets implicitement que tu as dit une connerie.
Mon énoncé était très clair. Sur une machine de calcul faisant
tourner de quatre à six threads _simultanément_, une SS20 avec 2
SM71 est bien plus lente qu'une U1E/140, machines qui sont de
puissance de calcul par ailleurs égales. Et cette comparaison n'a
d'objet que lorsqu'on fait tourner plus de threads que de
processeurs. Cela permet de voir l'overhead rajouté par la gestion
multipro (contre l'overhead rajouté par le multitâche).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Sors les moi que je rigoles.
J'ai autre chose à faire que fouiller google groups. Ça tournait autour du fait que le C ne permettrait pas d'écrire portablement.
Tu coupes encore. Il manque encore une hypothèse.
Pour l'instant, tu n'as jamais sorti que des lieux communs provenant de l'architecture i386/amd64.
Quand la discussion porte précisément sur ces deux architectures, c'est la moindre des choses.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Que vient foutre perl ici ?
Ah, oui, j'avais pris vim comme exemple et pas perl comme j'en avais l'intention au début.
Mékilékon ! Je n'ai _jamais_ prétendu que l'alignement fait _gagner_ de la vitesse, simplement que si le processeur le permettait, cela éviterait d'en _perdre_. Ce n'est pas exactement la meme chose. <snip>
En d'autres termes, les gens chez intel et AMD sont des abrutis, tu sais tout mieux qu'eux.
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité. Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Non, tu viens encore d'oublier une hypothèse. Mais tu es coutumier du fait.
J'ai assez de ce petit jeu. Soit tu énonces clairement la comparaison que tu faisais, soit tu admets implicitement que tu as dit une connerie.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales. Et cette comparaison n'a d'objet que lorsqu'on fait tourner plus de threads que de processeurs. Cela permet de voir l'overhead rajouté par la gestion multipro (contre l'overhead rajouté par le multitâche).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
talon
wrote:
Michel Talon wrote:
A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces calculs en 64 bits même sur les machines 32 bits
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
--
Michel TALON
Philippe.Weill@aero.jussieu.fr wrote:
Michel Talon wrote:
A titre d'information, sur nos
machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui,
une augmentation de 100%) sur des calculs symboliques avec, par exemple
Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper
court aux arguments ridicules prétendant que le 64 bits ne sert qu'à
adresser plus de 4 Gigs de mémoire.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces
calculs en 64 bits même sur les machines 32 bits
Je parle de calculs formels, pas de calculs numériques. Que les calculs
numériques soient faits de façon standard en "double-précision" (64
bits) tout le monde le sait (et même en 80 bits dans le processeur
flottant du x86), et là n'est pas la question. Le calcul symbolique
c'est des pointeurs, des manipulations de mémoire, et là je doute fort
(mais je n'en sais précisément rien) que Maple utilise du 64 bits en
standard pour ses objets. J'en doute parcequ'il lui arrive très
facilement de trouver des "objects too large" ce qui fait fortement
penser à des objets sur 32 bits et avec un nombre de bits d'adressage
encore plus petit. Je crois qu'un des avantages du Maple 64 bits est
aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros,
utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus
vite.
A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces calculs en 64 bits même sur les machines 32 bits
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
--
Michel TALON
Nicolas George
Michel Talon, dans le message <fedd0d$2lmb$, a écrit :
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
Il y a une explication bien plus simple : maple fait du calcul multiprécision. C'est la même chose que pour la crypto asymétrique : le 64 bits divise par deux le nombre d'opérations pour gérer un grand entier.
Michel Talon, dans le message <fedd0d$2lmb$3@asmodee.lpthe.jussieu.fr>,
a écrit :
Je parle de calculs formels, pas de calculs numériques. Que les calculs
numériques soient faits de façon standard en "double-précision" (64
bits) tout le monde le sait (et même en 80 bits dans le processeur
flottant du x86), et là n'est pas la question. Le calcul symbolique
c'est des pointeurs, des manipulations de mémoire, et là je doute fort
(mais je n'en sais précisément rien) que Maple utilise du 64 bits en
standard pour ses objets. J'en doute parcequ'il lui arrive très
facilement de trouver des "objects too large" ce qui fait fortement
penser à des objets sur 32 bits et avec un nombre de bits d'adressage
encore plus petit. Je crois qu'un des avantages du Maple 64 bits est
aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros,
utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus
vite.
Il y a une explication bien plus simple : maple fait du calcul
multiprécision. C'est la même chose que pour la crypto asymétrique : le
64 bits divise par deux le nombre d'opérations pour gérer un grand entier.
Michel Talon, dans le message <fedd0d$2lmb$, a écrit :
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
Il y a une explication bien plus simple : maple fait du calcul multiprécision. C'est la même chose que pour la crypto asymétrique : le 64 bits divise par deux le nombre d'opérations pour gérer un grand entier.
Nicolas George
JKB , dans le message , a écrit :
Tu coupes encore. Il manque encore une hypothèse.
Bien sûr.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Essentiellement parce que les questions d'architectures sont rarement pertinentes.
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité.
Il y a eu largement le temps pour faire évoluer ça, mais de toute évidence ça n'a pas paru nécessaire à qui de droit.
Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Non, justement. Du code plus compact, ça veut aussi dire du code qui tient mieux dans les caches. Avec les multiplicateurs énormes entre la mémoire et le processeur, ça joue énormément.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales.
Comment définis-tu ces « puissance de calcul égales » ?
JKB , dans le message <slrnfgkdlh.3at.knatschke@fermat.systella.fr>, a
écrit :
Tu coupes encore. Il manque encore une hypothèse.
Bien sûr.
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Essentiellement parce que les questions d'architectures sont rarement
pertinentes.
Non, je dis simplement qu'on traîne un truc idiot pour raison de
compatibilité et qu'on paie cette compatibilité.
Il y a eu largement le temps pour faire évoluer ça, mais de toute évidence
ça n'a pas paru nécessaire à qui de droit.
Et qu'en cela le
fait de dire que le code obtenu n'est pas deux fois plus gros est
une argutie.
Non, justement. Du code plus compact, ça veut aussi dire du code qui tient
mieux dans les caches. Avec les multiplicateurs énormes entre la mémoire et
le processeur, ça joue énormément.
Mon énoncé était très clair. Sur une machine de calcul faisant
tourner de quatre à six threads _simultanément_, une SS20 avec 2
SM71 est bien plus lente qu'une U1E/140, machines qui sont de
puissance de calcul par ailleurs égales.
Comment définis-tu ces « puissance de calcul égales » ?
Depuis que je te connais, tu n'as jamais rien sorti d'autre.
Essentiellement parce que les questions d'architectures sont rarement pertinentes.
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité.
Il y a eu largement le temps pour faire évoluer ça, mais de toute évidence ça n'a pas paru nécessaire à qui de droit.
Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Non, justement. Du code plus compact, ça veut aussi dire du code qui tient mieux dans les caches. Avec les multiplicateurs énormes entre la mémoire et le processeur, ça joue énormément.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales.
Comment définis-tu ces « puissance de calcul égales » ?
remy
wrote:
Michel Talon wrote:
A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire. Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces
calculs en 64 bits même sur les machines 32 bits
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
sur le meme ordi ?
avec un code compiler pour du 32 bit et le meme programme compiler pour du 64 bit avec le meme calcul
remy
Philippe.Weill@aero.jussieu.fr wrote:
Michel Talon wrote:
A titre d'information, sur nos
machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui,
une augmentation de 100%) sur des calculs symboliques avec, par exemple
Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper
court aux arguments ridicules prétendant que le 64 bits ne sert qu'à
adresser plus de 4 Gigs de mémoire.
Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces
calculs en 64 bits même sur les machines 32 bits
Je parle de calculs formels, pas de calculs numériques. Que les calculs
numériques soient faits de façon standard en "double-précision" (64
bits) tout le monde le sait (et même en 80 bits dans le processeur
flottant du x86), et là n'est pas la question. Le calcul symbolique
c'est des pointeurs, des manipulations de mémoire, et là je doute fort
(mais je n'en sais précisément rien) que Maple utilise du 64 bits en
standard pour ses objets. J'en doute parcequ'il lui arrive très
facilement de trouver des "objects too large" ce qui fait fortement
penser à des objets sur 32 bits et avec un nombre de bits d'adressage
encore plus petit. Je crois qu'un des avantages du Maple 64 bits est
aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros,
utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus
vite.
sur le meme ordi ?
avec un code compiler pour du 32 bit et le meme programme
compiler pour du 64 bit avec le meme calcul
A titre d'information, sur nos machines, on voit des gains de temps de calcul (*) par un facteur 2 ( oui, une augmentation de 100%) sur des calculs symboliques avec, par exemple Maple (version 64 bits par rapport à la version 32 bits). Ceci pour couper court aux arguments ridicules prétendant que le 64 bits ne sert qu'à adresser plus de 4 Gigs de mémoire. Ne serait ca pas parce que Maple ( comme Matlab du reste ) fait tout ces
calculs en 64 bits même sur les machines 32 bits
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
sur le meme ordi ?
avec un code compiler pour du 32 bit et le meme programme compiler pour du 64 bit avec le meme calcul
remy
Mihamina Rakotomandimby
remy wrote:
et moi je te dis horloge temps réel Et toi tu ne sais pas de quoi tu parles.
peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
Penche toi vers l'avant, que je t'explique à ma façon.
remy wrote:
et moi je te dis horloge temps réel
Et toi tu ne sais pas de quoi tu parles.
peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
Penche toi vers l'avant, que je t'explique à ma façon.
et moi je te dis horloge temps réel Et toi tu ne sais pas de quoi tu parles.
peut être expliques moi le pb parce que la j'ai comme
un doute je suis prêt à apprendre je suis toute ouie dehors
Penche toi vers l'avant, que je t'explique à ma façon.
remy
Michel Talon, dans le message <fedd0d$2lmb$,
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
Il y a une explication bien plus simple : maple fait du calcul multiprécision. C'est la même chose que pour la crypto asymétrique : le 64 bits divise par deux le nombre d'opérations pour gérer un grand entier.
le monsieur te parle de calcul symbolique qui se résume à de la gestion de mémoire hou la j'ai honte sur ce raccourci
tiens j'ai trouvé un lien pour toi votre majesté http://fr.wikipedia.org/wiki/RDTSC
remy
Michel Talon, dans le message <fedd0d$2lmb$3@asmodee.lpthe.jussieu.fr>,
Je parle de calculs formels, pas de calculs numériques. Que les calculs
numériques soient faits de façon standard en "double-précision" (64
bits) tout le monde le sait (et même en 80 bits dans le processeur
flottant du x86), et là n'est pas la question. Le calcul symbolique
c'est des pointeurs, des manipulations de mémoire, et là je doute fort
(mais je n'en sais précisément rien) que Maple utilise du 64 bits en
standard pour ses objets. J'en doute parcequ'il lui arrive très
facilement de trouver des "objects too large" ce qui fait fortement
penser à des objets sur 32 bits et avec un nombre de bits d'adressage
encore plus petit. Je crois qu'un des avantages du Maple 64 bits est
aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros,
utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus
vite.
Il y a une explication bien plus simple : maple fait du calcul
multiprécision. C'est la même chose que pour la crypto asymétrique : le
64 bits divise par deux le nombre d'opérations pour gérer un grand entier.
le monsieur te parle de calcul symbolique
qui se résume à de la gestion de mémoire hou la j'ai honte sur ce
raccourci
tiens j'ai trouvé un lien pour toi votre majesté
http://fr.wikipedia.org/wiki/RDTSC
Je parle de calculs formels, pas de calculs numériques. Que les calculs numériques soient faits de façon standard en "double-précision" (64 bits) tout le monde le sait (et même en 80 bits dans le processeur flottant du x86), et là n'est pas la question. Le calcul symbolique c'est des pointeurs, des manipulations de mémoire, et là je doute fort (mais je n'en sais précisément rien) que Maple utilise du 64 bits en standard pour ses objets. J'en doute parcequ'il lui arrive très facilement de trouver des "objects too large" ce qui fait fortement penser à des objets sur 32 bits et avec un nombre de bits d'adressage encore plus petit. Je crois qu'un des avantages du Maple 64 bits est aussi de pouvoir manipuler des calculs symboliques beaucoup plus gros, utilisant beaucoup de mémoire, mais aussi le fait qu'il va bien plus vite.
Il y a une explication bien plus simple : maple fait du calcul multiprécision. C'est la même chose que pour la crypto asymétrique : le 64 bits divise par deux le nombre d'opérations pour gérer un grand entier.
le monsieur te parle de calcul symbolique qui se résume à de la gestion de mémoire hou la j'ai honte sur ce raccourci
tiens j'ai trouvé un lien pour toi votre majesté http://fr.wikipedia.org/wiki/RDTSC
