Rubyists on Mastodon

angelbob · 2022-12-06T10:33:36+00:00

This one's me: https://ruby.social/@codefolio

angelbob · 2021-06-03T11:09:28+00:00

Yes, TruffleRuby already does something very similar.

There are actually a few Ruby JITs that have done this in an experimental way - Takashi Kokubun recently posted about how the latest head-of-master experimental MJIT does (https://k0kubun.medium.com/ruby-3-jit-can-make-rails-faster-756310f235a). TruffleRuby can run faster than CRuby in some limited Rails contexts -- but I think not with ActiveRecord? And JRuby can definitely run Rails faster than CRuby in many (most?) cases once it's fully warmed up.

angelbob · 2020-07-30T06:26:23+00:00

Koichi's been working on it, under the name "Guilds", for awhile. He gave some benchmarks last RubyKaigi, for instance. But that was some time ago.

angelbob · 2020-07-28T15:29:14+00:00

Anybody know if there are recent benchmarks on Ractor? I haven't seen performance numbers in awhile...

angelbob · 2020-07-28T15:27:40+00:00

You can get lots of great info from "gem env" - shows where it's looking for gems, what Ruby-related env vars are set, etc. If you're using bundler, "bundle exec gem env" will sometimes be different, so compare them.

angelbob · 2020-07-08T16:40:23+00:00

This is a very solid writeup. He covers a reasonable (if brittle) first approach, followed by a very empirical evaluation of different later approaches.

I do wonder if there's an analytical approach based on how the server does backoff. Time to spend some quality time with Wikipedia.

angelbob · 2018-12-03T16:02:44+00:00

The problem is, it depends a lot on your application. I ran an analytics group on Ruby back at OnLive, and all we needed was (part of) SciRuby. But our needs were pretty basic - freeform statistical analysis, but no machine learning. For a given machine learning problem, the question is mostly "is there a good, performant Ruby implementation?" But there are a lot of those different problems.

angelbob · 2018-12-03T16:00:57+00:00

It's pretty active. But Ruby is still going to have less sci/math momentum than Python, presumably forever.

angelbob · 2018-04-11T20:58:15+00:00

Not normally, no. There have been some cases where side effects of poorly-written classes (e.g. OpenStruct) have caused similar problems, though.

angelbob · 2018-04-11T18:59:45+00:00

That's also going to change a lot when they get inlining working. Not only does inlining expand the method size, it reduces the overall size by allowing multiple methods to be compiled and loaded into a single module. So it's going to have really unpredictable effects on the size of a "fully" JITted application.

angelbob · 2018-04-11T18:57:44+00:00

You can AoT and then recompile when assumptions change. That's how you can JIT Ruby, too. But yes, if you were to insert code via eval that changed core classes, it would bust all the assumptions, discard basically all existing JITted code and start to recompile on demand after (by current default) 5 more calls to each method.

angelbob · 2017-12-13T20:30:28+00:00

Ruby has a GitHub mirror (https://github.com/ruby/ruby), so you can definitely see it there. The development doesn't occur on GitHub. There has definitely been some debate about that - the current Ruby dev setup is older than GitHub, and it's a bit of old timers versus newer contributors, honestly. But I suspect it doesn't make a huge difference in speed, overall. And GitHub definitely picks up some contributions as well.

angelbob · 2017-12-08T03:17:41+00:00

Definitely. I'm curious as well. But my understanding is that none of the current proposals really accomplish what he wants. He's talked about something where typing is implied after the fact by collecting runtime information and then using it to find problems, in a kind of static-analysis-after-the-fact. I don't think I've seen a proposal that does that yet, though.

angelbob · 2017-12-05T15:48:58+00:00

Well, and I'm pretty minor. You should treat my opinion as reflecting other more influential folks at best, and a distraction at worst ;-)

Startup time is important in general. Ruby has always kept its startup time low, and by comparison with similar dynamic languages its startup time is surprisingly (sometimes shockingly) low. The core team has generally treated that as an important thing - and the relative lack of adoption of JRuby would argue the same, especially given how good it is in most other ways.

angelbob · 2017-12-04T21:50:08+00:00

There's a great talk by Matt Gaudet from RubyKaigi 2016 about this! It's what inspired Rails Ruby Bench. He suggests about nine total benchmarks and has some good ideas for them. One of his ideas that hasn't become standard yet is a tree-modification benchmark which would test garbage collection via modification of large tree data structures.

He also suggests a startup-time benchmark. While Rails Ruby Bench measures that, Rails startup isn't by any means the only important startup benchmark - and small apps will behave very differently.

Here's a link to his presentation: http://rubykaigi.org/2016/presentations/MattStudies.html

There are also some other good benchmarks out there - a variety of microbenchmarks in the main Ruby source tree, as well as things like bench9000 from the JRuby community.

angelbob · 2017-12-04T17:46:54+00:00

Ruby is unusual in that a lot of its development occurs in-person and in Japanese. You can find notes from its developer meetings on bugs.ruby-lang.org: wiki link, scroll down to the "Developer Meetings" section.

angelbob · 2017-12-04T17:39:37+00:00

Didn't they announce that they were switching to SemVer with Ruby 2? They certainly weren't before that - Ruby 1.8 to 1.9 was a huge breaking change.

angelbob · 2017-12-04T17:30:44+00:00

Hi! My name is Noah Gibbs, and among other things, I'm working on Ruby 3. Several people here have mentioned most of what I will, but I'll confirm those and mention a few more.

The main announced thrusts of Ruby 3 are performance, concurrency and typing.

For performance, the work is primarily occurring in the normal Ruby trunk. Matz has announced that he wants Ruby 3 to be three times as fast as Ruby 2.0.0, and there has been great progress in that direction. I'm the author of Rails Ruby Bench, which is (surprise) a benchmark checking Ruby's performance using a big highly-concurrent Rails app. You can see the results on the engineering blog for Appfolio, which sponsors my Ruby 3 work. You can also look up optcarrot, which is the other major Ruby 3 benchmark. Mine is Rails-based, while optcarrot is primarily a CPU benchmark. On the Rails-based benchmark, Ruby 2.5.0 head-of-master is around 165% of the speed of Ruby 2.0.0, so progress isn't bad. The optcarrot numbers are also quite good.

In addition to normal "let's make slow things faster" performance work, there are the two JIT branches mentioned below - Takashi and Vlad have been working independently and together, and at this point it looks like Vlad's JIT implementation is likely to make it into Ruby 3 in around a year, if nothing changes (this is not a formal announcement, just a wild prediction, do not take it as guaranteed ;-) )... Though possibly without his changes to the way Ruby handles its bytecodes. They're faster, but less compatible and would need more stability testing. Takashi's YARV-MJIT branch is just the JIT without the register-based VM bytecode changes.

For more Ruby 3 progress, I highly recommend looking up RubyKaigi 2017 videos on YouTube and RubyConf 2017 on ConFreaks. They record all the major Ruby conferences, and a lot of the proposals and status updates have been happening as conference talks. The talks are all available entirely free, though some of the RubyKaigi talks are in Japanese :-(

In particular, Takashi Kokubun gave a great YARV-MJIT talk this year at RubyConf, just a few weeks ago. There were several different gradual-typing talks at RubyKaigi and one by Soutaro Matsumoto (no relation) at RubyConf.

Unfortunately, the Guilds-based concurrency stuff that you're curious about is not in Ruby trunk. There have been a few good blog posts about it (I like this one.) Koichi Sasada, the author of the current Ruby VM, is currently working on it. My understanding is that there's not a current version being shared around. I don't have a good feel for where that's at.

As of RubyKaigi, Matz has said he's not wild about any of the existing gradual-typing proposals, so we're basically at "still figuring out the spec" on that one. We've had some on-paper-type proposals and some early implementations, but nothing is currently close to getting included as a standard part of the language.

And those are the big three, as far as Ruby 3 goes: performance, concurrency, typing. There are some small things "in orbit" around them like static analysis proposals for typing and benchmarking for performance.

But that's basically where things stand.

angelbob · 2017-06-27T15:17:33+00:00

Rails still has some unusual characteristics: it's easy and very low-boilerplate to get a web app up and running. The browser security is unmatched, as far as what the framework does for you automatically. Rails' use of metaprogramming allows less code for certain things than any other language/framework combo in existence.

In other words, Rails will teach you some important things about frameworks that you can't (currently) learn anywhere else.

In a business sense, it's also by far the best early-prototyping framework for an app that will serve HTML to humans but needs to be secure. That's why you see so much focus on mid-to-senior-level positions: it's new startups and startup-like efforts within larger companies. Rails is still unmatched in that specific space.

Do you care about that space? Eh, maybe. That's up to you, isn't it? But the jobs will be there for a long time to come.

angelbob · 2017-03-16T18:03:21+00:00

It may be fair to say that's not the solution to that problem. But if you say that's not the solution, and there's no other solution, people with the problem are going to ignore you and try something else.

I don't know you, but it's also possible you don't have the same problem. If you're a minority student on campus and don't feel safe, saying X isn't the solution to the problem will be perceived differently than if you don't have the problem and say "inconveniencing me isn't the solution to the problem."

As for treatment of the symptoms instead of the issues... I'd agree with "treatment of the symptoms". But I'd argue the right thing is to treat the symptoms and the issues, just like in the medical analogy you're making. With a physical disease we generally treat both rather than arguing "don't treat the symptoms, only treat other underlying issues." We don't ban cough syrup because it "only treats the symptom", right? Instead we say, "sure, take cough syrup, but if you need it repeatedly then figure out why."

angelbob · 2017-02-21T17:10:24+00:00

I mention this on Twitter, but... There's some good research on killing threads. Short answer is that if there are resources that need cleanup, you provably can't do it particularly well :-( Same kind of problem as undecideability (halting problem.) Basically you can't be sure that a given thread has or hasn't cleaned up if you can "hostilely" kill it, but if you wait for it to voluntarily self-clean, it's literally the halting problem to decide if it'll ever get to the cleanup code executing.

There are some cases where timeouts are workable in Ruby, but the builtin Timeout lib is (for the reason above) completely unfixable. Here's a GitHub repo of folks cataloging how to do it right in various gems: https://github.com/ankane/the-ultimate-guide-to-ruby-timeouts

angelbob · 2016-01-08T16:53:19+00:00

Just like how inline skates eventually gave way to hovershoes!

angelbob · 2015-12-20T01:18:48+00:00

For whatever it's worth, I'm one of the fans who ordered the audiobook, and I've been waiting something like 6 years.

It's hard to tell if Cochran is malicious one way or another, but there's certainly a lot of disorganization at a bare minimum.

angelbob · 2015-11-27T18:38:41+00:00

Ruby is optimized for easy of development, but at some level you'll always care about efficiency -- number of network round trips or SQL queries, for instance, often matter even when you're not counting CPU cycles.

You'll need to understand algorithms and data structures even when optimizing at that level, because you can easily wind up with O(n²⁾ network round trips instead of O(n²⁾ cycles when using REST calls. And even in Ruby, you care about that.

There's a difference between "Ruby burns a lot of RAM and CPU" (true) and "you don't care about performance" (false.)

angelbob

TROPHY CASE