[SIZE=3]Thx, the win32 binary works fine at Polynomial selection on MSI Geforce 8600GT. It only slow down my prime95 iteration time on my AMD64 from 0,109 sec to 0,119.[/SIZE]

Timing
 

Is there any way to make the time limit count real-time rather than CPU-time? This 84-hour job took 140 hours to run ...

(it seems that there's some kind of contention going on with X; the compiz.real process is using 100% CPU for most of the time that msieve isn't)

[code]
Mon Jan 11 19:02:08 2010
Mon Jan 11 19:02:08 2010
Mon Jan 11 19:02:08 2010 Msieve v. 1.44
Mon Jan 11 19:02:08 2010 random seeds: 24b7997b cb9644e0
Mon Jan 11 19:02:08 2010 factoring 57935987372136483490920868637496989793253957704773020664231348177235315499760770915805111178249998523552665625493027256226450699872037675117751 (143 digits)
Mon Jan 11 19:02:09 2010 no P-1/P+1/ECM available, skipping
Mon Jan 11 19:02:09 2010 commencing number field sieve (143-digit input)
Mon Jan 11 19:02:09 2010 commencing number field sieve polynomial selection
Mon Jan 11 19:02:09 2010 time limit set to 84.25 hours
Mon Jan 11 19:02:09 2010 searching leading coefficients from 1 to 458169
Mon Jan 11 19:02:09 2010 using GPU 0 (GeForce GTX 275)
Sun Jan 17 14:27:08 2010 polynomial selection complete
Sun Jan 17 14:27:08 2010 R0: -5125388751823073987853288095
Sun Jan 17 14:27:08 2010 R1: 8524937249381093
Sun Jan 17 14:27:08 2010 A0: 4360089963420370665742813037146302
Sun Jan 17 14:27:08 2010 A1: 88863651970329415580546858627
Sun Jan 17 14:27:08 2010 A2: -18100237861642776280187
Sun Jan 17 14:27:08 2010 A3: -143518807675896523
Sun Jan 17 14:27:08 2010 A4: 10388032476
Sun Jan 17 14:27:08 2010 A5: 16380
Sun Jan 17 14:27:08 2010 skew 1430439.21, size 1.220156e-13, alpha -6.759336, combined = 1.899077e-11
Sun Jan 17 14:27:08 2010 elapsed time 139:25:00
[/code]

[QUOTE=fivemack;202191]Is there any way to make the time limit count real-time rather than CPU-time? This 84-hour job took 140 hours to run ...[/QUOTE]
Which SVN revision are you using? Only very old versions of msieve-gpu counted CPU time. Since rev 95, wall time is used.

However, the time limit only applies during the stage 1 side of the run. If the time limit is met while stage 2 is running, stage 2 must still finish normally before msieve stops. The unpredictability of stage 2 time means that the run may go several hours over the limit.

Perhaps an additional check for the time limit could be added to the stage 2 code? If this would be useful, I can make a patch.

[QUOTE=fivemack;202191](it seems that there's some kind of contention going on with X; the compiz.real process is using 100% CPU for most of the time that msieve isn't)[/QUOTE]
I find that it is best to shut down X before starting msieve-gpu. X is mostly un-usable while cuda code is running, anyway.

[QUOTE=jrk;192862]but 47000? I don't think I've ever seen that many, even on smaller composites.[/QUOTE]
I take this back. A recent run on a c172 with msieve produced over a million polys. It turns out that basing your expectations on a few hours worth of results is not a good idea. Msieve can go for hours without printing anything, and then surprise you with some tens of thousands of polys in one big batch. Such is the result of unpredictable stage 2 behavior.

[QUOTE=fivemack;202191]Is there any way to make the time limit count real-time rather than CPU-time? This 84-hour job took 140 hours to run ...
[/QUOTE]

I would suggest an option (flag to be specified in command line) like -wallclock or -cputime, how time should be counted. Reason: on a very busy box, or when the box is set to standby overnight (e.g. my P4 with a damn loud fan which stands in my sleeping room (no place otherwhere)), shorter poly search runs might get affected too much (therefore the wish for a -cputime option). Otherwise - if you [i]want[/i] to count wallclock-time, there should be a -wallclock option.

[quote=Andi47;202211]I would suggest an option (flag to be specified in command line) like -wallclock or -cputime, how time should be counted. Reason: on a very busy box, or when the box is set to standby overnight (e.g. my P4 with a damn loud fan which stands in my sleeping room (no place otherwhere)), shorter poly search runs might get affected too much (therefore the wish for a -cputime option). Otherwise - if you [I]want[/I] to count wallclock-time, there should be a -wallclock option.[/quote]
i agree
i am in a similar situation
however i have noticed that hibernating messes up anything i am running on the GPU:smile:

jrk, the CPU poly selection uses wallclock time but the GPU poly selection uses CPU time. Not for any good reason, it was just because the time is sampled much more often there and I thought I needed the higher resolution.

Tom, you mentioned previously that the target E-value was overly conservative at very large sizes; could you tabulate more reasonable E-values and take a stab at lowering the target norms? There's no obvious relationship between the two, to answer a question you asked long ago, so anything we decide will be a SWAG. Lowering the target norm will also make stage 2 much faster.

[QUOTE=jasonp;202261]jrk, the CPU poly selection uses wallclock time but the GPU poly selection uses CPU time. Not for any good reason, it was just because the time is sampled much more often there and I thought I needed the higher resolution.[/QUOTE]
[strike]The code says otherwise. Stage 1 CPU uses get_cpu_time() whereas Stage 1 GPU uses time(). This is the case in the latest SVN revision, at least.[/strike]

Is there actually a way to measure GPU time?

[QUOTE=jasonp;202261]Tom, you mentioned previously that the target E-value was overly conservative at very large sizes; could you tabulate more reasonable E-values and take a stab at lowering the target norms? There's no obvious relationship between the two, to answer a question you asked long ago, so anything we decide will be a SWAG. Lowering the target norm will also make stage 2 much faster.[/QUOTE]
For what it's worth, if you want another data point, I made this slight adjustment to the parameters for a c172 search I recently did, and it at least did not break anything.

[code]
{170, 5.00E+025, 1.58E+024, [color=red]1.50E-013[/color]},
{175, [color=red]2.00E+026[/color], [color=red]9.00E+024[/color], [color=red]6.40E-014[/color]},[/code]

Msieve printed over a million polys during a 2.5 week run on 8800 GTS, with these parameters, suggesting that they can probably be safely changed even more

The original parameters are, for comparison:

[code]
/* contributed by Tom Womack */
{170, 5.00E+025, 1.58E+024, [color=red]1.20E-013[/color]},
/* contributed by Serge Batalov */
{175, [color=red]3.00E+026[/color], [color=red]1.00E+025[/color], [color=red]6.00E-014[/color]},
[/code]

[QUOTE=jrk;202353][strike]The code says otherwise. Stage 1 CPU uses get_cpu_time() whereas Stage 1 GPU uses time(). This is the case in the latest SVN revision, at least.[/strike][/QUOTE]
Nevermind this, please. Stage 1 GPU uses time() for the per-coeff deadline, but still uses get_cpu_time() for the overall deadline. My apologies.

After modifying the Makefile I now have msieve compiling for CUDA on a system I have access to. If I pick a 125 digit number for example it says time limit set to 7.29 hours. Is that still the value calculated from using the CPU or is that the new suggested time for GPU poly selection?

Will it still exit automatically after that time?

Jeff.

The same time limits are used for the CPU and GPU versions; whether it will finish on schedule depends on how much work gets poured into stage 2 over the course of the search (if stage 1 finds a hit, stage 2 is not interruptible while the optimization takes place). For relatively small problems like yours it should be close the specified limit, as stage 2 will never run for very long.