eregon

38 ms·

1.
by eregon 6mo ago
Many native extensions just work with TruffleRuby, I'd estimate even the majority of the popular native extensions just work. Performance of native extensions is not always good, especially if they do a lot of back and forth between Ru
2.
Contributions to Ruby/spec by Ruby implementation(eregon.me)
5 points by eregon 1y ago|0 comments
3.
by eregon 2y ago
No it wouldn't.
4.
by eregon 2y ago
Thanks for the comment. > Cool, but what about replacing the regexp with straightforward parsing code written manually? If you take a look at the linked snippets of C code, I think it's clear it's all but straightforward. The r
5.
Benchmarking Ruby Parsers(eregon.me)
2 points by eregon 2y ago|0 comments
6.
by eregon 5y ago
When did you try? Fixnum/Bignum are gone since many years (before 1.0RC1 which was April 2018, it's all Integer now). So I guess many years ago, and back then TruffleRuby was basically implementing Ruby features, had fairly limite
7.
by eregon 5y ago
Yes, some things are slower. Most of them I'd say are unexpected performance bugs. I'd think most are easy to fix once investigated, but some can be hard to fix (recent example, `File.read` is quite fast on CRuby). Some things are
8.
by eregon 5y ago
Compatibility is certainly an issue for massive codebases, OTOH I think over time TruffleRuby is getting closer and closer to CRuby behavior to the point it would be fairly rare to find a compatibility issue. Do you have personal experience
9.
by eregon 5y ago
Startup is likely to be worse, because it typically runs a lot of different code for not long and the JIT might not have enough time to optimize much of that. OTOH the JIT needs to learn what the program is doing, i.e., profile it in a sens
10.
by eregon 5y ago
That second sentence seems a fair assessment. TruffleRuby does support many native (C/C++) extensions so that's rarely an issue. But indeed in such a large codebase it's likely to depend unexpectedly on CRuby-specific behavio
11.
by eregon 5y ago
Compatibility is one, it's hard to be 100% compatible with CRuby, and large codebases tend to sometimes depend unintentionally on weird behavior or even bugs in CRuby. Keeping up compatibility (while keeping things efficient) is a lot
12.
by eregon 5y ago
Actually TruffleRuby optimizes metaprogramming more than any other Ruby implementation. Rails is not the issue, big codebases is the issue: more code = more chances to use something which is not so fast on TruffleRuby yet = more chance to b
13.
by eregon 5y ago
It's the same benchmark in the blog post, `railsbench`. So TruffleRuby already speeds up some Rails apps like that one but not every Rails app/program. (TruffleRuby 3.27x, YJIT 1.33x on railsbench)
14.
by eregon 5y ago
Interesting, I did not know that just calling the original method, even when the refinement method is not used occurs such a cost on CRuby. Seems worth reporting if not already done. No such thing on TruffleRuby though, the only peak perfor
15.
by eregon 5y ago
Many popular C extension gems just work. About the only popular C extension I can think of which does not work yet is grpc, and there is work on that. There is a status overview at https://github.com/oracle/truffleruby&
16.
by eregon 5y ago
Here is a bit of a critical read of this blog post, from the point of view of alternative Ruby implementations: > instead of having to ship an entire language runtime to production Except they ship the CRuby language runtime in productio
17.
by eregon 6y ago
I've also found that the Computer Language Benchmarks Game benchmarks tend to be less and less representative of real workloads, due to what the benchmarks do and to the philosophy of "write it to make it fast, not idiomatic, and
18.
by eregon 6y ago
Interesting results, thanks for sharing, that matches my expectations. OptCarrot is probably one of the rare cases where Ruby 3.0+JIT is 3x Ruby 2.0. On most benchmarks, the gains are much smaller. I'll try to run these benchmarks on T
19.
by eregon 6y ago
I replied to the tweet. At least for TruffleRuby it's to improve testing, no hidden intent. And the PR is by someone not at Oracle, and his interest is to run some Rails app on TruffleRuby, and for that he'd like to ensure all gem
20.
by eregon 6y ago
TruffleRuby [can run Rails]( https://speakerdeck.com/eregon/running-rack-and-rails-faster... ), if that is what you refer to.
21.
by eregon 6y ago
That's rather vague. But yes, no matter which JIT you always need some extra memory to run the JIT, and it creates a more optimized version while also needing the unoptimized version of the code, so it needs more memory.
22.
by eregon 6y ago
It's exactly the same thing though, isn't it? I use both terms interchangeably. And it seems the term GIL is better known than GVL.
23.
by eregon 6y ago
Which comments?
24.
by eregon 6y ago
Seems there isn't any warmup accounted for: https://github.com/kostya/benchmarks/issues/246
25.
by eregon 6y ago
FWIW, I ran bench.b locally: MRI: 87.83s TruffleRuby Native 20.0: 18.82s truffleruby-dev Native: 14.09s
26.
by eregon 6y ago
Why is there is no TruffleRuby Native in that page? (i.e., the default)
27.
by eregon 6y ago
Concretely, TruffleRuby never shared much in terms of the core language implementation with JRuby (essentially the parser and encoding stuff, never core methods/operators/etc).
28.
by eregon 7y ago
JRuby has no support for C extensions. TruffleRuby supports C extensions, and has no GIL for Ruby code.
29.
by eregon 7y ago
> Guilds would have a major performance problem: can't allocate objects without GIL. Why not? It'd be possible to have TLABs, isn't it? But yes, GC would still be for all Guilds at once. Racket places don't allow to s
30.
by eregon 7y ago
Do you mean every thread would have its own place/isolate for executing C extensions? I think one difficulty there is some global state in C extensions might expect to be truly process-global. Also, how would you isolate global variabl

More ›