Lavalamp, with those kinds of numbers, you could get these exponents to 83 bits....in a few days. Need to be careful with your reservations, the OBD page hasn't been updated for checkouts since I took over some assignments from firejuggler, above.

Multiple instances of mfaktc in separate directories is, I believe, the correct way to go. SievePrimes measures how well the CPU filters out non-primes; my six-core runs 5 cores of P95 and one of mfaktc.

Benchmark: My GT440 is running 35M/s or so, taking around 30 hours at 79-80 bits, so you can easily reach 82 in that time. My program is to get everything up at 80 bits, maximising my chances of finding a factor in the minimum time; there are 120 or so unfactored numbers in the GPU range, with 78 bits being the lowest level of TF. As for rodrigo's question on top dog, if you keep at it, I won't stay top dog in progress for long...I told him not to tell you!!!! :smile:

All at 79 bits, no factors, continuing on:
3321933577
3321933613
3321933661
3321933679

In changing from 79 to 80 bits, the rate of trial factoring on the GPU dropped quite substantially. From an average of just over 55 M/s, it fell to just under 45 M/s, nearly a 25% drop. From over 220 M/s to under 180 M/s in a single bit level, that can't be normal can it?

The first level took around 9.5 hours for each instance, but instead of an ETA of around 19 hours for the next level, it's more like 22.5 hours. It would be longer but the CPU can sieve deeper now that the bins are bigger.

In the interests of increasing performance, can sieveprimes go any higher than 100000, and if so how high? I know that the sieve size doubles with each bit level, but can it be made to artificially increase further (use fewer classes for instance)? That way the number of sieve primes could be set a lot higher for the same CPU time and weed out more candidates, essentially free performance.

Edit: By setting NumStreams and CPUStreams to 5, I have brought the average rate up to just over 45 M/s, but it's still far from what it was.

[QUOTE=Christenson;262839]Lavalamp, with those kinds of numbers, you could get these exponents to 83 bits....in a few days.[/quote]Well the numbers just got a bit worse. I would have predicted just over 3 days for running an exponent from 78 to 83 bits (well, 12 and a bit days for four of them anyway), but now it's looking more like 4 days, possibly more if it keeps slowing down after every bit level.

I will be choosing to work on the exponents I got up to 78 bits earlier, 3,321,933,361 to 3,321,933,679 (ran out of steam on page 16 back in late 2009). Possibly extending down to 3,321,933,179 if I do what I'm thinking of doing.

What I'm thinking of doing is something that came to mind when level 11 was broken 12 days after level 10, but it would have taken too long on a CPU. I want to break two levels simultaneously. :w00t:

That means taking 17 candidates to 83 bits from here, assuming it doesn't slow down more, that's 2 months solid GPU time.

[QUOTE=Christenson;262839]Need to be careful with your reservations, the OBD page hasn't been updated for checkouts since I took over some assignments from firejuggler, above.[/quote]That's why I have this:
[url]http://2721.hddkillers.com/compare/[/url]

But I also check the last few posts in this thread too.

[QUOTE=Christenson;262839]Benchmark: My GT440 is running 35M/s or so, taking around 30 hours at 79-80 bits[/quote]Hm, unless they've changed the capability of the cores, I'd have expected closer to 40 M/s based on scaling the numbers.

560 Ti: 1.9 GHz * 384 cores = 729.6 GHz
440: 1.189 GHz * 144 cores = 171.216 GHz

180 M/s * 171.216 / 729.6 ~= 42 M/s

Have you tried throwing another CPU core at it and seeing if the rate goes up? I noticed while running trials that a single instance of this program was lucky to get 1/3 of the total throughput I'm getting now, even though it didn't seem to be CPU limited and sieveprimes adjusted itself upwards.

I'll need to get much deeper into mfaktc to do much with it...last time I tried a second core, I got no improvement in TF throughput and took a significant hit in other forms of GIMPS throughput, having used up another core.

Where's Oliver?

That's where hyperthreading can help, it's like having another core, but not really. For stuff that hasn't been honed and optimised for years like Prime95, you can run another instance on the same core for increased performance.

I managed to get back some speed by setting NumStreams and CPUStreams both to 10, only a little though.

To anyone who may know, is there a way to set something to low priority on the GPU like there is with the CPU? I ask because I've noticed that videos are a little jittery when I'm running mfakt, especially flash video.

Hi,

[QUOTE=lavalamp;262831]
Edit: Just to check, it's OK to run multiple instances of mfakt simultaneously (in separate folders) right?[/QUOTE]
Correct (did you read the README?:razz:)

[QUOTE=lavalamp;262861]In changing from 79 to 80 bits, the rate of trial factoring on the GPU dropped quite substantially. From an average of just over 55 M/s, it fell to just under 45 M/s, nearly a 25% drop. From over 220 M/s to under 180 M/s in a single bit level, that can't be normal can it?[/QUOTE]
That drop is no surprise for me. 2^79 is the limit for the barrett79 kernel, above that your GPU chooses barrett92 which is actually slower because of bigger numbers.

[QUOTE=lavalamp;262861]Hm, unless they've changed the capability of the cores, I'd have expected closer to 40 M/s based on scaling the numbers.

560 Ti: 1.9 GHz * 384 cores = 729.6 GHz
440: 1.189 GHz * 144 cores = 171.216 GHz

180 M/s * 171.216 / 729.6 ~= 42 M/s
[/QUOTE]
Are you talking about the same exponent sizes and same factor sizes?

[QUOTE=lavalamp;262884]I managed to get back some speed by setting NumStreams and CPUStreams both to 10, only a little though.

To anyone who may know, is there a way to set something to low priority on the GPU like there is with the CPU? I ask because I've noticed that videos are a little jittery when I'm running mfakt, especially flash video.[/QUOTE]

Try to lower the GridSize, this might have a small performance penalty but usability usually increases. :smile:
The high number of Streams might decrease the responsiveness, too.

Oliver

[QUOTE=TheJudger;262941]Correct (did you read the README?:razz:)[/quote]I did, but clearly missed that part.

[QUOTE=TheJudger;262941]That drop is no surprise for me. 2^79 is the limit for the barrett79 kernel, above that your GPU chooses barrett92 which is actually slower because of bigger numbers.[/quote]Ah, I assume that's due to the variable types used then, I'll have a dig through the code to see if I can work out what's going on. Who's barrett by the way, you?

[QUOTE=TheJudger;262941]Are you talking about the same exponent sizes and same factor sizes?[/quote]Didn't you read the posts? :razz: Yes 79 - 80 bits.

Incidentally, all of them are TF'd to 80 bits now, and about 1/3 through the next level. No factors as yet.

About half way through the 79 - 80 bit run, I restarted all the instances of mfakt and one of them apparently could not resume from the save file for whatever reason, so it lost all the progress and started again. So would it be possible to have 2 or 3 save files? Just to ensure that if some progress is lost, it's not much.

:rant:OK, serious business here...I want to get that 480 running!:smile::devil:
Factor=0,3321932161,78,80
Factor=0,3321932359,78,80
Factor=0,3321932491,78,80
Factor=0,3321932567,78,80

I'll certainly put multiple save files on the todo list, but I think automatic primenet will come first.

Reserving 3321935797 from 71 to 72 bits, using Factor5.

Luigi

Reserving 3321935321, 3321935327, 3321935567, 3321935569, 3321935963 from 71 to 72 bits (Factor5).

Luigi

Taking 3321935891 from 71 to 72

Grant.

Taking 3321935249 and 3321935801 from 71 to 72. (Something to do on an otherwise boring Friday afternoon.)

Is there a reason that some of the exponents are CPU only?