Before you start...

[henryzz]

I am assuming that nfs@home will then be doing 14e tasks again after the merge?

[jasonp]

The GPU code running on a hot card is about 5x faster than one core of a hot PC, so the situation here is not remotely equivalent to trial factoring.

I'll repeat that RSA896 is a better idea to start off; Paul's group is selecting a polynomial with less-than-BOINC-scale resources, we can compare what we find against what they've found, and it will give us a chance to get used to what 'the real thing' will feel like.

To start stage 1 of polynomial selection, we'll need a single number: the 'stage 1 norm' that is the cutoff in the (weighted) size of the resulting polynomial coefficients. I'll explain more about how to find it later. There's no need to rush to get started now. If a big job takes years, waiting a week to get more things in place won't make a difference at all.

[yoyo]

Hello,

regarding the Boinc questions above.

It is not necessarily needed to modify the source code if you want to run it in Boinc. With the wrapper approach you can also run binaries (without having the source code) in Boinc. In yoyo@home Boinc project I do it e.g. with the evolution@home and distributed.net clients. The only requirement is, that the binary which you want to run has one (or a fixed number of) input files and one (or a fixed number of) output files.

But even if you want to boincify the source that is not much complicated. You just have to add a boinc start/end, a different mode to open input-/result file, something to tell Boinc the checkpointing and the progress.

A requirement (but not a must) towards the binary is to save checkpoints during the run from which it automatic can continue and to indicate the percentage which was done.

The more important questions (at least for me who doesn't has much knowledge about msieve and sieving) are:
- Who can provide thousands of input files which should run in Boinc?
- What should happen with all the results?
- How to validate the results? In Boinc the concept is to run a input file multiple times and check if 2 hosts computed the same result. Don't know if with msieve 2 computer are generating the exact same result for the same input file.
- How big is an input-/output file?
- How long will a msieve task run?

yoyo

[debrouxl]

BTW, there's already a BOINC version of msieve in Tom Ritter's factoring framework: https://github.com/GDSSecurity/cloud-and-control (announced by jasonp at http://www.mersenneforum.org/showthread.php?t=16114 ), complete with documentation on the BOINC-ification process, and some scripts / programs for generating WUs

But for integration into upstream, it would need an update. The diffs (one per file) against msieve 1.49 amount to ~16 KB (only), but they're not directly usable, from a quick glance (by someone who doesn't know the msieve code base well, and isn't supposed to have time in the next few weeks, before RSALS is shut down):
* in multiple files, the hunks aiming at reducing the trace production on stdout are a bit quick & dirty, they simply comment out the printf statements;
* the demo.c hunks would need an update after the very recent rework of msieve's argument handling code, and improvement to replace system("rm -rf ...") by a more portable equivalent, such as remove().

[lorgix]

RSA896 is now in sieving, right?

Is msieve ready for finding a poly for RSA1024?

[firejuggler]

AFAIK, msieve can't, becuse the number of relation needed is too high.

[lorgix]

Originally Posted by firejuggler

AFAIK, msieve can't, becuse the number of relation needed is too high.

I was thinking about poly select only.
Sooner or later there will be software that can handle the later steps. But poly select comes first anyway, and I think that part is ready for it.

[henryzz]

Originally Posted by lorgix

I was thinking about poly select only.
Sooner or later there will be software that can handle the later steps. But poly select comes first anyway, and I think that part is ready for it.

Poly selection is improved too often to spend a large amount of effort like that.

[lorgix]

Originally Posted by henryzz

Poly selection is improved too often to spend a large amount of effort like that.

Are you saying we should wait for poly select to be made faster?

[henryzz]

Originally Posted by lorgix

Are you saying we should wait for poly select to be made faster?

Considering that we aren't going to be able to use the poly any time soon yes. Not just faster but it should find better polys.

[jasonp]

To my knowledge, RSA896 is not currently sieving.

In order for Msieve poly selection to be practical for RSA1024, even with a large number of GPUs, the code will need some changes to handle the larger polynomial coefficients that are involved.

But more important, with degree 6 polynomials we need the top 4 algebraic coefficients to be small, and the poly selection algorithms we know about can only optimize the top 3 coefficients. That means we have to rely on luck to get the 4th one small enough, and it makes the search take exponentially longer. Ideally we need to be able to adapt the algorithms involved to force that 4th coefficient to be better, even if it means greatly increasing the search time for any one candidate.