[quote=T.Rex;177239]Glucas/Nehalem : end today ~2:00pm USA CST (9:00pm France) ~90% done now.
Glucas/Itanium2 : end sunday ~0:20am USA CST (7:20pm France) ~80% done now.
I see with George how he wants the results to be announced.
("Jusqu'ici, tout va bien...")
Tony[/quote]
T-07:38:00
T-41:58:00
These two aren't completely independent from each other though, are they? After all the Nehalem started with the Itanium's save file. Is another, completely separate, verification going to finish soon?

[quote=rgiltrap;177231]Mea culpa, mea culpa, mea maxima culpa. You are correct I meant 1 billion digits. :redface:[/quote]

Yeah we know that but what's your exact argument ... with one core you would need around 850 years. How about first find a 100M one and then think about the Billion challenge ;) ...

[QUOTE=T.Rex;177129]Since Nehalem is not in GA, I will provide no information about its speed.
However, it is really fast !!!
And the scalability between 1 and 8 cores is very good: 7.51 .
I confirm that the verification ends at: ~8:45pm France time (~1.45pm USA CST) tomorrow (Friday 12th).
I did not start the run on Nehalem from scratch. I used a save file from Itanium and put it on Nehalem. Guillermo wrote Glucas so that the saved file is compatible with many architectures. I've checked that the next residues are the same both on Itanium2 and on Nehalem.
Tony[/QUOTE]
Very impressive, Tony - two questions:

1) Does #cores = #threads, or is each core a multi-CPU one running multiple threads?

2) Is this the straight C-code Glucas, or with SSE2 enabled?

Anyway, I see you were very determined to be the #1 DCer this time around - nice work.

[QUOTE=ewmayer;177268]Very impressive, Tony - two questions:
1) Does #cores = #threads, or is each core a multi-CPU one running multiple threads?
2) Is this the straight C-code Glucas, or with SSE2 enabled?
Anyway, I see you were very determined to be the #1 DCer this time around - nice work.[/QUOTE]#cores = #threads. No Hyperthreading.
I don't remember about SSE2 or not. I guess not. I very quickly compiled Glucas, and was happy it works (self-test OK) fast. I'll go back to it later, next week. It seems now that there are more Nehalem available here. So, I'll try to get one from time to time for experimenting with Glucas and prime95. And Mlucas if you want. I simply hope that the compilation will be easier than on AIX/Power !
I didn't plan to be the first... I thought that my 16xNovaScale machine was now too old. I hope that you'll find time for fixing the problem with MLucas. Since Guillermo has no more time for maintaining Glucas, and since I am nuts about FFT, Mlucas seems to be the future, in // with prime95. However, I see that my old Itanium2 machine is still useful ! Different SW and different HW than prime95/PC.
I'm also very interested to understand the reason why Kevin's verification failed ! That's one of the good reasons why important companies cannot buy simple PCs for important stuff: they are not as reliable as are the big machines, like IBM Power or Sun SPARC.
Tony

[quote=ewmayer;177268]Very impressive, Tony - two questions:

1) Does #cores = #threads, or is each core a multi-CPU one running multiple threads?

2) Is this the straight C-code Glucas, or with SSE2 enabled?

Anyway, I see you were very determined to be the #1 DCer this time around - nice work.[/quote]

Prime95 isn't scalling very well with multicores that means it will be probably more interesting to setup all virtual cores and let the cpu do the scheduling.

[QUOTE]8 processors with 130 Watt each ... isn't that expensive (perhaps you get an extra rate with your power plant ;). If it won't scale I'll send another one of these babies to George so he can optimize it for high core usage.

Unfortunately until I'm rich that have to wait. ;). [/QUOTE]

Eh, it may be more expensive here, not sure. Perhaps you should invest in a couple of lottery tickets.

[QUOTE]Prime95 isn't scalling very well with multicores that means it will be probably more interesting to setup all virtual cores and let the cpu do the scheduling.[/QUOTE]

This seems like one of the biggest problems we will have to overcome as the active range of testing continues to climb, other than relying on faster and faster cpus.

[quote=Primeinator;177277]Eh, it may be more expensive here, not sure. Perhaps you should invest in a couple of lottery tickets.

This seems like one of the biggest problems we will have to overcome as the active range of testing continues to climb, other than relying on faster and faster cpus.[/quote]

I haven't found the actual Watt numbers on the official Intel site but wikipedia has written that number. But even if it is not under 2.000 Watt it is not a financial breakdown (around 800 Euro every year).

I'm not very familiar with the concurrency optimization in the program code but it is probably still optimizable. In the future with more people owning multicores it will change.

These multicore computers are only interesting for the hunt for 100M numbers - for the actual 10M+ numbers you can use cheap 2 or 4 core PCs ...

Less than 1 1/2 hours to go...

[QUOTE]These multicore computers are only interesting for the hunt for 100M numbers - for the actual 10M+ numbers you can use cheap 2 or 4 core PCs ... [/QUOTE]

True but these computers have to become cheaper for more people to actually be involved in the hunt for a 100M digit prime. That, or the existing consumer end desktops must become significantly faster in the coming years.

[QUOTE]Less than 1 1/2 hours to go... [/QUOTE]

Is Tony going to give the verdict or was he instructed to wait until the third check finished?

[quote=Primeinator;177282]Is Tony going to give the verdict or was he instructed to wait until the third check finished?[/quote]

He certainly could present the result. I'm still waiting for the math party with half-naked math chicks promised by cheesehead ;).

[QUOTE]He certainly could present the result.[/QUOTE]

I think it depends on what George says...he may want it kept under wraps until a second double check is completed. Personally, I do not see a lot of purpose in delaying if at least one double-check confirms.