![]() |
|
|
#320 |
|
∂2ω=0
Sep 2002
República de California
2D7F16 Posts |
I would think after the first independent verify completes, but it's really up to George.
About the per-iteration timings of the various verify runs, I will note only this tidbit: Due to some multithreaded performance issues which will be the subject of ongoing analysis, Rob Giltrap and Tom Duell of Sun are doing their Mlucas-based verify run using an FFT length of 4096K, which is much larger than really needed based on roundoff error considerations. Thankfully, some blazingly fast hardware [and excellent multithreaded performance at least at that FFT length] is helping to mitigate the resulting performance hit. By the time the next M-prime discovery rolls around, my intention is to have the thread-related issues worked out and be able to do the verify in a week or less. At least that's the plan. I told y'all this verify was "messier" than the last one, but everyone thought I was just making a silly astronomical joke. ;) |
|
|
|
|
|
#321 |
|
Bemusing Prompter
"Danny"
Dec 2002
California
2×11×109 Posts |
I still think Tony is going to win this "race."
Since rgiltrap reported he was 55% complete at 4:07 a.m. this morning (my local time), and assuming that he started his run some time after 8:45 a.m. on August 23 (the time when the e-mails were sent), I would say that he is completing about 6.3% each day. Tony started two days ago, and he's already at 22% done. That's not taking the compiler problems into account. Even if he started on September 1, he is still getting at least 7% done each day. Thus, I would still say that he will be the first to be done. |
|
|
|
|
|
#322 | |
|
∂2ω=0
Sep 2002
República de California
19×613 Posts |
Quote:
55 + 6.3*x = 100 and 22 + 7.0*y = 100 yields y < x. "Does not compute"... |
|
|
|
|
|
|
#323 |
|
Jul 2008
San Francisco, CA
3×67 Posts |
Sorry if this is obvious or covered elsewhere, but how are you guys completing the verification tests so fast? Is there some way you are running these parallel, with several processors working on a single exponent? If so, is that an option for those of us running dual and quad core systems?
|
|
|
|
|
|
#324 | |
|
Jun 2003
Ottawa, Canada
100100101012 Posts |
Quote:
|
|
|
|
|
|
|
#325 | |
|
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
426710 Posts |
Quote:
Edit: What Jeff posted above me is true for what he's running, but ignores Prime95 v25's new multi-threaded (that's what you're referring to is called BTW) feature. Last fiddled with by Mini-Geek on 2008-09-04 at 17:40 |
|
|
|
|
|
|
#326 |
|
Jun 2003
Ottawa, Canada
117310 Posts |
Cool, I learned something new. I thought Prime95's multi-threaded feature allowed you to automatically run 4 LL tests or factoring simultaneously (if you had 4 CPUs), I didn't realize it let you do a multi-threaded LL test to speed up individual tests.
|
|
|
|
|
|
#327 |
|
Bamboozled!
"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across
3·5·719 Posts |
|
|
|
|
|
|
#328 | |
|
Oct 2007
9010 Posts |
Quote:
|
|
|
|
|
|
|
#329 | ||
|
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
17·251 Posts |
Quote:
Too bad the new Prime95 isn't used for double checks, and with the normal FFT length, too...it'd be lightning fast on that 16 CPU system. I guess eliminating any possibility of an error caused by Prime95 or x86 is more important than speed, but can't both be done? Edit: Quote:
http://www.mersenneforum.org/showthread.php?t=9779 It's not on mersenne.org because it's still pre-beta and could have many problems. Last fiddled with by Mini-Geek on 2008-09-04 at 17:57 |
||
|
|
|
|
|
#330 | |
|
∂2ω=0
Sep 2002
República de California
101101011111112 Posts |
Quote:
AFAIK all 3 ongoing big-iron verify runs are running on 16 cores in parallel, though the hardware is different [Rob/Tom/Ernst on a Sparc, Tony and Jeff using Itanium but with different kinds of hardware clustering] and the way the multithreading is done by the 2 different verify codes [Glucas and Mlucas] is very different [fine-grain vs coarse-grain]. In other words, Lots of interesting stuff going on behind the scenes. Not necessarily, as I noted above. Getting a big-vector FFT code to scale decently well to large numbers of threads is a very nontrivial issue. We coders *wish* there were a software tool that would just profile the running || code and spit out notes to the effect "Well, ya got some thread-locking issues here in routine foo() - try sticking this patch in there..." The current state of the art for thread-profiling tools is extremely primitive, still lots of guesswork involved. Last fiddled with by ewmayer on 2008-09-04 at 18:00 |
|
|
|
|
![]() |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| (New ?) Wagstaff/Mersenne related property | T.Rex | Wagstaff PRP Search | 6 | 2019-11-23 22:46 |
| Holy Speedup, Batman! | R.D. Silverman | NFSNET Discussion | 4 | 2008-10-02 01:28 |
| Holy Beaverpotamus, Batman! | ewmayer | Science & Technology | 4 | 2008-03-14 19:19 |
| holy tethered cow! new Mersenne prime? (M43-related) | ixfd64 | News | 265 | 2006-01-04 09:47 |
| Mersenne prime related shirts and other items | adpowers | Lounge | 40 | 2004-08-12 22:05 |