[QUOTE=Prime95;261073]I'm going to be away from my computer for several weeks. Two questions:

1) What is the best way to restart the program after a reboot due to a power failure? Windows 7 machine.

2) How do I make sure it doesn't retest exponents on a restart? I have several exponents queued up using a worktodo.bat file. However, on a reboot it will retest the exponent on the first line of the worktodo.bat file.[/QUOTE]I think you forgot:

3) How long will I be away and unable to deal with a new prime?

Paul

[QUOTE=xilman;261094]I think you forgot:

3) How long will I be away and unable to deal with a new prime?

Paul[/QUOTE]

I wouldn't worry there - even when staying at Antarctica and a Tsunami just hitting the eastcoast of North-America he'd find a way to deal with a new prime :smile:

Isn't an automated email sent out to past prime verifiers when a new prime is found even when George isn't here. I think that functionality has been added at somepoint since the last prime.

If anyone will be able to compile CUDALucas for windows again, please provide the VS project file for the compilation.

I have been having an issue with CUDALucas crashing after completing an exponent that was resumed from a checkpoint file.


It crashes during the final call to the input(...) function

[QUOTE=Karl M Johnson;262089]If anyone will be able to compile CUDALucas for windows again, please provide the VS project file for the compilation.[/QUOTE]

I didn't do VS project but I used included makefile to compile Win x64 version. Anyway, in addition to toolkit you would also need SDK samples.

Attached is CUDALucas 1.2 executable compiled with CUDA 4.0.

Missing lib
 

Needed for mfaktc Win64bit build: lib in CUDA 4.0 version 1.7

Like I suspected, CUDALucas compiled with 4.0 toolkit is slower than the one, compiled with 3.2 tk(even though it's 32 bit).

It's 8.5 ms/iter vs. 8.84 ms/iter.

I dont recommend anyone using 4.0 unless the app has inline ptx asm optimizations.

[QUOTE=Karl M Johnson;266356]Like I suspected, CUDALucas compiled with 4.0 toolkit is slower than the one, compiled with 3.2 tk(even though it's 32 bit).

It's 8.5 ms/iter vs. 8.84 ms/iter.

I dont recommend anyone using 4.0 unless the app has inline ptx asm optimizations.[/QUOTE]
For some CUDA apps 32 bit might be [I]faster[/I].

It's not about whether it's 32 or 64 bits, it's about toolkits used.
But I agree, I've seen 32 bit apps being slower than their 64 bit variants, rarely.
Almost always it was because the application was not optimized.

I dont know what Nvidia changed, but I've saw overall-slowdown of many CUDA apps for : 3.1 -> 3.2 change(this one was driver related, but 3.2 could not be used on old drivers) and 3.2 -> 4.0(this time it's purely the toolkit which causes the slowdown).

Oh, and I'm on a 64 bit OS:smile:

The reason I used 32 bit binaries of CUDALucas 1.2 compiled with 3.2 TK is because there were no 64 bit binaries! I grabbed em from post 431, ty Alex.

[QUOTE=Karl M Johnson;266360]It's not about whether it's 32 or 64 bits, it's about toolkits used.
But I agree, I've seen 32 bit apps being slower than their 64 bit variants, rarely.
Almost always it was because the application was not optimized.

I dont know what Nvidia changed, but I've saw overall-slowdown of many CUDA apps for : 3.1 -> 3.2 change(this one was driver related, but 3.2 could not be used on old drivers) and 3.2 -> 4.0(this time it's purely the toolkit which causes the slowdown).

Oh, and I'm on a 64 bit OS:smile:

The reason I used 32 bit binaries of CUDALucas 1.2 compiled with 3.2 TK is because there were no 64 bit binaries! I grabbed em from post 431, ty Alex.[/QUOTE]
I would like to see a comparison of two 32 bit (or 64 bit) versions compiled with the 3.2 and the 4.0 SDK. I have seen 32 bit CUDA apps running 10% [I]faster[/I] than their 64 bit counterparts (both running on the same 64 bit Linux box).