![]() |
[QUOTE=Mini-Geek;182096]Wouldn't it be more efficient to finish all ECM, then do all poly search, then all sieving, then all filtering, instead of letting them overlap?[/QUOTE]
Yes - as it is still possible that ECM finds a factor, and in that case any work done with GNFS would be wasted. |
[QUOTE=Mini-Geek;182096]Wouldn't it be more efficient to finish all ECM, then do all poly search, then all sieving, then all filtering, instead of letting them overlap?[/QUOTE]
Unless you want to finish it as early as possible (calendar time). My proposal was intended to minimize the wastage, while trying to speedup the process. |
[quote=axn;182106]Unless you want to finish it as early as possible (calendar time).
My proposal was intended to minimize the wastage, while trying to speedup the process.[/quote] Hm, makes sense. I suppose it's the best way with what we've got. However, if someone were to make a program to automate and communicate between all the CPUs working on this c157, it could keep ~100% efficiency and best possible wall time. Imagine each CPU checking in every 1-5 curves. Once the server determines that enough ECM has been run, it switches all the CPUs over to poly searching as soon as they report their batch of curves finished. Use similarly small batches and switchover method for poly searching and sieving, (with automated reporting of found polys and relations) then stop all workers once the relations gathered reaches how many should be needed and run the filtering, then if necessary resume sieving on all workers. I don't suppose anything like that exists, does it? I don't suppose any of our resident coders would put forward the time for an app like that? :whistle: Hey, I can dream can't I? |
Isn't it called "ECMNET server"? :smile:
|
Look!
[code]Using B1=43000000, B2=388112953420, polynomial Dickson(30), sigma=492002632 Step 1 took 169903ms Step 2 took 85269ms ********** Factor found in step 2: 270389991140767419113595201012871830378223721738111 Found probable prime factor of 51 digits: 270389991140767419113595201012871830378223721738111 Probable prime cofactor 13097232778890996127721661850226147250346721968629381919532862503065919780081186230385499514937725380715199 has 107 digits [/code] |
[quote=Batalov;182142]Isn't it called "ECMNET server"? :smile:[/quote]
Except that ECMNet doesn't do polynomial searches or sieving. |
[quote=jrk;182148]Look!
[code]Using B1=43000000, B2=388112953420, polynomial Dickson(30), sigma=492002632 Step 1 took 169903ms Step 2 took 85269ms ********** Factor found in step 2: 270389991140767419113595201012871830378223721738111 Found probable prime factor of 51 digits: 270389991140767419113595201012871830378223721738111 Probable prime cofactor 13097232778890996127721661850226147250346721968629381919532862503065919780081186230385499514937725380715199 has 107 digits [/code][/quote] :w00t: Very nice! |
[QUOTE=bsquared;182151]:w00t:
Very nice![/QUOTE] Indeed. But another c155 :sad: Did someone say 8000 curves @ 43M? |
[quote=Batalov;182142]Isn't it called "ECMNET server"? :smile:[/quote]
Unless I'm mistaken, that only runs ECM, not all the sections with smart switchover. |
Well, if we had an ECMNET server running, by now all willing ECMers would have thrown quite a few curves on the c155, not wasting time on the solved c157! The server (with a manager) would have coordinated that.
Of course it doesn't do poly sel, but it doesn't prevent us from setting it up. imho. |
running 600@43e6 should be done in about 24 hours
|
| All times are UTC. The time now is 22:40. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.