CUDALucas (a.k.a. MaclucasFFTW/CUDA 2.3/CUFFTW)

[flashjh]

Originally Posted by Dubslow

Good idea. I'm not sure how to check if a file exists in C, but a quick Google ought to solve that.

Yich... part of the inifile is that, like I said, it includes a lot of ancillary information besides configuration. I'll have to think about it. (And it'd put improving FFT selection on hold.)

Yeah, I know it's too much :) In fact, the only reason to have the program check is just to let the user know it's missing.

[Dubslow]

Sorry about taking so long with this, we wound up going out for ice cream (and getting my bike fixed).

Originally Posted by flashjh

1) The MAKEFILE.WIN you created worked except I can't remove '/Tp'. Without that the compiler didn't understand 'timezone':

 
timeval.c(31) : warning C4115: 'timezone' : named type definition in parentheses
timeval.c(32) : error C2055: expected formal parameter list, not a type list make: *** [timeval.x64.obj] Error 2

I think that's a a result of the "hacked from original purpose" nature of the code. Just point any sort of letters/variable name after the '*' and it should compile fine without /Tp.

(That's a function definition; after the list of arguments, there's a {} indicating what the function does. With function declarations, after the list of args, there's only a semicolon, like in parse.h. Declarations are so that the compiler can check that a function is used correctly without having to know what it does. In a definition however, you need to have names for all the arguments, so that you can actually define what the function does. For whatever reason when that code was initially put into mfaktc, the second argument became useless, but it's still a compiler error to not name it.)

Originally Posted by flashjh

2) I was able to remove all the requested extern statements from CUDALucas.cu

In that case, you should be able to remove the "extern"s entirely from parse.h.

Originally Posted by flashjh

3) CUDALucas.cu line 352 needed (float)

I didn't have helium, but I think hydrogen will do the trick ;)

Originally Posted by flashjh

4) Parse.c line 386 needed '}' to close the if statement (this one took me a while to find)

Whoops, sorry

Originally Posted by flashjh

5) I was able to remove the "-I$(CUDA)/include" line in the MAKEFILE.WIN

6) I was able to compile 3.2 | sm_13 ( I was using the wrong environment for 3.2 before... that's what happens with no )

I also made one change to 'cleaner' in Makefile.win; you can do "cleaner: clean \n rules" instead of "cleaner: \n rules \n make clean" to get the same effect.

Originally Posted by flashjh

I didn't change any of your linux definitions and the statements seem good for compiling 'out of the box' for Win and Linux. You can take the included files and see if you can compile. If not, pass everything back to me for another run.

It compiled fine for me. I'll reattach the trifling changes I've made.

Originally Posted by flashjh

Have you tested everything on Linux? Since you made the changes, can you pass along a sample worktodo.txt file with good and bad so I can ensure Windows is capable of everything your Linux can do ;)

I haven't actually done serious testing of what is and isn't rejected by the worktodo parser. To help rectify that, I've made an example worktodo.txt, as well as some cosmetic modifications to parse.c (and CuLu.cu). Additionally, the parser now recognizes '#' as a comment character. You'll need to recompile to get the '#'; otherwise this newer version should be functionally equivalent to the binaries you made above.

bill@Gravemind:~/CUDALucas/test∰∂ cat worktodo.txt 
//Test=25723987
#Test=25723987,69,1       /* Will not parse correctly */
//Test=25723987,69
//Test=N/A,25723987,69
//Test=N/A,25723987      /* Will not parse correctly */
#Test=N/A,25723987,69,1
#Test=N/A,25723987,      /* Will parse correctly because of extra comma */

Uncomment one line at a time to test them. Currently, if there are less than two commas, it assumes there is no AID, that the first number is the exponent, and ignores the rest. Otherwise, the first field is treated as AID, and second is exponent. Better parsing ideas, anyone?

[LaurV]

Originally Posted by Dubslow

In the future, how should the code handle not being able to read the ini file but getting options through the command line?

That was my argument, if you read carefully my post, I only complained the fact that the messages do not reflect the real parameters (given in the command line or wherever else). You won't request the stupid user like me to go through all your sources before using the program, or to carry a luggage full of files with him, like the guy with the watch/laptop/mobile phone (I know the joke in my time when the electronic watches appeared, but now it should be said about the smartphones) carrying two big suitcases with batteries with him.

So, the code should simple handle this situation by printing the right argument.

Saying or not the fact that it "uses default" or "overwritten by cmd line args", this is optional and not very important.

edit: or handle like flash suggested, that is better (I did not read all the posts to the end of the thread when I replied).

[Dubslow]

Originally Posted by LaurV

That was my argument, if you read carefully my post, I only complained the fact that the messages do not reflect the real parameters (given in the command line or wherever else). You won't request the stupid user like me to go through all your sources before using the program, or to carry a luggage full of files with him, like the guy with the watch/laptop/mobile phone (I know the joke in my time when the electronic watches appeared, but now it should be said about the smartphones) carrying two big suitcases with batteries with him.

So, the code should simple handle this situation by printing the right argument. Saying or not the fact that "uses default" or "overwritten by cmd line args" is optional, and not very important.

I was intending that the .ini file would be packed with the binaries, just like mfaktc or Prime95.

The problem is, I'd like to type "CUDALucas" and just have the program do work without telling me what it's doing.

What I could do is move the ini-read after the command line, and only read options not passed as commands, and then print warnings only if the command wasn't passed and if the ini file didn't have it. If I did that, would you still want me to print the options used?

Edit: Okay, sure. I'll do my proposition because it seems to me it's more useful in a wider variety of situations than just checking if it exists.

Originally Posted by LaurV

Related to typing "cudalucas" and the program runs, well, you don't imagine that I have typed all those things... I am even more lazy than you, I only typed "cu" and pressed enter. My file is called "cu.bat" .

It calls another two batches, one for each card, and the maintenance (add exponents to each line, delete the old lines) is done by a third batch, which is reading the exponents from an worktodo list. I used this solution because sometime I only work with one card (the second is busy with daily work), and at that time there was no "worktodo file" option either. Later I got used with it and kept it. Bad habits die hard. The idea is that you can make a batch file if you want only to type "cudalucas" and everything runs. Don't need changing the program for it. Even with maintenance by hand, there is only a matter of few copy/paste you do only when you get new assignments. Of course, this way you have to be careful and delete the lines for the jobs already completed (I used to do that by hand in the past too).

See, I had the same problem, except in my rush to be useful, I decided to modify CUDALucas (with mfaktc code) to do it without bothering with bash, etc.

@flash: Wait before compiling my most recent post, I'm going to redo fopen as well as redo parameter-reading.

[LaurV]

I don't mind if you print or not the options. I only mind them be correct, if you choose to print them.

Related to typing "cudalucas" and the program runs, well, you don't imagine that I have typed all those things... I am even more lazy than you, I only typed "cu" and pressed enter. My file is called "cu.bat" .

It calls another two batches, one for each card, and the maintenance (add exponents to each line, delete the old lines) is done by a third batch, which is reading the exponents from an worktodo list. I used this solution because sometime I only work with one card (the second is busy with daily work), and at that time there was no "worktodo file" option either. Later I got used with it and kept it. Bad habits die hard. The idea is that you can make a batch file if you want only to type "cudalucas" and everything runs. Don't need changing the program for it. Even with maintenance by hand, there is only a matter of few copy/paste you do only when you get new assignments. Of course, this way you have to be careful and delete the lines for the jobs already completed (I used to do that by hand in the past too).

edit: for confirmation :P added the photo. the choice lines make a pause of 10 seconds between the launches of CL (I forgot about them, hehe). If you launch two CL immediately one after the other you will get an error sometime (discussed on the forum in the past too).

ps: (saw the PM, man ye never go to bed? I will catch ye when ye will be sleeping... :P)

[Dubslow]

I asked LaurV, but he had no preference.

If a user does not enter a workfile, and the ini file does not exist or its WorkFile option is bad, should CUDALucas silently assume worktodo.txt, or print a warning like "no work file specified, assuming worktodo.txt"? If I don't see an answer, I think I'll default to no warning.

[flashjh]

Originally Posted by Dubslow

I asked LaurV, but he had no preference.

If a user does not enter a workfile, and the ini file does not exist or its WorkFile option is bad, should CUDALucas silently assume worktodo.txt, or print a warning like "no work file specified, assuming worktodo.txt"? If I don't see an answer, I think I'll default to no warning.

I think no warning, just like mfakt* for standardization

[flashjh]

@Dubslow: I finally got around to testing. I know you're making some changes again, but there is something wrong. I think it's with the Windows worktodo.txt parser.

CuLu works fine if I use the command line switches with exponent, but any combination with no exponent on the command line causes a force closes every time (with a good Test or DoubleCheck line).

I'll look at it while you rework the program. Maybe you'll find/fix it?

[Dubslow]

Originally Posted by flashjh

@Dubslow: I finally got around to testing. I know you're making some changes again, but there is something wrong. I think it's with the Windows worktodo.txt parser.

CuLu works fine if I use the command line switches with exponent, but any combination with no exponent on the command line causes a force closes every time (with a good Test or DoubleCheck line).

I'll look at it while you rework the program. Maybe you'll find/fix it?

Does it throw any errors? What does it print? What if you try passing the workfile name on the command line? (Is it able to read the ini file?)

[flashjh]

Originally Posted by Dubslow

Does it throw any errors? What does it print?

No, no errors. Just closes: see attached picture. (All CUDA versions do the same thing & this is the same build you posted with the ini file)

What if you try passing the workfile name on the command line? (Is it able to read the ini file?)

 
start E:\CUDA\CUDALucas2.02.cuda3.2.sm_13.x64.exe -d 1 worktodo.txt

Still force closes.

(Is it able to read the ini file?)

When I supply the exponent, the ini file seems to parse fine because I can make changes in the ini file and they affect execution. Also, command line switches do override the ini file (though I still have not tried all possible combinations).

[break]

Since my 580s are TFing, I got access to a friends GT 430 for CUDALucas testing - 153 hours for one DC (at least it's better than nothing)

[Dubslow]

Originally Posted by flashjh

No, no errors. Just closes: see attached picture. (All CUDA versions do the same thing & this is the same build you posted with the ini file)

 
start E:\CUDA\CUDALucas2.02.cuda3.2.sm_13.x64.exe -d 1 worktodo.txt

Still force closes.



When I supply the exponent, the ini file seems to parse fine because I can make changes in the ini file and they affect execution. Also, command line switches do override the ini file (though I still have not tried all possible combinations).

Wow. I am shocked and confused. Does the command line stay open, so that we can at least see the last thing printed? I have literally no idea where to start. (Keep in mind that the large majority of this code used in mfaktc.) If so, I'll throw in some prints statements so we can see how far it gets before crashing. I've just added the "debug" option to Makefile.win.

LaurV, can you reproduce this?

Edit: Please find attached my most recent copy, which now includes various debugging statements. Run "make debug", or if that doesn't work, just add the definitions manually and run "make". (Edit2: Be sure to clean out the object files before running "make debug".)

Other changes: Added -i, -v options which are PrintDeviceInfo and version respectively. -d no longer automatically prints info for any device. -v (at the moment) prints CUDALucas 2.02, though I wonder if that shouldn't be upped to 2.03.
I've also modified parse.c so that every fopen() call isn't riddled with ifdefs. Instead I've defined _fopen() with the solitary #ifdef for its body.
(Argument parsing is now a separate function in CUDALucas.cu to clean up main() a little bit, but there is no functional difference.)