etehtsea has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
etehtsea has joined #jruby
zacts has joined #jruby
etehtsea has quit [Quit: Computer has gone to sleep.]
etehtsea has joined #jruby
takanuva has joined #jruby
<takanuva>
I'm precompiling a few classes with jrubyc... shouldn't java_package automatically import any classes on the same package? is there any way to achieve this?
vali has joined #jruby
pawnbox has joined #jruby
etehtsea has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
headius: we (the entire VM community) doesn't really know how to detect if something is warmed up so that warning is just a heuristic, and it's a bad one really
<chrisseaton>
I've improved everything in benchmark-interface, bips and I was working on a new tool deep-bench but didn't get very far on that yet
<chrisseaton>
bips now does proper confidence intervals on comparisons, if you didn't know
<chrisseaton>
ebarrett who you sometimes see in this room has some new ideas on it though
<headius>
chrisseaton: ok, thanks
<headius>
what's the easiest way to reduce warmup on this? JRuby proper doesn't need minutes
<headius>
hard to iterate on profiling when it takes 5 minutes for one bench to run
<chrisseaton>
the new benchmark-interface solves the warmup problem by running blocks of iterations that take a second, rather than a fixed number
<chrisseaton>
bench9000 ran a fixed number, so that number has to be huge for when it's warmed up, but then during warmup it's far too big
<chrisseaton>
And also I was just erring on the side of caution so I did a massive warmup, as too much wastes time but doesn't really harm anything
<nicksieger>
headius: you too!
<headius>
nicksieger: how's the new gig treating you?
<chrisseaton>
unless I was publishing a paper I'd be happy using benchmark-interface and bips, and then warmup is fine in most cases
<nicksieger>
good! believe it or not at the new job we've inherited a jruby/torquebox app
<chrisseaton>
nicksieger: where did you go to?
<nicksieger>
whose performance characteristics are not nearly what I would expect
donV has quit [Ping timeout: 260 seconds]
<nicksieger>
so you might be hearing from me as I get back up to speed.
<nicksieger>
chrisseaton: I landed at a Minneapolis company called Sports Engine, primarly a Ruby/Rails shop
enebo has joined #jruby
<headius>
nicksieger: ahh excellent...we'll have to get together and chat about that
<nicksieger>
definitely! you and enebo should come over here sometime, I'm in the middle of brewery central
<enebo>
nicksieger: you has me at ‘should'
<headius>
indeed
<nicksieger>
yes, indeed is right over here :)
<nicksieger>
Indeed, you should be Able to meet up
<chrisseaton>
We need a shared server somewhere we can all log into!
hobodave_ has joined #jruby
<headius>
well switching to CMS reduced my score to 160
<headius>
it's a very object-heavy bench
<enebo>
headius: 160 from what?
<headius>
160 is still 40-50% faster tha n MRI Though
<headius>
215ish
<enebo>
wow
<headius>
yep
hobodave has quit [Ping timeout: 240 seconds]
<enebo>
I think nirvdrum wired Boehm into his JDK
<nirvdrum>
headius: These numbers are from a virtualized environment (I wouldn't do that for a paper), but hardware timers are set up correctly and the results are remarkably consistent. It's an Ivy Bridge-E CPU.
<headius>
oh you're not directly on hardware
<nirvdrum>
I'll run them on a dedicated server somewhere.
ahorek has joined #jruby
<headius>
that could make a big difference
<headius>
still something to look into but we're comparing apples and oranges here
<enebo>
it would be a remarkable discovery
<headius>
and it might not even be our fault if it's the virtualization
<enebo>
At least knowing what would halve perf on virtualized system
<headius>
I mean, it's just jdk right?
<nirvdrum>
I'd think TurboBoost would be a more likely culprit.
<nirvdrum>
It's a shame. The ones before that with the soft keys were amazing.
<headius>
I liked the older one better but I got used to the new ones
<headius>
I don't think I could ever use the new air keyboard though
<nirvdrum>
But, other manufacturers followed suit and now it's really hard to find a laptop with keys I like. I settled for this Lenovo mostly because it has at least reasonable travel distance.
<nirvdrum>
It may just be that I type too aggressively. Dunno.
<headius>
I wouldn't mind having a dedicated workstation but RHT isn't exactly made of money
<headius>
and I have no need for it otherwise
<nirvdrum>
This is from my Mogotest days.
<enebo>
nirvdrum: is that a single SSD?
<headius>
I still have some workstations Sun gave us but they're circa 2006 Opteron boxes with 4GB max memory :-D
<headius>
hmm opteron 180 around $100 refurb
<enebo>
headius: there was non-operaton multi cores which fit that socket
<enebo>
headius: so less cache but more CPU
<headius>
athlon 64 I think
<headius>
but it doesn't have dual core
<headius>
I'd rather go to dual core opteron than faster athlon 64
<enebo>
headius: there was definitely a multicore which fit on that board
<headius>
opteron 180
<enebo>
ah ok
donValentin has quit [Quit: donValentin]
<enebo>
nirvdrum: what I find weirdest is we get 2x on all benches and you get 2x on all but this one
<enebo>
nirvdrum: something distinct about this bench the others don’t run into
<nirvdrum>
enebo: Have you run all the others?
<headius>
I don't know what all the others are
<enebo>
I just meant in file.rb
<enebo>
err not all were 2x I guess but several were
bbrowning is now known as bbrowning_away
<nirvdrum>
headius: They're all in that repository.
dinfuehr_ has quit [Remote host closed the connection]
nicksieger has quit [Remote host closed the connection]
claudiuinberlin has quit []
<GitHub151>
[jruby] chrisseaton closed pull request #4120: [Truffle] Add name to Thread layout (truffle-head...truffle-thread-name) https://git.io/v6hkr
<GitHub68>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/vivmj
<GitHub68>
jruby/truffle-head dc3dc85 Chris Seaton: Merge pull request #4120 from jruby/truffle-thread-name...
bbrowning has quit [Quit: Leaving]
nicksieger has joined #jruby
nirvdrum has joined #jruby
rsim has joined #jruby
zacts has joined #jruby
tcrawley is now known as tcrawley-away
nicksieger has quit [Remote host closed the connection]
nicksieger has joined #jruby
zacts has quit [Ping timeout: 240 seconds]
zacts_pi has joined #jruby
zacts_pi has quit [Ping timeout: 240 seconds]
zacts has joined #jruby
enebo has quit [Quit: enebo]
lanceball is now known as lance|afk
mberg is now known as Galt
hobodave_ has quit [Quit: Computer has gone to sleep.]
rsim has quit [Quit: Leaving.]
zacts has quit [Quit: WeeChat 1.4]
nicksieger has quit [Remote host closed the connection]
<nirvdrum>
headius: Back to bad news I guess. I did a clean Linux install, running without a hypervisor, and the numbers are basically what I reported previously.
<nirvdrum>
headius: Which is to say ~150 for MRI and ~190 for JRuby 9.1.2.0 with indy.
<nirvdrum>
That obviously gives JRuby a modest win, but not quite the 2x seen elsewher.
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
<nirvdrum>
And if I make it fairer, by turning off TurboBoost, SpeedStep, hyperthreading, and C states, the gap narrows to 145 (MRI) vs 170 (JRuby 9.1.2.0 +indy)
<nirvdrum>
And the numbers are much more stable with this config. While I was seeing +/- 10% before, I'm seeing +/- 1.2% now.