On Monday, 20 June 2016 16:35:09 UTC+7, Michael Jones wrote: > > Your code (with slightly changed print formatting) on my MacBook Pro: > > $ go install > $ time fasterEratspeed > Init: 2.885352ms > Search: 284.849689ms, found 8621475 primes up to 1018429650 > Total: 287.735041ms > > real 0m0.302s > user 0m0.287s > sys 0m0.007s > > > It is pretty complicated to me so I don’t understand why the values > printed are as they are. My sense of prime number counts is that > the 8621475th prime is 153339973. (Mathematica thinks so too.) > > My old illustrative Go SoE code does this calculation pretty quickly: > > BenchmarkNew153339973 5 312174802 ns/op > > That’s 312.174802ms to construct and retain a sieve for the > first 153339973 integers, count the total number of primes included, and > determine the final one in the range. Compiling with “-B” is a big help > here... > > BenchmarkNew153339973 5 281989575 ns/op > > ...reducing the total time to 281.989575ms >
I hope you say my message below showing a new play link correcting the code (somehow one of my computers does want to reply to a message, but only add to the thread), which was culling to a billion but only counting about 1/6th of the primes sieved. You'lll find that the corrected program really can sieve to a billion in that amount of time, making it quite a bit faster than your probably odds-only version. By your timing results, I'm guessing that you have an almost top-of the line late model 15" MacBook Pro with the 2.5 GHz i7-4770HQ quad-core CPU that can Turbo Boost to 3.7 Ghz, which is where this test was probably run as it is short enough not to heat the CPU. Am I right? > > On Jun 20, 2016, at 3:40 AM, gordo...@gmail.com <javascript:> wrote: > > > The golang FasterEratspeed that implements this maximum wheel > factorization version is posted at play.golang at: > https://play.golang.org/p/8Bo04bnT5F and runs about 33% faster than the > previous standard wheel factorized version, just as the ratio of operations > suggests that it should; also, because it minimizes array access it doesn't > matter much whether array bound checking is enabled or not. This is almost > as fast as the highly optimized C++ primesieve (http://primesieve.org/) > run signle threaded on my cache access speed bottle-necked machine, but on > faster machines it will be slower than primesieve, as much as twice as slow > on high end Intel desktop CPU's. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
