GNFS poly search time limit oddity

[Andi47]

Yesterday, I switched my PC to standby overnight (it is standing in my sleeping room, and the fan is damn loud) approx. 5-10 minutes after msieve had started to search for a polynomial for a c108. When I switched it on again to day in the morning, msieve thought that poly search had exceeded the time limit and stopped searching.

So msieve seems to measure "calender time" and not cpu-time. Is there a possibility to determine, how long msieve is running on the cpu - and take this value to tell if the time limit has been exceeded?

[jasonp]

I don't know a portable way for C programs to measure CPU time and not calendar time. Linux has the means to get that information, but IIRC it's not filled in by the OS. If the CPU actually throttles to a low clock speed, even that won't be sufficient.

[akruppa]

The clock() function is in C89, C99 and Posix. Most Unix-like OSs should have it. It usually has pretty poor resolution (1/100 second on Linux I think...) but that's not an issue for measuring how long the poly selection ran so far. However, clock() does not exist on Windows afaik, so in GMP-ECM we use GetProcessTimes() if _WIN32 is defined.

Alex

[fivemack]

I believe on linux that clock() measures something like CPU time; though this is only because I recall that it gave useless results in multi-threaded programs.

http://msdn.microsoft.com/en-us/libr...37(VS.85).aspx looks as if it might be helpful for Win32, though it was introduced in Win2000 so isn't portable back to Win98.

My machines never sleep so the issue doesn't arise for me

[jasonp]

Would the time fields from getrusage() be better than what clock() returns?

[akruppa]

getrusage() usually has better resolution (often microsecond), so it's nice for timing smallish functions. You can also tell it whether you want to include cpu time used by child processes. For getting the time in hours that the poly selection ran, clock() should easily suffice, though. As for machines with variable clock rate... I suppose you could read the cpu cycle counter, if available. But that will be seriously thrown off if the machine is busy and other processes get cycles.

Alex

[R.D. Silverman]

Originally Posted by jasonp

I don't know a portable way for C programs to measure CPU time and not calendar time. Linux has the means to get that information, but IIRC it's not filled in by the OS. If the CPU actually throttles to a low clock speed, even that won't be sufficient.

Isn't get_rusage(....) available???

[jasonp]

getrusage appears to be POSIX but google shows lots of people needing a windows equivalent. It's also not in the MinGW headers, so I suspect it's not in the win32 collection

[Brian Gladman]

Jason, I can let you have a version of get_rusage() that I use on Windows if this would help.

As Alex says the appropriate Windows call is GetProcessTimes() and I use this to emulate get_rusage().

Brian Gladman

[R.D. Silverman]

Originally Posted by jasonp

getrusage appears to be POSIX but google shows lots of people needing a windows equivalent. It's also not in the MinGW headers, so I suspect it's not in the win32 collection

I can supply high resolution CPU timing for Windows.

[jasonp]

As mentioned, for this particular application there isn't a need for high-resolution timing, only for a moderately accurate measure of CPU time. There are certainly alternatives that are available, so I can build whatever I need.

PS: Alex, according to the clock() man page the timing resolution is supposed to be fixed at 1 microsecond, but going through the headers the value of a clock_t is a 32-bit integer on 32-bit linux. That means the clock count would wrap around every 72 minutes, which isn't enough for a long-duration event like the limit on poly selection.