"You can find it in the place where nvidia installed the developer's kit. Just go to the root of the installation and search for files named cufft...IIRC,..."

Thanks! I downloaded and installed that, but have not dug into it yet. The roadmap is appreciated.

[QUOTE=Christenson;274692]Right...you need cufft_32_xx_xx.dll. You can find it in the place where nvidia installed the developer's kit. Just go to the root of the installation and search for files named cufft...IIRC, it installs either in C:\nvidia or C:\program files\nvidia....the simple thing to do is to copy it into the directory with CUDALucas, the more complicated way is to ensure that that binary directory is on your path when you call CUDALucas....either with a set command in your batch file, or by adding it to the global PATH environment variable, or possibly be the settings for your desktop icon.[/QUOTE]
In Linux I've found that regardless of PATH, it doesn't find the requisite file, and in fact looks for a file with a slightly different name. Ask The Judger about the fix, as he's who I copied: Creating a subdirectory (in mfaktc or cudalucas) with a properly named (what mfaktc/cudalucas look for) shortcut to the file (as named by nVidia). Their best bet is to just copy the dll's into the proper directory.

[QUOTE=Dubslow;274710]In Linux I've found that regardless of PATH, it doesn't find the requisite file, and in fact looks for a file with a slightly different name.[/QUOTE]
LD_LIBRARY_PATH

Recommended reading: man ldconfig :smile:

[QUOTE=bcp19;274652]I downloaded the 32 bit version of CudaLucas and unzipped it, but when I try to run it I get an error "cufft32_32_16.dll not found". I have tried searching both the forum and the web for this but have had no success. Can anyone point me in the right direction?[/QUOTE]

Got it. It's located in C:\Program Files (x86)\NVIDIA GPU Computing Toolkit\CUDA\v4.0\bin .
You can also download it from [url]http://filesmelt.com/downloader/cufft32_40_17.dll[/url] . (I didn't want to bother zipping it to attach it.)

the _40_ indicates it's from CUDA 4.0. If that doesn't work, I can get you a 3.2 _32_ version, though I'm pretty sure the 4.0 version will work.

[QUOTE=Ralf Recker;274713]LD_LIBRARY_PATH

Recommended reading: man ldconfig :smile:[/QUOTE]

The nVidia instructions indicate adding certain folders to both PATH and LD_LIBRARY_PATH, which I did, to no avail. That trick I mentioned includes setting LD_LIBRARY_PATH=mfaktc/cufft . Like I said, ask The Judger for details.
Edit2: [url]http://www.mersenneforum.org/showpost.php?p=270670&postcount=1175[/url]
That tarball has an extra directory 'lib' with the library files that it can never find. I used a variant of this hack to get mfaktc (and later CUDALucas) running in Linux.

Edit: I am forced to admit that after reading [url]http://linux.die.net/man/8/ldconfig[/url] I am no closer to understanding what that command does. :P Could you try explaining it please?

[QUOTE=Dubslow;274715]The nVidia instructions indicate adding certain folders to both PATH and LD_LIBRARY_PATH, which I did, to no avail. That trick I mentioned includes setting LD_LIBRARY_PATH=mfaktc/cufft . Like I said, ask The Judger for details.
Edit2: [url]http://www.mersenneforum.org/showpost.php?p=270670&postcount=1175[/url]
That tarball has an extra directory 'lib' with the library files that it can never find. I used a variant of this hack to get mfaktc (and later CUDALucas) running in Linux.

Edit: I am forced to admit that after reading [url]http://linux.die.net/man/8/ldconfig[/url] I am no closer to understanding what that command does. :P Could you try explaining it please?[/QUOTE]

OK, here goes:
Windows instructions break on Linux...Big surprise! :smile:

ldconfig sets up Shared Object files (.so -- analogous to windows DLL) so they can be found when called for at run-time. I don't remember having to fool with this with mfaktc on my Linux box, so I think it must have been handled as part of the instructions (make install). The medium-level GT440 is saturated by one core, so I haven't tried CUDALucas on Linux.

But copying SO's/DLLs into the directory with the executable is fine with me...it's not like they take up huge amounts of very cheap disk space or anything...

Hi,

.so files (shared object) on Linux are similar to DLLs on Windows.[LIST][*][I]ldconfig[/I] is a utility which parses (usually) [I]/etc/ld.so.conf*[/I] to create some kind of database in which directory which .so can be found. OK, this does a little bit more but for now this should be enough. With [I]ldconfig[/I] you setup your .so files [B]systemwide[/B][*][I]LD_LIBRARY_PATH[/I] is a environment variable which contains a list of directories which should [B]additionally[/B] included when searching .so files. This is only for the current process and (if LD_LIBRARY_PATH is exported) to the child processes of the current process.[/LIST]
You can use [I]ldd[/I] to check which libraries are used. (OK, it is possible to fool the output of ldd but lets assume we don't want to fool ldd.)

Using this [url]http://www.mersenneforum.org/mfaktc/mfaktc-0.17.linux64.tar.gz[/url] on my Linux box:
[CODE]o@Lysithea:~/foo/mfaktc-0.17> ldd mfaktc.exe
linux-vdso.so.1 => (0x00007fff53ac4000)
[COLOR="Red"]libcudart.so.3 => not found[/COLOR]
libc.so.6 => /lib64/libc.so.6 (0x00007ff7d8ef3000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff7d8be9000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff7d8992000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff7d9253000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff7d877c000)
[/CODE]

setting the variable LD_LIBRARY_PATH temperary ONLY for this command
[CODE]o@Lysithea:~/foo/mfaktc-0.17> LD_LIBRARY_PATH=./lib/ ldd mfaktc.exe
...
[COLOR="Red"]libcudart.so.3 => ./lib/libcudart.so.3 (0x00007f6264d23000)[/COLOR]
...
[/CODE]

setting the variable for the current shell and all their child processes
[CODE]o@Lysithea:~/foo/mfaktc-0.17> export LD_LIBRARY_PATH="./lib:${LD_LIBRARY_PATH}"
o@Lysithea:~/foo/mfaktc-0.17> ldd mfaktc.exe
...
[COLOR="Red"]libcudart.so.3 => ./lib/libcudart.so.3 (0x00007f3a716d6000)[/COLOR]
...
[/CODE]

Oliver

Thanks for the help, I did finally get cufft32_32_16.dll by installing the 3.2 toolkit and there are no more errors.

Hey guys, is this how mfaktc is supposed to work? When I TF a number in the 59,xxx,xxx range from 70 to 71, it takes me about 6 hours or so on my card. I read that it is more efficient to take a number from a low bit to a high bit, so I tried TF'ing 306,xxx,xxx from 65 up to 71. I saw that it did this in stages, from 65 up to 69 first and then 69 to 70 and then 70 to 71. When it did 70 to 71, I thought it would take me longer then the 6 hours it took me to take the 59M number from 70 to 71, but this only took me 1.5 hours. Is this how it is supposed to work?

[QUOTE=rysk;274986]Hey guys, is this how mfaktc is supposed to work? When I TF a number in the 59,xxx,xxx range from 70 to 71, it takes me about 6 hours or so on my card. I read that it is more efficient to take a number from a low bit to a high bit, so I tried TF'ing 306,xxx,xxx from 65 up to 71. I saw that it did this in stages, from 65 up to 69 first and then 69 to 70 and then 70 to 71. When it did 70 to 71, I thought it would take me longer then the 6 hours it took me to take the 59M number from 70 to 71, but this only took me 1.5 hours. Is this how it is supposed to work?[/QUOTE]

Yes. All factors of the Mersenne number Mp - hence all candidates for trial factorisation - are of form 2kp+1. The larger the exponent, the greater the gap between successive candidates, and the fewer candidates there are at any single bit level.

thanks!