20180909, 17:25  #23  
"Tilman Neumann"
Jan 2016
Germany
2×11×19 Posts 
Quote:
I typed in a number that fits into the window, so the answer should definitely come instantly? Code:
19700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000197 Last fiddled with by Till on 20180909 at 17:26 Reason: typo 

20200501, 22:28  #24  
Jun 2015
Vallejo, CA/.
961_{10} Posts 
Quote:
For instance π(2^{90} is very close to π(10^{27}) and while the next exponent (10^{28} is a difficult task I would think some progress might be there after almost 5 years. Last time it took about a year to go from 10^26 to 10^27 

20200506, 07:21  #25  
Sep 2015
21_{8} Posts 
Quote:
I don't exactly know which values David is currently computing using primecount, but we will announce important new records here on the mersenneforum. I don't want to publicly disclose ongoing computations as this could give competitors a strategic edge. If you would like to contribute and use primecount to compute new records please send me an email and we can discuss privately and I can share more information. 

20200524, 12:35  #26 
"Dana Jacobsen"
Feb 2011
Bangkok, TH
5×181 Posts 

20200529, 18:49  #27  
Bemusing Prompter
"Danny"
Dec 2002
California
2303_{10} Posts 
Quote:


20200830, 10:04  #28 
Aug 2005
115_{10} Posts 
New prime counting function record, pi(10^28)
I am happy to announce that Kim Walisch and I have computed the number of primes below 10^28, the result is:
pi(10^28) = 157,589,269,275,973,410,412,739,598 The computation was performed using a version of Kim's primecount program with backup functionality. primecount counts primes using a highly optimized parallel implementation of Xavier Gourdon's algorithm (combinatorial method). The computation took 26.42 CPU core years (only physical CPU cores are counted) and the peak memory usage was 370 gigabytes. My part of the calculation was run on a dual socket server (36 CPU cores, 2x Intel Xeon E52699 v3). The rest of the computation was run on a single socket server (48 CPU cores, 1x AMD EPYC 7642). Our result passes the parity check and the result is also very close to RiemannR(10^28), i.e.:  R(10^28)  157,589,269,275,973,410,412,739,598 < sqrt(10^28) / log(10^28) As can be expected with such a large and protracted calculation, a few hardware issues were dealt with. However, the software is extremely robust and we have sufficient confidence in the result. We will start a full verification shortly by recalculating pi(10^28) a second time using different configuration parameters and an improved version of primecount. We expect this verification to take less than a year. Best regards, David Baugh 
20200830, 10:31  #29 
Romulan Interpreter
Jun 2011
Thailand
8,741 Posts 
yay!

20200830, 11:31  #30 
"Dana Jacobsen"
Feb 2011
Bangkok, TH
905_{10} Posts 
Fantastic! I've been following the git repo watching the continuing improvements to the code.

20200830, 20:38  #31  
Sep 2015
10001_{2} Posts 
Quote:
What David has not mentioned is that we had a miscalculation of PrimePi(1e28) at the beginning of the year. It was depressing! That computation was started back in August 2017 jointly by David and myself using the DelegliseRivat algorithm. At the time I had significantly improved the sieving algorithm of the hard special leaves formula (S2_hard) and the benchmarks of the new implementation were very promising. I expected that we could compute PrimePi(1e28) in about 6 to 8 months. So we started the computation but we soon realised that my estimations were too optimistic and that the S2_hard formula had severe scaling issues. After running that formula for about 18 months on a dualsocket server it still had not completed and it was difficult for me to estimate how much longer it would run. Every month I estimated that it would finish next month. Another issue was that the backups were happening very infrequently, sometimes it took more than a month until the program would write a new backup to disk. So what happened frequently is that we lost a lot of work due to power outages or my EC2 spot instances got killed for various reasons. At the end of 2019 the issue of infrequent backups become so annoying that we decided to manually edit the backup files to reduce the thread sieving distances in order to increase the backup frequency. That was likely a big mistake! When the computation of the S2_hard formula finally finished after about 2.5 years we calculated the final sum and we immediately realised that the result was not correct, it was orders of magnitude off. This was the first primecount miscalculation in about 3 years and unfortunately we couldn't even tell which formula had been miscalculated, we guess it is S2_hard but we don't know for sure. Because of that miscalculation, I started the tiring work of rechecking every single formula/algorithm and I reread all the combinatorial prime counting papers. After a few weeks I had such a indepth understanding of all the different formulas and algorithms that I realised that the scaling issue we had experienced was not a hardware issue as I expected but rather an unsound optimization that I had copied from other people's implementations. The problem is/was that theory and practice have diverged significantly. All math papers describe that one must compute the special leaves using a binary indexed tree, however most of the prime counting function implementations that one can find on the web don't do this, instead most implementations use a large number of micro optimizations to quickly count the number of unsieved elements from the sieve array. Once I understood that these optimizations were deteriorating the runtime complexity of the algorithm and hence causing my scaling issue it did not take long until I found a simple but significant improvement that fixed my scaling issue: https://github.com/kimwalisch/primec...cialLeaves.md. So in the end that miscalculation was hugely beneficial to primecount: I implemented Gourdon's algorithm, I found an improvement that fixed the scaling issue of the hard special leaves formula and I also improved the backup functionality (more frequent backups + checksums). When we recomputed PrimePi(1e28) using Gourdon's algorithm the computation of the hard special leaves took only 37 days (instead of 2.5 years). Here is another example that shows how much primecount has improved since our last record: PrimePi(1e27) took 23.03 CPU core years whereas PrimePi(1e28) took only 26.42 CPU core years. Usually you can expect that computing a 10x larger value takes about 5x more time. Hence for record computations primecount has been sped up by about 4x since 2015. 

20200831, 03:01  #32 
Jun 2015
Vallejo, CA/.
31^{2} Posts 
Well, I must say it is impressive.
Congratulations to both of you. 
20200831, 16:58  #33  
Aug 2006
1723_{16} Posts 
Quote:


Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Prime gap records  MJansen  Prime Gap Searches  28  20200509 12:46 
Is there a powercounting function?  enzocreti  enzocreti  10  20200215 13:23 
Prime counting function  Steve One  Miscellaneous Math  20  20180303 22:44 
Prime counting function records  D. B. Staple  Computer Science & Computational Number Theory  43  20161225 22:15 
Legendre's prime counting function  pbewig  Information & Answers  0  20110714 00:47 