Re: Décomposition d’un nombre en produit de facteurs premier
Publié : mer. 16/déc./2015 21:26
Bonsoir,
Comme je l’ai déjà dit, je suis cette discussion avec intérêt, même si mes « hobbies » me posent moins de problèmes de recherche de primalité que de problèmes de factorisation, ou de problèmes de recherche de combinaisons de fractions qui approchent le plus possible un nombre réel élevé, qu’il soit premier ou pas (problèmes aujourd’hui résolus).
Le test de primalité par les nombres de la forme 6a+b, ou encore plus de la forme 30a+b, permet de réduire de façon importante la durée du test par rapport à la « méthode naïve » de division par tous les nombres en partant de 2, les pairs étant quand même exclus.
Du fait de mes connaissances modestes en informatique je ne comprends pas pourquoi le multithreading pourrait apporter des gains de temps décoiffants.
Tchargal peut il nous expliquer ? Merci.
Il me semble que pendant un test de primalité, quelle que soit la méthode utilisée, le processeur tourne à 100% du temps sur le thread en cours, parce qu'il n’a pas de temps d’attente de réponse d’une ressource quelconque. Comment alors lui soumettre un autre thread à traiter alors qu’il est déjà « ras la gueule ».
Par contre, je comprends qu’en multiprocesseurs on puisse faire du parallélisme sur le même test de primalité, et réduire d’autant le temps d’exécution, en confiant à chaque processeur un groupe de diviseurs à essayer.
A l’époque où je ne les avais pas optimisés, quand je lançais mes algos itératifs de recherche de fractions, ils duraient plusieurs minutes et je constatais que le ventilateur du processeur démarrait de suite après le lancement, signe que le processeur chauffait parce qu’il tournait à fond, qu’il était sur le chemin critique de l’exécution de l’algorithme en cours, qu’il ne pouvait rien absorber d’autre.
Mais encore une fois, je dis peut être des énormités (pas taper
) par manque de compétences.
Comme je l’ai déjà dit, je suis cette discussion avec intérêt, même si mes « hobbies » me posent moins de problèmes de recherche de primalité que de problèmes de factorisation, ou de problèmes de recherche de combinaisons de fractions qui approchent le plus possible un nombre réel élevé, qu’il soit premier ou pas (problèmes aujourd’hui résolus).
Le test de primalité par les nombres de la forme 6a+b, ou encore plus de la forme 30a+b, permet de réduire de façon importante la durée du test par rapport à la « méthode naïve » de division par tous les nombres en partant de 2, les pairs étant quand même exclus.
Du fait de mes connaissances modestes en informatique je ne comprends pas pourquoi le multithreading pourrait apporter des gains de temps décoiffants.
Tchargal peut il nous expliquer ? Merci.
Il me semble que pendant un test de primalité, quelle que soit la méthode utilisée, le processeur tourne à 100% du temps sur le thread en cours, parce qu'il n’a pas de temps d’attente de réponse d’une ressource quelconque. Comment alors lui soumettre un autre thread à traiter alors qu’il est déjà « ras la gueule ».
Par contre, je comprends qu’en multiprocesseurs on puisse faire du parallélisme sur le même test de primalité, et réduire d’autant le temps d’exécution, en confiant à chaque processeur un groupe de diviseurs à essayer.
A l’époque où je ne les avais pas optimisés, quand je lançais mes algos itératifs de recherche de fractions, ils duraient plusieurs minutes et je constatais que le ventilateur du processeur démarrait de suite après le lancement, signe que le processeur chauffait parce qu’il tournait à fond, qu’il était sur le chemin critique de l’exécution de l’algorithme en cours, qu’il ne pouvait rien absorber d’autre.
Mais encore une fois, je dis peut être des énormités (pas taper
