I don't think you are going to find something. When it comes to optimization, Ruby and Java are actually pretty similar, the main pain point for both are boxed objects and dynamic method dispatch, which they both inherited from Smalltalk (Ruby directly, Java via its main inspiration Objective-C). And the Java VMs are quite simply the most advanced production execution environments for dynamically-dispatched OO languages there are. There may be some research stuff for Scheme, for example, that is even faster, but when it comes to production-ready industrial-strength implementations, Azul Zing, Oracle HotSpot, Oracle JRockit, IBM J9 and friends win hands down.

So, unless the Rubinius guys have invented something that the Smalltalk/Java community have overlooked, you'll pretty much end up with same performance at best.

Your best bet is not numerical processing but text processing. That's something where Ruby's Perl heritage shines. Most Java implementations' regex engines aren't very performant (although they are getting better), whereas Onigmo is actually quite good (not as good as Perl's, though). Plus, Ruby's character-encoding independent strings allow you to eliminate re-encoding your string, whereas Java's strings will always have to be encoded to and from UTF-16, unless the input and output encodings are UTF-16, which is highly unlikely. In Ruby, you need to transcode at most once, even if your input and output encoding are different, you can set the internal encoding to be the same as either the input or the output encoding, and thus you only have to transcode during either input or output, but not both.

There are examples, though, of Ruby competing with C, and since "everybody knows"™ that C is faster than Java, this surely must mean that Ruby is faster than Java, right? Right?

[Actually, finding examples where Ruby outperforms C is probably easier, since dynamic optimizations like speculative inlining, polymorphic inline caching, adaptive optimization, as well as "unsafe" optimizations enabled by dynamic de-optimization don't exist in typical C implementations.]

In particular, Rubinius's Hash class which is written in Ruby is not significantly slower than YARV's Hash class which is written in C.

And a really exciting example is that JRuby+Truffle+Graal+TruffleC can run YARV C extensions in a C interpreter on top of the JVM(!!!) faster than YARV can run C extensions natively:

• Very High Performance C Extensions For JRuby+Truffle by Matthias Grimmer and Chris Seaton
• Dynamically Composing Languages in a Modular Way: Supporting C Extensions for Dynamic Languages by Matthias Grimmer, Chris Seaton, Thomas Wuerthinger, Hanspeter Mössenböck, in Proceedings of the 14th International Conference on Modularity, 2015.
• High-Performance Cross-Language Interoperability in a Multi-Language Runtime by Matthias Grimmer, Chris Seaton, Roland Schatz, Thomas Wuerthinger, Hanspeter Mössenböck, in Proceedings of 11th Dynamic Languages Symposium (DLS)

[Of course, this latter example is actually an example of the power of Truffle and Graal, i.e. two Java technologies, more than it is an example of the power of Ruby.]