mersenneforum.org ecm ram requirements
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2007-09-04, 03:03 #1 jasong     "Jason Goatcher" Mar 2005 3×7×167 Posts ecm ram requirements Could someone help me: (1) Calculate the RAM requirements for ECMing, based on the parameters in the second column here? (I just noticed that gmp-ecm has been updated a few times since that page was made. Dunno if it makes a difference.) And... (2) Calculate the slowdown for various non-optimal RAM settings(basically, any setting where Step 2 has to be done in more than one chunk)
 2007-09-04, 12:47 #2 jasong     "Jason Goatcher" Mar 2005 3·7·167 Posts A person who needs the above answered might also want an answer to the following: How do you force B1 and B2 to be certain values? I'm trying to do B2=B1*100, but ecm seems to be ignoring my B2 parameter. I'm in Ubuntu Linux, btw.
 2007-09-04, 13:39 #3 Xyzzy     Aug 2002 23×1,051 Posts Using the "-maxmem", "-treefile" and "-v" option you can get all sorts of answers. Tell the program that you have 4GB of memory. It won't check (at first) so it will give you a higher B2. Then just kill it. An example is we can run a number with no treefile and 512MB of memory allocated and get a maximal B2. If we use a treefile and reduce the memory to 256MB we still get the maximal B2. You just have to play with it to get an idea what is going on. Some examples: Code: $echo '2^1061-1' | ecm -maxmem 64 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=13980248621440, polynomial Dickson(30), sigma=3539738586$ echo '2^1061-1' | ecm -maxmem 128 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=13980960280570, polynomial Dickson(30), sigma=2583847295 $echo '2^1061-1' | ecm -maxmem 256 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=13982433063700, polynomial Dickson(30), sigma=1652733721$ echo '2^1061-1' | ecm -maxmem 512 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=13996217445226, polynomial Dickson(30), sigma=1752292022 $echo '2^1061-1' | ecm -maxmem 1024 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=14166423605890, polynomial Dickson(30), sigma=4274643031$ echo '2^1061-1' | ecm -maxmem 2048 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=14303528038816, polynomial Dickson(30), sigma=3917096619 $echo '2^1061-1' | ecm -maxmem 4096 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=15892628251516, polynomial Dickson(30), sigma=2472888744$ echo '2^1061-1' | ecm -maxmem 8192 -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=15892628251516, polynomial Dickson(30), sigma=4211883980 Note how B2 eventually tops out at 15892628251516. Code: \$ echo '2^1061-1' | ecm -maxmem 4096 -treefile tf -v 85e7 GMP-ECM 6.1.1 [powered by GMP 4.2.1] [ECM] Input number is 2^1061-1 (320 digits) Using B1=850000000, B2=15892628251516, polynomial Dickson(30), sigma=1011091140 Note how treefile usage lets us get by with half the memory. (If we really cared about having a B2 that high, and if we had that kind of memory available.) Finally, getting a particular B2 value isn't that important. Just make sure it is reasonable. The program defaults usually are fine. We do a lot of ECM work here with only 1GB in the system, and on another box that shares 1GB between two cores. What number are you working on?
2007-09-04, 14:46   #4
jasong

"Jason Goatcher"
Mar 2005

DB316 Posts

Thanks, I'll try your idea.
Quote:
 Originally Posted by Xyzzy Finally, getting a particular B2 value isn't that important. Just make sure it is reasonable. The program defaults usually are fine. We do a lot of ECM work here with only 1GB in the system, and on another box that shares 1GB between two cores.
Well, see, I'm on a quad-core, so in trying to maximize throughput, I'm running a couple scripts(a gift from another thread :) ) which alternate between having 4 threads doing Stage 1, then saving it, and another thread picking it up and doing Stage 2 while 3 threads continue Stage 1. The way things are set up, I think Stage 1s would build up faster than the one thread could handle.

Of course, since one attempt is as good as the next(since you can't tell without actually doing the work), I guess I could just play catch-up every few weeks.
Quote:
 What number are you working on?
I PMed Wblipp(Odd Perfect Number search dude) to request a number. It'll probably be from 50-60 digits, maybe 65, in terms of the factors I'll be searching for.

2007-09-04, 17:22   #5
Xyzzy

Aug 2002

23×1,051 Posts

Quote:
 Well, see, I'm on a quad-core, so in trying to maximize throughput, I'm running a couple scripts(a gift from another thread :) ) which alternate between having 4 threads doing Stage 1, then saving it, and another thread picking it up and doing Stage 2 while 3 threads continue Stage 1. The way things are set up, I think Stage 1s would build up faster than the one thread could handle.
Sometimes you can spend more time "optimizing throughput" that you lose time overall.

In your case, why not just treat the 4 cores like 4 little computers. You can get fancy later on.

Or maybe use 2 cores with mprime to generate the stage one stuff and have 2 cores running ecm to process the savefiles from mprime?

We have 3 cores here. (We call all CPUs now a core just to simplify things.) We have a single core desktop and a dual core laptop. We tried having one core do the mprime thing and tried having the other cores process stage 2, but things got very complicated and backlogged real quick.

We can't stand to see a core idle so we run a very low priority job on every core, to catch any unused cycles, and then we take our time and run something important on top of that.

Right now you are, in our opinion, trying to learn and do too much, too quickly. Take baby steps and initially just try to get the cores up with useful work. It doesn't have to be esoteric, ultra interesting work. Just useful work.

We think mprime, since it is so automated, is a good candidate for catching idle cycles. You can run LL tests, trial factor, run ECM curves or do P-1 work, all in one binary. And, it is trivial to start/stop/resume automatically. And it is well documented.

Then get to the fancy stuff.

Here is a single core example:
Code:
top - 13:30:14 up 19 days, 15:43,  4 users,  load average: 2.21, 2.31, 2.35
Tasks:  96 total,   3 running,  93 sleeping,   0 stopped,   0 zombie
Cpu0  : 72.4%us,  0.9%sy, 26.5%ni,  0.1%id,  0.0%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:   1035136k total,  1011004k used,    24132k free,    20504k buffers
Swap:  1035128k total,       48k used,  1035080k free,   452008k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4358 m         39  19  183m 182m  772 R  3.6 18.1 973:00.60 ecm -maxmem 768 -n -treefile tf 43e6
31862 m         25   0 36180  17m  784 R 94.9  1.8 149:18.76 /home/m/Desktop/ggnfs/src/gnfs-lasieve4I13e -k -o spairs.out -v
Note how ecm has been running for a while but uses very little processor right now, since we are running a SNFS job. No idle cycles!

 2007-09-04, 18:31 #6 jasong     "Jason Goatcher" Mar 2005 3×7×167 Posts I appreciate your comments Xyzzy, but my main problem was actually getting ecm to work. When I very first used ecm, I either wasn't aware of the idea of apt-geting ecm or it wasn't available. As for the interesting and useful work part, I'll probably just stick OGR-25 on there until I've both figured out how to get ecm to run best, and I've heard from Wblipp. Thanks, though. :) Last fiddled with by jasong on 2007-09-04 at 18:32

 Similar Threads Thread Thread Starter Forum Replies Last Post brilong PrimeNet 18 2014-09-06 00:40 rogue No Prime Left Behind 45 2010-01-29 17:28

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

Sun Jan 23 06:42:29 UTC 2022 up 184 days, 1:11, 0 users, load averages: 1.51, 1.45, 1.31

Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔