Ok bon bah je peux l'enlever de ma liste alors mais je vais me renseigner voir si je peux en avoir un si le prix n'est pas exorbitant et si il ne c'est pas fatigué depuis
j'en prendrais peut etre un
Sinon j'ai lancé du PrimeGrid aujourd'hui pour la première fois, mon PC a dis merde
je sais pas ce qu'il c'est passé j'étais au boulot quand je l'ai lancé depuis mon téléphone et je viens de rentrer chez moi le pc a comme redémarrer tout étais fermé. Après avoir relancer primegrid je crois que j'ai compris pourquoi. Il utilise ma CG et mon CPU en même temps à 100%, le cpu n'a pas supporté je pense. CPU : 321 sieve et GPU : Do You Feel Lucky (d'ailleurs si quelqu'un peux me dire ce que c'est Do You Feel Lucky parce que 2j pour une tâche CG c'est long ?)
J'ai ce problème très souvent quand les projets utilisent fortement ma CG. La CG résiste très bien car elle est très bien refroidi mais le cpu en prend plein la gueule et chauffe + que la normal et je pense que c'est pour sa que tous c'est arrêté.
J'ai relancé avec le cpu à 70% et j’atteins les 67C en même pas quelques minutes donc à 100% je pense que il est allé à 80C voir + au bout d'une heure.
Certains projets comme einstein, seti,... utilise ma CG et mon CPU à 100% mais ne fait pas chauffer ma CG (55C avec les ventilateurs à 70%) mais certain projet la pousse à 67C avec les ventilateurs à 100% ce qui est normal pour ma CG en pleine charge mais du coup elle doit dégager trop de chaleur pour mon pauvre CPU à coté
il a déjà du mal à rester dans ses températures en temps normal alors avec la CG qui lui crache son air chaud dans la figure
__________________________________________________________________________________________________________________________________________________________________________________________________________________
J'ai finalement trouver des infos sur Do You Feel Lucky ma CG va en avoir pour son compte
:
En 2009, PrimeGrid a commencé à exécuter GFN-15 et GFN-16 sur PRPnet en utilisant le programme Genefer d'Yves Gallot.
En 2010, GFN-18 et GFN-19 ont également été lancés sur PRPNet. À cette époque, un seul nombre premier GFN-18 était connu et aucun nombre premier GFN-19 n'était connu. En février et mars 2011, PrimeGrid a trouvé les deuxième et troisième nombres premiers GFN-18 connus. Puis, en octobre, nous avons trouvé le 4ème Prime GFN-18 connu: 361658262144 + 1.
361658262144 + 1 est spécial: c'est le premier choix que nous avons trouvé en utilisant le nouveau programme GPU GeneferCUDA. La version GPU de Genefer était environ 40 fois plus rapide que la version CPU, et représentait une énorme augmentation de la puissance de calcul.
Juste après cette découverte, John nous a mis au défi d'utiliser GeneferCUDA pour trouver un GFN-19. Personne ne savait si un GFN-19 existait même. Certes, aucun n'a jamais été découvert.
"Pourquoi pas?" a déclaré I. 4 jours et seulement 16 tâches plus tard, j'ai découvert le premier GFN-19 premier au monde.
À ce moment-là, je travaillais chez PrimeGrid depuis un peu moins de deux ans. Quelque part au cours de ces deux années, j'ai découvert GIMPS. Leur recherche de Mersenne avait trouvé tous les plus grands nombres premiers. Les nombres premiers trouvés à PrimeGrid, aussi gros soient-ils, étaient encore beaucoup plus petits que les nombres premiers de Mersenne.
Voyant une chance de trouver peut-être des nombres premiers aussi grands que ceux trouvés par GIMPS, j'ai suggéré que si nous pouvions faire fonctionner GeneferCUDA sur notre serveur BOINC, où il serait plus utilisé, nous pourrions commencer à rechercher la gamme GFN-22. Tous les nombres premiers GFN-22 potentiels, sauf les plus petits, seraient plus grands que le nombre record de Mersenne alors record, qui était de 12,9 millions de chiffres. Compte tenu de la rapidité de GeneferCUDA, nous avons eu une vraie chance de trouver un record mondial. C'était encore loin, mais il y avait une chance.
J'ai proposé de porter Genefer et GeneferCUDA pour qu'ils soient des programmes BOINC natifs, une idée à laquelle les administrateurs PrimeGrid étaient prêts. J'ai donc porté les programmes et ils ont apporté les modifications nécessaires aux serveurs de PrimeGrid. Nous avons commencé à exécuter GFN-18 sur BOINC en janvier 2012, et avons commencé la recherche de record mondial avec GFN-22 en février 2012.
Un an plus tard, en février 2013, GFN-22 recherchait des chiffres d'environ 16,5 millions de chiffres lorsque GIMPS a découvert un nouveau record du monde Mersenne prime de 17,4 millions de chiffres.
Trois ans plus tard, ils ont trouvé un indice Mersenne à 22,3 millions de chiffres.
Deux ans plus tard, ils ont trouvé un indice Mersenne de 23,2 millions de chiffres.
Onze mois plus tard, en décembre de l'année dernière, ils ont trouvé un nombre premier de 24,8 millions de chiffres, qui est le plus grand nombre premier connu actuellement.
GFN-22 recherche actuellement 21,6 millions de chiffres.
Il semblerait que l'occasion de trouver un record mondial avec le GFN-22 soit venue. Même si nous avons un excellent programme GPU, Mersenne a l'avantage d'être intrinsèquement plus facile à rechercher, et leur nombre augmente plus rapidement car leur recherche augmente n (la taille est proportionnelle à n) tandis qu'une recherche GFN augmente b (la taille est proportionnelle uniquement pour enregistrer (b)). De plus, il leur suffit de rechercher les valeurs premières de n alors que nous devons rechercher toutes les valeurs paires de b. Même si nous avons un programme plus rapide, leur recherche progresse toujours plus rapidement dans l'ensemble. Nous sommes en retard et ils s'éloignent.
Après chacune de ces 4 découvertes Mersenne, il y avait des gens ici - des gens intelligents - qui pensaient que nous devrions augmenter b pour être à nouveau à la recherche d'un record du monde, ou commencer une recherche n = 23, qui serait également un record du monde chercher. Le calcul, cependant, ne fait pas que ce soit un bon pari. Lorsque nous avons lancé le GFN-22, il n'a pas fallu longtemps avant qu'il ne soit nettement supérieur au record du monde actuel. Nous avions une certaine latitude. Commencer une nouvelle recherche de record du monde avec un plus grand nombre aurait encore plus de chances de succès. Mon oncle avait l'habitude de dire: "Le loto est une taxe pour les personnes mathématiquement handicapées". Je ressens la même chose à propos de l'augmentation de GFN pour être au-dessus de GIMPS. Ce n'est pas un bon pari. Ils sont plus susceptibles de trouver un autre prime avant d'en trouver un de cette taille.
Donc, après chaque prime de Mersenne, nous avons pensé à faire une autre recherche de record du monde, et à chaque fois, nous avons décidé de ne pas le faire.
Jusqu'à maintenant.
Permettez-moi de commencer par dire que c'est un très long plan. Il frise la stupidité. Mais beaucoup de gens veulent le faire, et ça va être amusant.
Nous démarrons un nouveau projet intitulé "Avez-vous de la chance?" Ce sera une recherche GFN-22 avec b commençant à 846 398. C'est le premier b non supprimé par le tamisage où b4194304 + 1 est supérieur au record du monde actuel.
Comme GFN-17, nous aurons maintenant deux recherches GFN-22 exécutées simultanément. Contrairement au GFN-17, cependant, cette nouvelle recherche ne sera pas une recherche contiguë. Si un nouveau prime de Mersenne est trouvé, nous augmenterons à nouveau b pour continuer à rechercher un record du monde. GFN-22 est tamisé à b = 100M, nous pouvons donc continuer à faire cette recherche jusqu'à environ 33,5 millions de chiffres. Si nous devons rechercher de plus grands nombres, nous devrons soit tamiser GFN-22 au-dessus de 100M, soit tamiser GFN-23.
"Chanceux?" les tâches seront plus lentes que les tâches GFN-22 normales car ni les transformations OCL ni OCL4 ne peuvent être utilisées. Tous les GPU doivent utiliser OCL5.
Les tâches CPU ne seront pas disponibles. Ces tâches sont au-delà de la plage des transformations CPU 64 bits, donc la transformation 80 bits x87 doit être utilisée. Non seulement cela est environ 10 fois plus lent, mais il ne peut pas utiliser le multithread comme les transformations CPU AVX et FMA3. Les processeurs prendraient une éternité pour exécuter ces tâches.
Ce projet est un projet de recherche de premier plan, il sera donc disponible pour TdP, ou du moins pour la plupart. Je ne sais pas exactement quand nous allons l'allumer.
Le nom interne est "genefer_extreme". C'est ce que vous utiliseriez dans app_config.xml ou app_info.xml. Si jamais cela était nécessaire, les noms suivants seraient genefer_ultimate, puis genefer_ludicrous, puis genefer_plaid.