Bon voila en poussant un peu plus loin le nombre d'éléments.
Avec le 2eme algorithme :
Pour 100000: Lisp = 0.005s C = 0.009s C(O3) = 0.006s
Pour 1000000: Lisp = 0.409s C = 0.432s C(O3) = 0.407s
Pour 10000000: Lisp = 5.469s C = Segmentation fault (normal à cause des indices du tableau)
Pour 100000000: Lisp = 68.193s C = Segmentation fault
Pour 1000000000: Lisp = Plein de warning à la compilation : on atteint la limite de l'implémentation actuelle et des fixnum qui est à 536870911.
Je n'ai rien changer au code en Lisp (juste incrémenté nb-entries). Pour le code en C, je pense qu'il faut passer au malloc à la main et changer le type des indices.
Sinon, voila les derniers nombres amis trouvé avec 100000000 éléments testés :
[^] # Re: "x100 pour y voir clair"
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 1.
Avec le 2eme algorithme :
Pour 100000: Lisp = 0.005s C = 0.009s C(O3) = 0.006s
Pour 1000000: Lisp = 0.409s C = 0.432s C(O3) = 0.407s
Pour 10000000: Lisp = 5.469s C = Segmentation fault (normal à cause des indices du tableau)
Pour 100000000: Lisp = 68.193s C = Segmentation fault
Pour 1000000000: Lisp = Plein de warning à la compilation : on atteint la limite de l'implémentation actuelle et des fixnum qui est à 536870911.
Je n'ai rien changer au code en Lisp (juste incrémenté nb-entries). Pour le code en C, je pense qu'il faut passer au malloc à la main et changer le type des indices.
Sinon, voila les derniers nombres amis trouvé avec 100000000 éléments testés :
(89477984 92143456)
(90437150 94372450)
(91996816 93259184)
(93837808 99899792)
(95629904 97580944)
(96304845 96747315)
(97041735 97945785)