Activity Graph

Page 1 of 4 | Next »


[05:50:10] headius: Ping timeout: 244 seconds


[23:46:54] headius: *.net *.split


[15:42:42] headius: RougeR: unfortunately despair left, but in theory a JIT could be used to precompile a whole program, especially one as minimal as the Ruby JIT
[15:53:30] headius: phage: well, eval always will limit AOT compilation
[15:53:46] headius: if you need it you'd have to include the parser and interpreter too
[15:54:16] headius: well, look at mruby
[15:54:30] headius: it does a single binary...by serializing the Ruby instructions directly into C code
[15:54:35] headius: is that AOT?
[15:54:53] headius: JRuby 9.x AOT actually does the same thing, rather than precompiling to JVM bytecode
[15:55:06] headius: single binary but it's not really compiled to "native"
[16:39:28] headius: lambarena: ah yeah, basically the same thing...when people claim they want ahead-of-time compliation most of the time what they really want is just an all-in-one binary
[16:39:45] headius: oops lambchop


[17:08:17] headius: havenwood: worth pointing out that small benchmarks often end up doing nothing at all in TR, which isn't typical for e.g. a web application with lots of opaque IO


[04:11:08] headius: has joined #ruby


[01:14:37] headius: Ping timeout: 246 seconds


[18:28:37] headius: NL3limin4t0r: you can't rely on that code in MRI either because it doesn't treat the -= as atomic either


[15:22:58] headius: bomb: enebo and others have been maintaining JRubyFX on and off
[15:23:08] headius: https://github.com/jruby/jrubyfx
[15:36:56] headius: you can use it as a DSL or with FXML


[19:05:48] headius: has joined #ruby


[09:30:57] headius: Ping timeout: 240 seconds


[13:19:47] headius: Ping timeout: 245 seconds
[18:19:02] headius: has joined #ruby


[00:07:08] headius: *.net *.split
[00:15:49] headius: has joined #ruby


[21:42:59] headius: apeiros, JJonah: both JRuby and TR should optimize that case, though TR currently does more to reduce the cost of the closure
[21:43:40] headius: the short answer on MRI is that the code block will be reused but the state around it (local variables, self, etc) goes into a memory structure that has to be allocated and then cleaned up later
[21:44:16] headius: for a simple case JRuby will not allocate as much, and I'm working on getting it to inline and allocate nothing


[00:28:37] headius: >> RUBY_VERSION
[00:28:48] headius: >> RUBY_ENGINE
[00:29:00] headius: there should be a JRuby version



[18:01:19] headius: havenwood: I need to start aggregating some of your results, have you managed to put them somewhere?
[18:03:35] headius: ideally I would be able to reproduce them under a specific environment so nobody can cry foul :-)
[22:06:16] headius: havenwood: cool that's great...not quite beating TR on that one but in shooting distance
[22:06:39] headius: my experiments show that small algorithms that inline completely optimize on JRuby almost as well as on TR
[22:07:02] headius: if we can't/don't inline some things or if it's using a lot of data structures we have more work to do
[22:07:09] headius: but at least I know what we're not doing
[22:07:20] headius: havenwood: http://blog.headius.com/2018/07/running-jruby-on-graal-jit.html
[22:07:31] headius: I'd be interested in a follow-up post showing your results
[22:08:05] headius: oh jeez, yeah
[22:08:17] headius: class vars are dirt stupid in JRuby now
[22:09:30] headius: I don't know what TR does for class vars
[22:11:14] headius: yeah looks like TR does optimize class vaes
[22:11:16] headius: so there's an opportunity
[22:11:24] headius: I know how to do it, I just hate class vars :-)
[22:12:18] headius: sure, hopefully more to come as I explore this stuff
[22:27:53] headius: I used to hate final newline until I realized that version control is way cleaner that way
[22:28:01] headius: you add a new line it's only a single +, rather than a - and a +
[22:32:13] headius: eam: just to make sure
[22:32:23] headius: if one's good, two is better
[22:50:07] headius: give each issue a 4096-bit RSA key to be sure


[01:19:55] headius: havenwood: we impl monotonic with nanotime
[01:20:26] headius: I think I traced it down into the guts of JVM and that's basically what it's doing
[01:24:48] headius: huh, there's no clock_gettime specs
[01:46:26] headius: al2o3-cr: I'm on macOS but I was referring to ruby/spec
[01:46:39] headius: >> RUBY_ENGINE
[01:47:16] headius: ruby[bot]: help


[18:46:57] headius: havenwood: wow that's excellent
[18:55:54] headius: havenwood: Are you keeping a repo of these somewhere?


[18:52:13] headius: havenwood: hey do you have a set of benchmarks you're seeing JRuby+Graal do really well on?
[18:52:34] headius: I'm going to be doing a talk at the JVM Language Summit on the perf improvements we're seeing with Graal *not* using Truffle
[22:09:34] headius: havenwood: that would be great...I'm trying to show that we've got a good long future ahead of us just by leveraging Graal and making incremental improvements to JRuby
[22:09:44] headius: and also to show that Graal is great with or without Truffle
[22:15:19] headius: havenwood: yeah in that case I would assume it's basically doing nothing because there's no side-effect after initially compiling the regexp
[22:15:28] headius: graal (and truffle) are great at doing nothing
[22:20:02] headius: heh ok I wasn't sure


[20:52:57] headius: Ping timeout: 240 seconds
[20:55:16] headius: has joined #ruby


[18:36:01] headius: has joined #ruby


[04:13:32] headius: Ping timeout: 268 seconds


[02:38:36] headius: havenwood: I got 34M for JRuby
[02:40:37] headius: the benchmark also doesn't use any of the results and it's likely TR can statically "do nothing"
[02:41:36] headius: havenwood: well that's fine, but throw -Xcompile.invokedynamic on there too
[02:42:11] headius: the benchmark blocks are going to be the biggest cost here
[02:44:47] headius: I modified your bench to call keys.first five times and use the results, and JRuby gets 27M ips to TR's 8M
[02:45:23] headius: on graal with indy
[02:46:55] headius: TR is good at optimizing away unused work...we're getting there :-)
[02:47:44] headius: I'll gist my changes and numbers in a sec
[02:49:12] headius: https://gist.github.com/headius/4982be842c5282d6de7e2d018c5cd262
[02:49:48] headius: TR still manages to eliminate most of the first.first one but the others it's being forced to do the work it seems
[02:50:21] headius: it's hard to benchmark an impl that eliminates useless work because it eliminates the benchmark
[02:53:42] headius: havenwood: FWIW let me know what else you see with JRuby + indy + graal...for small benchmarks here that gives JRuby outstanding perf
[02:53:49] headius: mixed back for large apps though
[03:38:11] headius: oh yeah that's a perfect case for JRuby + Graal right now
[03:38:34] headius: given these exciting results we'll be working over the next few weeks to get stuff inlining that isn't currently...that should open up more doors
[03:39:32] headius: is that a gem I can install?
[03:39:50] headius: I'm curious about jruby indy hotspot now
[03:41:47] headius: havenwood: you should also try -Xfixnum.cache=false
[03:42:07] headius: to blunt the cost of numerics, we cache -256..256 Fixnum objects
[03:42:19] headius: but on Graal that can get in the way of escape analysis, so it's usually faster to disable it
[03:42:38] headius: sometimes much faster
[03:43:20] headius: we may detect graal in the future and only use it in the interpreter, or something
[03:46:33] headius: yeah seems to help some of them


[17:55:48] headius: that shouldn't cost anything
[17:55:57] headius: maybe they're iterating all values to get the count
[17:56:14] headius: the size/count feature was added relatively recently and you need to explicitly populate it everywhere you enumeratorize
[17:56:42] headius: I don't quite get the negative value though
[17:57:16] headius: that is not even 64 bit boundary...it's 32 bit
[17:57:32] headius: we do love to match MRI weirdness though
[17:59:49] headius: count doesn't seem to be size
[18:00:12] headius: it's Enumerable
[18:00:16] headius: so it actually does run the iterator
[18:00:20] headius: that seems like it should be fixed to use size
[18:00:42] headius: like if there's a size defined, why would count return anything else
[18:03:49] headius: I mean if it's intended as a verb it makes sense to iterate, right?
[18:03:54] headius: if it's a noun it should just be .size
[18:05:42] headius: havenwood: I'm unclear why it overflows though
[18:05:46] headius: I think in our case it's a bug
[18:06:05] headius: we are *always* 64-bit integers internally...not 32, not 31, not 62
[18:06:33] headius: our count aggregates with an int...now should I change it and have some weirdo report it as a bug?
[18:07:30] headius: self.worries.count
[18:07:48] headius: if you use rubinius at least you'll never know how many there are
[18:07:51] headius: ba dum dum
[18:09:02] headius: maybe they're aggregating all the values into an array to be summed later
[18:09:04] headius: I have no idea
[18:09:27] headius: I'm going to get banned again
[18:09:36] headius: double secret probation
[18:11:26] headius: I have to know why
[18:12:01] headius: I wonder if I'm allowed to clone it
[18:13:36] headius: and a pain in the ass to optimize
[18:14:08] headius: use "int32" inC if you want to be specific right?
[18:14:39] headius: if not for int promotion we could turn a lot of code into just 64-bit long math
[18:14:43] headius: but dat overflow
[18:18:53] headius: well we're balancing complexity a bit
[18:19:02] headius: at this point we get a lot of that magic for free by just running JRuby on Graal
[18:19:16] headius: like we can run mandelbrot benchmark and similar things as fast as Truffle
[18:19:33] headius: faster than our manual numeric specialization even
[18:20:07] headius: so yeah we lean on deopt and safepoints heavily in standard JRuby, and the VMs are starting to catch up with what we need
[18:21:20] headius: it's an old and crazy story
[18:21:47] headius: I'm not sure it's even searchable anymore
[18:25:27] headius: aw man is there no bundle viz that doesn't require all the gems to be installable?
[18:25:29] headius: I just want the dep graph
[18:25:43] headius: trying to run rubygems.org on JRuby but something depends on kgi
[18:26:03] headius: havenwood: victory!
[18:26:10] headius: now tweet it
[18:26:29] headius: I have no idea why it would consume *any* memory for that
[18:36:57] headius: https://gist.github.com/headius/7296808402fd2fae496310cf0baa7239
[18:45:09] headius: al2o3-cr: seems like it should be fixed right?
[19:07:22] headius: magic numbers that aren't so magic
[19:09:16] headius: 0xCAFEBABE
[19:09:23] headius: name that magic number
[19:18:40] headius: good old deadbeef


[23:16:47] headius: *.net *.split


[12:25:47] headius: *.net *.split
[12:27:17] headius: has joined #ruby
[15:01:17] headius: *.net *.split
[15:03:20] headius: has joined #ruby


[23:56:01] headius: aarkerio: base
[23:56:18] headius: so 36 is 0-9a-z for digits


[08:39:57] headius: Ping timeout: 264 seconds
[08:41:33] headius: has joined #ruby


[15:22:15] headius: only if the movie is about ruby, the programming language


[09:16:24] headius: Ping timeout: 268 seconds
[09:35:44] headius: has joined #ruby


[15:24:59] headius: has left #ruby: ()
[17:12:05] headius: has joined #ruby


[06:34:47] headius: *.net *.split
[06:35:20] headius: has joined #ruby


[02:43:54] headius: Ping timeout: 268 seconds
[02:45:05] headius: has joined #ruby


[00:38:27] headius: Ping timeout: 240 seconds
[00:38:37] headius: has joined #ruby


[18:30:29] headius: Quit: ZNC - http://znc.in


[15:09:35] headius: Quit: ZNC - http://znc.in
[15:30:35] headius: has joined #ruby


[12:52:26] headius: darix: no update really I guess...can you point me at the issue again?
[12:52:36] headius: we do a search, but it must not be enough on some platform


[17:02:29] headius: dionysus69: those benchmarks are only adding numbers, which has a bit higher cost in JRuby
[17:02:41] headius: dionysus69: generally JRuby will be faster for things that aren't just loops


[09:39:36] headius: Ping timeout: 240 seconds


[21:51:48] headius: Ping timeout: 255 seconds
[21:52:15] headius: has joined #ruby


[21:13:33] headius: RickHull: MRI has native threads but they're locked to only allow one running Ruby code at once
[21:13:41] headius: green threads are different
[21:21:53] headius: RickHull: Ruby 1.9 switched to native threads with a lock
[21:22:01] headius: like 2007 or 8
[21:22:44] headius: also jruby and truffle are separate projects now btw


[18:35:25] headius: morfin: JRuby should work fine with any JDK, and we recommend OpenJDK


[13:41:55] headius: has joined #ruby


[14:33:32] headius: Quit: ZNC - http://znc.in


[00:17:18] headius: *.net *.split
[00:23:11] headius: has joined #ruby


[22:27:26] headius: has joined #ruby


[14:43:36] headius: Ping timeout: 240 seconds
[15:08:06] headius: has joined #ruby


[20:03:00] headius: Ping timeout: 245 seconds
[20:03:22] headius: has joined #ruby


[18:50:04] headius: Mattx: rvm jruby do ruby ....
[18:50:24] headius: I have ruby23 aliased to "rvm ruby-2.3.0 do ruby"


[20:12:38] headius: Papierkorb, rann: any gem can ship binaries for a specific platform by releasing a platform-specific gem
[20:12:47] headius: most JRuby gems that have jars in them are -java for this reason
[20:13:37] headius: Papierkorb: I remember seeing one but can't remember what it was
[20:14:05] headius: I think it's usually just easier to have some makefile rules for *nix than to release binary builds
[20:14:15] headius: maybe if you're closed source you'd want to do it


[18:15:44] headius: CRuby doesn't even have a JIT
[18:16:55] headius: well apart from getting the overhead of an interpreter out of the way, you can inline methods and get better optimization of the whole
[18:17:46] headius: it's definitely interpreted
[18:18:34] headius: yes, and it runs in the interpreter
[18:18:43] headius: it's a bytecode interpreter, similar to JVM
[18:19:06] headius: unlike JVM or JRuby or Truffle, they don't proceed on to a JIT ever
[18:19:51] headius: Papierkorb: chrisseaton knows the current status but I believe there's still hoops to jump through
[18:20:11] headius: last time I saw someone try to play with it they had to build Graal themselves
[18:20:33] headius: things are moving rather fast but it's still a good ways out from general use
[18:21:39] headius: I wouldn't expect Elixir to compare at all
[18:22:14] headius: jhass: it's more than that specific pattern
[18:22:26] headius: it could be [a, b, c, d, e].max and it still optimizes through it
[18:22:39] headius: Papierkorb: heh, JRuby's 5-10x faster than CRuby already
[18:22:47] headius: for compute-heavy loads
[18:24:42] headius: you absolutely should
[18:24:45] headius: that's almost always a bug
[18:25:37] headius: Papierkorb: there are a few specific areas where we have trouble matching perf, but most stuff should be much faster in JRuby
[18:25:59] headius: dminuoso: they may, yes
[18:26:35] headius: the most popular JVM JIT, Hotspot, has its own internal representation that it optimizes before proceeding to machine code
[18:26:44] headius: and then the machine code gets some different sorts of optimization passes
[18:27:34] headius: Papierkorb: well please do ping me here or in #jruby
[18:27:59] headius: dminuoso: most JITs gather profile information while the code is interpreting, and then use that to optimize the code well
[18:28:32] headius: so if you have a loop calling obj.to_s all the time and it turns out "obj" is an Array, we can just check that and inline Array#to_s right there
[18:28:50] headius: lupine: we do not yet but have talked about doing it in the future
[18:29:03] headius: it's difficult to know if that profile is still valid between runs, though
[18:33:34] headius: Papierkorb: .NET does a one-time compile from IL to native, and never optimizes again
[18:33:59] headius: at least, last I read about it they didn't ever optimize again, and had no profiling happening in that generated binary
[18:34:16] headius: CLR generally starts faster but runs slower than JVM


[21:20:30] headius: Ping timeout: 246 seconds
[21:23:14] headius: has joined #ruby


[06:10:32] headius: pilne: JRuby proper can use Java libraries very easily. I don't believe that's implemented for JRuby+Truffle yet (and it's not really production-ready for a while anyway)