Taking 2027-71
 

Taking 2027^71-1

(ETA Monday morning)

2027^71-1 done
 

[code]
Mon Jan 11 04:15:01 2016 p76 factor: 1204253002431366149859482948760832274442577274829552962838426912911894803237
Mon Jan 11 04:15:01 2016 p153 factor: 105109785025566811458601629348458511230953847327876108743764162477978501075269414541496577411099192147231131474007172573894334603065809329180245592190233
[/code]

29.6 hours for 8.5M density-120 matrix on 6 cores i7/5820K

[pastebin]YZM6Xdzs[/pastebin]

C260_131_97 running
 

ETA 400 hours (so around the end of January) for 25.8M matrix on 6 threads i7/5820K

I'm a little disappointed at the speed of the 5820K - I was expecting linear algebra to be RAM-limited and four-channel DDR4/2400 to be significantly faster than four-channel DDR3. Going to 12 threads got about a 15% slow-down over using six. I'm getting about 15% slower than an E5-2650v2 which has eight cores and DDR3.

What happens if you shutdown HT and run on 6 cores?

Not much. On my 5820k with stock-speed memory, running 6 tasks in linux with HT disabled and 6 tasks with HT enabled produced results within 2% of each other (tested with 6x LLR, and also 6x lasieve). I assume the penalty is due to the linux scheduler sending two tasks to one physical core on occasion (I noticed a worse speed hit running 8 or 9 tasks, where a physical core would be idle sometimes while 3-4 cores had two tasks each).

Reserving C161_P170_plus_1

[QUOTE=VBCurtis;422127]Not much. On my 5820k with stock-speed memory, running 6 tasks in linux with HT disabled and 6 tasks with HT enabled produced results within 2% of each other (tested with 6x LLR, and also 6x lasieve). I assume the penalty is due to the linux scheduler sending two tasks to one physical core on occasion (I noticed a worse speed hit running 8 or 9 tasks, where a physical core would be idle sometimes while 3-4 cores had two tasks each).[/QUOTE]

I use 'taskset' to prevent the scheduler from doing such stupid things - it does seem able to take a task with six threads and assigned six cores and run one thread on each core reliably.

It looks like we are about to run out of work to sieve.

[url]http://escatter11.fullerton.edu/nfs/crunching.php[/url]

:mike:

[QUOTE=Xyzzy;422231]It looks like we are about to run out of work to sieve.

[url]http://escatter11.fullerton.edu/nfs/crunching.php[/url]

:mike:[/QUOTE]Curiously enough, I was just about to post on that very topic.

Based on what I currently believe about the 14e queue, the GCW project has just about run out of candidates. My beliefs may be faulty, hence the decision to post.

Right now, there are two <C140 runts which I'll complete in the next few days.

These are the sub-S250 remainders:
[c]226.37 7,265- C168
227.22 7,266- C173
227.27 8,249+ C178
227.27 8,249- C173
227.35 6,289- C160
227.44 2,746- C219
227.58 5,322+ C207
227.74 4,374- C215
[/c] which, I believe, are rather too easy for NFS@Home and which I've been keeping back for individuals. Even If I do them all myself, it won't take me more than a couple of months. I further believe that S250 is the upper limit for the 14e queue.

As for GNFS, there are 12 <= C165 remaining. Excluding the runts, two more which are reserved and 6,289- above, there are seven. Polynomial searching will take a couple of days each with my resources.

What are the true limits on the 14e queue? If the upper limit can be stretched there are six C166 and 28 <S252, of which 12 are < S251.

Sam Wagstaff is already running ECM on the S250-260 range and removing them by SNFS starting at the high end. If the smaller ones can be added to NFS@Home I'll need to liaise with him carefully.

Paul

Reserving C221_118_81

As far as I know all the holes in the Brent tables have had enough ECM run against them. Certainly none of the ones I factored were ECM misses.

@Jcrombie, did Prof Brent send you any details of how much ECM he had run against them?

Chris

PS. Should posts 580, 581 and this one (583) be in the queue management thread?