5p2_950M doable on 24 cores?

[kruoli]

Yes, VBITS will be set in the make command of msieve. Sometimes MPI may help with data locality, but it also might induce overhead, but directions are possible. Yes, octa channel is hardware, it depends on whether this is your own machine or not. If you own it, you can install eight DIMMs in the according slots and this will enable octa channel memory.

What do you mean by msieve sleeping a lot? Going with your estimation of 92.5 % efficiency, I would say that this is normal for more than 16 threads.

[bur]

Ok, having looked at old logs I can say this is sub-average speed but nothing strange. A 15M matrix took 140 hours, a 13 M 130 hours. So the 800 h is fine, as I said the 7401P is not that fast. So as long as the matrix size is ok, I don't think any further optimization makes sense.

"Sleeping a lot" as in every few seconds they all go to "S" and then switch back. Htop average is 18.5/20 cores utilization.

[swellman]

Originally Posted by bur

Yes, I made that mistake before. These arguments have to be immediately after the -nc option.

See this post.

[VBCurtis]

32M is close enough to my guess of 30M to consider the matrix a typical size / normal for this size of job.

800 hours sounds high; I bet if you tried the list of ideas in the last few posts you'd find 10-30% more speed. The good news is that when you do find the time to test ideas, the fastest invocation will be fastest on all future jobs.

For (poor) comparison: I'm running my first job on a new 5950x, 16 core 2-channel RAM. a 35M matrix is taking 420 hr, so I would do a 32M matrix in around 360hr on an otherwise-idle CPU. My cores are much faster than that EPYC's, but I still would expect the EPYC to be relatively faster than the clockspeed comparison due to all its memory bandwidth.

[pinhodecarlos]

I recall msieve not utilising in full a thread or a core, maybe the reference for the sleeping comes from this. Some threads/cores are awaiting for others to finish.

[bur]

Originally Posted by VBCurtis

800 hours sounds high; I bet if you tried the list of ideas in the last few posts you'd find 10-30% more speed. The good news is that when you do find the time to test ideas, the fastest invocation will be fastest on all future jobs.

Other than MPI that would be:

• recompiling with VBITS=256
• assigning to physical cores
• not use HT

?

Regarding HT, if the threads aren't fully utilizing the physical cores, wouldn't that be an ideal situation for HT?

If I try something, I can just close msieve with Ctrl+C and restart with -ncr? Will I loose everything not checkpointed, i.e. would it make sense to wait for a checkpoint?

[VBCurtis]

The more threads you assign to msieve, the more waiting there is. Break a task into 20 pieces instead of 10 pieces, and wait for everyone to finish their slice before anyone can proceed; while each task is half as big, there would be a lot of waiting. One experiments to find how to reduce this waiting (such as assigning cores with taskset). Hyperthreads aren't always bad for msieve, just usually- they introduce more variability into how long each slice takes, so more waiting happens.

Yes to using -ncr. You don't lose work when closing via ctrl-c; msieve writes a checkpoint upon closure.

[frmky]

Note, though, that you can't restart if you change VBITS. You would have to start the linear algebra from the beginning.

[bur]

Thanks, that's what I figured, so I didn't do that but just assigned cores. ETA went down for a while and now it's up again. I also tried assigning the range of physical cores, but that didn't do anything noticeable.

But actually, I'm not sure there's really that much to gain. 24 cores vs 10 cores, the 7401P is still 10-15% slower than an i10 10900k - and I'm only using 20/24. And a recent LA by swellman with 8 threads had 400+ hours for a 17M matrix. That would correspond to nearly 1600 hours for 31M, if I'm not mistaken.

I can later on offer the matrix for benchmarking, if someone's interested.

[swellman]

Originally Posted by bur

But actually, I'm not sure there's really that much to gain. 24 cores vs 10 cores, the 7401P is still 10-15% slower than an i10 10900k - and I'm only using 20/24. And a recent LA by swellman with 8 threads had 400+ hours for a 17M matrix. That would correspond to nearly 1600 hours for 31M, if I'm not mistaken.

Keep in mind that recent result was performed on an 8 year old laptop with an i7-3520M CPU @2.9 GHz and 16 Gb of RAM. Not sure it has enough memory to even move a 31M matrix into LA never mind solve it. So a direct comparison between your machine and my old box likely doesn’t work. But I agree with your scaling estimate if we ignore the RAM limitations.

Not sure you can gain much more performance out of your machine, though I do sincerely hope I’m wrong.

[bur]

It's finally done, LA took 800 hours.

I noticed the machine is generally not very effective if you use a lot of threads for one task. As an example:

Single threaded LLR took 4.5 ms per iteration
2 threads = 2.9 ms / iter
20 threads = 1.2 ms / iter

The cores start to see only 70-90 % utilization once a lot of threads are involved.

I still have it until end of August, so I guess I'll use it for sieving.

Sun Jul 17 03:04:52 2022 commencing square root phase
Sun Jul 17 03:04:52 2022 Sqrt: Handling dependencies 1 to 8

I saw this in a log of frmky, is it a result of using MPI? Seems like parallel processing of more than one dependency?