22 ms·

Ruby 3.2’s YJIT is Production-Ready

481 points by onnnon 4y ago

patientplatypus 4y ago
[dead]
asim 4y ago
It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the HipHop VM for PHP code and compiling PHP to large C++ binaries. I mean I get it, you have millions of lines of code, you don't want to rewrite it, but I often wonder, is there a better solution to this? Is there just a natural path towards, write new things in a new language and leave the old behind? Genuine question, because I'm not talking about rewriting the stack, I'm just talking about not investing significant amounts of time in low level infrastructure that's totally unrelated to business priorities. Yes fast code means better user experiences but often there's alternative ways around this than doing some literal JIT compiler work.
- xoac 4y ago
  Someone has to do this work, and I this is a good example of a company giving back to what was originally a non-industry project (Ruby).
  - asim 4y ago
    Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.
    - olau 4y ago
      The loss of human time in big corporations is immense. Coordination overhead and losses due to information logistics problems. I'd imagine a project like this with no dependencies on the rest of the stack can be run efficiently. From a bang per buck point of view it might beat other means (rewrite, using multiple languages, redoing ops to run on cheaper backbone) by a huge factor. I get your sunk cost objection, but it's a bit depressing to hear people worry about someone doing genuinely useful work. Nobody wants to take responsibility or get their hands dirty. There's still plenty of low-hanging fruit in both language implementations and databases. The world today is just mountains upon mountains of bullshit.
    - xal 4y ago
      Creating and sharing powerful tools for people to build the things that they want to exist is kinda in Shopify's DNA. It's also important to me to give back to open source. It's done so much for us.
    - xoac 4y ago
      Well they have one of the bigger ruby/rails deployments so a 10% perf increase benefits them quite a bit.
- psychoslave 4y ago
  I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red. From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: https://github.com/codicoscepticos/ruby-implementations https://github.com/codicoscepticos/ruby-implementations
  - maxime_cb 4y ago
    Yes. Not only is YJIT directly integrated into CRuby, it's also 100% compatible with your existing Ruby code, which is why we chose to go that route. We didn't want to independently reimplement Ruby because we knew that this would lead to a situation where we wouldn't be 100% compatible, which would stop people from using YJIT. If you think about PyPy for example, they have great performance numbers, but relatively few people are using it.
    - v3ss0n 4y ago
      Yeah , it was because Guido himself was not promoting that project . PyPy team really tried hard to be compatible , now almost all c-extensions including DS libraries worked. I am using PyPy in production for 8 years and - it reduce memory load by a lot , ( 80 MB vs over 300 MB for tornado web service running) - it is so much faster than python that is comparable to node in high load peformance. - it would be compatibile with every lib if Main Stream Python community had even tried it and work on it.
- giraffe_lady 4y ago
  I think thinking of the "sunk cost" as being only or even primarily code is incomplete. It's internal expertise in that language, understanding of its strengths and weaknesses and how they fit into your business needs, custom tooling around dev, debugging & deployment, practice evaluating candidates for expertise in it, particular strengths of that language not guaranteed to be in a replacement, just all of the "unknown unknowns" that you now know through bitter experience. Surely there will still be a point where it's worth throwing all that out and starting fresh, but some of those are very hard to quantify or even see, when you have them, so the conservative choice is to stay put in the system that works.
- ryanianian 4y ago
  You can often solve ~70% of this with language interop. Bindings and FFIs are in my opinion very under-appreciated. This is the approach taken by PHP+HipHop, Apple with Swift/ObjC, and many Python bindings over C++ internals (TF etc). There is no magic bullet. You can't do an overnight transition. If you decide to make a language shift (or equivalently large architecture shift), you need an interop. Old and new have to coexist. The remaining 30% (where interop fails) is where engineering happens and is often where you had hidden technical debt anyway.
- jrochkind1 4y ago
  The JVM is as performant as it is because so much resources were invested in optimization (including various forms of JIT etc). It's an amazingly performant VM because of so much invested in tuning it. Or same about various Javascript VMs. This kind of performance comes from lots of resources invested in tuning. Lots of resources are invested, generally, when there are lots of entities relying on a thing; that's a very good reason people invest in improving a thing, right? So I'm not really sure what you mean -- you say "sunk cost", I say "Well, those who are using a thing are those who invest in improving it, how is it ever any different? And that there are people with current investments in ruby who will continue to invest to improve it is what will make ruby continue to thrive -- and how is it ever any different with any technology?" What would make it "sunk cost", i suppose, is if you think ruby is a poor technology and everyone using it should switch to something else. I guess it is popular to hate on ruby right now, but that seems to be an orthogonal debate. Ironically, one of the most popular reasons to hate on ruby is "performance" (rightly or wrongly), so it seems especialy weird to me to show up with an argument like "Sure, they're drastically improving ruby performance, but is ruby the right choice of thing to improve it's performance? After all, ruby has such bad performance!" To be fair, you didn't specifically say "because ruby has such bad performance", you didn't say anything about why ruby might be the wrong thing to invest in at all -- which makes it all the more just weird FUD, intentionally or not. You are suggesting that just in general we should prefer switching to new languages over investing in the existing ones? Since you didn't supply any specific arguments, it makes it seem as if you suggest this as a general principle, regardless of details? I think many of our experiences is that this leads to always using immature technology; to reach the stability and performance of (say) the JVM or V8 requires... investing in the thing, not constantly chasing a new immature thing hoping it will be different this time.
- bastawhiz 4y ago
  The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code written in it, and there's a ton of operational knowledge about how to use it well. Switching is possible, but the cost to replace it is half a decade or more. During that time, you're not building new features, you're worrying about compatibility and making sure there's no downtime. Instead of making incremental improvements, your infra folks are worrying about migration paths. At the end of the day, the major arguments against Ruby is lack of native type checking (solved with tooling) and performance. For Shopify, you can either undertake a major engineering effort to rewrite your stack (years of effort, incidents, no real feature development, morale killing) or kick a few million dollars at making the thing your engineers like faster. The cost of replacing Ruby is tens of millions of dollars: not just engineers putting pen to paper, but lost business from putting the company on hold, breakages, and throwing out immense amounts of operational knowledge and experience. Said another way, telling a thousand+ people to drop what they're doing, learn a new language, and redo all their work is an expensive way to end up with a worse version of what you already have. It's not a sunk cost fallacy if you literally can't afford to change.
  - JohnBooty 4y ago
    Love this post, although: Ruby is easy to hire for I've always had the opposite experience!
    - bastawhiz 4y ago
      In my time at Stripe, few of the candidates were fluent in Ruby, but it almost always took less than a couple weeks to get spun up with it. If you're looking for Ruby talent, it's more challenging.
      - JohnBooty 4y ago
        I've worked at places that hire folks with Ruby experience only (more difficult) and places that just hired the best available engineer and let them learn Ruby (easier but EXTREMELY mixed results - specifically lots of Java ppl insisting on writing Ruby that looks like Java and insisting upon using e.g. Spring conventions in Rails)
- ljm 4y ago
  I think it's almost a cliché that Ruby is dying, is dead, or is outdated and uncool. It comes up in almost every post about Ruby. It's going as strong as ever and, if anything, it's stabilised into a robust, expressive and powerful language and in many cases that's a pretty acceptable trade-off. The fact it has long since matured into 'boring' technology (as in 'choose boring technology') is nothing but a good thing. It's great that so much work is going into performance, though. I've been excited to try this new JIT out in prod, and I'm excited to see how Ractor, for example, evolves.
  - jack_riminton 4y ago
    Indeed. Oh well, while people keep spouting these cliches Ruby will continue running the worlds code bases (Github), a lot of the world's payments (Stripe) and a lot of the worlds e-commerce (Shopify)
- pdntspa 4y ago
  I am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.
  - stevebmark 4y ago
    irb > def method irb > 'yes' irb > def method irb > 'it is not' irb > end irb > end irb > method => :method irb > method => "it is not"
    - pdntspa 4y ago
      yeah don't nest your methods. When have I ever needed that anyway?
      - stevebmark 4y ago
        That’s true, method_missing is both much more common and much worse
- msie 4y ago
  I think you don’t like Ruby and would want investment in the your favourite language. Because why would you care what a corporation does with their money?
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
cdiamand 4y ago
You love to see the continued investment in this language. I've been using Ruby for about a decade and I'm still enjoying writing code in it. I hope the language continues to improve and the community stays vibrant. I can remember about 8 years ago someone telling me how they were worried Ruby (and Rails) was dying. At this point the community could dry up and I think I'd still stick with it.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
frou_dh 4y ago
Does this work put Ruby into a faster category than Python until if/when Python gets a JIT in its official implementation?
- maxime_cb 4y ago
  If you believe the language benchmark game, Ruby is faster than Python on many of the microbenchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And the benchmark game is using Ruby 3.1, whereas 3.2 is significantly faster. YMMV though, it is going to depend on your use case, but we are always working on making Ruby faster, and if you run into a use case where Python is a lot faster, you can ping me on twitter @Love2Code and tell me about it. We'll take a look.
  - igouy 4y ago
    fyi now ruby 3.2.0 +YJIT
  - igouy 4y ago
    If only someone would contribute programs that used Ractors.
  - gvalkov 4y ago
    Python 3.11 also claims [1] to be 10-60% faster than 3.10, which is the version that the benchmarks game is using at this time. The difference in used RSS is also quite interesting in this comparison. [1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-faster-cpython
    - igouy 4y ago
      fyi now Python 3.11.1
    - byroot 4y ago
      > The difference in used RSS is also quite interesting in this comparison. YJIT 3.1 was eagerly allocating it's executable memory region regardless of whether it was needed or not. With the default settings that meant an extra 256M of RSS right at boot. As mentioned in TFA that's no longer the case in 3.2, so expect this RSS number to go down by at least a good 200MB once they upgrade to 3.2.
erikrothoff 4y ago
I'm pretty sure (there isn't a lot of info on how to enable it in production workloads) we're running YJIT in production and didn't notice any improvement in load times, CPU usage or anything really. If any slightly higher metrics across the board. We're using Rails as API and web frontend with a pretty high number of requests per second, so I was hoping we'd see something. Does anyone have any experience rolling it out?
- jrochkind1 4y ago
  > I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly incorrect info here about how to enable it. I agree that it's not clear to me where to find this documented. I am pretty sure it is not on by default.
  - JohnBooty 4y ago
    The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.
    - MSkog 4y ago
      You can also set RUBY_YJIT_ENABLE=1 to enable it.
      - erikrothoff 4y ago
        That’s what I ended up using: passenger_env_var RUBY_YJIT_ENABLE 1;
    - jrochkind1 4y ago
panzi 4y ago
What does 10% speedup mean? Doing 10% more work in the same time or needing 10% less time for the same amount of work?
- the_sleaze9 4y ago
  I have to admit my brain seems to be short circuiting on this one. Aren't these 2 ways of saying the same thing?
  - JohnBooty 4y ago
    At it's heart they seem to be asking kind of a latency vs. throughput question. The answer is frustratingly "it depends" but for some real world Rails benchmarks, Shopify has published quite a few benchmarks including the ones in the linked article.
  - uluyol 4y ago
    At 10% it's approximately the same. But say 50% instead. If it takes 1/2 the time to do something, you can do double the work in that time. If on the other hand, you can do 1.5x the work in the same time, it means you've made it use 33% less time than before. With 10% less time you're taking 1/0.9 = 1.11111x more work in the same time.
  - masklinn 4y ago
    Not exactly, "doing 10% more work in the same time" means needing 9(.1)% less time to do the same work (100 / 110 versus 90 / 100). Needing 10% less time for the same amount of work means you can do 11(.1)% more work in the same time.
  - rrgok 4y ago
    The percentage is applied to two different things. One for work and the other for the time. It took sometime to me too.
- ufuk 4y ago
  10% less time for the same amount of work, since we are measuring the total response time of the workload in question and looking at median (p50), p90 and p99 numbers.
sergiotapia 4y ago
Man that is a terrible graph. Why use tiny fonts and smush them together, them make the image small as well. I wish I could read the charts...
- ufuk 4y ago
  You can see this chart and all the numbers and more at https://speed.yjit.org/ https://speed.yjit.org/, which this chart was taken from.
  - sergiotapia 4y ago
    Thank you!
- deleted 4y ago
  [deleted]
hardwaregeek 4y ago
It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.
- jrochkind1 4y ago
  No, I'm afraid I'd say Sorbet/RBS haven't really been catching on widely.
  - sitkack 4y ago
    https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet looks really cool. You know the yjit folks are going to take this and make yjit even faster right?
- treis 4y ago
  The problem, I think, is the restrictions that not having a compilation step places on what typing you can do without a big breaking change. Typescript didn't have this problem because everyone already used bundlers/minifiers/etc. Adding another compiler like step to that process was pretty natural. Ruby doesn't have that and adding it in poses problems for REPL development. They chose to go with a separate file for types. Which gets around the breaking change problem but the ergonomics are terrible. Think the hope is that IDE support eventually gets around that issue. But thus far not a whole lot of adoption.
  - letmeinhere 4y ago
    Sure, this is an advantage that Typescript has, but it doesn't explain Ruby's lagging progress compared to Python and PHP. Some of that can probably pinned on the greater dynamism of Ruby, making all manner of static analysis quite challenging. But from what I've seen, it seems like the main reason is indifference or even mild hostility from the language maintainers. It looks a lot like they saw Sorbet taking off and slapped together a competing spec (without any associated tooling) that would ensure all type information stays outside of the `.rb` file. It seems like the only impact it has had is to dissuade people who would like some static types from adopting it, in favor of this vaporware. Contrast this with Python's embrace gradual extension of mypy type hints. I'd love to be proven wrong, that there are thriving projects building atop RBS. I'd still _prefer_ a system that allowed me to type a function signature so that anyone inspecting it could immediately know its shape, but at least the shadow types would be _something_.
revskill 4y ago
For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And as far as i know, no other language could bring me such experience.
- setheron 4y ago
  Ruby definitely optimizes for the writer but it fails for the reader (a saying I say quite frequently at work).
  - richardlblair 4y ago
    It _can_. Much like any other language, if you're not careful you can write some very convoluted Ruby code. What makes Ruby different is when you invest in readability you get far greater returns for much less effort.
  - deleted 4y ago
    [deleted]
  - itake 4y ago
    I've been coding for 10+ years and I would argue that ruby is not kind to the writer. Ruby requires you to be aware of much more "state" than any other language that I have coded in, because all assumptions about methods cannot be confirmed until the code is run. For example, a gem might modify the default_scope of a portion of active record models. You have to memorize all these tweaks and even then you don't know if the code you've written will do what you want until it is actually been run.
    - jeltz 4y ago
      That is a Rails issue, not a Ruby issue. Outside some Rails libraries this is not a thing. Virtually all non-Rails libraries try hard to avoid modifying global state.
weatherlite 4y ago
Glad to see Ruby still going strong it will forever be the 1st programming language I actually loved working with, and the combination of it with Rails was amazing. Had to move to the other side (Typescript, Django) but I think unless ChatGPT will write all the code 10 years from now - Rails and Ruby will still be there, providing teams with a lot of power and a lot of fun.
- deleted 4y ago
  [deleted]
- aidog 4y ago
  Funny that you say that. If AI writes code, it should be Ruby, because it's shorter and easier to read. I'm making a site and love ChatGPTs Ruby code. PS: Any Microsoft people here? Ruby could be 10x faster on Windows, if we figure out how to load files faster! https://bugs.ruby-lang.org/issues/19325#note-11 https://bugs.ruby-lang.org/issues/19325#note-11
  - weatherlite 4y ago
    Ah I meant if the AI is so capable in writing code there won't be any need for a human to read the code anymore. The "code" will be a bunch of english requirements, like an essay describing the program. Its unclear what language ChatGPT would use in that case (and who cares if the human is no longer important?).
    - jojo14 4y ago
      If an AI were meant to write code it would be Python. That is english with very few syntactic sugar mainly parens and colons. Unless the result wouldn't be meant to be read nor understood by anyone. IMHO Python is the closest to pseudo-code specifications.
- piyushpr134 4y ago
  Rails is like that first college girl/boy friend one had. Long gone, due to practical considerations, but that their fragrance, memories and love you felt for them then, is still buried somewhere deep in your heart. Rather troubling experience are those bad days with your current real one, and you suddenly remember those sun kissed, beautiful days with your dearest ruby :D
pantulis 4y ago
I'm wondering about what impact would this have in Basecamp's hosting bills...
- byroot 4y ago
  If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 https://twitter.com/dhh/status/1613508201953038337 So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.
  - DoctorOW 4y ago
    > Remember, this excludes the current Basecamp and Basecamp 2, which use our own hardware for this https://dev.37signals.com/our-cloud-spend-in-2022/ https://dev.37signals.com/our-cloud-spend-in-2022/
  - pantulis 4y ago
    Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.
    - earthnail 4y ago
      There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. And so Ruby may scale in cpu performance, but not with your number of teams. That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two). Note that I still choose Rails for all my projects, but my company is small.
      - gtirloni 4y ago
        > There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. Such as?
AcerbicZero 4y ago
I'm still a shameless ruby fanboy at heart. To be fair, its almost all devops type tasks but there is something about that language that just clicks with me, and while I def have to use python more than ruby, I still love ruby.
- deleted 4y ago
  [deleted]
stevebmark 4y ago
Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist. If you tell me that Ruby and Rails scaled for Github and Shopify, be careful using that as an argument for choosing Rails for your company. Rails definitely didn't scale for Github, and doesn't appear like it scaled for Shopify, until a manager greenlit a year long JIT project unrelated to Shopify. If your company has as many resources, free cash, klout to hire core Ruby maintainers, and enough downtime you can throw a few engineers at a non-product problem for a few years, then sure, go ahead and use that reasoning.
- nirvdrum 4y ago
  Don't most large products have teams working on performance? With a VM-based language like Ruby, speeding up the VM is a sound strategy because it works across all of your applications. There are teams embedded in corporations working on the JVM, the Python VM, the PHP VM, and so on (sometimes brand new VM implementations). There are teams working on improving performance of the standard library and compiler in C, C++, Rust, and Go. There are teams working improving performance of applications in all of those languages. Sure, if you're a startup and you can't afford it, you probably shouldn't be spending time speeding up your language. But, you're also unlikely to experience performance issues under your lighter load that can't be attributed to your application.
- xutopia 4y ago
  Shopify like many other successful Ruby shops were successful because of the speed of development. The cost of hosting is secondary and any company the size of Shopify can afford to involve a small team to reduce hosting costs... with impact for the developers happiness to boot.
  - ezekg 4y ago
    I wonder if YJIT actually did decrease infrastructure costs for Shopify, seeing as it requires ~3x more memory. For my business, it’s come out about even. But a >30% decrease in response time is worth it, for me at least. I run many small servers (2 processes each), but IIRC, Shopify runs beefy servers. So may be different for them.
lakomen 4y ago
> Multiple large clusters of servers distributed across the world, capable of serving over 75 million requests per minute That doesn't say anything at all sadly. Ruby people seem to be sensitive when someone asks them about performance, my last question about that was downvoted heavily here. I don't know any Ruby, I know how much Go can handle with the stdlib, a single non-parameterized route, returning "hello world". On my machine xeon e3-1275v5 with 8 threads 1000 concurrent wrk about 220k/ rps. Errors start appearing (aka non-200 results) between 5000 and 6000 concurrent. Don't forget to ulimit -n 10000 or more before you start wrking. Alternatively can you provide a simple single route hello world in Ruby so I can bench it myself with this Ruby 3.2 YJIT? Maybe also how to build and run? Yes, I'm being serious. I'm also guessing that Ruby with Rails has a large overhead compared to Go and just the stdlib. So that comparison wouldn't be fair, but I guess it is what it is, since we're talking semi real world scenarios (yeah don't get your ocd panties in a bunch) and Rails AFAIK is the standard for Ruby web development while the stdlib in Go is also used quite often.
- jrochkind1 4y ago
  > since we're talking semi real world scenarios A single non-parameterized route returning "hello world" is a real-world scenario? You have an interesting business domain!
  - claudiug 4y ago
    he has a saas that return hello world.
- deleted 4y ago
  [deleted]
- djur 4y ago
  Complaining about downvoting, demanding that other people do work for you, and preemptively using demeaning language about people who might disagree with you are all ways to reliably get downvoted.
kawsper 4y ago
I'm so grateful for these geniuses working tirelessly on improving the language and runtime, and it allows me to just add an argument and magically my code runs faster. It's been fascinating following Maxime working on Yjit.
- deleted 4y ago
  [deleted]
tinglymintyfrsh 4y ago
I use Ruby and Chef at work (MAANG). For side projects, I use Rails 7 to get things going and replace components selectively with native extensions and separate processes. It's all about productivity, especially when small, because performance is rarely an issue.
- deleted 4y ago
  [deleted]
Alifatisk 4y ago
That's some good news
acchow 4y ago
I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
- JohnBooty 4y ago
  Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)
  - saagarjha 4y ago
    Oh, yikes, I didn't realize this. Felt like I had seen him around on the site just yesterday :(
  - the-alchemist 4y ago
    so sad, I had no idea. We lost a brilliant mind...
  - eddsh1994 4y ago
    Looks like it’s still a WIP https://github.com/oracle/truffleruby/commits?author=eregon https://github.com/oracle/truffleruby/commits?author=eregon
    - cutler 4y ago
      With due respect to the tireless efforts of the TruffleRuby team TruffleRuby always seemed fated to be forever almost ready. I first came across it in 2013, I think it was, but there was always a not-quite-ready factor. If I remember the show-stopper was that it was unlikely to ever be Rails compatible but I may be wrong.
      - chucke 4y ago
        https://ruby.social/@eregon/109280839376585363 https://ruby.social/@eregon/109280839376585363 Tl;Dr it runs rails for a while already, it even runs mastodon.
v3ss0n 4y ago
Python have a 99% compatible jit implementation called PyPy and nobody much know about it. It was production ready since 5 years ago but ignored by mainstream. It is 400% faster than vanilla python on average and Guido and MS is working on for a few percent gain instead of promoting it or eventually making it default. PyPy.org
- deleted 4y ago
  [deleted]
- Alir3z4 4y ago
  Even if GvR promotes it fully, it won't be adopted unless c extensions work out of the box. Python without its crazy amount of extensions in c-api won't survive.
  - whizzter 4y ago
    This is something that's up to the community really. The PyPy developers early on made a new FFI that is also available for CPython, sadly not entirely as easy as the classic API but completely functional and if there was a push to rewrite extensions to use that FFI (or provide dual-paths) then the gap could be bridged.
    - theLiminator 4y ago
      Are you referencing https://github.com/hpyproject/hpy https://github.com/hpyproject/hpy? I do hope it takes off.
  - v3ss0n 4y ago
    They didn't update their website often , that is the main problem of people not knowing much about PyPy . But they had made CPyext compatible and works fine with several Data-science Libs over past 2-3 years . Even anaconda have a miniconda for pypy called pypyforge where many of CPyext are building fine with it and they have same performance comapre to CPython. ( Can't make C-Extension faster since they are already C anyways.)
- 4y ago
samsquire 4y ago
This is awesome. I am impressed. I recently wrote a toy compiler for x86_64. I use an external assembler. My dream is to write a JIT compiler runtime. https://GitHub.com/samsquire/compiler https://GitHub.com/samsquire/compiler My understanding is that you generate machine code and then mprotect the code to be executable then jump to the void * as a function pointer to execute generated instructions. What I would like to understand more is tracing compilers and how they optimise hot loops. And how they deoptimise and optimise at runtime based on runtime information.
- saagarjha 4y ago
  Here's a good start: https://webkit.org/blog/10308/speculation-in-javascriptcore/ https://webkit.org/blog/10308/speculation-in-javascriptcore/
- SirGiggles 4y ago
  That looks so cool. Do you have any resources you would recommend to someone who want's to explore (or develop as you have) in this subject?
  - samsquire 4y ago
    Write a C program that does something interesting or useful then compile it with -S and inspect the assembly. I am a beginner at assembly and learned everything from GCC. There's so many details. I learned about rbp+rsp registers recently. And from Reddit post on the compiler someone told me I need to keep the stack aligned.
daviding 4y ago
I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low. This means that you often have to deal with, say 512 MB per instance, and then if using something like Puma, have to work out how to split concurrency vs memory footprint. What I'm finding is that v3.2 YJIT loves memory, so I have to trade off that, which means less concurrency per process. Benchmarking it quickly, the 15% gains I might get on the thread aren't worth having to move to just 2 threads on a 512 MB instance versus the 3 threads I can get with YJIT not enabled. I think it's really neat and will continue to track it, but the performance in terms of memory trade-off isn't there quite as yet for our app profile. Not sure if others will find the same, but I guess its if their production environments aren't PAAS's with low memory headroom or not.
- w-ll 4y ago
  OT(ish) but a t3.medium on ec2 with 2v cores and ~4gb of mem is $33 a month ondemand. $20/mo on ri, and $10/mo spot. I'm mostly done with Heroku. With one kinda big app left, all other envs, and projects are now just on aws without the tax of heroku. And I was a big heroku fan, but their recent decisions made me shop around. I do miss the price $$ of metal in a dc, but not the price :clock: of metal.
  - Abishek_Muthian 4y ago
    Have you considered fly.io?
    - w-ll 4y ago
      yeah. but their 2cpu with 4gb of ram aint competitive enough at ~$22/mo. That and swearing off vendor locked ci, switched to Terraform and Capistrano.
- claudiug 4y ago
Existenceblinks 4y ago
I start to have less love for technical pride languages and love business backed languages like Ruby more. It also means wide ranges of library, more jobs. Great or elegant niche languages put me in bad position so far. (Also sick of developer complex)
- cutler 4y ago
  I'm with you on this as I get older. 'Been fascinated with Clojure for years but now sick of being out in the cold/on the fringe as it hasn't really converted into anything which brings home the bacon so I've turned to Java and Javascript lately. Will even do PHP if necessary if it means more paid work as a solo dev.
  - pjmlp 4y ago
    Hence why I embrace the FP stuff that lands on Java, C# and co. It might not be as nice as having the original package, but it is good enough approximation while using boring technology (TM). I leave the cool languages for hobby coding.
- Abishek_Muthian 4y ago
  I understanding where you're coming at when I use Mastodon and see how RoR has enabled it but at the same time I cannot avoid thinking how much money the poor maintainers can save if it was written in Go or Rust.
idk1 4y ago
Can someone 'explain it like I'm 5' why someone would just JIT instead of compiled Ruby, or even what the difference is please.
- hamandcheese 4y ago
  JIT VMs often rely on runtime tracing to form assumptions about a program, and then JIT native code that fits those assumptions. If/when those assumptions break, the VM can fall back to interpreting the original code. That means there is no need to write a fully-featured Ruby compiler, instead you only have to emit native code in places/situations where it will have the maximum benefit.
- tomstuart 4y ago
  It’s hard to generate efficient code ahead-of-time because the compiler doesn’t know what the types of values will be, so it has to emit very general code that can cope with all possibilities at the expense of performance. A just-in-time compiler has access to this type information because it’s executing at runtime, so it’s able to generate more efficient code which only works in the more specific situation that is actually happening right then. See Natalie [0] for a work-in-progress Ruby compiler which works ahead of time. It’s a super cool project but it’s just for fun [1] so I don’t believe it’s trying to compete on performance. [0] https://natalie-lang.org/ https://natalie-lang.org/ [1] https://justforfunnoreally.dev/ https://justforfunnoreally.dev/

481 points by onnnon 4y ago

[dead]

asim 4y ago

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the HipHop VM for PHP code and compiling PHP to large C++ binaries. I mean I get it, you have millions of lines of code, you don't want to rewrite it, but I often wonder, is there a better solution to this? Is there just a natural path towards, write new things in a new language and leave the old behind? Genuine question, because I'm not talking about rewriting the stack, I'm just talking about not investing significant amounts of time in low level infrastructure that's totally unrelated to business priorities. Yes fast code means better user experiences but often there's alternative ways around this than doing some literal JIT compiler work.

xoac 4y ago
Someone has to do this work, and I this is a good example of a company giving back to what was originally a non-industry project (Ruby).
- asim 4y ago
  Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.
  - olau 4y ago
    The loss of human time in big corporations is immense. Coordination overhead and losses due to information logistics problems. I'd imagine a project like this with no dependencies on the rest of the stack can be run efficiently. From a bang per buck point of view it might beat other means (rewrite, using multiple languages, redoing ops to run on cheaper backbone) by a huge factor. I get your sunk cost objection, but it's a bit depressing to hear people worry about someone doing genuinely useful work. Nobody wants to take responsibility or get their hands dirty. There's still plenty of low-hanging fruit in both language implementations and databases. The world today is just mountains upon mountains of bullshit.
  - xal 4y ago
    Creating and sharing powerful tools for people to build the things that they want to exist is kinda in Shopify's DNA. It's also important to me to give back to open source. It's done so much for us.
  - xoac 4y ago
    Well they have one of the bigger ruby/rails deployments so a 10% perf increase benefits them quite a bit.
psychoslave 4y ago
I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red. From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: https://github.com/codicoscepticos/ruby-implementations https://github.com/codicoscepticos/ruby-implementations
- maxime_cb 4y ago
  Yes. Not only is YJIT directly integrated into CRuby, it's also 100% compatible with your existing Ruby code, which is why we chose to go that route. We didn't want to independently reimplement Ruby because we knew that this would lead to a situation where we wouldn't be 100% compatible, which would stop people from using YJIT. If you think about PyPy for example, they have great performance numbers, but relatively few people are using it.
  - v3ss0n 4y ago
    Yeah , it was because Guido himself was not promoting that project . PyPy team really tried hard to be compatible , now almost all c-extensions including DS libraries worked. I am using PyPy in production for 8 years and - it reduce memory load by a lot , ( 80 MB vs over 300 MB for tornado web service running) - it is so much faster than python that is comparable to node in high load peformance. - it would be compatibile with every lib if Main Stream Python community had even tried it and work on it.
giraffe_lady 4y ago
I think thinking of the "sunk cost" as being only or even primarily code is incomplete. It's internal expertise in that language, understanding of its strengths and weaknesses and how they fit into your business needs, custom tooling around dev, debugging & deployment, practice evaluating candidates for expertise in it, particular strengths of that language not guaranteed to be in a replacement, just all of the "unknown unknowns" that you now know through bitter experience. Surely there will still be a point where it's worth throwing all that out and starting fresh, but some of those are very hard to quantify or even see, when you have them, so the conservative choice is to stay put in the system that works.
ryanianian 4y ago
You can often solve ~70% of this with language interop. Bindings and FFIs are in my opinion very under-appreciated. This is the approach taken by PHP+HipHop, Apple with Swift/ObjC, and many Python bindings over C++ internals (TF etc). There is no magic bullet. You can't do an overnight transition. If you decide to make a language shift (or equivalently large architecture shift), you need an interop. Old and new have to coexist. The remaining 30% (where interop fails) is where engineering happens and is often where you had hidden technical debt anyway.
jrochkind1 4y ago
The JVM is as performant as it is because so much resources were invested in optimization (including various forms of JIT etc). It's an amazingly performant VM because of so much invested in tuning it. Or same about various Javascript VMs. This kind of performance comes from lots of resources invested in tuning. Lots of resources are invested, generally, when there are lots of entities relying on a thing; that's a very good reason people invest in improving a thing, right? So I'm not really sure what you mean -- you say "sunk cost", I say "Well, those who are using a thing are those who invest in improving it, how is it ever any different? And that there are people with current investments in ruby who will continue to invest to improve it is what will make ruby continue to thrive -- and how is it ever any different with any technology?" What would make it "sunk cost", i suppose, is if you think ruby is a poor technology and everyone using it should switch to something else. I guess it is popular to hate on ruby right now, but that seems to be an orthogonal debate. Ironically, one of the most popular reasons to hate on ruby is "performance" (rightly or wrongly), so it seems especialy weird to me to show up with an argument like "Sure, they're drastically improving ruby performance, but is ruby the right choice of thing to improve it's performance? After all, ruby has such bad performance!" To be fair, you didn't specifically say "because ruby has such bad performance", you didn't say anything about why ruby might be the wrong thing to invest in at all -- which makes it all the more just weird FUD, intentionally or not. You are suggesting that just in general we should prefer switching to new languages over investing in the existing ones? Since you didn't supply any specific arguments, it makes it seem as if you suggest this as a general principle, regardless of details? I think many of our experiences is that this leads to always using immature technology; to reach the stability and performance of (say) the JVM or V8 requires... investing in the thing, not constantly chasing a new immature thing hoping it will be different this time.
bastawhiz 4y ago
The big difference compared to HHVM is that this is part of Ruby. It's not a separate project. Shopify is sponsoring much of the effort, but it's owned by the community. At Stripe, there are millions of lines of Ruby. Lots of it would be better off in a different language—if it had been written in another language initially. Ruby is easy to hire for, there are tens of thousands of pages of documentation for the code written in it, and there's a ton of operational knowledge about how to use it well. Switching is possible, but the cost to replace it is half a decade or more. During that time, you're not building new features, you're worrying about compatibility and making sure there's no downtime. Instead of making incremental improvements, your infra folks are worrying about migration paths. At the end of the day, the major arguments against Ruby is lack of native type checking (solved with tooling) and performance. For Shopify, you can either undertake a major engineering effort to rewrite your stack (years of effort, incidents, no real feature development, morale killing) or kick a few million dollars at making the thing your engineers like faster. The cost of replacing Ruby is tens of millions of dollars: not just engineers putting pen to paper, but lost business from putting the company on hold, breakages, and throwing out immense amounts of operational knowledge and experience. Said another way, telling a thousand+ people to drop what they're doing, learn a new language, and redo all their work is an expensive way to end up with a worse version of what you already have. It's not a sunk cost fallacy if you literally can't afford to change.
- JohnBooty 4y ago
  Love this post, although: Ruby is easy to hire for I've always had the opposite experience!
  - bastawhiz 4y ago
    In my time at Stripe, few of the candidates were fluent in Ruby, but it almost always took less than a couple weeks to get spun up with it. If you're looking for Ruby talent, it's more challenging.
    - JohnBooty 4y ago
      I've worked at places that hire folks with Ruby experience only (more difficult) and places that just hired the best available engineer and let them learn Ruby (easier but EXTREMELY mixed results - specifically lots of Java ppl insisting on writing Ruby that looks like Java and insisting upon using e.g. Spring conventions in Rails)
ljm 4y ago
I think it's almost a cliché that Ruby is dying, is dead, or is outdated and uncool. It comes up in almost every post about Ruby. It's going as strong as ever and, if anything, it's stabilised into a robust, expressive and powerful language and in many cases that's a pretty acceptable trade-off. The fact it has long since matured into 'boring' technology (as in 'choose boring technology') is nothing but a good thing. It's great that so much work is going into performance, though. I've been excited to try this new JIT out in prod, and I'm excited to see how Ractor, for example, evolves.
- jack_riminton 4y ago
  Indeed. Oh well, while people keep spouting these cliches Ruby will continue running the worlds code bases (Github), a lot of the world's payments (Stripe) and a lot of the worlds e-commerce (Shopify)
pdntspa 4y ago
I am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.
- stevebmark 4y ago
  irb > def method irb > 'yes' irb > def method irb > 'it is not' irb > end irb > end irb > method => :method irb > method => "it is not"
  - pdntspa 4y ago
    yeah don't nest your methods. When have I ever needed that anyway?
    - stevebmark 4y ago
      That’s true, method_missing is both much more common and much worse
msie 4y ago
I think you don’t like Ruby and would want investment in the your favourite language. Because why would you care what a corporation does with their money?
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

cdiamand 4y ago

You love to see the continued investment in this language. I've been using Ruby for about a decade and I'm still enjoying writing code in it. I hope the language continues to improve and the community stays vibrant. I can remember about 8 years ago someone telling me how they were worried Ruby (and Rails) was dying. At this point the community could dry up and I think I'd still stick with it.

deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

frou_dh 4y ago

Does this work put Ruby into a faster category than Python until if/when Python gets a JIT in its official implementation?

maxime_cb 4y ago
If you believe the language benchmark game, Ruby is faster than Python on many of the microbenchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And the benchmark game is using Ruby 3.1, whereas 3.2 is significantly faster. YMMV though, it is going to depend on your use case, but we are always working on making Ruby faster, and if you run into a use case where Python is a lot faster, you can ping me on twitter @Love2Code and tell me about it. We'll take a look.
- igouy 4y ago
  fyi now ruby 3.2.0 +YJIT
- igouy 4y ago
  If only someone would contribute programs that used Ractors.
- gvalkov 4y ago
  Python 3.11 also claims [1] to be 10-60% faster than 3.10, which is the version that the benchmarks game is using at this time. The difference in used RSS is also quite interesting in this comparison. [1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-faster-cpython
  - igouy 4y ago
    fyi now Python 3.11.1
  - byroot 4y ago
    > The difference in used RSS is also quite interesting in this comparison. YJIT 3.1 was eagerly allocating it's executable memory region regardless of whether it was needed or not. With the default settings that meant an extra 256M of RSS right at boot. As mentioned in TFA that's no longer the case in 3.2, so expect this RSS number to go down by at least a good 200MB once they upgrade to 3.2.

erikrothoff 4y ago

I'm pretty sure (there isn't a lot of info on how to enable it in production workloads) we're running YJIT in production and didn't notice any improvement in load times, CPU usage or anything really. If any slightly higher metrics across the board. We're using Rails as API and web frontend with a pretty high number of requests per second, so I was hoping we'd see something. Does anyone have any experience rolling it out?

jrochkind1 4y ago
> I'm pretty sure (there isn't a lot of info on how to enable it in production workloads The YJIT is not on by default in ruby 3.2, you have to specifically enable it. If you aren't sure if you have enabled it... what makes you pretty sure you have enabled it? It seems possible you have not enabled it, if you aren't confident you know how to do so? I am not using it yet myself, and don't want to put any possibly incorrect info here about how to enable it. I agree that it's not clear to me where to find this documented. I am pretty sure it is not on by default.
- JohnBooty 4y ago
  The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.
  - MSkog 4y ago
    You can also set RUBY_YJIT_ENABLE=1 to enable it.
    - erikrothoff 4y ago
      That’s what I ended up using: passenger_env_var RUBY_YJIT_ENABLE 1;
  - jrochkind1 4y ago

panzi 4y ago

What does 10% speedup mean? Doing 10% more work in the same time or needing 10% less time for the same amount of work?

the_sleaze9 4y ago
I have to admit my brain seems to be short circuiting on this one. Aren't these 2 ways of saying the same thing?
- JohnBooty 4y ago
  At it's heart they seem to be asking kind of a latency vs. throughput question. The answer is frustratingly "it depends" but for some real world Rails benchmarks, Shopify has published quite a few benchmarks including the ones in the linked article.
- uluyol 4y ago
  At 10% it's approximately the same. But say 50% instead. If it takes 1/2 the time to do something, you can do double the work in that time. If on the other hand, you can do 1.5x the work in the same time, it means you've made it use 33% less time than before. With 10% less time you're taking 1/0.9 = 1.11111x more work in the same time.
- masklinn 4y ago
  Not exactly, "doing 10% more work in the same time" means needing 9(.1)% less time to do the same work (100 / 110 versus 90 / 100). Needing 10% less time for the same amount of work means you can do 11(.1)% more work in the same time.
- rrgok 4y ago
  The percentage is applied to two different things. One for work and the other for the time. It took sometime to me too.
ufuk 4y ago
10% less time for the same amount of work, since we are measuring the total response time of the workload in question and looking at median (p50), p90 and p99 numbers.

sergiotapia 4y ago

Man that is a terrible graph. Why use tiny fonts and smush them together, them make the image small as well. I wish I could read the charts...

ufuk 4y ago
You can see this chart and all the numbers and more at https://speed.yjit.org/ https://speed.yjit.org/, which this chart was taken from.
- sergiotapia 4y ago
  Thank you!
deleted 4y ago
[deleted]

hardwaregeek 4y ago

It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.

jrochkind1 4y ago
No, I'm afraid I'd say Sorbet/RBS haven't really been catching on widely.
- sitkack 4y ago
  https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet looks really cool. You know the yjit folks are going to take this and make yjit even faster right?
treis 4y ago
The problem, I think, is the restrictions that not having a compilation step places on what typing you can do without a big breaking change. Typescript didn't have this problem because everyone already used bundlers/minifiers/etc. Adding another compiler like step to that process was pretty natural. Ruby doesn't have that and adding it in poses problems for REPL development. They chose to go with a separate file for types. Which gets around the breaking change problem but the ergonomics are terrible. Think the hope is that IDE support eventually gets around that issue. But thus far not a whole lot of adoption.
- letmeinhere 4y ago
  Sure, this is an advantage that Typescript has, but it doesn't explain Ruby's lagging progress compared to Python and PHP. Some of that can probably pinned on the greater dynamism of Ruby, making all manner of static analysis quite challenging. But from what I've seen, it seems like the main reason is indifference or even mild hostility from the language maintainers. It looks a lot like they saw Sorbet taking off and slapped together a competing spec (without any associated tooling) that would ensure all type information stays outside of the `.rb` file. It seems like the only impact it has had is to dissuade people who would like some static types from adopting it, in favor of this vaporware. Contrast this with Python's embrace gradual extension of mypy type hints. I'd love to be proven wrong, that there are thriving projects building atop RBS. I'd still _prefer_ a system that allowed me to type a function signature so that anyone inspecting it could immediately know its shape, but at least the shadow types would be _something_.

revskill 4y ago

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And as far as i know, no other language could bring me such experience.

setheron 4y ago
Ruby definitely optimizes for the writer but it fails for the reader (a saying I say quite frequently at work).
- richardlblair 4y ago
  It _can_. Much like any other language, if you're not careful you can write some very convoluted Ruby code. What makes Ruby different is when you invest in readability you get far greater returns for much less effort.
- deleted 4y ago
  [deleted]
- itake 4y ago
  I've been coding for 10+ years and I would argue that ruby is not kind to the writer. Ruby requires you to be aware of much more "state" than any other language that I have coded in, because all assumptions about methods cannot be confirmed until the code is run. For example, a gem might modify the default_scope of a portion of active record models. You have to memorize all these tweaks and even then you don't know if the code you've written will do what you want until it is actually been run.
  - jeltz 4y ago
    That is a Rails issue, not a Ruby issue. Outside some Rails libraries this is not a thing. Virtually all non-Rails libraries try hard to avoid modifying global state.

weatherlite 4y ago

Glad to see Ruby still going strong it will forever be the 1st programming language I actually loved working with, and the combination of it with Rails was amazing. Had to move to the other side (Typescript, Django) but I think unless ChatGPT will write all the code 10 years from now - Rails and Ruby will still be there, providing teams with a lot of power and a lot of fun.

deleted 4y ago
[deleted]
aidog 4y ago
Funny that you say that. If AI writes code, it should be Ruby, because it's shorter and easier to read. I'm making a site and love ChatGPTs Ruby code. PS: Any Microsoft people here? Ruby could be 10x faster on Windows, if we figure out how to load files faster! https://bugs.ruby-lang.org/issues/19325#note-11 https://bugs.ruby-lang.org/issues/19325#note-11
- weatherlite 4y ago
  Ah I meant if the AI is so capable in writing code there won't be any need for a human to read the code anymore. The "code" will be a bunch of english requirements, like an essay describing the program. Its unclear what language ChatGPT would use in that case (and who cares if the human is no longer important?).
  - jojo14 4y ago
    If an AI were meant to write code it would be Python. That is english with very few syntactic sugar mainly parens and colons. Unless the result wouldn't be meant to be read nor understood by anyone. IMHO Python is the closest to pseudo-code specifications.
piyushpr134 4y ago
Rails is like that first college girl/boy friend one had. Long gone, due to practical considerations, but that their fragrance, memories and love you felt for them then, is still buried somewhere deep in your heart. Rather troubling experience are those bad days with your current real one, and you suddenly remember those sun kissed, beautiful days with your dearest ruby :D

pantulis 4y ago

I'm wondering about what impact would this have in Basecamp's hosting bills...

byroot 4y ago
If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 https://twitter.com/dhh/status/1613508201953038337 So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.
- DoctorOW 4y ago
  > Remember, this excludes the current Basecamp and Basecamp 2, which use our own hardware for this https://dev.37signals.com/our-cloud-spend-in-2022/ https://dev.37signals.com/our-cloud-spend-in-2022/
- pantulis 4y ago
  Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.
  - earthnail 4y ago
    There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. And so Ruby may scale in cpu performance, but not with your number of teams. That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two). Note that I still choose Rails for all my projects, but my company is small.
    - gtirloni 4y ago
      > There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. Such as?

AcerbicZero 4y ago

I'm still a shameless ruby fanboy at heart. To be fair, its almost all devops type tasks but there is something about that language that just clicks with me, and while I def have to use python more than ruby, I still love ruby.

deleted 4y ago
[deleted]

stevebmark 4y ago

Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist. If you tell me that Ruby and Rails scaled for Github and Shopify, be careful using that as an argument for choosing Rails for your company. Rails definitely didn't scale for Github, and doesn't appear like it scaled for Shopify, until a manager greenlit a year long JIT project unrelated to Shopify. If your company has as many resources, free cash, klout to hire core Ruby maintainers, and enough downtime you can throw a few engineers at a non-product problem for a few years, then sure, go ahead and use that reasoning.

nirvdrum 4y ago
Don't most large products have teams working on performance? With a VM-based language like Ruby, speeding up the VM is a sound strategy because it works across all of your applications. There are teams embedded in corporations working on the JVM, the Python VM, the PHP VM, and so on (sometimes brand new VM implementations). There are teams working on improving performance of the standard library and compiler in C, C++, Rust, and Go. There are teams working improving performance of applications in all of those languages. Sure, if you're a startup and you can't afford it, you probably shouldn't be spending time speeding up your language. But, you're also unlikely to experience performance issues under your lighter load that can't be attributed to your application.
xutopia 4y ago
Shopify like many other successful Ruby shops were successful because of the speed of development. The cost of hosting is secondary and any company the size of Shopify can afford to involve a small team to reduce hosting costs... with impact for the developers happiness to boot.
- ezekg 4y ago
  I wonder if YJIT actually did decrease infrastructure costs for Shopify, seeing as it requires ~3x more memory. For my business, it’s come out about even. But a >30% decrease in response time is worth it, for me at least. I run many small servers (2 processes each), but IIRC, Shopify runs beefy servers. So may be different for them.

lakomen 4y ago

> Multiple large clusters of servers distributed across the world, capable of serving over 75 million requests per minute That doesn't say anything at all sadly. Ruby people seem to be sensitive when someone asks them about performance, my last question about that was downvoted heavily here. I don't know any Ruby, I know how much Go can handle with the stdlib, a single non-parameterized route, returning "hello world". On my machine xeon e3-1275v5 with 8 threads 1000 concurrent wrk about 220k/ rps. Errors start appearing (aka non-200 results) between 5000 and 6000 concurrent. Don't forget to ulimit -n 10000 or more before you start wrking. Alternatively can you provide a simple single route hello world in Ruby so I can bench it myself with this Ruby 3.2 YJIT? Maybe also how to build and run? Yes, I'm being serious. I'm also guessing that Ruby with Rails has a large overhead compared to Go and just the stdlib. So that comparison wouldn't be fair, but I guess it is what it is, since we're talking semi real world scenarios (yeah don't get your ocd panties in a bunch) and Rails AFAIK is the standard for Ruby web development while the stdlib in Go is also used quite often.

jrochkind1 4y ago
> since we're talking semi real world scenarios A single non-parameterized route returning "hello world" is a real-world scenario? You have an interesting business domain!
- claudiug 4y ago
  he has a saas that return hello world.
deleted 4y ago
[deleted]
djur 4y ago
Complaining about downvoting, demanding that other people do work for you, and preemptively using demeaning language about people who might disagree with you are all ways to reliably get downvoted.

kawsper 4y ago

I'm so grateful for these geniuses working tirelessly on improving the language and runtime, and it allows me to just add an argument and magically my code runs faster. It's been fascinating following Maxime working on Yjit.

deleted 4y ago
[deleted]

tinglymintyfrsh 4y ago

I use Ruby and Chef at work (MAANG). For side projects, I use Rails 7 to get things going and replace components selectively with native extensions and separate processes. It's all about productivity, especially when small, because performance is rarely an issue.

deleted 4y ago
[deleted]

Alifatisk 4y ago

That's some good news

acchow 4y ago

I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?

JohnBooty 4y ago
Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)
- saagarjha 4y ago
  Oh, yikes, I didn't realize this. Felt like I had seen him around on the site just yesterday :(
- the-alchemist 4y ago
  so sad, I had no idea. We lost a brilliant mind...
- eddsh1994 4y ago
  Looks like it’s still a WIP https://github.com/oracle/truffleruby/commits?author=eregon https://github.com/oracle/truffleruby/commits?author=eregon
  - cutler 4y ago
    With due respect to the tireless efforts of the TruffleRuby team TruffleRuby always seemed fated to be forever almost ready. I first came across it in 2013, I think it was, but there was always a not-quite-ready factor. If I remember the show-stopper was that it was unlikely to ever be Rails compatible but I may be wrong.
    - chucke 4y ago
      https://ruby.social/@eregon/109280839376585363 https://ruby.social/@eregon/109280839376585363 Tl;Dr it runs rails for a while already, it even runs mastodon.

v3ss0n 4y ago

Python have a 99% compatible jit implementation called PyPy and nobody much know about it. It was production ready since 5 years ago but ignored by mainstream. It is 400% faster than vanilla python on average and Guido and MS is working on for a few percent gain instead of promoting it or eventually making it default. PyPy.org

deleted 4y ago
[deleted]
Alir3z4 4y ago
Even if GvR promotes it fully, it won't be adopted unless c extensions work out of the box. Python without its crazy amount of extensions in c-api won't survive.
- whizzter 4y ago
  This is something that's up to the community really. The PyPy developers early on made a new FFI that is also available for CPython, sadly not entirely as easy as the classic API but completely functional and if there was a push to rewrite extensions to use that FFI (or provide dual-paths) then the gap could be bridged.
  - theLiminator 4y ago
    Are you referencing https://github.com/hpyproject/hpy https://github.com/hpyproject/hpy? I do hope it takes off.
- v3ss0n 4y ago
  They didn't update their website often , that is the main problem of people not knowing much about PyPy . But they had made CPyext compatible and works fine with several Data-science Libs over past 2-3 years . Even anaconda have a miniconda for pypy called pypyforge where many of CPyext are building fine with it and they have same performance comapre to CPython. ( Can't make C-Extension faster since they are already C anyways.)
4y ago

samsquire 4y ago

This is awesome. I am impressed. I recently wrote a toy compiler for x86_64. I use an external assembler. My dream is to write a JIT compiler runtime. https://GitHub.com/samsquire/compiler https://GitHub.com/samsquire/compiler My understanding is that you generate machine code and then mprotect the code to be executable then jump to the void * as a function pointer to execute generated instructions. What I would like to understand more is tracing compilers and how they optimise hot loops. And how they deoptimise and optimise at runtime based on runtime information.

saagarjha 4y ago
Here's a good start: https://webkit.org/blog/10308/speculation-in-javascriptcore/ https://webkit.org/blog/10308/speculation-in-javascriptcore/
SirGiggles 4y ago
That looks so cool. Do you have any resources you would recommend to someone who want's to explore (or develop as you have) in this subject?
- samsquire 4y ago
  Write a C program that does something interesting or useful then compile it with -S and inspect the assembly. I am a beginner at assembly and learned everything from GCC. There's so many details. I learned about rbp+rsp registers recently. And from Reddit post on the compiler someone told me I need to keep the stack aligned.

daviding 4y ago

I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low. This means that you often have to deal with, say 512 MB per instance, and then if using something like Puma, have to work out how to split concurrency vs memory footprint. What I'm finding is that v3.2 YJIT loves memory, so I have to trade off that, which means less concurrency per process. Benchmarking it quickly, the 15% gains I might get on the thread aren't worth having to move to just 2 threads on a 512 MB instance versus the 3 threads I can get with YJIT not enabled. I think it's really neat and will continue to track it, but the performance in terms of memory trade-off isn't there quite as yet for our app profile. Not sure if others will find the same, but I guess its if their production environments aren't PAAS's with low memory headroom or not.

w-ll 4y ago
OT(ish) but a t3.medium on ec2 with 2v cores and ~4gb of mem is $33 a month ondemand. $20/mo on ri, and $10/mo spot. I'm mostly done with Heroku. With one kinda big app left, all other envs, and projects are now just on aws without the tax of heroku. And I was a big heroku fan, but their recent decisions made me shop around. I do miss the price $$ of metal in a dc, but not the price :clock: of metal.
- Abishek_Muthian 4y ago
  Have you considered fly.io?
  - w-ll 4y ago
    yeah. but their 2cpu with 4gb of ram aint competitive enough at ~$22/mo. That and swearing off vendor locked ci, switched to Terraform and Capistrano.
claudiug 4y ago

Existenceblinks 4y ago

I start to have less love for technical pride languages and love business backed languages like Ruby more. It also means wide ranges of library, more jobs. Great or elegant niche languages put me in bad position so far. (Also sick of developer complex)

cutler 4y ago
I'm with you on this as I get older. 'Been fascinated with Clojure for years but now sick of being out in the cold/on the fringe as it hasn't really converted into anything which brings home the bacon so I've turned to Java and Javascript lately. Will even do PHP if necessary if it means more paid work as a solo dev.
- pjmlp 4y ago
  Hence why I embrace the FP stuff that lands on Java, C# and co. It might not be as nice as having the original package, but it is good enough approximation while using boring technology (TM). I leave the cool languages for hobby coding.
Abishek_Muthian 4y ago
I understanding where you're coming at when I use Mastodon and see how RoR has enabled it but at the same time I cannot avoid thinking how much money the poor maintainers can save if it was written in Go or Rust.

idk1 4y ago

Can someone 'explain it like I'm 5' why someone would just JIT instead of compiled Ruby, or even what the difference is please.

hamandcheese 4y ago
JIT VMs often rely on runtime tracing to form assumptions about a program, and then JIT native code that fits those assumptions. If/when those assumptions break, the VM can fall back to interpreting the original code. That means there is no need to write a fully-featured Ruby compiler, instead you only have to emit native code in places/situations where it will have the maximum benefit.
tomstuart 4y ago
It’s hard to generate efficient code ahead-of-time because the compiler doesn’t know what the types of values will be, so it has to emit very general code that can cope with all possibilities at the expense of performance. A just-in-time compiler has access to this type information because it’s executing at runtime, so it’s able to generate more efficient code which only works in the more specific situation that is actually happening right then. See Natalie [0] for a work-in-progress Ruby compiler which works ahead of time. It’s a super cool project but it’s just for fun [1] so I don’t believe it’s trying to compete on performance. [0] https://natalie-lang.org/ https://natalie-lang.org/ [1] https://justforfunnoreally.dev/ https://justforfunnoreally.dev/