Cooperative Agreement or Capitalist Takeover? You decide!
 

Mersenne@home ([URL]http://mersenneathome.net/[/URL]) is a BOINC-based project that appears to be duplicating GIMPS effort in finding Mersenne primes. The BOINC base means he has accumulated thousands of computers already.

Rather than posting criticisms on the forums ([URL]http://mersenneathome.net/forum_index.php[/URL]) over there, let's collectively brainstorm here:

(1) to write a document that carefully explains the advantages of cooperation and disadvantages of competition, and

(2) think up ways in which a BOINC-based project can cooperate with GIMPS.

Please, don't go over there and post criticisms based on the idea that GIMPS is superior to their project. Instead of convincing [URL="http://mersenneathome.net/show_user.php?userid=1"]Sebastian M. Bobrecki[/URL], the founder and leader, to cooperate with us, you might just antagonize him and give him the idea that it'd be good to leap-frog over the ranges GIMPS is currently testing systematically.

If Mersenne@home starts testing higher exponents without cooperating with us, there could be all sorts of trouble. So, please don't provoke their leader. Right now, their duplication in effort may offend your optimization sensibilities, but it isn't actually causing any damage. Let's leave it that way until we have a document that politely and carefully explains the joys of cooperation.

I'm curious, he must have known about GIMPS before starting; GIMPS is everywhere associated with the ~10 most recent discoveries. (13?) He has GIMPS' discoveries listed as known on his site. Therefore when he started the project, he must have had some sort of reason. Does anybody know what that is?

I do like the idea btw.

[QUOTE=Dubslow;300400]I'm curious, he must have known about GIMPS before starting; GIMPS is everywhere associated with the ~10 most recent discoveries. (13?) He has GIMPS' discoveries listed as known on his site. Therefore when he started the project, he must have had some sort of reason. Does anybody know what that is? [/QUOTE]My guesses:

(1) He's probably fond of math and started just for the fun of developing a BOINC client to do something mathematical, possibly before knowing about GIMPS

(2) Even after learning about GIMPS, he seems to think that his project can contribute something unique: the distribution of found factors can help predict locations of future Mersenne primes. Though we may think we have proof that this cannot possibly turn out to be useful, let's not provoke possible stubbornness by denigrating this. Possibly, this was just a rationalization for keeping his project going in spite of GIMPS's presence.

(3) Let's not underestimate the advantage that the BOINC platform gives Mersenne@home in terms of the ease with which it can recruit thousands of participants. I think he has about 1/10th of GIMPS's throughput now (without discounting their THz for their inefficiencies), but the BOINCness will make it possible to surpass GIMPS (even if [strike]H@h[/strike] M@h is less efficient) more readily than some of you might imagine.

- - -

If we can convince Mersenne@home to collaborate with GIMPS, that could bring a sharp jump in our rate of progress.

I've always thought we were missing out by not having a BOINC client. So now that someone's beaten us to that, let's carefully explore ways of cooperation. How to synchronize data, for instance. And let's not always presume that Mersenne@home necessarily has to convert to doing things GIMPS's way in all matters.

(There's also the tricky business of EFF prize money ...)

[QUOTE=cheesehead;300401]
(3) Let's not underestimate the advantage that the BOINC platform gives Mersenne@home in terms of the ease with which it can recruit thousands of participants. I think he has about 1/10th of GIMPS's throughput now (without discounting their THz for their inefficiencies), but the BOINCness will make it possible to surpass GIMPS (even if H@h is less efficient) more readily than some of you might imagine.[/QUOTE]
Yes, previously it had caused me to wonder if we should port GIMPS to BOINC, or at least make it BOINC-able...

Now that I've looked over the Mersenne@home site so more, it seems that the only type of work it has done so far is trial division, with no L-L work queued or accomplished yet.

My comments above about trouble caused by leapfrogging GIMPS were intended to refer to L-L only.

M@h's TF work seems to go up to exponent 9,999,999,999, compared to GIMPS's limit of 999,999,999.

They used to do [i]only[/i] LL work, but some time back, Batalov talked them into TF (which they took a bit too close to heart).

Cheesehead, I note your latest remark about LL work not currently being done by this competitor, only TF work (and Dubslow's information that they used to do LL work too). But let's assume that this new site does actually start some serious competition with GIMPS in the future if they are not already doing that now. I'd like to advocate that we welcome their initiative and let them carry on. I take this position because I don't see it as competition at all.

I'd like to quote something you told me almost 5 years ago when, as a new participant, I asked a question in the "Information & Answers" section of this forum.

[QUOTE=Brian-E;110858][...]It is not really independently verifiable that what GIMPS now calls M39 is the 39th Mersenne because no-one can run tens of thousands of computers for another 10 years.[...][/QUOTE]

[QUOTE=cheesehead;111164][...]Yes, it [U]is[/U] possible to do independent verification! What GIMPS did in its first 10 years takes less and less time to independently verify as computers get faster. The CPU I now use is over 40 times as fast as the one I used my first five years in GIMPS. I (or anyone else) could re-perform my first five years of GIMPS work in a couple of months now, using independently-written software if so wished to serve as verification.[...][/QUOTE]

If a serious organisation manages to achieve some serious independent checking/verification of the results which GIMPS has already determined, that will significantly improve the confidence in those results.

I appreciate that the "competitor" could also be LL-testing larger Mersenne numbers which the GIMPS members have yet to tackle. Then GIMPS is the independent verifier. I don't have any problem with this. Do other people perceive this as a problem?

Obviously the independent working does not need to extend to ignoring factors of Mersenne numbers found by the other group, since a known factor does not need independent discovery. I hope an amicable agreement can be sought between the two parties so that the competing databases can share known factors between each other.

[QUOTE=Brian-E;300416]
If a serious organisation manages to achieve some serious independent checking/verification of the results which GIMPS has already determined, that will significantly improve the confidence in those results.[/QUOTE]Yes, at least to some folks who might doubt GIMPS's perfection in this particular regard.

[quote]I appreciate that the "competitor" could also be LL-testing larger Mersenne numbers which the GIMPS members have yet to tackle. Then GIMPS is the independent verifier. I don't have any problem with this. Do other people perceive this as a problem?[/quote]Some will.

I think it could be problematic if not set up cooperatively. If we have, in effect if not intention, the possibility of "poaching" by each project on the other project's assignments-in-progress, that's trouble. I think that the document I propose _must_ address the method by which we might avoid overlapping assignments. (Remember that there's EFF prize money at stake, too.)

[quote]Obviously the independent working does not need to extend to ignoring factors of Mersenne numbers found by the other group, since a known factor does not need independent discovery. I hope an amicable agreement can be sought between the two parties so that the competing databases can share known factors between each other.[/quote]Yes.

IIRC I saw a comment by Bobrecki to the effect that (what follows is my paraphrase!) he was reluctant to use any information about factors that GIMPS already has in its database, because that sort of "belonged" to GIMPS. This is something else that our "Mersenne Project Cooperation" document must address.

(There! I came up with a title! But other nominations are still in order.)

[QUOTE=Dubslow;300412]They used to do [I]only[/I] LL work, but some time back, Batalov talked them into TF (which they took a bit too close to heart).[/QUOTE]Now I vaguely recall that (or maybe I'm just suggestible). Thanks for the reminder.

[QUOTE=cheesehead;300420]Yes, at least to some folks who might doubt GIMPS's perfection in this particular regard.

Some will.

I think it could be problematic if not set up cooperatively. If we have, in effect if not intention, the possibility of "poaching" by each project on the other project's assignments-in-progress, that's trouble. I think that the document I propose _must_ address the method by which we might avoid overlapping assignments. (Remember that there's EFF prize money at stake, too.)

Yes.

IIRC I saw a comment by Bobrecki to the effect that (what follows is my paraphrase!) he was reluctant to use any information about factors that GIMPS already has in its database, because that sort of "belonged" to GIMPS. This is something else that our "Mersenne Project Cooperation" document must address.

(There! I came up with a title! But other nominations are still in order.)[/QUOTE]
There's also the question of how "serious" they are. Considering how much ignorance they've shown with regards to TF, and then swinging to the complete opposite end of the spectrum, I'm not convinced that their program is good, unless we see some of the earlier LL results. I would love to be proven wrong.
[QUOTE=cheesehead;300420]"Mersenne Project Cooperation"
(There! I came up with a title! But other nominations are still in order.)
[/QUOTE]
Mersenne Prime Search Cooperation Agreement
[QUOTE=cheesehead;300421]Now I vaguely recall that (or maybe I'm just suggestible). Thanks for the reminder.[/QUOTE]
Let's just wait until that particular man himself comes online to verify our collective memories. :smile:

[QUOTE=Dubslow;300427]There's also the question of how "serious" they are.[/quote]Let's presume seriousness and sincerity. The BOINC platform makes it not-too-difficult to surpass GIMPS throughput, so politeness is in order.

[quote]Considering how much ignorance they've shown with regards to TF, and then swinging to the complete opposite end of the spectrum, I'm not convinced that their program is good,[/quote]Let's proceed with polite sincerity and education.

[quote]Mersenne Prime Search Cooperation Agreement[/quote]Better than mine! :-)

[quote]Let's just wait until that particular man himself comes online to verify our collective memories. :smile:[/QUOTE] :smile:

[QUOTE=cheesehead;300420]IIRC I saw a comment by Bobrecki to the effect that (what follows is my paraphrase!) he was reluctant to use any information about factors that GIMPS already has in its database, because that sort of "belonged" to GIMPS.[/QUOTE]

Using Will Edgington as the source and destination of factors should solve any concerns of ownership. Will covers all exponents, not just the prime ones of some currently feasible size.

Do we know for sure one way or another if George and/or Scott have already been in contact with BOINC heads?

It makes sense to me that the project leaders should be the primary point of discussions.

[QUOTE=petrw1;300461]Do we know for sure one way or another if George and/or Scott have already been in contact with BOINC heads?

It makes sense to me that the project leaders should be the primary point of discussions.[/QUOTE]


I did post in the forums once or twice that GIMPS would be happy to work cooperatively. I even pointed him to the web page that can access all of GIMPS TF data so that he doesn't reproduce our work. I've not had a positive response.

We can try a direct email approach instead. I'm not hopeful.

I agree with Cheesehead that a belligerent approach is disrespectful and unlikely to produce anything positive.

P.S. I just checked his website again. They now have a web page to download known factors. They appear to have loaded GIMPS' factoring data. I don't know if their database contains factors that GIMPS does not have.

[QUOTE=Brian-E;300416]<...snip...>
If a serious organisation manages to achieve some serious independent checking/verification of the results which GIMPS has already determined, that will significantly improve the confidence in those results
<...snip...>[/QUOTE]
I would really doubt that. I have read all the "good Samaritan"-style speeches posted before in the current thread, and I don't wanna go bitchy, but those are "serious independent bla bla" as I am the discoverer of the 50th known mersenne prime. They are noting but little thieves up to now, as there is no way they could re-discover all the [U][B]BIG[/B][/U] factors GIMPS has. The guys knew about gimps, they STARTED their project from a [U]copy of the GIMPS database [/U]containing all the factors already known to GIMPS. Well, I am not advocatind that someone should re-do all the TF for the exponents with already known factors, this would be stupid and a completely waste of resources. But at least a mention it should be done somewhere like "we keep our database sync-ed with GIMPS database". And if you start by "stealing" factors, then I won't trust you in keeping "independent" LL residues either...

I sent Bobrecki a PM. We'll see where that leads.

I think you won't get any feedback from him. Look at this post: [URL]http://mersenneathome.net/forum_thread.php?id=79[/URL]

and this one

[URL]http://mersenneathome.net/forum_thread.php?id=84[/URL]

Anyway, a thread was already started here a few years ago by Greg. [url]http://www.mersenneforum.org/showthread.php?t=14416[/url]
Carlos

This [URL="http://mersenneathome.net/forum_thread.php?id=6"]one thread[/URL] gives a good window in the project leader's mindset.

What's frightening is that people graze there because statistically that project gives more credit than other BOINC programs. (They don't care what the project does, just care for a bright shiny badgy thingies with some credit numbers.) I wonder if there exists any oversight from BOINC? Any guidelines for credit?

What if I wrote an implementation of BOINCified FRACTRAN VM, load it with Conway's prime generating [URL="http://en.wikipedia.org/wiki/FRACTRAN#Conway.27s_prime_algorithm"]program[/URL], and then registered it at BOINC and gave everyone [strike]twice[/strike] ten times (why not? let's live a little) more credit than any other project? Tomorrow I would be swimming in contributors!

[QUOTE=Batalov;300489]This [URL="http://mersenneathome.net/forum_thread.php?id=6"]one thread[/URL] gives a good window in the project leader's mindset.

What's frightening is that people graze there because statistically that project gives more credit than other BOINC programs. (They don't care what the project does, just care for a bright shiny badgy thingies with some credit numbers.) I wonder if there exists any oversight from BOINC? Any guidelines for credit?

What if I wrote an implementation of BOINCified FRACTRAN VM, load it with Conway's prime generating [URL="http://en.wikipedia.org/wiki/FRACTRAN#Conway.27s_prime_algorithm"]program[/URL], and then registered it at BOINC and gave everyone [strike]twice[/strike] ten times (why not? let's live a little) more credit than any other project? Tomorrow I would be swimming in contributors![/QUOTE]
Interesting. Would you be willing to try? :cmd:

It seems that if we make a concerted appeal to work together, especially with an official representative of GIMPS (i.e. George) that we can probably work something out. Let's see if George's PM gets anywhere. (Anybody speak Polish? :razz:)

If you ever wanted to be [strike]John Malkovich[/strike] R.D. Silverman for one hour (yes, really!), try going there and write on their forum. It's a PORTAL! Everyone's experience in [strike]John Malkovich[/strike] R.D. Silverman's head could be different, of course, but don't be surprized if "You can lead a horse to water but you can't make it drink" will come out at the end of your typing and then you will bang your head on the keyboard repeatedly. It is softer than the wall. I do recommend the keyboard.

Read hkbm's epic windmill struggle in that thread - and weep.
:soapbox:

(What I mean, with apologies to the real-life [strike]John Malkovich[/strike] R.D. Silverman, is that you will feel that an average mersenneforumer to their forum is like R.D. Silverman to an average mersenneforumer. And yes, prepare to be called a troll, too, over there on that forum.)

[QUOTE=Batalov;300489] I wonder if there exists any oversight from BOINC? Any guidelines for credit?
[/QUOTE]
Yes, there are loose guidelines, basically be comparable to SETI and Einstein. However, since BOINC is an open platform, following those guidelines is optional. The only penalty is that you probably won't get included in the list of projects displayed by default in the client.

My two pee worth
 

If [EMAIL="M@home"]M@home[/EMAIL] encourages participants less bitchy than some of us (:smile:)
then at least explain that George has the definitive(?) database re the state of the art.

David

George should make a Prime95 version for BOINC and give people lots of credits so we get thousands of new contributors :smile:

It would be like Newegg getting new customers by opening an ebay storefront. Seems utterly redundant... only it isn't!

[QUOTE=davieddy;300564] George has the definitive(?) database re the state of the art.[/QUOTE]
State of the art database? Well... I'll give him state of the art software :smile:
(Awesome software, hands down.)

[QUOTE=ATH;300574]George should make a Prime95 version for BOINC and give people lots of credits so we get thousands of new contributors :smile:[/QUOTE]
What are "they" on?

Re "credit", all I care about is maximizing the probability of finding another MP before I die.

Two new factors, but there are probably many others
 

They have two factors for small exponents on their webpage ([URL]http://mersenneathome.net/[/URL]), which are not in the GIMPS database:

[QUOTE]For [I]p=2100451[/I], [I]M(p)[/I] is divisible by [I]63923221582748657[/I]. The divisor found by:[LIST][*][URL="http://mersenneathome.net/show_user.php?userid=1727"][B]tng*[/B][/URL] from team [URL="http://mersenneathome.net/team_display.php?teamid=438"]Sicituradastra[/URL] and,[*][URL="http://mersenneathome.net/show_user.php?userid=2014"][B]vanos0512[/B][/URL] from team [URL="http://mersenneathome.net/team_display.php?teamid=1187"]BOINC@Taiwan[/URL][/LIST]For [I]p=2102207[/I], [I]M(p)[/I] is divisible by [I]124414352434216087[/I]. The divisor found by:
[LIST][*][URL="http://mersenneathome.net/show_user.php?userid=3017"][B]matszpk[/B][/URL] and,[*][URL="http://mersenneathome.net/show_user.php?userid=3939"][B]ximian[/B][/URL], both from team [URL="http://mersenneathome.net/team_display.php?teamid=97"]BOINC@Poland[/URL].[/LIST][/QUOTE]How to deal with that. Should we submit them to GIMPS or those factors are not "ours"?

[QUOTE=bloodIce;300608]They have two factors for small exponents on their webpage ([URL]http://mersenneathome.net/[/URL]), which are not in the GIMPS database:

How to deal with that. Should we submit them to GIMPS or those factors are not "ours"?[/QUOTE]Surely the appropriate way would be to send a polite request that they be added into the GIMPS database, with the offer for one of the GIMPS team to submit them if the finders' prefer, and that GIMPS credit be given to the finders.

Paul

Although, it takes about 0.00913267 GHz days to produce those factors (which are around 56-57 bits). I thought that the factorization to 2^60 was already done for those two exponents ([I]2102207[/I] and [I]2100451),[/I] but obviously not.

Well guys, I got this reply from Bobrecki:
----------------------------------------------------------------------------
Hello KEP,

Hello Sebastian
...
1. Is all candidates previously factored by GIMPs removed from testing?

The majority of it. But probably an insignificant percentage of the work may overlap.
----------------------------------------------------------------------------

It was given to me as a reply to a PM. I'm really not understanding if George should fail to get a reply if he sends a PM at the mersenneathome.net website, since I got reply in less than 8 hours. But as you can see it appears that all candidates previously factored by GIMPs has been removed from the database. However it appears that the remaining candidates were left for further TF without concern to previous TF depths. So maybe a consideration should be to convince Bobrecki to do 1 of following suggestions:

1. Give people the possibility of only doing TF of candidates for n>1G (All 3 phases)
2. Only to do TF that has not allready been done by GIMPs (thereby also consider current TF bit depth)
3. To coordinate the future workload with George or other people at GIMPs such that new discoveries are made by both projects. Discoveries wich can then be exported to one anothers different database.

Well that's my thoughts. I'm unfortunantly not able to speak Polish, but with todays recent findings of 2 unknown factors, it actually shows that there may be something to look for afterall, despite those different TF ranges has already been extensively tested previously.

Take care

Kenneth

[QUOTE=KEP;300617]...but with todays recent findings of 2 unknown factors, it actually shows that there may be something to look for afterall, despite those different TF ranges has already been extensively tested previously.[/QUOTE]

In Science, independent work is welcomed, not discouraged.

[QUOTE=bloodIce;300613]Although, it takes about 0.00913267 GHz days to produce those factors (which are around 56-57 bits). I thought that the factorization to 2^60 was already done for those two exponents ([I]2102207[/I] and [I]2100451),[/I] but obviously not.[/QUOTE]

We've found that if bad hardware is used, sometimes factors are missed, when they [I]should[/I] have been found. A few members of this forum like to go back to low exponents that have already been double-LLed and rerun P-1, if it was skipped or done poorly the first time; occasionally they find factors that [I]should[/I] have been found the first time, but due to hardware errors were not found. James Heinrich maintains a list of such exponents [URL="http://mersenne-aries.sili.net/p1missed.php"]here[/URL].

Neither trial factoring nor P-1 factoring are double checked by GIMPS, because the effort/value ratio is far too high compared to just running two LL tests. As far as I know, there isn't anybody that is redoing TF on very low exponents. The nature of the P-1 algorithm means that extending the bounds will find smaller factors anyways, whereas doing TF from 2^60 to 2^61 will not find any missed factors <2^60.

Addendum: [URL="http://www.mersenneforum.org/showthread.php?p=279251#post279251"]Here[/URL]'s some discussion of should-have-been-found-the-first-time P-1 factors.

[QUOTE=Dubslow;300630]We've found that if bad hardware is used, sometimes factors are missed, when they [I]should[/I] have been found.[/QUOTE]

We've also found that the software provided by GIMPS did not always find the factors which should have been found....

[QUOTE=chalsall;300632]We've also found that the software provided by GIMPS did not always find the factors which should have been found....[/QUOTE]

[strike]In the case of recent versions of the last 1-2 years, this isn't true, and we know this because they [i]are[/i] finding factors that were missed the first time. For the times when the exponents were first P-1ed, yes, we can't prove that the program was correct. (I still think hardware errors are a much more likely culprit.)[/strike]

Let me redo this ^. [url]http://mersenne-aries.sili.net/p1missed.php?s=x&o=a&p=200[/url]

There are exponents all the way up to 50M that have been missed. I'm pretty darn sure that since we [i]are[/i] finding these on a second run, the hardware must have been to blame the first time.

[QUOTE=Dubslow;300634]
There are exponents all the way up to 50M that have been missed. I'm pretty darn sure that since we [i]are[/i] finding these on a second run, the hardware must have been to blame the first time.[/QUOTE]

Some versions of prime95 had TF bugs -- especially in the early days.

[QUOTE=bloodIce;300608]They have two factors for small exponents on their webpage ([URL]http://mersenneathome.net/[/URL]), which are not in the GIMPS database:

How to deal with that. Should we submit them to GIMPS or those factors are not "ours"?[/QUOTE]

If you do not hear back from mersenneathome as to their preference, then please create a GIMPS account called MersenneAtHome and submit the factors under that user id.

No one "owns" Mersenne factors, but they should be submitted with the proper credit.

I've not yet heard back from Bobrecki either by PM or email.

[QUOTE=Dubslow;300630]We've found that if bad hardware is used, sometimes factors are missed, when they [I]should[/I] have been found.[/QUOTE]
[QUOTE=chalsall;300632]We've also found that the software provided by GIMPS did not always find the factors which should have been found....[/QUOTE]
[QUOTE=Prime95;300644]Some versions of prime95 had TF bugs -- especially in the early days.[/QUOTE]
Human error is also a likely cause of missed factors.

Errors likely happened in manipulating worktodo files, and TF results lines from early versions of the client did not show the starting level, so it was hard to pick up if a level was missed.

[QUOTE=Brian-E;300416]Cheesehead, I note your latest remark about LL work not currently being done by this competitor, only TF work
[/QUOTE]

Request for clarification. Are they doing LL work or not??? If so, whose
CODE are they using? If they are not doing LL work at all, then their
entire effort is inconsequential.

[QUOTE]
(and Dubslow's information that they used to do LL work too). But let's assume that this new site does actually start some serious competition with GIMPS in the future if they are not already doing that now. I'd like to advocate that we welcome their initiative and let them carry on. I take this position because I don't see it as competition at all.
[/QUOTE]

If they succeed in eliminating some candidates by finding small factors,
GIMPS should simply accept the information, double check that it is correct,
and say "thank you for saving us the trouble".



[QUOTE]
If a serious organisation manages to achieve some serious independent checking/verification of the results which GIMPS has already determined, that will significantly improve the confidence in those results.
[/QUOTE]

Their lack of knowledge and their babbling about predicting the next
prime based on historical data makes me doubt their competence. I
do not take them seriously. Do they have a knowledgeable
mathematician who is advising them? Based on what I have seen
they would not take such advice very seriously. They'd probably
accuse him/her of being a troll.

[QUOTE=bloodIce;300608]They have two factors for small exponents on their webpage ([URL]http://mersenneathome.net/[/URL]), which are not in the GIMPS database:

How to deal with that. Should we submit them to GIMPS or those factors are not "ours"?[/QUOTE]

They are [b][i]IRRELEVANT[/i][/b]. The numbers had already been fully
tested. Knowing some new small factors does not help at all.

Casablanca
 

This could be the start of a beautiful friendship
:smile:

[QUOTE=R.D. Silverman;300715]They are [b][i]IRRELEVANT[/i][/b]. The numbers had already been fully
tested. Knowing some new small factors does not help at all.[/QUOTE]

No, but PrimeNet is reporting false statements in the meantime, namely that "there are no factors below 2^62" is patently false.
[url]http://mersenne.org/report_exponent/?exp_lo=2100451[/url]
I hope that BloodIce does create a Mersenne@Home and does report the factors. As has been noted, it seems that some of GIMPS' earlier TF could use some double checking. (No, it does not advance the search for a large Mersenne prime, but I would argue that searching for factors is no less useless than searching for primes.)

As for LL, they used to do only LL but no TF; Batalov convinced them that TF was a good idea, but now they currently do not do LL. It is their plan to resume doing LL at some point.

Why? If you look through the first page, Mr. Bobrecki believes he can use patterns in the factors to find new primes. Now, we at this forum believe this to be folly (please don't repeat this statement RDS, we are all well aware of this and more than one of us has tried to convince Mr. Bobrecki of this). However, just because we believe it to be folly does [i]not[/i] mean that we cannot be polite to them and hopefully organize an agreement where GIMPS and Mersenne@Home do not do redundant work. Depending on how much firepower M@H collects, it would perhaps be reasonable that each exponent should have one test from each project.


@everyone, as opposed to just RDS:

One cause for concern is the speed and/or safety of their LL code. Prime95 has a lot of error catching code, as well as the infamous bit-shift.

Somewhat related to that, it would make sense to me, if this goes through (or even not), would be to add more data to each exponent that is checked. Instead of comparing the last 64 bits, we could for example compare the first 64 and the last 64 bits; or, since those data are co-located in the bit-shifted FFTs, perhaps what would make more sense is compare the last 64 bits as well as 64 bits smack in the middle of the residue. That way data from different parts of the FFT are compared.


Even if we agree to work together, somebody would need to find a way to cross-communicate between the two servers. Among other things, PrimeNet would definitely need that upgrade that's supposed to be coming soon, and even that might need to be souped up a bit. We would also need Mr. Bobrecki's agreement. Is anybody familiar with BOINC servers and/or specifically the way M@H's servers are set up? (Between frmky, chalsall and JH, if they are willing, we could probably get pretty far in getting cross server communication to work.)

[QUOTE=Dubslow;300725]We would also need Mr. Bobrecki's agreement. Is anybody familiar with BOINC servers and/or specifically the way M@H's servers are set up? (Between frmky, chalsall and JH, if they are willing, we could probably get pretty far in getting cross server communication to work.)[/QUOTE]

Trivial to set up.

But, as you say, it should only be implemented with the knowledge and agreement of Mr. Bobrecki and Mr. Woltman.

[QUOTE=chalsall;300734]Trivial to set up.

But, as you say, it should only be implemented with the knowledge and agreement of Mr. Bobrecki and Mr. Woltman.[/QUOTE]
I was thinking more on design terms. Should one or the other be a "master" and the other grab assignments from the first? Should PrimeNet just add BOINC functionality, and have the M@H address redirect to PrimeNet? ...et cetera. That would also need to be something Messrs. Woltman, Bobrecki, and any "implementators" agree on.

[QUOTE=Dubslow;300736]I was thinking more on design terms. Should one or the other be a "master" and the other grab assignments from the first? Should PrimeNet just add BOINC functionality, and have the M@H address redirect to PrimeNet? ...et cetera. That would also need to be something Messrs. Woltman, Bobrecki, and any "implementators" agree on.[/QUOTE]
If we go down the road of working together with M@H beyond only the most trivial level, that is beyond sharing known factors, then suddenly the entire operation becomes only as good as its weaker participant. In practical terms, that probably means a huge sacrifice of credibility by GIMPS. M@H, a new initiative with dubious ideas as indicated by Dr. Silverman, should not be allowed to contribute to the same database as the long-established GIMPS except insofar as sharing instantly-verifiable known factors.

[QUOTE=Brian-E;300738]If we go down the road of working together with M@H beyond only the most trivial level, that is beyond sharing known factors, then suddenly the entire operation becomes only as good as its weaker participant. In practical terms, that probably means a huge sacrifice of credibility by GIMPS. M@H, a new initiative with dubious ideas as indicated by Dr. Silverman, should not be allowed to contribute to the same database as the long-established GIMPS except insofar as sharing instantly-verifiable known factors.[/QUOTE]

Obviously such cooperation would require Mr. B. to release his code, if he hasn't already.

[QUOTE=Dubslow;300739]Obviously such cooperation would require Mr. B. to release his code, if he hasn't already.[/QUOTE]

I would be [B][I][U]very[/U][/I][/B] surprised if Mr. Bobrecki could produce any LL code which is anywhere near as optimal as Mr. Woltman's.

The only possible benefit I see from collaboration is collecting data on factors found which GIMPS missed in the early days. No real benefit to the core GIMPS agenda.

Sadly, Mr. Bobrecki project is taking cycles away from other BOINC projects which are doing actual new (and possibly useful) work.

[QUOTE=chalsall;300740]I would be [B][I][U]very[/U][/I][/B] surprised if Mr. Bobrecki could produce any LL code which is anywhere near as optimal as Mr. Woltman's.
[/quote]Yes, but 1) He might not like using GIMPS' code, and 2) There's something to be said for independent code. Agreed though that it generally would be pretty darn slow, even compared to [G]|[M]lucas.
[QUOTE=chalsall;300740]
The only possible benefit I see from collaboration is collecting data on factors found which GIMPS missed in the early days. No real benefit to the core GIMPS agenda.[/quote] Depends on where/where they do LL tests, though it seems it wouldn't be anywhere near our wanefront as yet.
[QUOTE=chalsall;300740]
Sadly, Mr. Bobrecki project is taking cycles away from other BOINC projects which are doing actual new (and possibly useful) work.[/QUOTE]
That's why we're considering this in the first place; GIMPS could gain a lot from BOINC, and BOINC shouldn't be cheated out of cycles by M@H (or rather, we should optimize M@H as much as possible).

[QUOTE=chalsall;300740]I would be [B][I][U]very[/U][/I][/B] surprised if Mr. Bobrecki could produce any LL code which is anywhere near as optimal as Mr. Woltman's.
[/QUOTE]
But bear in mind that all that is required is squaring a large number.

(A large number of times -:)

D

[QUOTE=davieddy;300752]But bear in mind that all that is required is the squaring a large number.[/QUOTE]

But bear in mind that squaring a large number is [i][u]very hard[/u][/i].

Or how about this: I'll give you £25 if you can write a program that can square a 12M digit number in 200 minutes on one core of a Core2. I don't think I could. Prime95 can do it in 90 ms.

[QUOTE=davieddy;300752]But bear in mind that all that is required is squaring a large number.[/QUOTE]

Is that anything like squaring a circle?

[QUOTE=Dubslow;300753]Or how about this: I'll give you £25 if you can write a program that can sqaure a 12M digit number in 200 minutes on one core of a Core2.[/QUOTE]Is that 200 minutes to write the program or 200 minutes to sqaure [sic] a 12M digit number?

Pity you didn't direct your comment to me, then I would be £25 richer.

But I think you over estimate the level of optimisation required to square things quickly. A basic and naive FFT implementation can do squaring a lot faster than 200 minutes. P95 code can, of course, do it very quickly, but the speed-up over normal FFT code is not anywhere as marked as you suggest with 200 minutes vs. 90ms.

[URL]http://mersenneathome.net/forum_thread.php?id=100&nowrap=true#416[/URL]
Is that true? :loco:

[QUOTE=retina;300755]Is that 200 minutes to write the program or 200 minutes to sqaure [sic] a 12M digit number?[/quote] The latter.
[Quote=retina;300755]
Pity you didn't direct your comment to me, then I would be £25 richer.

But I think you over estimate the level of optimisation required to square things quickly. A basic and naive FFT implementation can do squaring a lot faster than 200 minutes. P95 code can, of course, do it very quickly, but the speed-up over normal FFT code is not anywhere as marked as you suggest with 200 minutes vs. 90ms.[/QUOTE]
And do you think D or I could write even a basic FFT? (Actually, if I had my high school linear algebra text book I probably could, but it'd take me a few days at least.)
[QUOTE=kracker;300756][URL]http://mersenneathome.net/forum_thread.php?id=100&nowrap=true#416[/URL]
Is that true? :loco:[/QUOTE]
Yes; in page 2 of this thread, George says he sent an email to Mr. Bobrecki.

Ah, I saw that but I didn't hear he replied....
This will be really nice if it does work I guess :)

[QUOTE=kracker;300760]Ah, I saw that but I didn't hear he replied....
This will be really nice if it does work I guess :)[/QUOTE]

I didn't hear that he had, not in this thread, but that's what I assume based on your link.

[QUOTE=Dubslow;300753]But bear in mind that squaring a large number is [I][U]very hard[/U][/I].

Or how about this: I'll give you £25 if you can write a program that can square a 12M digit number in 200 minutes on one core of a Core2. I don't think I could. Prime95 can do it in 90 ms.[/QUOTE]

[URL="http://www.youtube.com/watch?v=OBOC93xLtJ8"]Jeez (as Garo would say) I can't find my knees[/URL].

I'll waive the £25:smile:

Love as ever,
David

PS "Don't teach your Grandma how to suck eggs"

[QUOTE=Dubslow;300758]
And do you think D or I could write even a basic FFT? [/QUOTE]
Assuming D is my good self I would reply in the affirmative.
As for you, keep on taking the tablets.
D

[QUOTE=davieddy;300767]Assuming D is my good self I would reply in the affirmative.
As for you, keep on taking the tablets.
D[/QUOTE]
Well then excuse me for thinking such :razz:

Mr. Bobrecki has responded. He has no objections to sharing factoring data. At first we'll probably use our respective web pages that query our databases. If you have any recommendations for him to make that easier, let us know.

I'm tempted to make BloodIce our official mers@home DB query manager :)

I've also pointed him to Oliver's CUDA code, so he may contact TheJudger at some point.

Will some mod please change this thread's title to "Brainstorming ways to cooperate with Mersenne@home"?

I think that would be more suitable than my original title, since it's apparent by now that Mr. Bobrecki is open to a cooperating agreement and has no intention of competing.

[QUOTE=cheesehead;300786]Will some mod please change this thread's title to "Brainstorming ways to cooperate with Mersenne@home"?

I think that would be more suitable than my original title, since it's apparent by now that Mr. Bobrecki is open to a cooperating agreement and has no intention of competing.[/QUOTE]
[B]'Cooperative Agreement or Communist Takeover? You decide!'[/B]

Nice touch :cool:

[QUOTE=flashjh;300794][B]'Cooperative Agreement or Communist Takeover? You decide!'[/B]

Nice touch :cool:[/QUOTE]

Been changed again :smile:

[QUOTE=Dubslow;300753]But bear in mind that squaring a large number is [I][U]very hard[/U][/I].

Or how about this: I'll give you £25 if you can write a program that can square a 12M digit number in 200 minutes on one core of a Core2. I don't think I could. Prime95 can do it in 90 ms.[/QUOTE]
Agree with you, but I won't waste the 25 bucks which you could lose very easy. I can produce a kinda karatsuba (don't need fft, just "[I]divide and impera[/I]", mul(2^k*a+b, 2^k*c+d)=2^(2k)*mul(a,c)+2^k*(mul(a,d)+mul(b,c))+mul(b,d) in less then a hour in C, which would do the job in less then 200 minutes, for sure. I would bet on "under 10 minutes". Well, rework a bit the expression in the middle, this sounds like a school-grade complexity as it is written.

For the record, pari does it in 3 seconds (core2 duo, single core used, 2.8GHz, FFT, not optimized at all for this size).
[CODE](15:05:06) gp > #
timer = 1 (on)
(15:05:25) gp > a=1<<45000000+random(1<<45000000);
*** at top-level: a=1<<45000000+random(1<
*** ^--------------------
*** _<<_: the PARI stack overflows !
current stack size: 4000000 (3.815 Mbytes)
[hint] you can increase GP stack with allocatemem()

*** Break loop: type 'break' to go back to GP
break>
(15:06:36) gp > allocatemem()
*** Warning: new stack size = 8000000 (7.629 Mbytes).
(15:06:43) gp > allocatemem()
*** Warning: new stack size = 16000000 (15.259 Mbytes).
(15:06:44) gp > allocatemem()
*** Warning: new stack size = 32000000 (30.518 Mbytes).
(15:06:45) gp > allocatemem()
*** Warning: new stack size = 64000000 (61.035 Mbytes).
(15:06:46) gp > allocatemem()
*** Warning: new stack size = 128000000 (122.070 Mbytes).
(15:06:46) gp > a=1<<45000000+random(1<<45000000);
time = 63 ms.
(15:06:51) gp > b=a^2;
time = 2,735 ms.
(15:07:07) gp >[/CODE]edit: if you try the example, don't forget the semicolons at the end, which inhibit the printing. Otherwise you have to wait ages for the number to be printed, and eventually your pari can crash.

[QUOTE=LaurV;300805]Agree with you, but I won't waste the 25 bucks which you could lose very easy. I can produce a kinda karatsuba (don't need fft, just "[I]divide and impera[/I]", mul(2^k*a+b, 2^k*c+d)=2^(2k)*mul(a,c)+2^k*(mul(a,d)+mul(b,c))+mul(b,d) in less then a hour in C, which would do the job in less then 200 minutes, for sure. I would bet on "under 10 minutes". Well, rework a bit the expression in the middle, this sounds like a school-grade complexity as it is written.

For the record, pari does it in 3 seconds (core2 duo, single core used, 2.8GHz, FFT, not optimized at all for this size).
[CODE](15:05:06) gp > #
timer = 1 (on)
(15:05:25) gp > a=1<<45000000+random(1<<45000000);
*** at top-level: a=1<<45000000+random(1<
*** ^--------------------
*** _<<_: the PARI stack overflows !
current stack size: 4000000 (3.815 Mbytes)
[hint] you can increase GP stack with allocatemem()

*** Break loop: type 'break' to go back to GP
break>
(15:06:36) gp > allocatemem()
*** Warning: new stack size = 8000000 (7.629 Mbytes).
(15:06:43) gp > allocatemem()
*** Warning: new stack size = 16000000 (15.259 Mbytes).
(15:06:44) gp > allocatemem()
*** Warning: new stack size = 32000000 (30.518 Mbytes).
(15:06:45) gp > allocatemem()
*** Warning: new stack size = 64000000 (61.035 Mbytes).
(15:06:46) gp > allocatemem()
*** Warning: new stack size = 128000000 (122.070 Mbytes).
(15:06:46) gp > a=1<<45000000+random(1<<45000000);
time = 63 ms.
(15:06:51) gp > b=a^2;
time = 2,735 ms.
(15:07:07) gp >[/CODE]edit: if you try the example, don't forget the semicolons at the end, which inhibit the printing. Otherwise you have to wait ages for the number to be printed, and eventually your pari can crash.

edit2: lowering the limits after some goggle-ing. A copy-paste from [URL="http://www.saahiihii.com/images/story/ENUBusiness1354DOCUMENT2.pdf"]this[/URL] into my Excel (VBA) took 10 minutes to "adjust" and a minute to run on that big number. You would lose the money! hehe :P[/QUOTE]

Hey, I said write a program, meaning not pari or Excel or whatnot :razz: I certainly would not have thought to write a general integer as a2^k+b and then square that instead.

yeah, whatever, I eliminated the second edit in my former post, as it was false :blush:, I was posting before the calculus finished. It took about 15 minutes! grrrr... you can delete it from your post too, as the reference to VBA could be misleading too, for some who cant directly convert from pseudocode/pascal to vb). I would however keep [URL="http://www.saahiihii.com/images/story/ENUBusiness1354DOCUMENT2.pdf"]the link[/URL], as the document is quite interesting for some beginner who wants to start experimenting with this.

edit, in fact it makes no sense to include the whole text when you reply to the [U]last post[/U]...(and it is not really polite:razz:, and not very cautious too, guys like me use to edit their last post many times, from English reasons, stupidity, tendency to boast, etc. hehe)

[QUOTE=Dubslow;300806]Hey, I said write a program, meaning not pari or Excel or whatnot :razz: I certainly would not have thought to write a general integer as a2^k+b and then square that instead.[/QUOTE]

Ok. Some BotE calculations -- just to give you some perspective. A 12M digit number has appr 40M bits. On a 64-bit m/c, that is 625000 64-bit words. To multiply two such numbers by naive n^2 multiplication would take (625000^2 = 4e11) "64x64=128" multiplications. [You can halve that for squaring, but let's just go with this] A 2GHz m/c would need (2e9*200*60) clock cycles / 4e11 operations = 60 clock cycles / operation to be able to hit your mark. Typical modern processor can do a single "64x64=128" multiplication in under 10 clock cycles. So that leaves enough head room for the various other operations (like additions, memory writes, etc..) and still comfortably come in under your target. And this is the O(n^2) method.

[QUOTE=LaurV;300807]
edit, in fact it makes no sense to include the whole text when you reply to the [U]last post[/U]...(and it is not really polite:razz:, and not very cautious too, guys like me use to edit their last post many times, from English reasons, stupidity, tendency to boast, etc. hehe)[/QUOTE]
Yeah, I do that sometimes (a lot). If figure if somebody was going to die (or some other crazy bad thing) because of something they edited out, it wouldn't have been in there in the first place.
[QUOTE=axn;300808]Ok. Some BotE calculations -- just to give you some perspective. A 12M digit number has appr 40M bits. On a 64-bit m/c, that is 625000 64-bit words. To multiply two such numbers by naive n^2 multiplication would take (625000^2 = 4e11) "64x64=128" multiplications. [You can halve that for squaring, but let's just go with this] A 2GHz m/c would need (2e9*200*60) clock cycles / 4e11 operations = 60 clock cycles / operation to be able to hit your mark. Typical modern processor can do a single "64x64=128" multiplication in under 10 clock cycles. So that leaves enough head room for the various other operations (like additions, memory writes, etc..) and still comfortably come in under your target. And this is the O(n^2) method.[/QUOTE]
Cool :razz: I think it's clear to everyone I pulled a large (relative to processors) amount of time straight out of my @$$ and didn't more than a half-an-ounce of thought into it :smile:

[QUOTE=Dubslow;300753]But bear in mind that squaring a large number is [I][U]very hard[/U][/I].

[/QUOTE]
Careful with that term when Silverman's around.
It's about as fatale as an after dinner mint.

(Pink Floyd and Cabaret)

D

The factors were reported to GIMPS
 

[QUOTE=Dubslow;300725]No, but PrimeNet is reporting false statements in the meantime, namely that "there are no factors below 2^62" is patently false.
[URL]http://mersenne.org/report_exponent/?exp_lo=2100451[/URL]
I hope that BloodIce does create a Mersenne@Home and does report the factors. [/QUOTE]

I did register MersenneAtHome account (Mersenne@Home was not available) and I uploaded the two mentioned factors. The problem is that they went in as ECM assignments. However, the credit is so low, that it does not matter. Actually, my GPU produced both factors in less than 15 min. I agree that even if it the knowledge of the two factors does not matter for the discovery of future primes, it might save some TF, P-1 and ECM effort. By the way, I think I have spent half an hour or more GPU work on one of those exponents couple of months ago. Obviously that was total waste of time. In my opinion every factor found helps the big search, despite the fact that the ultimate proof for a number being composite is to find its factors.

[QUOTE=Prime95;300775]
I'm tempted to make BloodIce our official mers@home DB query manager :)
[/QUOTE]

Flattering, but unnecessary :smile:. I shall help with whatever I can. By the way I can understand some polish, but that I am far from a constructive dialogue. I just want more factors in the GIMPS database and hopefully one day to see another Mprime. Let the human knowledge expand :-).

Primarily@Dubslow
 

But I hope it will entertain others (ignore if you feel like it).

I first got hooked on this stuff when Kim Novak came out of the
sea wearing nothing but a record breaking prime number circa Feb 2005.

David

Thread title advice
 

Pre-empt the Gerbils
See my latest in the Primenet forum (before they get there:smile:)

D

Note to Dubslow
 

[QUOTE=axn;300808]Ok. Some BotE calculations -- just to give you some perspective. A 12M digit number has appr 40M bits. On a 64-bit m/c, that is 625000 64-bit words. To multiply two such numbers by naive n^2 multiplication would take (625000^2 = 4e11) "64x64=128" multiplications. [You can halve that for squaring, but let's just go with this] A 2GHz m/c would need (2e9*200*60) clock cycles / 4e11 operations = 60 clock cycles / operation to be able to hit your mark. Typical modern processor can do a single "64x64=128" multiplication in under 10 clock cycles. So that leaves enough head room for the various other operations (like additions, memory writes, etc..) and still comfortably come in under your target. And this is the O(n^2) method.[/QUOTE]
As a novice programmer, you may well find it very instructive/satisfying
to write a neat "school" long multiplication program.
I speak from experience.

D

Lesson 2: Division and square roots!

Don't take this too personally
 

[QUOTE=Dubslow;300758]
And do you think D or I could write even a basic FFT? (Actually, if I had my high school linear algebra text book I probably could, but it'd take me a few days at least.)
[/QUOTE]
Go FORTH and multiply.

D

[QUOTE=davieddy;300950]Go FORTH and multiply.

D[/QUOTE]
I can't take it at all. It's one of the large majority of cases where it's lost on me :razz:

[QUOTE=davieddy;300942]As a novice programmer, you may well find it very instructive/satisfying
to write a neat "school" long multiplication program.
I speak from experience.

D
[/quote][url]http://dubslow.tk/random/mersenne.txt[/url]
[QUOTE=davieddy;300942]
Lesson 2: Division and square roots![/QUOTE]
Haven't done that yet. How does Newton's method compare to others for the sqrt? That's the only method that occurs to me off the top of my head.

Three hints
 

[QUOTE=Dubslow;300974]I can't take it at all. It's one of the large majority of cases where it's lost on me :razz:
[/QUOTE]

1) computer languages
2) The Holy Bible
3) Ernst

[QUOTE=davieddy;301011]1) computer languages
2) The Holy Bible
3) Ernst[/QUOTE]

Ah, seems kind of obvious now.

[QUOTE=Dubslow;301012]Ah, seems kind of obvious now.[/QUOTE]
From your PM apparently not.
3) was supposed to mean "Ask Ernst about it"

[QUOTE=davieddy;301017]From your PM apparently not.
3) was supposed to mean "Ask Ernst about it"[/QUOTE]
As in "How shall we go FORTH and multiply, oh Lord?"

Blessed are the cheesemakers.

As chalsall pointed out somewhere, M@H has apparently shutdown. It appears that the admin wasn't not able to continue with it for personal reasons, though I may be reading too much into it.

He did recommend GIMPS for those with an interest in Mersenne primes.
[quote=Sebastian Bobrecki]I regret inform that unfortunately I have no further possibility of engaging in and maintaining the project. Therefore, I decided to turn it off. I'm sorry that it did not give this information earlier, but I was hoping that maybe is possible to do something so that this did not happen. I would also like to thank all the volunteers and the BOINC community for your support.

I also encourage everyone to continue support other BOINC projects, and those particularly interested in the subject of Mersenne numbers, to the GIMPS project.

At this site you can find all the divider from the project database. It will remain available for some time.

Once again, I would like to thank all of you and good luck.[/quote]

I think this [URL="http://mersenneathome.net/dump/"]dump[/URL] should be taken seriously, as this very thread has proven that GIMPS has missed some factors.

[QUOTE=Dubslow;304988]I think this [URL="http://mersenneathome.net/dump/"]dump[/URL] should be taken seriously, as this very thread has proven that GIMPS has missed some factors.[/QUOTE]Has anyone compared them to the list from GIMPS and submitted those that were missed?

[QUOTE=Uncwilly;304990]Has anyone compared them to the list from GIMPS and submitted those that were missed?[/QUOTE]
I'd do it myself, but today is the start of a five day vacation and I can't write code. If no one has done it then, I'll do it. (I think chalsall could do it easily enough.)

PS I [i]knew[/i] I forgot something in my first post!!!

Now that [EMAIL="M@H"]M@H[/EMAIL] is out of business, should we consider BOINCifying Prime95 and creating a server? I'm pretty sure we could get a massive throughput increase.

First, someone would need to BOINCify Prime95. (GC?)

Second, and harder, someone would need to create a BOINC server that's integrated with PrimeNet. Ideally this would be on the same hardware, but considering that we can barely get PrimeNet alone to work, that may not be viable, but I'm not sure how else it could be done with any sort of decent efficiency. ([i]Mayber[/i], [i]perhaps[/i] it's possible to do something like GPU273, but then that would require advanced reservations as GPU273 does now. Probably not a good idea.)

[QUOTE=Dubslow;304991]Now that [EMAIL="M@H"]M@H[/EMAIL] is out of business, should we consider BOINCifying Prime95 and creating a server? I'm pretty sure we could get a massive throughput increase.

First, someone would need to BOINCify Prime95.[/QUOTE]
I think that TF and ECM would be good work types for it. If the extra resources are put toward 60m-100m, they could be given discreet areas and levels. Then the GPU's could follow through taking them to the upper bit levels.

[QUOTE=Uncwilly;304990]Has anyone compared them to the list from GIMPS and submitted those that were missed?[/QUOTE]

George said that he was on it already (low priority, though).

He also had contact with Bobrecki and loaded the June batch into PrimeNet. There were ~100 factors, mostly for those exponents that had already had a factor (this is how TF mod 120 works; cf. mfaktc; the first found factor is not necessarily the smallest but the default behaviour was to report and get the next one).

That dump seems huge, but if you'd care to get it (as I did), you will find that it contains mostly other people's factors (e.g. for p<1200 from Cunnighams; huge factors; they couldn't have found them). The largest part of the dump file are factors for 10^9<p<10^10. Many are simply 2p+1. The whole file could have been reorganized for storing k's and putting very small k's in a separate dump.

EDIT2: you don't have to get the file if you are only curious. It contains just one factor per exponent (ostensibly the smallest); it would be a big hit on the GIMPS database if everyone (and their mums) will start essentially screenscraping known factors from it. The bottleneck is to efficiently dump the known factors from GIMPS and compare. It is best left to George.

[QUOTE=Dubslow;304991]First, someone would need to BOINCify Prime95. (GC?)

Second, and harder, someone would need to create a BOINC server that's integrated with PrimeNet. Ideally this would be on the same hardware, but considering that we can barely get PrimeNet alone to work, that may not be viable, but I'm not sure how else it could be done with any sort of decent efficiency. ([i]Mayber[/i], [i]perhaps[/i] it's possible to do something like GPU273, but then that would require advanced reservations as GPU273 does now. Probably not a good idea.)[/QUOTE]

If someone was willing to BOINCify Prime95/mprime (and possibly mfakt*), I'd be willing to take responsibility for the BOINC server side of things. I could run it on the same server as GPU72.com (lots of capacity), and I've been looking into BOINC already for another project.

As with GPU273 (:wink:), this would have to be done with the knowledge and approval of George. But I don't see any real issues with reserving reasonable ranges and quantities of candidates.

[QUOTE=chalsall;305042]If someone was willing to BOINCify Prime95/mprime (and possibly mfakt*), I'd be willing to take responsibility for the BOINC server side of things. I could run it on the same server as GPU72.com (lots of capacity), and I've been looking into BOINC already for another project.

As with GPU273 (:wink:), this would have to be done with the knowledge and approval of George. But I don't see any real issues with reserving reasonable ranges and quantities of candidates.[/QUOTE]
Interesting: BOINC's description of volunteer computing mentions GIMPS more than once.

[url]http://boinc.berkeley.edu/trac/wiki/VolunteerComputing[/url]

The main problem I see with BOINCifying Prime95 is the conflict between Prime95's built-in priority/affinity routines and those that come with BOINC. I'd be curious what Greg (or other such knowledgeable persons) think about such an endeavor.

Edit: The other problem is the security code. How does BOINC secure its communications?

[QUOTE=Dubslow;306039]The main problem I see with BOINCifying Prime95 is the conflict between Prime95's built-in priority/affinity routines and those that come with BOINC. I'd be curious what Greg (or other such knowledgeable persons) think about such an endeavor.
[/QUOTE]

In BOINC world, when crunching multiple WU's, you launch multiple copies of the app. So BOINC-ified P95 would benefit by cutting out all multi-threaded codes, dealing with affinities, etc -- just assume that you're running one thread only.

[QUOTE=axn;306046]In BOINC world, when crunching multiple WU's, you launch multiple copies of the app. So BOINC-ified P95 would benefit by cutting out all multi-threaded codes, dealing with affinities, etc -- just assume that you're running one thread only.[/QUOTE]

Would it not be possible to multithread one WU then? (Not to make it harder for me or anything :razz: In any case, that is encouraging, thanks.)

[QUOTE=Dubslow;306047]Would it not be possible to multithread one WU then? [/QUOTE]

I suppose you could just do it. But I think that would mess with BOINC scheduler. Is there a BOINC-approved way of making a WU use multiple-cores? None that I'm aware of. I'll admit that I don't have any first hand experience implementing either the client or server -- only running projects. Someone more knowledgeable can correct me.

[QUOTE=axn;306054]I suppose you could just do it. But I think that would mess with BOINC scheduler. Is there a BOINC-approved way of making a WU use multiple-cores? None that I'm aware of. I'll admit that I don't have any first hand experience implementing either the client or server -- only running projects. Someone more knowledgeable can correct me.[/QUOTE]
I think there is actually a way to do it and "play nice" with BOINC's scheduler; it's been a while since I used BOINC myself, but the last time I ran it I poked around in a number of the .xml files defining the workunits and such, and there, I recall, three fields defining what resources the workunit would require: # of CPU cores, # of GPU cores, and whether the application was network-intensive. Each of the former two can be set to anything >=0, and the BOINC scheduler will plan around them appropriately--so if, for instance, a Prime95 task is labeled as using 4 cores, BOINC will leave 4 cores free for Prime95 to use however it can. Ditto for GPU tasks--you could have, for instance, an mfaktc workunit that is scheduled for 1 GPU and 1 CPU core.

Though I've never seen a project do this, I [I]think[/I] that you can have a mix of 1-threaded and multi-threaded workunits available on the server; the client reports to the server the # of cores it has available (by default this is all the cores on the system--counting hyperthreaded CPUs double, FYI--though the user can manually set the # of cores and affinities differently), so I'd guess that the server just gives out the highest-priority workunit that can fit within that client's available resources. So, for instance, if the server was loaded with a mix of 4-thread and 1-thread LL tests, and the 4-threads were set to a higher precedence, the 4-thread jobs will be handed out to an clients with 4 cores allocated to BOINC.

Possibly a more flexible way to do it would be to set up two client "applications" on the server, both of which are basically identical implementations of Prime95 but with one of them reserved for only 1-core jobs and the other for only 4-core jobs (for example). Then the user could manually select/deselect which combinations they want to be able to receive on their preferences page at the project website. This could be a handy way to implement the current variety of work choices we have now: first time LL, world record LL, 100 million digit LL, etc.; the number of cores used could be customized for each worktype, so, for instance, 100 million digit jobs could be only for 4 cores and up. Deadlines could then be set appropriately so that clients will estimate whether they can complete the job in a reasonable amount of time, thus ensuring that the big jobs only get assigned to computers that can complete them within our lifetime.

[QUOTE=mdettweiler;306097]I think there is actually a way to do it and "play nice" with BOINC's scheduler; it's been a while since I used BOINC myself, but the last time I ran it I poked around in a number of the .xml files defining the workunits and such, and there, I recall, three fields defining what resources the workunit would require: # of CPU cores, # of GPU cores, and whether the application was network-intensive. Each of the former two can be set to anything >=0, and the BOINC scheduler will plan around them appropriately--so if, for instance, a Prime95 task is labeled as using 4 cores, BOINC will leave 4 cores free for Prime95 to use however it can. Ditto for GPU tasks--you could have, for instance, an mfaktc workunit that is scheduled for 1 GPU and 1 CPU core.

Though I've never seen a project do this, I [I]think[/I] that you can have a mix of 1-threaded and multi-threaded workunits available on the server; the client reports to the server the # of cores it has available (by default this is all the cores on the system--counting hyperthreaded CPUs double, FYI--though the user can manually set the # of cores and affinities differently), so I'd guess that the server just gives out the highest-priority workunit that can fit within that client's available resources. So, for instance, if the server was loaded with a mix of 4-thread and 1-thread LL tests, and the 4-threads were set to a higher precedence, the 4-thread jobs will be handed out to an clients with 4 cores allocated to BOINC.

Possibly a more flexible way to do it would be to set up two client "applications" on the server, both of which are basically identical implementations of Prime95 but with one of them reserved for only 1-core jobs and the other for only 4-core jobs (for example). Then the user could manually select/deselect which combinations they want to be able to receive on their preferences page at the project website. This could be a handy way to implement the current variety of work choices we have now: first time LL, world record LL, 100 million digit LL, etc.; the number of cores used could be customized for each worktype, so, for instance, 100 million digit jobs could be only for 4 cores and up. Deadlines could then be set appropriately so that clients will estimate whether they can complete the job in a reasonable amount of time, thus ensuring that the big jobs only get assigned to computers that can complete them within our lifetime.[/QUOTE]

Interesting, interesting. That reminded me that BOINCing Prime95 would also mean tossing the hyperthread detection package.

[QUOTE=Dubslow;306099]That reminded me that BOINCing Prime95 would also mean tossing the hyperthread detection package.[/QUOTE]

Quite probably. Let's be honest -- we're a little spoilt by how close George codes to the metal.

On the other hand, a BOINCed Prime95 could allow intermediate uploads of LL check-point files. Given 4 MB each (an overestimate) and 100,000 tests underway at any one time (an approximate estimate), a server with 2 TB of bandwidth allotment a month could easily handle five such updates a month from every single tester.

Such servers are retail $60 USD a month. And, actually, there are many with unlimited bandwidth for that price.

[QUOTE=chalsall;306102]Quite probably. Let's be honest -- we're a little spoilt by how close George codes to the metal.

On the other hand, a BOINCed Prime95 could allow intermediate uploads of LL check-point files. Given 4 MB each (an overestimate) and 100,000 tests underway at any one time (an approximate estimate), a server with 2 TB of bandwidth allotment a month could easily handle five such updates a month from every single tester.

Such servers are retail $60 USD a month. And, actually, there are many with unlimited bandwidth for that price.[/QUOTE]
Umm... a 60M expo would be closer to 7.5 MB.
[url]http://www.wolframalpha.com/input/?i=6e7+bits[/url]

Interesting idea though.

I think we can be safe in saying that such a project would require a lot of experimentation, errors and trials to get right.

[QUOTE=Dubslow;306103]Umm... a 60M expo would be closer to 7.5 MB.
[url]http://www.wolframalpha.com/input/?i=6e7+bits[/url][/QUOTE]

You're right.

And, of course, the server would need to be able to store the data. I should add that for $60 a month you also get 500 GB of online storage and 250GB of near-line; for $80 you get 1.5 TB online.

[QUOTE=Dubslow;306103]I think we can be safe in saying that such a project would require a lot of experimentation, errors and trials to get right.[/QUOTE]

Unquestionably.

But given that BOINC is much more "mainstream", it could be a worthwhile exercise.

[QUOTE=Uncwilly;304990]Has anyone compared them to the list from GIMPS and submitted those that were missed?[/QUOTE]

It seems that nobody else worked on it (because I checked no missing factors had been uploaded), so I made the comparison and uploaded all missing factors (using a new account, Mersenne@Home Dump).

All together, there are 145,165,204 factors in factors.csv files, with 27,770,827 factors whose corresponding exponents are less than 1,000,000,000. Among these factors, 30434 of them were not in PrimeNet database; especially 79 factors were missed by GIMPS, because these exponents had not been factored before I uploaded them. For example, M[URL="http://www.mersenne.org/report_exponent/?exp_lo=81096871&exp_hi=&B1=Get+status"]81096871[/URL] has a 49.2-bit factor, but it had been TFed to [URL="http://www.unc.edu/%7Exiaoyinl/gimps/StatusPage/M81096871.html"]70 bit[/URL] without reporting any factors.

Mersen Neat Homes?
 

"Mersen Neat Home" turned out to be a weird (not even an acronym) homonym for [url]http://mersenneathome.net/[/url]

Sic transit gloria mundi!