64-bit gnfs-lasieve*

[joral]

Well, I can get a build to go all the way through, but I'm running into some sort of segmentation fault in the asm code. At this point I'm wondering if I should cut down on the amount of the asm code I'm trying to include.

[R. Gerbicz]

bsquared, I'm also interested in the Franke's code, can you send me?

[henryzz]

could someone post a link to the 64-bit linux binaries please?

[bsquared]

Originally Posted by joral

Well, I can get a build to go all the way through, but I'm running into some sort of segmentation fault in the asm code. At this point I'm wondering if I should cut down on the amount of the asm code I'm trying to include.

Hmm, maybe I didn't send you the working source, I thought I did. There were a couple simple edits that were made to stop the segfaulting, then the compiled binaries worked on opteron and core2 64 bit linux systems. Or are you trying it out on a different system?

[bsquared]

Originally Posted by henryzz

could someone post a link to the 64-bit linux binaries please?

http://www.mersenneforum.org/showpos...6&postcount=23

[bsquared]

Originally Posted by R. Gerbicz

bsquared, I'm also interested in the Franke's code, can you send me?

Check your PM.

Until this code makes it into the SVN trunk, maybe someone could host it somewhere? This passing around hand to hand business is inefficient. Jeff?

[henryzz]

Originally Posted by bsquared

Check your PM.

Until this code makes it into the SVN trunk, maybe someone could host it somewhere? This passing around hand to hand business is inefficient. Jeff?

would it be possible to have it as a branch of the SVN(apologies if that isnt possible i dont have much knowledge in that area)?

[joral]

Originally Posted by bsquared

Hmm, maybe I didn't send you the working source, I thought I did. There were a couple simple edits that were made to stop the segfaulting, then the compiled binaries worked on opteron and core2 64 bit linux systems. Or are you trying it out on a different system?

It's a normal Athlon64x2, not opteron.

Do you recall what kind of edits they were?

Edited to add:

I can find some place to host it this evening, if no one else jumps up by then. Do we know if the rest of the asm code is faster than what is already in SVN, or has no one seen it worthwhile to find out?

[bsquared]

Originally Posted by joral

It's a normal Athlon64x2, not opteron.

Do you recall what kind of edits they were?

Edited to add:

I can find some place to host it this evening, if no one else jumps up by then. Do we know if the rest of the asm code is faster than what is already in SVN, or has no one seen it worthwhile to find out?

I edited it to work with my non-standard gmp build (changing <gmp.h> to "gmp.h" and copying over the header... not sure why I didn't just use -I.

Also added some header files that gcc complained about. Batalov helped a lot with this. Check to see if your gcc build is throwing up warnings involving alloca or memset.

I haven't had opprotunity to check, but I think it should work on athlon64 as well as opteron. The folder with all the asm code in it is named athlon64, after all :)

[edit]
If you do host it, would it be too much work to change things back to work with a normal gmp build (change back all the "gmp.h" to <gmp.h>)? That was stupid of me to do in the first place... sorry.

[joral]

Originally Posted by bsquared

I edited it to work with my non-standard gmp build (changing <gmp.h> to "gmp.h" and copying over the header... not sure why I didn't just use -I.

Also added some header files that gcc complained about. Batalov helped a lot with this. Check to see if your gcc build is throwing up warnings involving alloca or memset.

I haven't had opprotunity to check, but I think it should work on athlon64 as well as opteron. The folder with all the asm code in it is named athlon64, after all :)

[edit]
If you do host it, would it be too much work to change things back to work with a normal gmp build (change back all the "gmp.h" to <gmp.h>)? That was stupid of me to do in the first place... sorry.

There was one memcpy warning, but that was in a different part of the code.

Where it looks like I'm having trouble now comes down to a problem with the lasched() function. The memory pointer to ri that it has keeps getting set to something quite weird.

Then, in the lasched1() asm function, the following asm

movl (%rdi),%r14d

is called with %rdi = 0xffffffffa96b7d80 (which is the value of the ri pointer.)

and the app segfaults.

[Batalov]

Here are the new experimental Opteron/Phenom 64-bit assembly-optimized binaries for 12e..15e
http://www.boo.net/~jasonp/lasieveLinuxAsm64.zip
(hosted by Jason)

These binaries and are based on Greg/Paul/K/F source and include the patches from GGNFS (including resume option, and infinite loop prevention).

Need more tests from you guys. Sieve any project as usual and please report any cases of the message
SCHED_PATHOLOGY k=... excess=...

More details here:
http://mersenneforum.org/showthread....934#post168934