Conversation
cabal generally installs packages with default -O1 optmization unless forced by a manual install - the only way to force it always to be installed with optimization is to add this to the cabal file. Performance testing shows that the extra level of optimization gives a boost in execution speed of about two times, and for the prime counting function about two and a half times.
This version is more concise, simplified, and thereby faster at about twice the speed of the old version for the same counting range and optimization level; it would be about 100 lines of code without the comments, but it is much better documented than the old version, also including a "HowPrimeCountingWorks.md" file to give even more details. This version does not call the Sieve of Eratosthenes (SoE) module, which was part of the cruft in using that module when there wasn't much point; the algorithm doesn't much depend for execution speed on SoE sieving and this new version just implements a simple odds-only SoE within itself. As specified, the module has been tested with GHC compiler versions 9.0.2, 9.2.8, 9.4.8, 9.6.7, 9.8.4, 9.10.2, and 9.12.2; version 14.1.0 was not tested because it is in the Release Candidate stage amd thus not able to be installed through "ghcup". I could not get it through the tests without hanging at toPrimeIntegral Integer -> Int and don't know why it would change as it woudn't seem counting primes would have anything to do with that, but the new version has been tested extensively as to counting accuracy outside the testing framework.
Upgraded PrimeCount to something a little faster and better documented. Also: - added a documentation file: "HowPrimeCountingWorks.md". - upped the version of "integer-roots" to 1.0.4.0 so `Word64` is a specialization for square root. - made the optimization default to level 2. - tweaked some benchmark settings to make them complete faster.
|
As a crude benchmark, I ran |
I'm happy to help, and yes, that is about the expected ratio of improved performance on top of the about 2.5 times due to using As I have mentioned before, the Meissel algorithm I am working on won't be all that much faster than this Legendre implementation, at least for smallish counting ranges such as this, but of course the main reason for wanting it is to reduce the memory consumption from O(n^(1/2)) to O(n^(1/3)). There is also some room for some constant factor speed improvements by improving the sieving, but that gets more and more complex... |
2 participants
Word64is a specialization for square root.