> 111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travaille dans un espace
mémoire de taille finie ?
> 111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travaille dans un espace
mémoire de taille finie ?
> 111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travaille dans un espace
mémoire de taille finie ?
111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travailler dans un espace
mémoire de taille finie ?
111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travailler dans un espace
mémoire de taille finie ?
111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travailler dans un espace
mémoire de taille finie ?
111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travailler dans un espace
mémoire de taille finie ?
Merci,
111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travailler dans un espace
mémoire de taille finie ?
Merci,
111secondes pour multiplier 2^21701-1 par lui même...
Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre de
8188 chiffres en sortie...
Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
bidouiller de manière pédagogique sur les multiplications de grands
nombres me bouffe + de 500 Mo de ram pour faire l'opération.
Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas),
ca me parait tout de même beaucoup.
Du coup, les questions que je me/vous pose sont les suivantes :
1. Ca devrait se limiter à quel ordre de grandeur normalement ?
2. Est-il possible de construire un algo qui travailler dans un espace
mémoire de taille finie ?
Merci,
Julien Vehent a écrit :
bonjour
> 111secondes pour multiplier 2^21701-1 par lui même...
> Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre d e
> 8188 chiffres en sortie...
> Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
> bidouiller de manière pédagogique sur les multiplications de grands
> nombres me bouffe + de 500 Mo de ram pour faire l'opération.
> Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas) ,
> ca me parait tout de même beaucoup.
> Du coup, les questions que je me/vous pose sont les suivantes :
> 1. Ca devrait se limiter à quel ordre de grandeur normalement ?
> 2. Est-il possible de construire un algo qui travailler dans un espace
> mémoire de taille finie ?
> Merci,
il y a un truc qui m'échappe
time bc pow
real 0m6.985s
user 0m6.128s
sys 0m0.040s
less pow
(2^221701-1)^2
quit
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 3
model name : AMD Duron(tm) Processor
stepping : 1
cpu MHz : 800.097
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr p ge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up
bogomips : 1602.20
clflush size : 32
en gros un truc antédiluvien
a+ remy
Julien Vehent a écrit :
bonjour
> 111secondes pour multiplier 2^21701-1 par lui même...
> Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre d e
> 8188 chiffres en sortie...
> Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
> bidouiller de manière pédagogique sur les multiplications de grands
> nombres me bouffe + de 500 Mo de ram pour faire l'opération.
> Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas) ,
> ca me parait tout de même beaucoup.
> Du coup, les questions que je me/vous pose sont les suivantes :
> 1. Ca devrait se limiter à quel ordre de grandeur normalement ?
> 2. Est-il possible de construire un algo qui travailler dans un espace
> mémoire de taille finie ?
> Merci,
il y a un truc qui m'échappe
time bc pow
real 0m6.985s
user 0m6.128s
sys 0m0.040s
less pow
(2^221701-1)^2
quit
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 3
model name : AMD Duron(tm) Processor
stepping : 1
cpu MHz : 800.097
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr p ge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up
bogomips : 1602.20
clflush size : 32
en gros un truc antédiluvien
a+ remy
Julien Vehent a écrit :
bonjour
> 111secondes pour multiplier 2^21701-1 par lui même...
> Ce qui me fait deux nombres de 4094 chiffres en entrée et un nombre d e
> 8188 chiffres en sortie...
> Seulement voila, le script que j'ai écris (en perl, baaaaa) pour
> bidouiller de manière pédagogique sur les multiplications de grands
> nombres me bouffe + de 500 Mo de ram pour faire l'opération.
> Quand bien même j'aurais un peu fait ca a l'arrache (n'en doutez pas) ,
> ca me parait tout de même beaucoup.
> Du coup, les questions que je me/vous pose sont les suivantes :
> 1. Ca devrait se limiter à quel ordre de grandeur normalement ?
> 2. Est-il possible de construire un algo qui travailler dans un espace
> mémoire de taille finie ?
> Merci,
il y a un truc qui m'échappe
time bc pow
real 0m6.985s
user 0m6.128s
sys 0m0.040s
less pow
(2^221701-1)^2
quit
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 3
model name : AMD Duron(tm) Processor
stepping : 1
cpu MHz : 800.097
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr p ge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up
bogomips : 1602.20
clflush size : 32
en gros un truc antédiluvien
a+ remy
pari se base sur gmp pour les calculs sur les entiers, voir par exemple
http://gmplib.org/manual/Multiplication-Algorithms.html
pari se base sur gmp pour les calculs sur les entiers, voir par exemple
http://gmplib.org/manual/Multiplication-Algorithms.html
pari se base sur gmp pour les calculs sur les entiers, voir par exemple
http://gmplib.org/manual/Multiplication-Algorithms.html
> > pari se base sur gmp pour les calculs sur les entiers, voir par exemple
> http://gmplib.org/manual/Multiplication-Algorithms.html
Je voudrais pas dire de bêtises, mais il me semble que ce n'est pas
vrai pour toutes les installations de GP, et que c'est plutôt une
option de compilation et qu'on peut utiliser du code propre à pari/gp
pour ça (qui est moins performant que gmp). Je ne sais plus quelle est
l'option par défaut.
> > pari se base sur gmp pour les calculs sur les entiers, voir par exemple
> http://gmplib.org/manual/Multiplication-Algorithms.html
Je voudrais pas dire de bêtises, mais il me semble que ce n'est pas
vrai pour toutes les installations de GP, et que c'est plutôt une
option de compilation et qu'on peut utiliser du code propre à pari/gp
pour ça (qui est moins performant que gmp). Je ne sais plus quelle est
l'option par défaut.
> > pari se base sur gmp pour les calculs sur les entiers, voir par exemple
> http://gmplib.org/manual/Multiplication-Algorithms.html
Je voudrais pas dire de bêtises, mais il me semble que ce n'est pas
vrai pour toutes les installations de GP, et que c'est plutôt une
option de compilation et qu'on peut utiliser du code propre à pari/gp
pour ça (qui est moins performant que gmp). Je ne sais plus quelle est
l'option par défaut.
Me rendant bien compte que ma précédente version était pourrie, j'a i
repris ca aujourd'hui.... et ca va beaucoup mieux !
Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
secondes et moi de 4Mo de mémoire.
Me rendant bien compte que ma précédente version était pourrie, j'a i
repris ca aujourd'hui.... et ca va beaucoup mieux !
Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
secondes et moi de 4Mo de mémoire.
Me rendant bien compte que ma précédente version était pourrie, j'a i
repris ca aujourd'hui.... et ca va beaucoup mieux !
Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
secondes et moi de 4Mo de mémoire.
On 10 oct, 13:27, Julien Vehent wrote:Me rendant bien compte que ma précédente version était pourrie, j'ai
repris ca aujourd'hui.... et ca va beaucoup mieux !
Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
secondes et moi de 4Mo de mémoire.
bon, c'est pas encore ca... je fais en 27 secondes ce que bc fait en
0.034s......
meme si on compare du perl a de l'assembleur, j'imagine que les algos
implemetes par bc doivent etre beaucoup plus performant et tirer
partie des capacites 32bits des machines.. (genre karatsuba)
On 10 oct, 13:27, Julien Vehent <julien.veh...@gmail.com> wrote:
Me rendant bien compte que ma précédente version était pourrie, j'ai
repris ca aujourd'hui.... et ca va beaucoup mieux !
Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
secondes et moi de 4Mo de mémoire.
bon, c'est pas encore ca... je fais en 27 secondes ce que bc fait en
0.034s......
meme si on compare du perl a de l'assembleur, j'imagine que les algos
implemetes par bc doivent etre beaucoup plus performant et tirer
partie des capacites 32bits des machines.. (genre karatsuba)
On 10 oct, 13:27, Julien Vehent wrote:Me rendant bien compte que ma précédente version était pourrie, j'ai
repris ca aujourd'hui.... et ca va beaucoup mieux !
Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
secondes et moi de 4Mo de mémoire.
bon, c'est pas encore ca... je fais en 27 secondes ce que bc fait en
0.034s......
meme si on compare du perl a de l'assembleur, j'imagine que les algos
implemetes par bc doivent etre beaucoup plus performant et tirer
partie des capacites 32bits des machines.. (genre karatsuba)
Julien Vehent a écrit :
> On 10 oct, 13:27, Julien Vehent wrote:
>> Me rendant bien compte que ma précédente version était pourrie, j'ai
>> repris ca aujourd'hui.... et ca va beaucoup mieux !
>> Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
>> secondes et moi de 4Mo de mémoire.
> bon, c'est pas encore ca... je fais en 27 secondes ce que bc fait en
> 0.034s......
> meme si on compare du perl a de l'assembleur, j'imagine que les algos
> implemetes par bc doivent etre beaucoup plus performant et tirer
> partie des capacites 32bits des machines.. (genre karatsuba)
c'est dans les vieux pots que l'on fait la bonne confiture
http://www.recreomath.qc.ca/dict_russe_multiplication.htm
en gros fais un décalage à gauche de la représentation en base 2
ce qui revient à multiplier par deux
a+ remy
Julien Vehent a écrit :
> On 10 oct, 13:27, Julien Vehent <julien.veh...@gmail.com> wrote:
>> Me rendant bien compte que ma précédente version était pourrie, j'ai
>> repris ca aujourd'hui.... et ca va beaucoup mieux !
>> Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
>> secondes et moi de 4Mo de mémoire.
> bon, c'est pas encore ca... je fais en 27 secondes ce que bc fait en
> 0.034s......
> meme si on compare du perl a de l'assembleur, j'imagine que les algos
> implemetes par bc doivent etre beaucoup plus performant et tirer
> partie des capacites 32bits des machines.. (genre karatsuba)
c'est dans les vieux pots que l'on fait la bonne confiture
http://www.recreomath.qc.ca/dict_russe_multiplication.htm
en gros fais un décalage à gauche de la représentation en base 2
ce qui revient à multiplier par deux
a+ remy
Julien Vehent a écrit :
> On 10 oct, 13:27, Julien Vehent wrote:
>> Me rendant bien compte que ma précédente version était pourrie, j'ai
>> repris ca aujourd'hui.... et ca va beaucoup mieux !
>> Multiplication de deux nombres de 1774 chiffres (du random) en 2.8
>> secondes et moi de 4Mo de mémoire.
> bon, c'est pas encore ca... je fais en 27 secondes ce que bc fait en
> 0.034s......
> meme si on compare du perl a de l'assembleur, j'imagine que les algos
> implemetes par bc doivent etre beaucoup plus performant et tirer
> partie des capacites 32bits des machines.. (genre karatsuba)
c'est dans les vieux pots que l'on fait la bonne confiture
http://www.recreomath.qc.ca/dict_russe_multiplication.htm
en gros fais un décalage à gauche de la représentation en base 2
ce qui revient à multiplier par deux
a+ remy