ARGOMENTO:

Nubman ha scritto:

Sarà un po' difficile scrivere tale numero per esteso, visto che le basi b candidate sono numeri di 489 cifre.

Beh , ti concedo il trattino ( - ) per andare a capo

sabayonino ha scritto:

Nubman ha scritto:

Sarà un po' difficile scrivere tale numero per esteso, visto che le basi b candidate sono numeri di 489 cifre.

Beh , ti concedo il trattino ( - ) per andare a capo

Il megaprimo è stato trovato, ma sembra che non possa essere reportato sul database T5K a causa dell'eccessiva lunghezza.

GFN-11 MEGA Prime found!

March 25 2022, a GFN-11 MEGA prime was found by PDW. Congratulations!

Technically, it is not a first mega prime yet because there are untested candidates below this number, they must be completed first. But with high probability it is.

What was really unexpected is that base was easily factorized and the number is not just a PRP but a proven prime! The base had a 22-digits factor which was quickly found by ECM and remaining 463-digits part also was prime. It was a lot of luck involved!

Unfortunately, currently T5K cannot handle so long primes (its standard form, b^2048+1, is 496 characters long!) I wrote Chris about this issue hoping that limit can be increased.

Link: www.primegrid.com/forum_thread.php?id=9459&nowrap=true#154934

Hanno trovato un modo un po' più compatto per rappresentarlo.
Link: primes.utm.edu/primes/page.php?id=133922

Il sottoprogetto GFN-11 MEGA sta per concludersi. 3 mesi passati e, dunque, secondo i piani inizia la fase di cleanup (niente nuovo lavoro e completamento workunit rimanenti).
Al momento abbiamo trovato 1 primo GFN-11 MEGA (reportato al database T5K, vedi sopra) e 2 primi probabili (che non possono essere provati primi e reportati perché la base non è stata ancora fattorizzata).

Scusa, ma quel "abbiamo" è un plurale majestatis ???

Ho tradotto letteralmente ciò che ha scritto l'admin. L'admin è uno solo e non credo si riferisse soltanto a sé stesso.
Penso invece che con la prima persona plurale intendesse "noi volontari" (pure lui lo è, oltre a gestire il suo private gfn server), dato che tale ricerca non andrebbe molto lontano senza un lavoro coordinato.
Poi, chi ha scoperto cosa lo si trova in pagine come questa: boincvm.proxyma.ru:3.../user_profile/gfn11mega_hunt_status.html

Nuovo sottoprogetto CPU-only: PRST testing

www.primegrid.com/forum_thread.php?id=10108

Pavel Atnashev , autore di LLR2, ha riscritto da zero un nuovo programma per testare numeri primi, dal nome PRST. Grazie alle peculiarità di questo programma, sarà possibile migrare la ricerca dei numeri primi fattoriali e primoriali su BOINC dalla PRPNet. Nella prima fase, che si svolgerà sul Private GFN Server, si farà doublecheck del vecchio lavoro svolto, sia per testare criticità nella gestione di situazioni particolari o malfunzionamenti (apprezzato l'utilizzo di hardware inaffidabile/che si surriscalda e/o con frequenti avvii/pause) che per trovare eventuali residui scorretti.

Sto facendo un'analisi comparativa dei tempi di processamento sul mio Ryzen 9 5950X tra l'ambiente WIndows e l'ambiente LInux (in questo caso un LInux Mint)
Ho riscontrato un caso un po anomalo.

Mi riferisco all'applicativo PRST Testing v 1.04

L'elaborazione sotto Window mi da elapsed time medio di 20000 sec (min 12500 max 31000) e tempo di cpu ovviamente (e correttamente leggermente inferiori)
L'elaborazione sul LInux Mint VBoxato mi da un elapsed di cerca 23000 sec e un tempo di CPU di 53000

Questo è abbastanza strano perchè questa differenza viene fuori solo nel caso che l'applicativo sia in multithreading (in questo caso specifico il rapporto tra i due valori non è vicino a un numero intero)
Chiedo se succede questo anche a qualcuno che ha Linux nativo.

Ciao, fatalità negli ultimi giorni e dopo mesi e mesi, ho elaborato un po' su Private GFN Server ma solo in ambiente Windows.
Ho provato anche PRST sul R3 (4c 4t).
Credo che "l'anomalia" a cui ti riferisci stia nel numero di threads dedicati. A Mint hai dedicato 6t, quando usi Windows quanti ne utilizzi?
Proverò con il mio usando lo stesso (molto basso purtroppo...) numero di t sia con Win sia con Ubuntu e ti saprò dire.

Attenzione, non c'entrano i cores dedicati, perchè nel caso di questo progetto, (come quasi tutti i progetti BOINC) le Wu sono processate come singolo thread.
Ci sono pochissimi progetti che sono dichiarati come multithread (Milkyway@home N-Body Simulation 1.82 (mt), qualche applicativo di LHC/LHC-DEV)
Sono due cose separate il multithread a livello di progetto/programma e il multithread a livello di microcodice (gestito autonomamente dal S.O.)

Nel caso di Milkyway si nota come passare da WU (2 thread ) a WU (4 thread) si nota proprio che l'elapsed time diventa la metà mentre il CPU time rimane costante, ovviamente approssimativamente)
Si dovrebbe, forse proprio con Milkyway, fare una sperimentazione su quanto convenga aumentare il multithreading sul risultato finale (se non è già stato fatto)

Si hai ragione. Scrivevo di Private gfn ma non so perchè pensavo a yafu.
Ho lanciato 4 wu e quando finiscono rifaccio sotto linux. Vediamo.

Non ho mai elaborato sotto la parte di Private-GFN, ma su PrimeGrid molti applicativi cpu possono essere resi multi-thread semplicemente dal pannello impostazioni sul sito del progetto (prima necessitava di un app_config)

Credo che quel parametro di primegrid non tocchi minimamente PGFN
nel mio caso quel parametro è 5 mentre, solo nel Linux Mint VBoxato, c'è quella anomalia riscontrata (il rapporto tra CPUTime ed ElapsedTime è, prendendo i valori medi delle due variabili è 1.68)

farò altre prove perchè ho trovato comportamenti anomali su alcune istanze clonate, anomalie che forse potrebbero giustificare il comportamento

Il sottoprogetto PRST riguarda il doublecheck di numeri primi fattoriali (già completato al 100%) e primoriali (in corso). Se si escludono i primissimi test, la stragrande maggioranza riguarda numeri molto grossi e andrebbero eseguiti solo con multithreading, pena sforamento della cache L3 e collo di bottiglia da parte della ram.
Trattandosi di un test server, non è organizzato scrupolosamente come PrimeGrid, ma si può utilizzare il seguente app_config.xml:
www.primegrid.com/forum_thread.php?id=10108&nowrap=true#159303 (numero dei thread da impostare in base alla vostra cpu)

Come si può vedere da questo vecchio post , la FFT length per primoriali con n>2723401 (attuale leading edge, a quanto vedo dallo stato della ricerca ) è approssimativamente intorno a 400K, quindi almeno 3.5MB di cache per test usando la formula empirica fft_length*8.

Adesso anche PRIVATE GFN SERVER ha creato una nuova applicazione . Factorial / Primorial sieve
Per ora solo per pc Linux, e non ci sono WUs da elaborare
Vedremo

boincvm.proxyma.ru:30080/test4vm/apps.php