Implement integer modular exponentiation using BigInteger#mod_pow

[skateman]

As @eregon suggested here I replaced the modular exponentiation in Integer#pow with the more effective BigInteger#mod_pow using a primitive.

I also found out that the Integer#pow wasn't raising a TypeError when the 1st argument was not an integer, which results with the following in MRI:

irb(main):012:0> 10.pow(0.1, 1)
 => TypeError (Integer#pow() 2nd argument not allowed unless a 1st argument is integer)

Note that this message is not grammatically correct, but I copy-pasted it from MRI. If it's not good, please let me know how it should look like.

After this change the 2nd example from here runs faster (2.934s for me), but still significantly slower than in MRI. However, the profiling shows that the bottleneck is no longer the pow:

--------------------------------------------------------------------------------------------------------------------------------------------------
 Thread: Thread[main,5,main]
 Name                                                       |      Total Time     |  Opt % ||       Self Time     |  Opt % | Location             
--------------------------------------------------------------------------------------------------------------------------------------------------
 block in Object#divisors                                   |        776ms  30.7% |   0.0% ||        556ms  22.0% |   0.0% | bench.rb~14:508-594 
 Range#each                                                 |       2425ms  95.9% |   0.0% ||        285ms  11.3% |   0.0% | (core)~1:0 
 Object#prime?                                              |        637ms  25.2% |   0.0% ||        272ms  10.8% |   0.0% | bench.rb~1-10:0-433 
 Integer#pow                                                |        269ms  10.6% |   0.0% ||        269ms  10.6% |   0.0% | src/main/ruby/truffleruby/core/integer.rb~123-128:3646-4011 
 Integer#gcd                                                |        234ms   9.3% |   0.0% ||        212ms   8.4% |   0.0% | src/main/ruby/truffleruby/core/integer.rb~231-241:6276-6518 
 Numeric#zero?                                              |        144ms   5.7% |   0.0% ||        144ms   5.7% |   0.0% | src/main/ruby/truffleruby/core/numeric.rb~174-176:4823-4853 
 block in Object#long_prime?                                |        374ms  14.8% |   0.0% ||        105ms   4.2% |   0.0% | bench.rb~22:786-856 
 Object#long_prime?                                         |       2271ms  89.8% |   0.0% ||         80ms   3.2% |   0.0% | bench.rb~20-24:736-868 
 Array#each                                                 |       2407ms  95.2% |   0.0% ||         75ms   3.0% |   0.0% | (core)~1:0 
 BasicObject#!=                                             |         77ms   3.0% |   0.0% ||         69ms   2.7% |   0.0% | (core)~1:0 
 Integer.sqrt                                               |        129ms   5.1% |   0.0% ||         63ms   2.5% |   0.0% | src/main/ruby/truffleruby/core/integer.rb~309-313:7459-7587 
 block in Enumerable#count                                  |       2285ms  90.4% |   0.0% ||         60ms   2.4% |   0.0% | src/main/ruby/truffleruby/core/enumerable.rb~118:4184-4222 

Fixes #1999

[graalvmbot]

Hello Dávid Halász, thanks for contributing a PR to our project!

We use the Oracle Contributor Agreement to make the copyright of contributions clear. We don't have a record of you having signed this yet, based on your email address skateman -(at)- skateman -(dot)- eu. You can sign it at that link.

If you think you've already signed it, please comment below and we'll check.

[eregon]

Could you check if this passes the specs?
Run them with:

jt test spec/ruby/core/integer/pow_spec.rb

It would be good to add specs for the new exception case that was missing, and other combinations of pow arguments with "Bignums".

[eregon]

Regarding performance, it would be interesting to run this benchmark on MRI using stackprof to see where the remaining overheads are.

[eregon]

And I should have said this first: thanks for the PRs!

[graalvmbot]

Dávid Halász has signed the Oracle Contributor Agreement (based on email address skateman -(at)- skateman -(dot)- eu) so can contribute to this repository.

[skateman]

@eregon I am unable to build the latest master, so I can't really rebase against it to fix the merge conflict.

I implemented the BigIntegerCastNode and it works fine, however, the Java.math.BigInteger.modPow method returns an ArithmeticException if the modulo is <=0 while the MRI implementation gives you a valid result for anything <0:

# TruffleRuby with modPow
3.pow(2, -14)
=> ZeroDivisionError

3 ** 2 % -14
=> -5

# MRI
3.pow(2, -14)
=> -5

3 ** 2 % -14
=> -5

How should I handle this corner-case? Should I create a specialization that falls back to ``** %`?

[eregon]

The "Conflicting files: CHANGELOG.md" shown on GitHub is actually not a conflict, it's a bug in GitHub UI not considering

truffleruby/.gitattributes

Line 3 in 3fb1262

/CHANGELOG.md merge=union

I am unable to build the latest master

What's the issue? It might be easier to discuss on Slack for that.

Regarding the negative modulo you can look at what JRuby does:
https://github.com/jruby/jruby/blob/9.2.8.0/core/src/main/java/org/jruby/RubyInteger.java#L816-L819
Using ** % would have the same performance issue as before, so we should avoid that.
So one way is to have a different specialization if the modulo is negative.

[skateman]

@eregon I addressed all the issues.

[eregon]

Thanks! I'll merge this.