How much ecm should i do???
 

how much ecm should i do before switching to msieve
i keep on finding that i have spent more time on ecm than msieve takes
this is with numbers between 85 and 100 digits that i am having this problem
i have did 35 digit ecm on a 97 digit number a couple of days ago and that turned out to be way too much
could people post what rules they would use for switching to msieve
i have searched the forum but found nothing
thanks

[QUOTE=themaster;125965]how much ecm should i do before switching to msieve
i keep on finding that i have spent more time on ecm than msieve takes
this is with numbers between 85 and 100 digits that i am having this problem
i have did 35 digit ecm on a 97 digit number a couple of days ago and that turned out to be way too much
could people post what rules they would use for switching to msieve
i have searched the forum but found nothing
thanks[/QUOTE]
Let the msieve binary do the ECM for you; it already has tuning that guarantees you won't spend too much time before switching to QS.

i do the ecm on multiple pcs so that is not possible
i looked at msieves code and found
[code]
static uint32 choose_max_digits(msieve_obj *obj, uint32 bits) {
/* choose the amount of work to do. We want the
chosen digit level to be a small fraction of what
QS and NFS would need */
uint32 max_digits = 15;
if (bits == 0)
return 0;
if (obj->flags & MSIEVE_FLAG_DEEP_ECM) {
if (bits > 220) {
if (bits < 280)
max_digits = 20;
else if (bits < 320)
max_digits = 25;
else if (bits < 360)
max_digits = 30;
else if (bits < 400)
max_digits = 35;
else
max_digits = 40;
}
}
return max_digits;
}
[/code]
this seems a bit low to me

[QUOTE=themaster;125976]i do the ecm on multiple pcs so that is not possible
i looked at msieves code and found
[code]
static uint32 choose_max_digits(msieve_obj *obj, uint32 bits) {
/* choose the amount of work to do. We want the
chosen digit level to be a small fraction of what
QS and NFS would need */
uint32 max_digits = 15;
if (bits == 0)
return 0;
if (obj->flags & MSIEVE_FLAG_DEEP_ECM) {
if (bits > 220) {
if (bits < 280)
max_digits = 20;
else if (bits < 320)
max_digits = 25;
else if (bits < 360)
max_digits = 30;
else if (bits < 400)
max_digits = 35;
else
max_digits = 40;
}
}
return max_digits;
}
[/code]
this seems a bit low to me[/QUOTE]

hmmmm... that's roughly what I am doing manually. (I am ECM'ing on multiple PCs too.)

Additionally I do some p-1 and p+1.

it probably is just that i am used to doing a lot more

I've heard a 2/7 rule of thumb mentioned before. For a 97-digit number, that would mean stopping ECM at 25 or 30 digits if you're trying to optimize computer time.

before this i used 1/3 but it often stretched

[QUOTE=jbristow;125994]I've heard a 2/7 rule of thumb mentioned before. For a 97-digit number, that would mean stopping ECM at 25 or 30 digits if you're trying to optimize computer time.[/QUOTE]AFAIK, the rulle of thumb is 2/9 for SNFS and 1/3 for GNFS. This latter rule is consistent with the 3/2 relative difficulties ROT for NFS.

Within reason, it doesn't much matter. If the factorization is non-trivial other considerations come into play, such as memory usage and communication overheads.

Paul

[quote=xilman;126007]AFAIK, the rulle of thumb is 2/9 for SNFS and 1/3 for GNFS. This latter rule is consistent with the 3/2 relative difficulties ROT for NFS.

Within reason, it doesn't much matter. If the factorization is non-trivial other considerations come into play, such as memory usage and communication overheads.

Paul[/quote]
what would u use for QS

[QUOTE=themaster;126039]what would u use for QS[/QUOTE]As I said, it doesn't much matter. QS is only competitive below 100 digits or thereabouts. I'd probably go to around 30 digits or so.


Paul

thanks
this should speed me up quite a bit so i can find more 100 digit RHPs

x86_64 ECM changes the weighting in this situation
 

On 64-bit machines, ECM runs over three times as fast it does in 32-bit, due to the GMP library's use of 64-bit*64-bit multiplication and 128-bit by 64-bit division (IIRC -- I haven't looked at the GMP assembler routines in a couple of years). This changes the weighting a bit, if you're lucky enough to have this problem.

So for x86_64-compiled ECM binaries, you can add 5 digits to your level of ECM cleanout.

what r the disadvantages of going to 64bit
i have a Athalon 64 3800+ running 32-bit Vista Ultimate(never bother getting Ultimate it is twice as slow as the home versions)
is it worth me upgrading to 64bit

[QUOTE=henryzz;126142]what r the disadvantages of going to 64bit
i have a Athalon 64 3800+ running 32-bit Vista Ultimate(never bother getting Ultimate it is twice as slow as the home versions)
is it worth me upgrading to 64bit[/QUOTE]

Are you referring to GMP-ECM or Windows?

windows

64-bit XP Pro has few advantages over 32-bit, and some disadvantages. Some applications will run faster, a few will run more slowly, and most will see no difference. You'll be able to see more than 3.6G of RAM with the 64-bit version.

64-bit versions of Windows lack antivirus software and certain other things, although I have heard that this situation is improving.

As for the sort of programs we on this forum love to heat our processors (and homes) with, it will only benefit those programs with configure/make options that take advantage of the double-wide registers and other goodies. I run 32-bit XP pro and 64-bit Centos 5.1 (Red-Hat Enterprise clone), and here are my observations:
[LIST][*]Pari-gp: No appreciable difference, but I don't use it for anything heavy[*]gnfs-lasieveXXXX (ggnfs): 15% slower on 64-bit, even when compiled for x86_64.[*]GMP-ECM: Around 3.2 times faster in 64-bit -- a huge advantage[*]msieve: No appreciable difference, but I haven't run any explicit tests, and I would bet that the square-root phase would run much faster in 64-bit.[/LIST]
This is a dual-boot situation, so processors, RAM, and motherboard are the same for both 32-bit XP and 64-bit Linux.

I might get 64-bit XP, but I prefer to do my compiling (and other, actual remunerative, non integer-obsessed work) in Linux, so there seems little point to it. You won't see the advantage unless you're prepared to recompile things for the 64-bit x86_64 instruction set, and things like lattice sievers are all about the cache and not about raw multiplication speed.

[quote=FactorEyes;126169]64-bit XP Pro has few advantages over 32-bit, and some disadvantages. Some applications will run faster, a few will run more slowly, and most will see no difference. You'll be able to see more than 3.6G of RAM with the 64-bit version.

64-bit versions of Windows lack antivirus software and certain other things, although I have heard that this situation is improving.

As for the sort of programs we on this forum love to heat our processors (and homes) with, it will only benefit those programs with configure/make options that take advantage of the double-wide registers and other goodies. I run 32-bit XP pro and 64-bit Centos 5.1 (Red-Hat Enterprise clone), and here are my observations:[LIST][*]Pari-gp: No appreciable difference, but I don't use it for anything heavy[*]gnfs-lasieveXXXX (ggnfs): 15% slower on 64-bit, even when compiled for x86_64.[*]GMP-ECM: Around 3.2 times faster in 64-bit -- a huge advantage[*]msieve: No appreciable difference, but I haven't run any explicit tests, and I would bet that the square-root phase would run much faster in 64-bit.[/LIST]This is a dual-boot situation, so processors, RAM, and motherboard are the same for both 32-bit XP and 64-bit Linux.

I might get 64-bit XP, but I prefer to do my compiling (and other, actual remunerative, non integer-obsessed work) in Linux, so there seems little point to it. You won't see the advantage unless you're prepared to recompile things for the 64-bit x86_64 instruction set, and things like lattice sievers are all about the cache and not about raw multiplication speed.[/quote]
thanks

[QUOTE=FactorEyes;126169]
gnfs-lasieveXXXX (ggnfs): 15% slower on 64-bit, even when compiled for x86_64.[/QUOTE]

I find that [i]very[/i] surprising. When I added the amd-64 assembler routines to the Franke lattice siever the speed increased markedly. I don't have measurements to hand but seem to remember it doubling or more.

Admittedly, my experience isn't primarliy with ggnfs, but ggnfs is (I believe) built around the Franke siever.

Paul

[QUOTE=xilman;126176]I find that [i]very[/i] surprising. When I added the amd-64 assembler routines to the Franke lattice siever the speed increased markedly. I don't have measurements to hand but seem to remember it doubling or more.

Admittedly, my experience isn't primarliy with ggnfs, but ggnfs is (I believe) built around the Franke siever.

Paul[/QUOTE]This is encouraging.

I compiled ggnfs a few days ago with the x86_64 target, but I have not dug into the code to see what the build process does with this information. It could be that my system lacks the right assembler executable, or something like that.

Is your source the CWI code?

This might be worth a new thread on what to expect from a 64-bit system, and how to ensure you're getting it.

[QUOTE=xilman;126176]I find that [i]very[/i] surprising. When I added the amd-64 assembler routines to the Franke lattice siever the speed increased markedly. [/QUOTE]

Are these AMD64 assembler routines publicly available? The version of the lattice sieve in GGNFS doesn't include them. As such, the 32-bit version, which has assembler routines, is about 15% faster than the 64-bit version without assembler support.

Greg

[QUOTE=frmky;126200]Are these AMD64 assembler routines publicly available? The version of the lattice sieve in GGNFS doesn't include them. As such, the 32-bit version, which has assembler routines, is about 15% faster than the 64-bit version without assembler support.
[/QUOTE]
I vaguely remember Joppe Bos was working on integrating the 64-bit asm into the GGNFS lattice siever.

Worth looking into
 

If this is easy or moderately difficult, someone would have done it already, but this might merit a trip through the 32-bit lattice siever code to see where the asm is called, and see if any means of souping it up comes to mind.

:ouch1::yucky:

I know enough about the Franke code to fear it, so I can only guess at the likelihood that this would be fruitful. Plus, you have to RTFM for the instructions that will do the best job, which, with these new jackrabbit processors, is not as clear as it used to be.

[QUOTE=frmky;126200]Are these AMD64 assembler routines publicly available? The version of the lattice sieve in GGNFS doesn't include them. As such, the 32-bit version, which has assembler routines, is about 15% faster than the 64-bit version without assembler support.

Greg[/QUOTE]To the best of my knowledge, they are distributed under GPL like the rest of Franke's code.

A tarball is attached.


Paul

[QUOTE=xilman;126221]To the best of my knowledge, they are distributed under GPL like the rest of Franke's code.

A tarball is attached.


Paul[/QUOTE]

You wouldn't happen to have the rest of Franke's code would you? I tried to integrate this into the GGNFS source. I got a binary, but it segfaults in the scheduling code. There have been extensive changes in the code in GGNFS and no doubt this is the source of the problem. I'm hoping I can get a working binary from the original source, but I can't seem to find it anywhere online.

Thanks,
Greg

[QUOTE=frmky;126315]You wouldn't happen to have the rest of Franke's code would you? [/QUOTE]
Never mind ... I was able to get it elsewhere. Starting from that, I was able to create working 64-bit Linux binaries. They are posted in the M2376 thread.

Greg

[QUOTE=frmky;126575]Never mind ... I was able to get it elsewhere. Starting from that, I was able to create working 64-bit Linux binaries. They are posted in the M2376 thread.

Greg[/QUOTE]

Those are a big huge 100% turbo help. My Opteron-based siever and space heater runs 65% more efficiently now.

Thanks!