Where can I get a copy of the most stable Linux binary, or source if not possible?

Found CUDALucas1.2 source code tar, unzipped, got it compiled and working (that was a challenge) but now it says

device_number >= device_count ... exiting

like monst. Unlike monst though, I just reinstalled CUDA to 4.0, and it's still not working. Do I have old source code?

Hi ,Dubslow
[QUOTE=Dubslow;271739]Found CUDALucas1.2 source code tar, unzipped, got it compiled and working (that was a challenge) but now it says

device_number >= device_count ... exiting

like monst. Unlike monst though, I just reinstalled CUDA to 4.0, and it's still not working. Do I have old source code?[/QUOTE]
I guess you use old CUDA library. Please check Makefile.

[QUOTE=apsen;271217]Double checking 28258603 I'm getting different results with 1.2b and 1.3alpha_eoc.[/QUOTE]

Does anyone else have problem with incorrect results when using 1.3alpha_eoc?

[QUOTE=Dubslow;271739]...I just reinstalled CUDA to 4.0, and it's still not working. Do I have old source code?[/QUOTE]

CudaLucas1.2 should work on Linux64 with Cuda 3.2

[QUOTE=apsen;272289]Does anyone else have problem with incorrect results when using 1.3alpha_eoc?[/QUOTE]

I've added 27482573 to the list of successful double checks with it, but it's disturbing that you're seeing incorrect results. You're on a GTX 465, right? I keep having to put off working on CUDALucas, but the first thing to try would be to back out my change to the block size in the transpose kernels...

My results with 1.3alpha_eoc so far:
[code]
M( 25038353 )C, 0x4ba4dda319e35665, n = 2097152, CUDALucas v1.3alpha_eoc
M( 25056947 )C, 0x25502fd0e6d506d2, n = 2097152, CUDALucas v1.3alpha_eoc
M( 27482573 )C, 0xfc2af4775ec0247c, n = 2097152, CUDALucas v1.3alpha_eoc
[/code]

ps. I'm about six days away from finishing a doublecheck on 101001001 as well... very curious about that one :)

[QUOTE=Ethan (EO);272660]I've added 27482573 to the list of successful double checks with it, but it's disturbing that you're seeing incorrect results. You're on a GTX 465, right?[/QUOTE]

Right GTX 465.

I'm getting consistently different results between the two versions right from first 10000 iterations.

I haven't been able to get the code out of the repository as I had no time to look into why the client is not able to connect to it. If you'd like to post the code I may compile it and run comparison with 1.2b. Or just post binaries.

I have fetched Ethan (EO)'s bzr sources and started playing with it... And I've actually put my modifications up at github: [URL]https://github.com/ah42/CUDALucas[/URL]

I'm only working with my GTX460 at the moment, but I've already realized almost a 9% improvement under linux with some of the changes I've made.

I think there's still a lot of room for improvement in the kernels outside of what goes on in CUFFT. Profiling shows we're only spending 55-65% of the GPU time in CUFFT (more with higher exponents: M216091 is only 50% in CUFFT)

[QUOTE=apsen;272289]Does anyone else have problem with incorrect results when using 1.3alpha_eoc?[/QUOTE]

You wouldn't by any chance be on 64-bit linux? 1.3alpha seems to have stripped out a bit too much "unneeded stuff" and while the internal state is correct, printbits() gives the wrong output on 64-bit linux. I've been working on trying to fix this and figure out how for a couple days now in my git. It's because sizeof(unsigned long) changes on 64-bit unices, but not on windows.

I know the internal state is correct because I get the correct results for known primes (a.k.a. residue == 0). However I'm getting 0xffffffffblahblah for non-prime residues. I have a locally working fix, but I'm [I]positive[/I] that it's not the [I]right[/I] fix.

[QUOTE=aaronhaviland;273244]You wouldn't by any chance be on 64-bit linux?[/QUOTE]

Win64

Woohoo -- I just got a matching residue from 1.3alpha_eoc w/ msft's previous double check of 101001001 :D Unfortunately, the manual results submission form is acting strangely for me, so it's not visible on primenet yet. But this is a great result for the reliability of GPUs for this task!

Ethan