[QUOTE=paulunderwood;140854]When will we mere mortals be told the exponent?[/QUOTE]

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. ;)

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.

[QUOTE=ixfd64;140859]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.[/QUOTE]
Your math seems suspect - in algebraic terms your are saying that solving the 2 uncoupled linear algebraic equations

55 + 6.3*x = 100

and

22 + 7.0*y = 100

yields y < x.

"Does not compute"...

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?

[QUOTE=stars10250;140863]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?[/QUOTE]

We are using 16+ CPU systems. Since the software is not optimized for the x86 architecture, running what we are running on a dual or quad-core x86 system would actually take longer than running Prime95 on 1 CPU.

[quote=stars10250;140863]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?[/quote]
Yes they are, and yes it's possible for dual/quad core owners to use it also (the next version of Prime95 will support it), but when you run it like that, it always loses some efficiency because of delays in the core's communications (e.g. on a quad, you might finish one every 10 days instead of four every 30 days if you had all CPUs run one number, so it's faster for one, but slower overall throughput), so it's only really useful for verification work that you'd want much faster, even at the cost of reduced total throughput.
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.

[QUOTE=Mini-Geek;140866]
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.[/QUOTE]

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.

[QUOTE=R.D. Silverman;140841]Well sure!! Haven't you heard of Buffalo chips?[/QUOTE]Nope. Is that's what's left of the Buffalo after its wings have been removed?

Paul

[quote=Mini-Geek;140866]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.[/quote]

How do you get version 25? Version 24 is the one available at the download at [url]www.mersenne.org[/url].

[quote=Jeff Gilchrist;140868]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.[/quote]
Yep, it has both available. It does let you run x tests simultaneously on x CPUs, or run x threads on one test on x CPUs (or some combination, of course, like 2 CPUs for 1 test, then 1 each for 2 other tests).
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=Jud McCranie;140871]How do you get version 25? Version 24 is the one available at the download at [URL="http://www.mersenne.org/"]www.mersenne.org[/URL].[/quote]Here:
[URL]http://www.mersenneforum.org/showthread.php?t=9779[/URL]
It's not on mersenne.org because it's still pre-beta and could have many problems.

[QUOTE=Jeff Gilchrist;140868]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.[/QUOTE]

I seem to recall that the Prime95 || performance deteriorates rapidly for > 2 threads, but don't know if that's reflective of the latest/greatest version.

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.

[QUOTE=Mini-Geek;140872]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.[/QUOTE]
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.