How Do Version Numbers Work for Mri Ruby

How do version numbers work for MRI Ruby?

They have changed to quasi-semantic versioning starting with Ruby 2.1.0. See https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ for further details, but the version numbers will now have the following meaning:

MAJOR: increased when incompatible change which can’t be released in MINOR
    Reserved for special events
MINOR: increased every christmas, may be API incompatible
TEENY: security or bug fix which maintains API compatibility
    May be increased more than 10 (such as 2.1.11), and will be released every 2-3 months.
PATCH: number of commits since last MINOR release (will be reset at 0 when releasing MINOR)

Ruby MRI 2.0.0 - Standard Library gems versions

You can look at Ruby's source-code to determine versions.

Look in the "ext" folder to find the Std-Lib stuff.

Drill down into a particular class or module to find its version.rb file. For instance, JSON's version.rb says it's currently at version 1.7.7.

If you're worried about having the most recent version of JSON, from my experience it's not necessary. Ruby gems picked up the 1.8.1 version from the Ruby-gems repo and upgraded to it on my machine, even though 1.7.7 came with Ruby v2.0p353:

gem list json

*** LOCAL GEMS ***

json (1.8.1, 1.7.7)

How to get ruby version with patch number

The constant RUBY_PATCHLEVEL gives you the current patch level.

RUBY_VERSION
=> "2.0.0"
RUBY_PATCHLEVEL
=> 247

MRI ruby threading and performance

Once you hit a high amount of threads (5000), the amount of overhead for switching between threads by the scheduler far outweighs the amount of work that each thread actually does. Typically you want 30-50 threads max.

Try lowering the amount of threads and proportionally increasing the amount of work that each does:

  20.times.map do
    Thread.new do
      250000.times do
        array << nil
      end
    end
  end.each(&:join)

and you should see far more comparable results.

Note you will probably see the lower bound Time(threaded) >= Time(non-threaded) - that is the Threaded version's time can't be lower than single-threaded version. This is because of the MRI's GIL which allows only one thread to execute at a time (they can never run in parallel). Some ruby implementations such as JRuby allow parallel execution of threads.

Is there any way to find the number of CPU cores in MRI Ruby (perhaps using a C extension)?

So far there isn't. But you can either use parallel gem or take a look how it figures out the number of cores.

What kind of memory reclamation algorithm does MRI Ruby 1.8 use?

The garbage collector Ruby 1.8 is actually quite awful. Every 7Mb of allocation it will perform a mark phase from all root objects and try to find which can be reached. Those that cannot be reached will be freed.

However, to find out what objects are reachable, it checks the stack, the registers and the allocated object memory. This allows for some false positives but eases writing C extensions: C extensions don't have to reference and deference, since the stack and so on which C extensions used are automatically scanned.

Furthermore, the state of the object (referenced or not) is kept in the state of each object. This is quite bad for cache behavior and copy-on-write behaviour: a lot of cache lines are touched during this process, and ruby interpreters do not share as much memory as they could if you've got more then one (relevant for server deployment like Ruby on Rails). Therefore, other implementations exists (Ruby Enterprise Edition) which do this in a separate part of the memory to speed GC up.

Also a problem are long linked lists. Since mark-and-sweep uses the stack to do the recursion, a long linked lists segfaults ruby.

The GC does also no compaction and this becomes problematic in the long run.

If you run JRuby however, those problems will disappear while keeping Ruby 1.8 compatibility to some extend.

How important is it to keep up with Ruby patch levels?

If the Ruby patches are specifically for security issues, then I would make these a priority to upgrade as soon as is possible. Having a good test suite makes this process much less stressful.

The more nuanced answer is that you should read the security releases and decide for yourself, but security issues are notoriously hard to think through the implications for. So the rule of thumb is to Just Upgrade!

The worst case if you don't upgrade is that Bad Guys will exploit the loophole (because they can read security releases too), and gain access to your servers, steal your customer email and password database and delete all your data.

Suddenly the process of upgrading doesn't sound so difficult!

As a shameless plug, I'm building a service to alert you when your current Gems and Ruby version needs to be patched, so you won't forget. Sign up for early access at http://www.rubyaudit.com

---

Related Topics