<ChrisBr>
enebo: headius: it's getting into shape :) With the hash cache in an int array and removed almost all RubyHashEntries I see quite some improvement :)
<enebo>
ChrisBr: cool
<sgeorge>
Good morning enebo, Do you happen to know of a handy resource for which JRUBY_OPTS options were deprecated in 9000? And for those options that have a recommended replacement, what those are? I didn't see on http://jruby.org/news , not sure if that's the right spot to be looking.
<ChrisBr>
enebo: I will update the PR in a bit with the new code and some numbers
<enebo>
sgeorge: weirdly I don't. Did you run into something we stopped supporting. I can think of version options like --1.8 and it is possible some more experimental ones stopped working
<sgeorge>
enebo: oh no worries, was just wondering. Thanks very much. Under JRuby 9.1.2.0 (sorry, I should be testing on 9.2) I noticed that JRUBY_OPTS='-Xcompile.mode.fastest=true -Xjit.treshold=20' lead to warnings: https://gist.github.com/sfgeorge/96eaf7790327cd6ab09dcf33d867f933 I'm just curious if there are newer/better ways to specify the same things - or if they are rendered moot.
<enebo>
sgeorge: yeah the one flag you may be interested in based on fastest would be -Xcompile.invokedynamic
<enebo>
sgeorge: That option is somewhat misnamed as it just enabled more invokedynamic than we use by default
<enebo>
sgeorge: threshold is the same as in 1.7
<enebo>
sgeorge: once we solve our issues with warmup using all the invokedynamic we want to use that option should eventually be a noop
<sgeorge>
nice. Yeah, currently I am a bad, bad old dinosaur with -Xcompile.invokedynamic=false using jruby-1.7.4 -_-
<sgeorge>
Wow, just realized that you guys totally have "jruby --properties" with an extensive explanation of current options. This is immensely useful! Sorry, I should have RTFM'd
<enebo>
sgeorge: oh yeah sorry I thought you knew about that :P
deobalds has quit [Quit: Computer has gone to sleep.]
<enebo>
I do wish we had a nice break down of what we changed
<sgeorge>
Not to worry. Oh wow - leave it to me to realize only now that I've been running with -Xjit.treshold=20 instead of -Xjit.threshold=20 all along -_- jruby-1.7.x doesn't seem to warn on unrecognized opts... but pretty awesome that 9k does.
Puffball has joined #jruby
slyphon has joined #jruby
<ChrisBr>
enebo: added some numbers to the PR
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
claudiuinberlin has joined #jruby
nelsnelson has joined #jruby
nelsnelson has quit [Client Quit]
nelsnelson has joined #jruby
<enebo>
ChrisBr: can you run a bench like you have but use String as key instead of fixnum?
<enebo>
String calculates hashCode every time
<enebo>
oh and so far the numbers look really good
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
ahorek has joined #jruby
ahorek has quit [Client Quit]
rdubya has quit [Quit: Leaving.]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
ChrisBr: that's sounding awesome
<headius>
ChrisBr: if possible I'd like to do some testing with this on Graal for my talk in two weeks, to see if it's better at eliminating this flatter structure
Puffball has quit [Quit: Puffball]
claudiuinberlin has joined #jruby
eregon has quit [Remote host closed the connection]
<ChrisBr>
enebo: I forgot, the bench is already with strings
eregon has joined #jruby
<ChrisBr>
I did it with fixnum but the hashes basically the fixnum value so the hash distribution is really bad for a range (basically not existent)
<ChrisBr>
I will add the script I used
<ChrisBr>
headius: ^^
<headius>
ok
<headius>
is the code on the PR branch usable right now for testing?
<ChrisBr>
headius: yup it is the latest version and should compile
<enebo>
ChrisBr: ah cool I think both something which caches hashcode and something which calculates is a good for measuring
<ChrisBr>
enebo: I can add numbers for Fixnum as well but IIRC the open addressing was still a lot better than master
<enebo>
ChrisBr: oh yeah no doubt but I just like to look at classes of data
<enebo>
If nothing else we get a bound of improvement to talk about
<enebo>
ChrisBr: along those lines doing something nuts like using Struct as keys would be a worst case but I suspect hash calculation to totally dominate whenever it was called
<enebo>
with that said it is weird to use stuff like that for keys
<ChrisBr>
my benchmarks are still sometimes flaky, especially for a small number of keys :/ So would be great if sb could verify my benches or have some ideas to make it less flaky
<ChrisBr>
seems like for a high number of keys the performance is close together, maybe because the distribution is quite "bad" (but also means no collisions)
<ChrisBr>
I think we also made some improvements for strings as put was "badly" implemented -> it first checked for existence, froze the string and then added which required to calc the hash and bucket index again
Puffball has joined #jruby
<enebo>
ChrisBr: can you readd the hask to reuse a single rubyhashentry and just see if you can see a big difference or not? That would not be part of this PR but it would inform us about whether we want another API
<havenwood>
we're prepping for a release of ruby-install and i have a few JRuby questions
<enebo>
havenwood: we prefer to have those go away at this point
<havenwood>
enebo: roger that
<headius>
well Java 8 for 9.2
<enebo>
plus it is getting difficult for older releases to be run no ancient java releases
<headius>
anything before that is fine with 7 but 7 is EOL for several years now
<havenwood>
default-jdk for apt?
<havenwood>
java-openjdk for dnf?
<havenwood>
openjdk for pkg
<havenwood>
and then jre8 for the ones that need versions?
<headius>
default might do 9 or 10 which could trip some people up because we aren't great on those versions yet
<headius>
other than that it sounds fine
<headius>
8 is recommended
<headius>
9 and 10 work but have known issues
<havenwood>
okay, 8 sounds good to me
<ChrisBr>
enebo: you mean have a static RubyHashEntry which I use instead of getting rid of the RubyHashEntries?
<headius>
thread-local but yeah basically
<ChrisBr>
I already tried that for fetching / deleting
<ChrisBr>
and it was almost the same as with using new RubyHashEntry objects
<ChrisBr>
that was the initial approach I had
<ChrisBr>
simplified
<ChrisBr>
I think for fetching / deleting it shouldn't be a problem to not use RubyHashEntry anymore, should it? Where I think it will break API I already use temporary RubyHashEntry objects
<enebo>
ChrisBr: it is purely just an experiment
<enebo>
if allocation shows up then we change API to pass in alloc'd object to get populated or return tuple of info another way
<enebo>
hopefully not as gory as how we deal with bytelist data though :)
<havenwood>
headius: thanks, we'll bump them to 8 and i'll check with postmodern on just dropping pre-1.7.5 support.
<ChrisBr>
enebo: could you maybe comment on the PR where I should do that? Not 100 % sure I understand correctly...
<enebo>
havenwood: thanks for contacting us. getting off s3 will really help us a lot
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jrafanie has joined #jruby
Puffball has quit [Ping timeout: 260 seconds]
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<GitHub60>
[jruby] headius created improve_kwargs (+2 new commits): https://git.io/fNmqD
<GitHub60>
jruby/improve_kwargs 4116c0c Charles Oliver Nutter: Reduce overhead of frobnicating by doing an initial symbol scan....
<GitHub60>
jruby/improve_kwargs c75aef3 Charles Oliver Nutter: Move frobnicate into method body, out of method handles.
<headius>
ChrisBr: performance/hash has all latest work?
<headius>
I'm twiddling kwarg performance a bit today and I'm curious if your stuff helps