mersenneforum.org fond of a factor? Turn yourself in to become insane.
 Register FAQ Search Today's Posts Mark Forums Read

2019-09-13, 23:21   #1497
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

13·409 Posts

Quote:
 Originally Posted by lycorn What if you had found this one? 11510125
I don't understand.

 2019-09-15, 23:43 #1498 Jwb52z     Sep 2002 75610 Posts P-1 found a factor in stage #2, B1=885000, B2=18585000. UID: Jwb52z/Clay, M96078113 has a factor: 40150180980878122799159 (P-1, B1=885000, B2=18585000) 75.088 bits.
 2019-09-17, 18:28 #1499 Jwb52z     Sep 2002 22·33·7 Posts P-1 found a factor in stage #1, B1=820000. UID: Jwb52z/Clay, M94654033 has a factor: 7507521220789479758248769 (P-1, B1=820000) 82.635 bits.
 2019-09-25, 00:38 #1500 mrh   "mrh" Oct 2018 Temecula, ca 5·11 Posts Found one for 7111127 - 786612060695816024641268553407 99.312 bits
 2019-09-29, 04:28 #1501 Jwb52z     Sep 2002 13648 Posts P-1 found a factor in stage #1, B1=890000. UID: Jwb52z/Clay, M96570209 has a factor: 24529069813789561422559319 (P-1, B1=890000) 84.343 bits.
 2019-09-29, 21:07 #1502 mrh   "mrh" Oct 2018 Temecula, ca 5×11 Posts I think this is the largest I've found so far 3333397 5987402934250702953071699518972409 112.206 bits
2019-09-29, 21:12   #1503
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

B0A16 Posts

Quote:
 Originally Posted by mrh I think this is the largest I've found so far 3333397 5987402934250702953071699518972409 112.206 bits
It is the largest of the 5 you've found: https://www.mersenne.ca/pm1user/19538

Last fiddled with by James Heinrich on 2019-09-29 at 21:12

 2019-10-03, 22:00 #1504 Maciej Kmieciak   Nov 2018 Poland 2·7 Posts Hey, I read that GPUs are more efficient on higher bitlevels. So why is there less GHz-days / day in 73-74 than in 71-73? Code: no factor for M909985499 from 2^71 to 2^72 [mfakto 0.14-Win cl_barrett15_73_gs_2] tf(): total time spent: 1m 9.138s (656.78 GHz-days / day) no factor for M909985499 from 2^72 to 2^73 [mfakto 0.14-Win cl_barrett15_73_gs_2] tf(): total time spent: 2m 17.558s (660.21 GHz-days / day) no factor for M909985499 from 2^73 to 2^74 [mfakto 0.14-Win cl_barrett15_82_gs_2] tf(): total time spent: 5m 6.655s (592.31 GHz-days / day) no factor for M909985451 from 2^71 to 2^72 [mfakto 0.14-Win cl_barrett15_73_gs_2] tf(): total time spent: 1m 8.872s (659.32 GHz-days / day) no factor for M909985451 from 2^72 to 2^73 [mfakto 0.14-Win cl_barrett15_73_gs_2] tf(): total time spent: 2m 17.148s (662.19 GHz-days / day) no factor for M909985451 from 2^73 to 2^74 [mfakto 0.14-Win cl_barrett15_82_gs_2] tf(): total time spent: 5m 5.676s (594.21 GHz-days / day)
2019-10-04, 00:11   #1505

"Sam Laur"
Dec 2018
Turku, Finland

22·7·11 Posts

Quote:
 Originally Posted by Maciej Kmieciak Hey, I read that GPUs are more efficient on higher bitlevels. So why is there less GHz-days / day in 73-74 than in 71-73?
Short answer: For those longer factors, mfakto needs to use a different GPU kernel that is less efficient, in other words, uses more instructions for the same operation.

Longer answer: Instead of division, mfakto (and mfaktc) use Barrett reduction, that basically turns division into multiplication, and because of the relatively small multipliers available in the GPU cores, there are some tricks that need to be done to extend the precision. There are some further optimization tricks that can be done, but these have the side effect of eating into this extended precision, so each more optimized GPU kernel has a lower corresponding maximum bitlevel.

The GHz-day formula doesn't take these changes into account, as it is supposed to be related to the time a CPU takes to factor something to a given bitlevel, not a GPU.

Now, I'm not familiar with AMD or mfakto specifics, are the barrett15_* kernels really still more efficient than barrett32_* even on more modern cards?

2019-10-04, 03:41   #1506
LaurV
Romulan Interpreter

Jun 2011
Thailand

31·271 Posts

Quote:
 Originally Posted by Maciej Kmieciak Hey, I read that GPUs are more efficient on higher bitlevels. So why is there less GHz-days / day in 73-74 than in 71-73?
Short-short-shortest (to paraphrase the ante-poster) answer: because you need more time to count to 13 than you need to count to 11. And if you have a task that requires repeatedly counting to 13, then you will do less of these tasks per day, compared with a task that asks you to repeatedly count to 11.

Correct answer: (which correctly implies that my previous answer, as well as both answers from the anteposter are wrong ) : Because the formula to calculate the credits is wrong, in the sense that it is only an approximation, based on empirical evidence, derived from middle age times when only the CPUs could do TF. The GHzDays/Day (as a measuring unit) should be the amount of work that a single-core 32 bits CPU can do in one day, running at 1 GHz. This is (approx) how it was defined long ago. This should have nothing to do with the exponents, bitlevels, TF, LL, whatever. But invention of multi-cores, 64-bit CPUs, GPUs, airplanes, flying spaghetti monster, and other alien stuff which invaded us in the last time, heavily changed the odds, and anyhow, such measurement, even if we could make it extremely accurate, would not be useful (think about it! if your card will always show 562.73 GHzD/D regardless of what you are doing with it, what should be the point?). Actual calculus could be altered by many things, including a "stimulation" for people to do certain type of work (yes, you may get more credit doing this or that bitlevel, in this or that range, because that is most needed now - well, dream on! that would be ideally, wouldn't be?)

Of course, everybody can use his/her cards and electricity money to do whatever type of work fits them better.

Last fiddled with by LaurV on 2019-10-04 at 03:46

 2019-10-04, 08:38 #1507 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 54128 Posts GHz-days credit for TF is broadly based on bitlevel, derived from how well an Intel CPU of decades ago could process TF work using Prime95 (example). The credit is scaled according to 3 ranges: up to 62-bit is "easy" and given 62.58% credit, 63-64 bit is "slightly easier" and given 95.15% credit, and >=65-bit gets 100% credit. Since all the TF done now is >65-bit the credit given is linear, but is subject to architectural efficiencies of the GPU (or whatever device you're using) and the software running the calculation. Broadly speaking, higher bit depths require more bits to be played with at once and therefore slow the calculations down somewhat, which is why mfaktx will choose the smallest kernel that can process the current assignment, since that will be the fastest. For historical interest, for the old-timers, I found these old notes in the code: Code: CPU credit - background information: In Primenet v4 we used a 90 MHz Pentium CPU as the benchmark machine for calculating CPU credit. The official unit of measure became the P-90 CPU year. In 2007, not many people own a plain Pentium CPU, so we adopted a new benchmark machine - a single core of a 2.4 GHz Core 2 Duo. Our official unit of measure became the C2GHD (Core 2 GHz Day). That is, the amount of work produced by the single core of a hypothetical 1 GHz Core 2 Duo machine. A 2.4 GHz should be able to produce 4.8 C2GHD per day. To compare P-90 CPU years to C2GHDs, we need to factor in both the the raw speed improvements of modern chips and the architectural improvements of modern chips. Examining prime95 version 24.14 benchmarks for 640K to 2048K FFTs from a P100, PII-400, P4-2000, and a C2D-2400 and compensating for speed differences, we get the following architectural multipliers: One core of a C2D = 1.68 P4. A P4 = 3.44 PIIs A PII = 1.12 Pentium Thus, a P-90 CPU year = 365 days * 1 C2GHD * (90MHz / 1000MHz) / 1.68 / 3.44 / 1.12 = 5.075 C2GHDs

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Programming 3 2016-09-30 07:15 markdjonson Information & Answers 9 2012-12-31 15:34 Rafael Information & Answers 12 2012-01-02 19:38 rogue Lounge 10 2008-11-21 05:25 nngs Hardware 0 2005-05-20 01:31

All times are UTC. The time now is 06:19.

Wed Apr 8 06:19:43 UTC 2020 up 14 days, 3:52, 2 users, load averages: 1.70, 1.42, 1.36