Miller Rabin algorithm can be used to test primality for integers smaller than a max value "MaxMR" (~3e24)
It can be much faster than previous implementation: ~100x faster for numbers with 13 digits, at least 5 orders of magnitude for even larger numbers (previous implementation is so slow that it requires more patience than I have for more precise estimate).
Miller Rabin test becomes faster than previous implementation at somewhere in the range 1e5-1e6. It seems that the range 62000..66000 is where Miller Rabin starts being always faster, so I picked 0xffff arbitrarily; before that, or above "MaxMR", the previous implementation remains.
I compared the `faster_prime` gem too. It is slower than previous implementation up to ~1e4. After that it becomes faster and faster compared to previous implementation, but is still slower than Miller Rabin starting at ~1e5 and up to MaxMR. Thus, after this commit, builtin `Integer#prime?` will be similar or faster than `faster_prime` up to "MaxMR".
Adapted from patch of Stephen Blackstone [Feature #16468]
Benchmark results and code: https://gist.github.com/marcandre/b263bdae488e76dabdda84daf73733b9
Co-authored-by: Stephen Blackstone <sblackstone@gmail.com>
* revert `rb_last_status_set`
* renamed the new function as `rb_process_status_new`
* `rb_process_status_new` always freezes the return value
* marked `Process::Status.wait` as EXPERIMENTAL, as it has not
been discussed totally yet.
This reverts commit bd47a8d660ab33a20c5e28d0effcc29105c434e4.
`libc_so` and `libm_so` are `nil` at line 124 because Big Sur doesn't have `/usr/lib/libSystem.B.dylib`.
The reassignment at line 127 is necessary in this case.
Revert "Lock the entire active_units loop"
This reverts commit 5c2ff88be2e515613dfe54823e8429656f688e9f.
Revert "Lock active_units references on compaction"
This reverts commit 556a7285080c1344c75bb93a333c9bfc5d631c61.
Revert "Wait for GC before unload_units"
This reverts commit a8f16df615daa55901bb351efe038e86b61fbb92.
Well, the previous revert actually didn't fix it, but this series of
reverts seems to rollback the situation a little.
* Windows: Read ENV names and values as UTF-8 encoded Strings
Implements issue #12650: fix https://bugs.ruby-lang.org/issues/12650
This also removes the special encoding for ENV['PATH'] and some
complexity in the code that is unnecessary now.
* Windows: Improve readablity of getenv() encoding
getenv() did use the expected codepage as an implicit parameter of the macro.
This is mis-leading since include/ruby/win32.h has a different definition.
Using the "cp" variable explicit (like the other function calls) makes it
more readable and consistent.
* Windows: Change external C-API macros getenv() and execv() to use UTF-8
They used to process and return strings with locale encoding,
but since all ruby-internal spawn and environment functions use UTF-8,
it makes sense to change the C-API equally.
* Use UTF-8 as default for Encoding.default_external on Windows
* Document UTF-8 change on Windows to Encoding.default_external
fix https://bugs.ruby-lang.org/issues/16604
Although gemspec file (e.g., power_assert and rake) often uses
`git ls-files`, as it does not make sense in other than its own
repository, it has been ignored now. Gather all files expanded
from the bundled gem to install, instead.
