[QUOTE=Primeinator;176823]Wouldn't the double check on these more powerful machines have been faster if the right FFT had been used as opposed to one that was far larger than necessary?[/QUOTE]

Yes, but we are having performance issues (for reasons as-yet unknown) which are causing runs at (say) 2560K with 16 threads to run more slowly than at 4096K.

Getting multithreaded code to run fast and scale well is a nontrivial issue, especial with data-nonlocal algorithms like the FFT, and with a coarse-grained problem decomposition in which each thread can do a whole bunch of work before it needs to re-sync with the others, but where each thread spans multiple function calls. (this is the major dfference between Mlucas and Glucas - the latter uses a fine-grained multithreading which is much more loop-local but which I believe will not scale as well to large thread counts).

That having been said, I really am mystified at the non-power-of-2 runtime issue because aside from the mere fact of the FFT length being a power of 2 or not, the data-processing that occurs is not qualitatively different. But perhaps there's some underlying issue which makes non-power-of-2 lengths in Mlucas more prone to e.g. race conditions when run multithreaded. We hope some performance-analysis tools Rob has just started using will provide useful clues.

[COLOR="DarkRed"][off topic][/COLOR]

[QUOTE=Kevin;176812]Nope, the urban legend that sewers have overflowed from so many people watching the Super Bowl on TV simultaneously using the bathroom at half-time.[/QUOTE]The sewer system is gravity flow and diverse, area-wise. The flow in a major city can be hours from the loo to the WWTP (wastewater treatment plant) (I know a paricular situation where the total travel time a partical would take could be ~24 hours). There are no appreaciable slug flows there (none more than the daily morning rise). The water supply system OTH is a pressure driven system. The excess capacity is on the supply side to handle such loads. These can see a sudden drop in supplies, but nothing that the system can't handle. Your local john may take a few seconds longer that normal to refill, but the wife watering the garden and the kids bathing would have a more dramatic effect (at least on the local scale).

Small towns, however can notice the slug flows and the water system pressure drops more than big cities. Pipe sizing and sump capacities tend to be tighter in small towns, and the standard deviation of the distance (travel time-wise) from the turlet to the turd farm tends to much smaller.
[QUOTE=Flatlander;176827]A few weeks ago I saw the a prog on TV about the UK equivalent of this effect. A guy sits at a control panel and, when the commercials come on in the middle of a popular soap, flips a switch to bring online a power station in France. To power all the kettles.[/QUOTE]Next time I talk to my electrical power distro friend, I will ask about this. I can see that in Euroland, with the penchant for electro-kettles, vs. the more proper, direct gas heat, this could be an issue during the FIFA play-off games.


The sheep's bladder discharge enmasse actually provides lubrication to the crustal plates, thus allowing the earthquake to form.
Bill Cosby similarly observed a link between vehicular accidents (and near misses) with stained undergarments.
The latter (the near miss) also has a correlation to deformity in the driver's seat. Recent studies link seats with a distinctive lump toward the centre, with vehicles that have come close to striking others. It seems that the height of the bump is inversely proptional to the distance multiplied by the closing velocity at closest approach and by (the decleration of the driver's vehicle over the maxium theoretical decleration for said vehicle). If I knew latex, I would render the proper equation, with the constants.
Vehicle manufacturers are processing this data, and trying to design safer seats that do not develope these deformations over time. Saab and Volvo state that their seats have 3x time to deformation versus the industry standard, while Kia and Dihatsu have 1/3x of the industry standard. Ford has stated that they noticed this phenomeon shortly after the introduction of the Pinto, while Morris and Cooper manufacturers noticed this on the motorways with heavy lorry traffic in Cornwall during the early 50's.
The EU, USA, China, and Japan plan to take up a global standard for the redesigned seats at the next G20 summit. China states that there is no problem with their seats and that this is a western issue.
[COLOR="DarkRed"][/off topic][/COLOR]

[QUOTE]Yes, but we are having performance issues (for reasons as-yet unknown) which are causing runs at (say) 2560K with 16 threads to run more slowly than at 4096K.

Getting multithreaded code to run fast and scale well is a nontrivial issue, especial with data-nonlocal algorithms like the FFT, and with a coarse-grained problem decomposition in which each thread can do a whole bunch of work before it needs to re-sync with the others, but where each thread spans multiple function calls. (this is the major dfference between Mlucas and Glucas - the latter uses a fine-grained multithreading which is much more loop-local but which I believe will not scale as well to large thread counts).

That having been said, I really am mystified at the non-power-of-2 runtime issue because aside from the mere fact of the FFT length being a power of 2 or not, the data-processing that occurs is not qualitatively different. But perhaps there's some underlying issue which makes non-power-of-2 lengths in Mlucas more prone to e.g. race conditions when run multithreaded. We hope some performance-analysis tools Rob has just started using will provide useful clues.[/QUOTE]

Well, that is all beyond me. I wish you luck not only because having hardware problems is an annoyance...but because it would be useful to know what caused the problem before an even bigger (maybe significantly bigger) potential prime needs to be double checked.

53.94% - 23M - 00:49 CST
 

[QUOTE][Jun 10 07:49:12] Iter. 23000000 ( 53.94%), Err= 0.000, 36751.59 user 21063% CPU (0.0174 sec/iter).
[Jun 10 07:49:13] Saved Interim file at iteration 23000000. Res64: C991CA8D6947461D.
[/QUOTE]
Jusqu'ici, tout va bien.
Tony

So far so good.
________

Один человек пошел чинить телевизионную антенну и, поскользнувшись, упал с крыши.
Пролетая мимо своего окна, на вопрос жены "Как дела?" он ответил:
"Пока всё идет хорошо."

babelfish.yahoo.com does a decent job.
Let's see if Tony like the translation:

[COLOR=green]Une personne est allée réparer l'antenne de télévision et, ayant glissé, est tombé du toit.
En volant devant la fenêtre, il a répondu à la question de la femme "Comment ça va?" : "Jusqu'ici, tout va bien".[/COLOR]

[quote=Batalov;176878]babelfish.yahoo.com does a decent job.
Let's see if Tony like the translation:

[COLOR=green]Une personne est allée réparer l'antenne de télévision et, ayant glissé, est tombé du toit.
En volant devant la fenêtre, il a répondu à la question de la femme "Comment ça va?" : "Jusqu'ici, tout va bien".[/COLOR][/quote]

Do you think we all can speak French (well, I can speak a little bit french so I understand it but ...) ;o) ...

Exponent status updated... :devil:

[quote]
[Wed Jun 10 12:56:18 2009]
UID: ckdo/decoy, M42643801 completed P-1, B1=1000000, B2=100000000, E=6, Wd8: 495F5216
[/quote][FONT=monospace]
[/FONT]CPU credit was 16.0955 GHz-days.

George seems to be fairly [URL="http://www.mersenne.org"]confident[/URL].

[quote=T.Rex;176874]Jusqu'ici, tout va bien.
Tony[/quote]
[code]23000000/.5394=42639970.33741193919169447534
23000000/.5395=42632066.72845227062094531974[/code]42632066 to 42639970 compared to the earlier 42635862 to 42647058 leaves [B]42635862 to 42639970[/B]. 42643801 is outside of this range! Either Tony changed the % slightly, the program he's using round the percentages differently than Prime95 (from the last time I checked and assuming I understood correctly; i.e. take the fraction complete and truncate to the correct number of digits, e.g. .5394831897534... becomes 53.94%), or M47 != M42643801. I wonder which it is. :bounce::bounce::bounce:

In case M47 really is in this range I calculated...
[URL="http://primes.utm.edu/nthprime/"]2584115-2583877=238 primes[/URL] in this range. There are [URL="http://v5www.mersenne.org/report_factors/?exp_lo=42635862&exp_hi=42639970&exp_date=&fac_len=&txt=1&dispdate=1&B1=Get+Factors"]176 factors[/URL] over 141 exponents, leaving 97 unfactored. Of those, [URL="http://v5www.mersenne.org/report_LL/?exp_lo=42635862&exp_hi=42639970&exp_date=&user_only=0&user_id=&exfactor=1&txt=1&dispdate=1&B1=Get+LL+data"]57 have unverified LLs[/URL] and 0 have verified LLs. So 40 are currently unassigned or assigned but uncompleted.

Wow, so there [B]is[/B] a way to "see" new primes in v5.

I guess we learn something new each day!