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

[flashjh]

CUDALucas 2.03 x64 Source with updated makefile.win

[flashjh]

CUDALucas 2.03 x64

This is for GTX 680 with CUDA 4.2 | sm_30. If someone has a 680, can you test this with other versions and let me know how it works?

Thanks

[ET_]

AFAICT, there is no diffrence in the math section between 2.01 and 2.03 (I'm on Linux)

Am I correct?

Luigi

[Redarm]

Originally Posted by flashjh

CUDALucas 2.03 x64

This is for GTX 680 with CUDA 4.2 | sm_30. If someone has a 680, can you test this with other versions and let me know how it works?

Thanks

 
Continuing work from a partial result of M65xxxxxx fft length = 3670016 iteration = 280001
Iteration 290000 M( 65434657 )C, 0x32166eaa07042500, n = 3670016, CUDALucas v2.03 err = 0.1731 (1:07 real, 6.7
623 ms/iter, ETA 122:21:37)

[Dubslow]

Originally Posted by ET_

AFAICT, there is no diffrence in the math section between 2.01 and 2.03 (I'm on Linux)

Am I correct?

Luigi

Yep
I'm so glad this works now.

[kjaget]

Originally Posted by flashjh

I still need /Tp for now

For this you have a choice. Either keep the /Tp in (no harm I can see) or you need to declare every function prototype called from cu files as extern "C" blah().

I think what's going on is this. .cu files end up being compiled as C++ files on Windows. Thus, when it sees a prototype it expects it to use C++ linkage & name mangling. But when you build .c files, MSVC assumes it's just regular C so the mangling and so on doesn't happen. That's why the missing function names at link time look like C++ mangled names - that's what they're being translated to in the .cu file.

But the short version is I don't see any harm in just building everything as C++ code using /Tp

[LaurV]

Originally Posted by Dubslow

Yep
I'm so glad this works now.

Have anyone created a worktodo file with more then two exponents (lines)?
Something fake, which will finish very fast, like:

Test=N/A,150001,69,1
Test=N/A,150003,69,1
Test=N/A,150007,69,1
Test=N/A,150009,69,1

or simpler

Test=150001
Test=150003
Test=150007
Test=150009

Then run cl_2.03 on it?
After SECOND exponent finishes (17-20 seconds on gtx580), the file will look like

Test=150003Test=150007Test=150009

And a parsing error is issued. Something close to:

Warning: ignoring line 1: "Test=N/A,150003,69,1Test=N/A,150007,69,1Test=N/A,150009,69,1" in "worktodo_1.txt". Reason: invalid format.
No valid assignment found.

It seems like the CR/LF characters are lost...

Looking summarily into the source of parse.c, around the lines 473, 480, it does not seem that variable called "line" contains the "\n" character. One "\n" should be printed in "%s\n" format specifier... Or not?**

edit: and by the way, another 2 good residues with v2.02, making the score 4 to 0.

Processing result: M( 26299261 )C, 0x7a7f02229ab66f20, n = 1474560, CUDALucas v2.02 
LL test successfully completes double-check of M26299261 
Processing result: M( 26331001 )C, 0xfc7b1d44c505c281, n = 1474560, CUDALucas v2.02 
LL test successfully completes double-check of M26331001

I switched to 2.03 in this evening (half hour ago, another two expos ETA ~18h).

---------------
***(edit 2: I saw the ini file only has LF at the end of the lines, it occurs to me that \n in windows is in fact \r\n, that is a 0x0D followed by a 0x0A, or CR followed by LF. In linux seems like a LF is enough. If I deleted all 0x0A characters from the worktodo, using programmer's notepad (PN2), it then worked ok. This could be a real problem, as all worktodo files generated by gpu272 or primenet have CR+LF as eol terminators, and I don't see myself doing manual replacement all the time. PN2 and Eclipse have autoreplace, "set eol as LF only", but still need open the file and then save the file by hand... Now this made me curious how mfaktc deal with this, because there I never had any problem of such)

[Batalov]

Oh, the usual CR/LF/\r\n thing. (Note that Mac's end-of-line is simply \r.)
A portable code(r) needs to know these things.
It's a good thing that this code is not widely used. ::
Makes it a good candidate for sandbox coding. ::razz again::

Seriously though! This project seems to have outgrown the ad hoc posting-and-tons-of-spaggetti-code stage. Pick a respectable admin (possibly the original author), start a git/svn repository, start real life tracking of bugs, rollbacks, code reviews. Just a suggestion. Of course you can continue doing what you are doing.

[ET_]

M( 26200729 )C, 0x02c4c8ac57869fae, n = 1572864, CUDALucas v2.01
M( 26227489 )C, 0x8e52cc33256a5bca, n = 1572864, CUDALucas v2.01

Both confirmed.

Luigi

[flashjh]

Originally Posted by kjaget

For this you have a choice. Either keep the /Tp in (no harm I can see) or you need to declare every function prototype called from cu files as extern "C" blah().

I think what's going on is this. .cu files end up being compiled as C++ files on Windows. Thus, when it sees a prototype it expects it to use C++ linkage & name mangling. But when you build .c files, MSVC assumes it's just regular C so the mangling and so on doesn't happen. That's why the missing function names at link time look like C++ mangled names - that's what they're being translated to in the .cu file.

But the short version is I don't see any harm in just building everything as C++ code using /Tp

I plan to fix it when I get more time

Originally Posted by LaurV

Have anyone created a worktodo file with more then two exponents (lines)?
Something fake, which will finish very fast, like:

Test=N/A,150001,69,1
Test=N/A,150003,69,1
Test=N/A,150007,69,1
Test=N/A,150009,69,1

or simpler

Test=150001
Test=150003
Test=150007
Test=150009

Then run cl_2.03 on it?
After SECOND exponent finishes (17-20 seconds on gtx580), the file will look like

Test=150003Test=150007Test=150009

And a parsing error is issued. Something close to:

Warning: ignoring line 1: "Test=N/A,150003,69,1Test=N/A,150007,69,1Test=N/A,150009,69,1" in "worktodo_1.txt". Reason: invalid format.
No valid assignment found.

It seems like the CR/LF characters are lost...

Looking summarily into the source of parse.c, around the lines 473, 480, it does not seem that variable called "line" contains the "\n" character. One "\n" should be printed in "%s\n" format specifier... Or not?**

You are correct. The \n is needed for Windows, but Linux will compile it correctly also. In Linux the file will contain a single LF to indicate the newline; under windows, it will contain a CRLF.

Attached updated 2.03 to correct error - tested, but please test again ;)

Originally Posted by Batalov

...

Seriously though! This project seems to have outgrown the ad hoc posting-and-tons-of-spaggetti-code stage. Pick a respectable admin (possibly the original author), start a git/svn repository, start real life tracking of bugs, rollbacks, code reviews. Just a suggestion. Of course you can continue doing what you are doing.

I agree. msft, dubslow, myself are all possible. I plan to be around for a while.

@Dubslow and msft, any ideas?

Attached file is .zip. Inside are all source files (with updated parse.c) and all CUDA builds. I used .7z (7-zip) because it compresses a lot better for the binaries. In the future, I'll use that if the files are too big (or until we move to a repository).

Included CUDALucas x64 binaries:

CUDA 3.2 | sm_13
CUDA 4.0 | sm_20
CUDA 4.0 | sm_21
CUDA 4.1 | sm_21
CUDA 4.2 | sm_30

[Dubslow]

Actually, '\n' as a format specifier guarantees that the proper line endings will be filled in by the compiler. gcc will literally do just '\n', whereas MSVC will use a literal '\r\n' whenever a '\n' is specified in print statements. The problem is, when you parse_worktodo_value() in line 432, one of the arguments is a pointer to a copy of the line; however, I changed that copy going from 2.02 to 2.03 to not include the '\n' because I wanted to be able to print the line-copy in warning messages without the newline, e.g. line 365

ignoring line %u: \"%s\" in \"%s\".

With a newline in the string, that message would look bad, so I removed it (lines 206-207) without realizing it was used in clear_assignment(). The solution is in fact to add a '\n' as LaurV suggested, and the compilers will take care of any platform specific line endings. (Furthermore, when a line is read in that ends with '\r\n', it is automatically converted to simply '\n' in memory, so any and all code only needs to bother with '\n's. Also Batalov, hasn't Apple switched from the '\r' a while ago? Edit: The Wiki article below says they switched after Mac OS 9.)

flash's fix is correct, however, considering my n00bosity, a SourceForge would be a good idea. msft, do you have any particular cares about setting one up?

http://en.wikipedia.org/wiki/Newline

Originally Posted by Wikipedia/Newline

The C programming language provides the escape sequences '\n' (newline) and '\r' (carriage return). However, these are not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two things:

2. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly.

Edit: I forgot the other big thread there

Regarding the C/C++ thing, kjaget is exactly right, and that's why #ifdef linux then all the functions are declared that way; the url in the comments of that section has basically the same explanation. I didn't realize that it only worked on Windows because it thought it was C++. Are there any dangers in our code where a C++ compiler would miscompile valid C? I know they're not entirely compatible, and that some incompatibilities exist, and therefore we should watch out for them.