<GitHub9>
jruby/master 250d564 Kevin Menard: Bumped jcodings from 1.0.17 to 1.0.18-SNAPSHOT.
prasunanand has quit [Ping timeout: 264 seconds]
rcvalle has joined #jruby
<headius>
chrisseaton: hey, I asked a form of this before but I have a bit more concrete question now
<chrisseaton>
hello
<headius>
I'm wondering about these many dyncalls from e.g. Integer and Numeric back into custom types and wondering about profile information for the various benchmarks and apps
<headius>
specifically I'm curious how valuable specializing these call sites, and even these methods, might end up being
<headius>
is that something that the truffle AST exposes?
<headius>
a pattern is emerging in which most of the core Java-based methods that have dyncalls might as well just be Ruby
<chrisseaton>
You can visit the Truffle AST to read information about caches and splitting (but not inlining)
<headius>
since JRuby proper can also do a better job of caching and specializing
<chrisseaton>
The group at King's College have a visualiser for this I can show you in private
<chrisseaton>
But yeah almost everything is better in Ruby
<headius>
well, it's better in a language that we can optimize like Ruby
<headius>
unfortunately Java makes that cumbersome right now
<chrisseaton>
Apart from cases where you have lots of options, and Ruby provides no language construct for something like an if statement with lots of cases, but allowing it to be reordered based on most common cases - we should do that
<headius>
yeah enebo and I have been talking about that in a few forms
<chrisseaton>
Let me give you a concrete examples from yesterday...
<headius>
pragmas for declaring low-level loops and switches, DSLs for IR
<headius>
we'd like to be able to write more in Ruby but we also don't want to introduce a huge startup issue
<chrisseaton>
I'd like to have all cases in that case to be behind a de-opt until they're first used, and then I'd like them to be ordered by frequency, but that's not compatible with conventional Ruby semantics, so I need to annotate it or something
<headius>
chrisseaton: heh yeah that's a beaut
<chrisseaton>
You're in a bit of a bind because you have to stay usable - I think we're more happy to break a few more eggs in hope of a better omlette
<headius>
it's a different challenge, indeed
<headius>
that form at least could be specialized pretty easily
<enebo>
hah
<enebo>
chas a random note why is this not a hash table?
<headius>
an all-constant switch that is constant time once it determines the branches are all fixnums
<headius>
that's certainly valid
<enebo>
I mean I agree this should be optimisable but it is a static set
<headius>
most languages don't have a constant-time branch-on-type in anything but the simplest cases
<chrisseaton>
but it's using ===, it's not .class lookup
<headius>
yes but that's just a technicality
<chrisseaton>
I mean that's why we can't use a hash
<enebo>
it also has Object and a fallthrough for BAsicObject
<headius>
if you knew they were all Class and hadn't overridden ===, the fact that it calls === is irrelevant
<chrisseaton>
Unless we start allowing custom comparison in hashes
<headius>
same for any other homogeneous switch
<headius>
so it is eventually stable
<chrisseaton>
but I mean value may not actually have these exact classes, it could be a subclass
<headius>
eventually is the tricky bit :-D
<enebo>
technically we cannot even know this is stable or homegenous
<chrisseaton>
(this code is just junk to get things working by the way, don't over analyse how we're implementing this)
<enebo>
it can always deopt if one of these constants change
tcrawley is now known as tcrawley-away
<headius>
pretty sure Class#eql? is the same as == and ===
<headius>
so this case doesn't care
<enebo>
chrisseaton: yeah just idle curiousity
<headius>
again assuming eql? is the built-in one
<headius>
I thought all these T's would be integers anyway
<headius>
in which case it could be a proc table
<headius>
I guess a hash like enebo suggested
<enebo>
will Hash not match Class wit ===?
<enebo>
I feel like I am having an ageism here :)
<headius>
Hash uses eql?
<headius>
but that's ==== for Class by default
<enebo>
headius: I am just looking at this code still
<enebo>
ignore me though I resolved my question
<nirvdrum>
headius, enebo: Any chance one of you wouldn't mind pushing a new jcodings snapshot please?
<enebo>
nirvdrum: so just mvn deploy HEAD?
prasunanand has joined #jruby
<enebo>
chrisseaton: since rbx has extra exposed stuff already (CompiledMethod…) you could change this to value.type.cext_type or something and eliminate switch or hashing
<enebo>
err value.class.cext_type
<enebo>
chrisseaton: not to keep foxusing on this basic code but I can’t help it :P
<enebo>
nirvdrum: I deployed HEAD
<chrisseaton>
enebo: I've got a vague intention of trying to do it all in pure Ruby
<enebo>
chrisseaton: that can be in pure Ruby?
bbrowning is now known as bbrowning_away
<chrisseaton>
well yeah as much as I can
<chrisseaton>
if it's slow I'll fix that later
<nirvdrum>
enebo: I think so. Thanks.
<chrisseaton>
openssl doesn't compile yet, so it's far down the list of problems
<enebo>
chrisseaton: yeah I just meant my suggestion was not something which would be in Java vs Ruby
<enebo>
chrisseaton: in Ruby it would expose an extra method on Module but I am guessing impl-specific methods already exist
<chrisseaton>
yeah they do
<chrisseaton>
We're trying to put them in modules like Truffle::Array instead
<enebo>
BasicObject.cext_type woudl raise and each specific one in the list would just return its value
<enebo>
but I realize you are addressing perf issues as you actually find them
<enebo>
and this one probably is not one :)
<chrisseaton>
There's not much documentation of the C API is there
<chrisseaton>
Even for users
<chrisseaton>
Can't get my head around the TypedData macros
<enebo>
chrisseaton: no I don’t think so
<headius>
heh
<headius>
yeah the C API is a huge surface area
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
man, numeric classes are chock full of redispatching
<enebo>
headius: I enjoyed seeing modulo easlier
<GitHub101>
[jruby] headius pushed 1 new commit to java_call_sites: https://git.io/vKHpZ
<GitHub101>
jruby/java_call_sites b3f930a Charles Oliver Nutter: Call site caching for Integer.
pitr-ch has joined #jruby
tjohnson has joined #jruby
<headius>
taking these one class at a time
<headius>
breakage in here is deep and hard to trace
<headius>
you are likely to be eaten by a grue
e_dub has quit [Quit: ZZZzzz…]
<GitHub76>
[jruby] headius pushed 1 new commit to java_call_sites: https://git.io/vKQfc
<GitHub76>
jruby/java_call_sites 8e4317a Charles Oliver Nutter: More sites for Numeric in Numeric.java utility class.
<subbu>
chrisseaton, no register allocation to locals. are jvm locals a scarce resource? or does packing into as few as possible locals help?
<chrisseaton>
subbu: well a JVM local has to always be live because of the debugger - if a Ruby variable goes out of scope (I know binding makes that hard to see) you could re-use the JVM local
<chrisseaton>
also I've seen real Ruby methods with more locals than JVM locals available
<chrisseaton>
re-using means less memory, better cache, etc
<subbu>
i see .. so, packing could help in some scenarios.
<subbu>
my take had been that the jvm (hotspot) could manage lvar resources ... but i see what you are saying about maintaining enough state for exceptions & debugging.
camlow32_ has joined #jruby
camlow32_ has quit [Remote host closed the connection]
camlow325 has quit [Read error: Connection reset by peer]