Loading ...
Sorry, an error occurred while loading the content.
 

New AP14 record

Expand Messages
  • mikeoakes2
    Here is a new AP14 records at 71 digits:- (145978014+25313115*n)*157#+1 is prime for n=0..13 All confirmed prime with PFGW -tc Input/output statistics:-
    Message 1 of 11 , Dec 10, 2009
      Here is a new AP14 records at 71 digits:-

      (145978014+25313115*n)*157#+1 is prime for n=0..13

      All confirmed prime with PFGW -tc

      Input/output statistics:-
      Numbers tested by NewPGen: 2*10^9
      NewPGen reduced these (by sieving to 100 billion) to: 4.06*10^8
      PRP's found by PFGW: 112,989,593
      AP13's found: 2
      AP14's found: 1

      Run-time statistics:-
      NewPGen: 5 GHz-hrs
      PFGW: 2 GHz-days
      Pascal program to find an AP14: 57 GHz-days

      The AP13 count was well below the Poisson-expected 16.
      The search program was killed at this point, at about 1/4 of the way through.

      Jens, this only creeps marginally above your nontrivial 2007 record announced in:
      http://tech.groups.yahoo.com/group/primeform/message/8760
      Do you have any stats on that - or on your search algorithm?
      (I can't see that any further speed-up is possible with mine.)

      -Mike Oakes
    • Jens Kruse Andersen
      ... Congratulations on beating my record. http://users.cybercity.dk/~dsl522332/math/aprecords.htm is updated. ... My old file shows 16 AP13 before the AP14. It
      Message 2 of 11 , Dec 10, 2009
        Mike Oakes wrote:
        > Here is a new AP14 records at 71 digits:-
        >
        > (145978014+25313115*n)*157#+1 is prime for n=0..13

        Congratulations on beating my record.
        http://users.cybercity.dk/~dsl522332/math/aprecords.htm is updated.

        > Jens, this only creeps marginally above your nontrivial 2007 record
        > announced in:
        > http://tech.groups.yahoo.com/group/primeform/message/8760
        > Do you have any stats on that - or on your search algorithm?

        My old file shows 16 AP13 before the AP14.
        It was on my 2.4 GHz Core 2 Duo. The AP14 was found with a
        C program 9 days after the AP detection stage started.
        It probably ran nearly the whole time but I don't remember.
        It used one core. Another project ran on the other core.
        It's my only computer and is also used for lots of other
        things but usually not cpu intensive.
        I guess it used around 20 GHz days on AP detection.

        I will get back to you on search algorithm within a couple
        of days when I have better time.
        The program has not changed since the start of 2005.
        I think we have discussed something about algorithms since then.
        I have not searched AP's since 2007.

        --
        Jens Kruse Andersen
      • Jens Kruse Andersen
        ... I use the same C program as when we discussed in April 2006: http://tech.groups.yahoo.com/group/primeform/message/7180
        Message 3 of 11 , Dec 12, 2009
          Mike Oakes wrote:
          > Do you have any stats on that - or on your search algorithm?
          > (I can't see that any further speed-up is possible with mine.)

          I use the same C program as when we discussed in April 2006:
          http://tech.groups.yahoo.com/group/primeform/message/7180
          http://tech.groups.yahoo.com/group/primeform/message/7185

          Back then you said your detector doesn't try to optimize caching.
          I said no cache optimization is bad in a program mostly doing
          lookups in large tables.
          I don't know whether your program has changed since then.
          Some of my programs become several times faster when they
          work on smaller tables or parts of a table at a time, so the used
          data fits in cache most of the time.
          If it's complicated to get good cache performance with large tables
          then you can consider making several smaller tables one at a time
          and only search for AP's fitting inside a small table. You will need
          more prp's if you only test potential AP's with small common
          differences but better cache performance may be well worth it.

          C also tends to be faster than Pascal.
          Make sure the Pascal compiler doesn't add code for array bounds checking.

          --
          Jens Kruse Andersen
        • Jack Brennen
          ... Years ago when I wrote a program to search for small long CCs and BiTwins, I found a roughly 3x - 5x performance boost by working in smaller chunks of
          Message 4 of 11 , Dec 12, 2009
            Jens Kruse Andersen wrote:
            > I said no cache optimization is bad in a program mostly doing
            > lookups in large tables.
            > I don't know whether your program has changed since then.
            > Some of my programs become several times faster when they
            > work on smaller tables or parts of a table at a time, so the used
            > data fits in cache most of the time.

            Years ago when I wrote a program to search for small long CCs
            and BiTwins, I found a roughly 3x - 5x performance boost by
            working in smaller chunks of memory which could fit in the
            CPU's level 1 memory cache.

            Yeah, 3x - 5x faster...
          • mikeoakes2
            ... I m sure what you say here is very important - I ll have another look at precisely that caching question. (It s not easy, tho...) ... Not much,
            Message 5 of 11 , Dec 12, 2009
              --- In primeform@yahoogroups.com, "Jens Kruse Andersen" <jens.k.a@...> wrote:
              >
              > Mike Oakes wrote:
              > > Do you have any stats on that - or on your search algorithm?
              > > (I can't see that any further speed-up is possible with mine.)
              >
              > I use the same C program as when we discussed in April 2006:
              > http://tech.groups.yahoo.com/group/primeform/message/7180
              > http://tech.groups.yahoo.com/group/primeform/message/7185
              >
              > Back then you said your detector doesn't try to optimize caching.
              > I said no cache optimization is bad in a program mostly doing
              > lookups in large tables.
              > I don't know whether your program has changed since then.
              > Some of my programs become several times faster when they
              > work on smaller tables or parts of a table at a time, so the used
              > data fits in cache most of the time.
              > If it's complicated to get good cache performance with large tables
              > then you can consider making several smaller tables one at a time
              > and only search for AP's fitting inside a small table. You will need
              > more prp's if you only test potential AP's with small common
              > differences but better cache performance may be well worth it.

              I'm sure what you say here is very important - I'll have another look at precisely that caching question. (It's not easy, tho...)

              > C also tends to be faster than Pascal.
              Not much, necessarily.
              I co-authored the compiler I'm using:
              http://en.wikipedia.org/wiki/Prospero_Pascal
              so am familiar with (how good:-) its code generator is.

              > Make sure the Pascal compiler doesn't add code for array bounds checking.
              Of course!

              Thanks for your input.

              Mike
            Your message has been successfully submitted and would be delivered to recipients shortly.