How about new .dat file?

[MikeH]

do these define the following?

results - the number of results eliminated through sieve and p-1?
n-min - the number of candidates eliminated by double-check (supersecret) raising the floor?

Correct.

And another interesting point, if someone was to find a factor for 28433 * 2 ^ 19999993, then the celling would lower, but the cause would still be 'results'.

and please tell me, we should use this new file to sieve?

Yes please use this file to seive.

I'll try to update the web page before Friday, I didn't want to do it straight away in case someone found some strange problem that no one could have antisipated, but everyone seems happy, so I'll do the update.

[vjs]

Come on Death give us a break

I think we have all (including yourself) suspected a performance increase with an updated dat, but truly the vertic is still out. The new dat file is not slower, and doesn't seem to produce any unknown errors etc, this is a good thing. Were we certian that it wouldn't the sieve effort, ... no, but it didn't.

Over time it will increase sieve speed that's for certain, I think we should all step back and give ourselves a pat on the back for what's been done.

Thanks to MikeH for his excellent work and a major step in the right direction.

to quote Mystwalker, he did some real accurate work, not like myself, proving increasing the floor does increase sieve speed:

using 2m<n<20m,... increase was a mere 0.61%

Also by Nuri,

As you would remember, the speed difference between 3m-20m and 1m-20m (or was it 300k-20m?..) was a mere ~1%

But still the best bet for a speed increase is still removing a prime let's keep hunting,

To quote myself

Orginal dat file on my machine 690 kps

Without 33661 yeilds 723 kps (4.8% speed increase)

Without 67607 yeilds 743 kps (7.6% speed increase)

Without 33661 and 67607 (only 9k) yeilds 790 kps (14.5% speed increase)

I'd like to do this for each number to see the effect but I don't have the time right now. Death if you'd like to do this I can explain to you how to do it, it's quitte simple really, or I can make the dat's for you if you can do decent/accurate speed testings.

[Death]

Originally posted by MikeH
Correct.

And another interesting point, if someone was to find a factor for 28433 * 2 ^ 19999993, then the celling would lower, but the cause would still be 'results'.

Yes please use this file to seive.

I'll try to update the web page before Friday, I didn't want to do it straight away in case someone found some strange problem that no one could have antisipated, but everyone seems happy, so I'll do the update.

i'm wonder whats the next number after 19999993? it must be greater then 2M

can you tune up .dat file to n > 2m, ie to next number after 19999993?

[Death]

Originally posted by vjs
Come on Death give us a break

+))

I think we have all (including yourself) suspected a performance increase with an updated dat, but truly the vertic is still out. The new dat file is not slower, and doesn't seem to produce any unknown errors etc, this is a good thing. Were we certian that it wouldn't the sieve effort, ... no, but it didn't.

i hope... it don't break something...

Over time it will increase sieve speed that's for certain, I think we should all step back and give ourselves a pat on the back for what's been done.

Thanks to MikeH for his excellent work and a major step in the right direction.

to quote Mystwalker, he did some real accurate work, not like myself, proving increasing the floor does increase sieve speed:

and there was a lot of talkin beforó that... =)))

But still the best bet for a speed increase is still removing a prime let's keep hunting,

as usual winter is a prime season. we all waitin for this. and afaik you already make your bet on a next candidate...

To quote myself


I'd like to do this for each number to see the effect but I don't have the time right now. Death if you'd like to do this I can explain to you how to do it, it's quitte simple really, or I can make the dat's for you if you can do decent/accurate speed testings.

i don't need explanation really. i looked into dat file and i wonder that i can remove any k very simple. but i cant do accurate testing. my pc is very hardly working and there's no free boxens around.

my speeds vary from 90k/s to 170 k/s it's a cel 1700

I DONT EVEN NOTICE THIS 1%

[Mystwalker]

Originally posted by Death
i'm wonder whats the next number after 19999993? it must be greater then 2M

can you tune up .dat file to n > 2m, ie to next number after 19999993?

It's 19,999,993 (19.x M, not 1.9x M).
So, with a factor, the upper bound can be decreased.

Originally posted by MikeH
And another interesting point, if someone was to find a factor for 28433 * 2 ^ 19999993, then the celling would lower, but the cause would still be 'results'.

How can I write this number (in whole digits) into a file under Linux? The expression parser of gmp-ecm can't handle it, "expr" seems not to know powering...

[hc_grove]

Originally posted by Mystwalker

How can I write this number (in whole digits) into a file under Linux? The expression parser of gmp-ecm can't handle it, "expr" seems not to know powering...

You can try

echo '28433 * 2 ^ 19999993' | bc > file

but I don't know how well it handles numbers of that size (I didn't have the patience to actually try that computation).

[Mystwalker]

I'm trying, thanks!

30 minutes so far on a Duron @ 800 or 850 MHz... *insertCoffeeCupOfMersenneforumHere*

[Mystwalker]

bc ended without creating the file.

[MikeH]

To this point I haven't commented on speed improvements with the new .dat file. I've now done enough tests to say ....... I think there is no noticeable speed improvement. I don't think it's any slower, but I don't think it's any quicker.

All the tests I've done so far with the new .dat (I think I'm now using Wednesday's) file are completed within the normal standard deviation that I've been seeing for the last few months with the old .dat file.

Anyone that sees any performance boost, that's great, just I don't. I'll continue keeping an eye on those tests over the next week, if I do see any change I'll let you know.

At least the daily updated .dat file has finally put to bed the "when are we going to get a new .dat file" requests.

[Mystwalker]

Originally posted by MikeH
At least the daily updated .dat file has finally put to bed the "when are we going to get a new .dat file" requests.

They'll come back when there is no new .dat file for more than 2 days... - you made it even worse!

[Keroberts1]

I've actually foundabout a 2% increase but it is noticable. Not that 2% isanything to get excitable about but in time it will definatly start to add up. The big thing we're all wishing for is a prime of course.

[vjs]

MikeH,

We are all just really glad that the new dat didn't slow things down or break anything . And again merging this dat file with the P-1 effort is also great.

My placebo effect shows a definate 1-2% increase in speed as well

I also hope you have a script that simply generates these *.dat's for you, you don't make or edit them by had or something crazy do you???

Also Mike, did you notice any changes in the number of factors in factexcl.txt or anything like that?? I just had a feeling that the number of factors appearing the factexcl.txt has decreased with the new dat is this possible or not. It could simply be a higher p value...

[MikeH]

I also hope you have a script that simply generates these *.dat's for you, you don't make or edit them by had or something crazy do you???

Fully automatic I don't like manual things (which is why the sieve and P-1 reservations don't get updated in the stats too often)

Also Mike, did you notice any changes in the number of factors in factexcl.txt or anything like that?? I just had a feeling that the number of factors appearing the factexcl.txt has decreased with the new dat is this possible or not. It could simply be a higher p value...

Haven't looked. But now you've made comment, I'll make a concious effort to have a look.

[vjs]

Too let those know,

From the p-1 section from MikeH

OK, the new small zipped sob.dat file is about 16KB in size. As with the other similar files it will be updated daily at about 03:00 UK time.

The current file spans n = 7081949 to 7581949.

If you download this file regulaly, you won't need to download the results.txt file.

DO NOT USE THIS FILE TO SIEVE. I'm sure to will make the sieve very fast, but you will find very few factors! I Repeat. DO NOT USE THIS FILE TO SIEVE.

For those that are curious,

My sieve speed with this file went from,

690 kp/s -->940 kp/s, of course it wouldn't generate many factors but it's interesting for the purposes of speed comparisions.

For a 19m range (~1<n<20m) I'm getting roughly, 690 kp/s
For a 50k range (~7.08m<n<~7.58m) I'm getting roughly, 940 kp/s

So , for a 99.997% decrease is the range size I saw a 36% speed increase.

Hummmmm,

So my question is what is kp/s really, is it 1000 of the p range per second?

So in other words if you had a speed of 1000 kp/s or 1 mp/s, it's comparing 1mp of your selected p range against all factors in the dat file every second?

I though that's what it means... but then it also generates out of range factors and excluded factors????

[mklasson]

Originally posted by vjs
So my question is what is kp/s really, is it 1000 of the p range per second?

Just so.

So in other words if you had a speed of 1000 kp/s or 1 mp/s, it's comparing 1mp of your selected p range against all factors in the dat file every second?

That's the end result, yeah.

I though that's what it means... but then it also generates out of range factors and excluded factors???? [/B]

Yupp, the algorithm doesn't try all candidates in the dat file individually, but does some other fancy stuff instead that has a chance of also finding factors for numbers that aren't in the dat. (at no extra cost, mind you)

[royanee]

Originally posted by mklasson
Yupp, the algorithm doesn't try all candidates in the dat file individually, but does some other fancy stuff instead that has a chance of also finding factors for numbers that aren't in the dat. (at no extra cost, mind you)

Really?!? So, others are free, but then should that mean that you should get a much larger jump from cutting out 99% of the numbers your are checking? Also, what is the highest number the sieve can give you from factrange? Is v .34 as good as it gets (and it is good, but... algorithm speedups bring hope to us all)? Thank you.

[mklasson]

Originally posted by royanee
Really?!? So, others are free, but then should that mean that you should get a much larger jump from cutting out 99% of the numbers your are checking?

No? The important thing is how big the n range is. (and how many k's you have)

Also, what is the highest number the sieve can give you from factrange? Is v .34 as good as it gets (and it is good, but... algorithm speedups bring hope to us all)? Thank you.

I don't really know, but I think I've seen n's in the couple of hundred millions. It depends on the factorization of p-1.

There's a v0.42 out there that's much better than v0.34. I don't have any other ideas atm, but perhaps someone else has.

[royanee]

Oops! Sorry, I meant .42... Maybe I was thinking about Joe when he was talking about an old version... Is the source available for the sieve client, or no?

[mklasson]

Originally posted by royanee
Oops! Sorry, I meant .42... Maybe I was thinking about Joe when he was talking about an old version... Is the source available for the sieve client, or no?

Not really, but you're better off that way. Trust me. It's not so cute.

[royanee]

Originally posted by mklasson
Not really, but you're better off that way. Trust me. It's not so cute.

hehe, ah well. I probably would have just been confused or congratulatory. Either one wouldn't have pushed it forward. Thanks anyway though.

[vjs]

Mike,

Just noticed something about your small dat file. It's basically 20K above the current n (e.g. 7.17m <n<7.19m) however people are factoring 200k beyond the current high n(e.g. current n is 7.17m factoring at 7.3m).

Perhaps you could change the n range of this small file say high n or (high n + 5k, ~one days worth) to high n +150 or 200K???

Just a suggestion,
VJS

Perhaps dcsoon could also be a little bigger say the next 50K or 100k as opposed to 5k that it is at current...

P.S. wasn't there a quote somewhere about this topic going away now that you've done a new dat ... Looks like somethings never change.

[MikeH]

Just noticed something about your small dat file. It's basically 20K above the current n (e.g. 7.17m <n<7.19m) however people are factoring 200k beyond the current high n(e.g. current n is 7.17m factoring at 7.3m).

The little files are just or info. The one intended for factoring is 500K beyond the current highest n.

[vjs]

Ahhh,

My mistake Mike, goes to show how current I am in factoring.