<nirvdrum>
thedarkone2: I forgot what I posted. I thought you were talking about the ropes work for a moment :-)
<chrisseaton>
that's brutal too - brutal to slow Ruby code
donV has quit [Quit: donV]
pawnbox has joined #jruby
<thedarkone2>
nirvdrum: starting to see ropes everywhere? :)
yfeldblum has quit [Ping timeout: 260 seconds]
brauliobo_ has quit [Ping timeout: 244 seconds]
grs has quit [Ping timeout: 276 seconds]
jeremyevans has joined #jruby
pawnbox has quit [Ping timeout: 260 seconds]
<nirvdrum>
thedarkone2: They're what I think about as I try to fall asleep and the first thing I think of when I wake up.
<lopex>
nirvdrum: crazy work on ropes
<thedarkone2>
nirvdrum: haha, you should start worrying once you buy a book on knot tying :)
<lopex>
nirvdrum: what's the potential of that lazy int rope thingy ?
<nirvdrum>
Heh.
<nirvdrum>
lopex: That was chrisseaton's work. But evidently there are a lot of cases where Fixnums are concatenated to a string and the real value is never called for.
<lopex>
so mostly the statistics ?
<chrisseaton>
I also just wanted to try a different kind of rope beyond some combination of byte[]
<lopex>
chrisseaton: what are the numbers wrt usage ?
<lopex>
er, cases I should say
<lopex>
in the corpus
<chrisseaton>
I only did it for Fixnum#to_s, and some exception messages, but it saved 5s on our spec times
<thedarkone2>
chrisseaton is just jelly of nirvdrum's ropes
<lopex>
chrisseaton: do you recall neo4j analysis wrt ruby code thingy ?
<chrisseaton>
no?
<chrisseaton>
someone told me neo were doing something interesting with Ruby though
<lopex>
nirvdrum: I admit the truffle/rope framework is not a thing one might want to jump at right away
grs has joined #jruby
<lopex>
but it's clever
<nirvdrum>
lopex: It's nice now. The early implementation sucked. I had to replace ByteList virtually everywhere and when String doesn't work, very little else does either.
<nirvdrum>
We still use ByteList. It has its place.
<lopex>
nirvdrum: bytelist must go away in truffle right ?
<nirvdrum>
I don't think so.
<nirvdrum>
We just don't want to have too many Rope <=> ByteList conversions.
<nirvdrum>
Since ropes are immutable and ByteLists might be shared, we have to make defensive copies at the boundaries.
<nirvdrum>
And that gets costly.
<lopex>
nirvdrum: huge work btw, very cool
<nirvdrum>
I'm hoping to have some real world performance numbers soon.
<nirvdrum>
I wrote them with an eye towards JRuby adopting them as well.
<lopex>
ropes help PE mostly right ?
<nirvdrum>
It'd require a few tweaks because I got lazy and started mixing in Truffle annotations. But that's manageable.
<lopex>
line substrings and so on
<nirvdrum>
lopex: It's amazing how much can be gained by having the character length already calculated.
<lopex>
yes
<nirvdrum>
And that has nothing to do with PE.
<lopex>
I admit it now
<lopex>
nothing ?
<nirvdrum>
Well, I mean you gain a lot without having to compile.
<nirvdrum>
If you have a CR_7BIT string and mix in a CR_VALID string, all of a sudden your length calculation goes from constant to linear time.
<nirvdrum>
And since character length is used for bounds checking, that can add up quickly.
<lopex>
but PE might exhaust substrings being a literal for example ?
<nirvdrum>
Eh?
<lopex>
disregard that
atambo has quit [Ping timeout: 276 seconds]
atambo has joined #jruby
<lopex>
nirvdrum: one can get lost on the specializations
<nirvdrum>
For ropes? Or in general?
<lopex>
general
<lopex>
I mean you have to put human effort to it
<lopex>
I see some redundancy
<lopex>
well
<lopex>
would a preliminary profile do somne start ?
<lopex>
the specialization is kind of fragile
<lopex>
it lacks a preliminary type system
yfeldblum has joined #jruby
seyfahni has quit [Ping timeout: 260 seconds]
<nirvdrum>
DynamicObject makes things harder, for sure.
<nirvdrum>
But IRubyObject can be annoying to work with as well.
<nirvdrum>
The @Cached annotation snippets can make specializations harder to read, too.
<nirvdrum>
On the other hand, the specialized methods are smaller than you'd get with a single method and a chain of conditionals.
* nirvdrum
shrugs
mj12`_ has joined #jruby
pawnbox has joined #jruby
mj12` has quit [Ping timeout: 276 seconds]
<lopex>
nirvdrum: explain to jit that's a small method
<nirvdrum>
It uses an inline cache to make virtual calls concrete.
<nirvdrum>
I was pretty excited to figure that out.
<lopex>
nirvdrum: shit
<lopex>
nirvdrum: rocket science
hobodave has joined #jruby
hobodave has quit [Client Quit]
<nirvdrum>
To be fair, Chris pointed me to Class#cast. I didn't know that existed.
<lopex>
nirvdrum: what's the limt ?
<lopex>
er, i mean the cache limit
<nirvdrum>
Practically, however many Rope subclasses there are, which is small.
<lopex>
ah a custom thing
<nirvdrum>
I think I have it set to 6.
<nirvdrum>
It's controllable as a runtime option at startup.
<lopex>
cool
Aethenelle has quit [Quit: Aethenelle]
<lopex>
nirvdrum: I really try to follow your commits but you;re so much advanced on those subjects
<nirvdrum>
Eh, I don't know about that. I'm just spending more time on them.
<lopex>
hah :)
<nirvdrum>
But if you think my commit messages aren't helpful enough, let me know.
pawnbox has joined #jruby
<lopex>
now I have a dilemma, joni byte core or joni truffle ?
<nirvdrum>
Heh.
<lopex>
no idea
<thedarkone2>
for regexes, do you concatenated into an arr and send it to a regexp lib?
pawnbox has quit [Ping timeout: 244 seconds]
<nirvdrum>
For regexes we basically call into JRuby's backend. Our regexp backend needs someone to sit down and do it properly.
<lopex>
why ?
<nirvdrum>
Why what?
<thedarkone2>
so do you have plans for a full-fledged truffle reimplementation?
<nirvdrum>
I don't see us moving away from joni or anything like that. But we currently convert ropes to ByteLists to call into JRuby's backend. And since we're using their runtime, we can't specialize on much.
<nirvdrum>
So, the plan is to unwind that, sharing common code in RegexpSupport like we've done with strings.
<thedarkone2>
or do you think changing regexp backend (without "truffleziation") to be able to operate on ropes is feaseable?
<thedarkone2>
(I've never looked at joni)
<nirvdrum>
I think we can make it work better with ropes, but not as optimally as if it were designed with ropes in mind from the outset.
<nirvdrum>
Although I don't know how what a rope-oriented rather than a byte-oriented engine would look like.
<nirvdrum>
I suspect a lot of it would be exploiting the structure of ropes.
<nirvdrum>
Keep track of match positions and traverse the leaves rather than reify a byte[] with all the rope contents, for instance.
<thedarkone2>
Rails doesn't use regexp on the view output (what comes out of view templates), right? I don't think it does.. otherwise that's a disaster waiting to happen
<nirvdrum>
They use erubis by default I believe, and I don't think that does much with regexp. But I've only looked at ERB in detail.
<nirvdrum>
erubis is some sort of evolution over ERB.
<nirvdrum>
And ERB needs to do an eval for every render, so it's not the pinnacle of efficiency to begin with.
<thedarkone2>
what I mean, is I see a huge opportunity for ropes in rails views as it basically 1000x short string appends
<thedarkone2>
Rails does the eval only once, the output of ERB (or whatever) backend is class_evaled into custom mangled method
<thedarkone2>
that is then called for each partial/template render
<nirvdrum>
Yes. Ropes work very well with a sequence of concats.
<thedarkone2>
and Rails is basically one long series of concats with some DB calls interspersed :)
<nirvdrum>
Heh.
<nirvdrum>
Don't forget all the superfluous metaprogramming.
<nirvdrum>
Truffle works really well with that :-)
<thedarkone2>
I was just an alaborate way to do a series of string concats :0
<thedarkone2>
it*
<nirvdrum>
I'm working on adding an ERB benchmark to bench9000.
<nirvdrum>
But I'm not exactly using ERB. I've just extracted the generated concat code.
<nirvdrum>
That way eval doesn't get in the way.
<thedarkone2>
now, you have a really wonderfull zero-copy rope comming from each particular view/template
<thedarkone2>
but if somebody uses a regexp on that rope, it means trouble...
<nirvdrum>
Deferring all those byte[] allocations and System.arraycopy operations is substantial.
<nirvdrum>
So something like (("abcdefghij" * 1_000) + 'こ').first can look into the left child and see that it's only 7-bit chars and do a direct element access.
<nirvdrum>
s/\.first/\[0\]/
<nirvdrum>
Currently, multi-byte characters wreak havoc on Ruby string implementations.
<nirvdrum>
I wouldn't be surprised if there's a DoS vector in there.
<thedarkone2>
that's neat, I haven't thought of that
<nirvdrum>
The example seems a bit contrived, but in a template rendering user input, it's not so contrived.
<thedarkone2>
yeah, that's the same with dead-code elimination optimization: "What the hell is that? That is not going to speed up my app! I don't write dead code, and even if I accidentally did, it wouldn't be in a bottlenecky code!!!"
<nirvdrum>
Heh.
<thedarkone2>
btw for that bench9000 erb template, make sure that the buf (the thing that everything is concatenated into) is stored in an i-var, that's what is happening in rails, don't use a local
<nirvdrum>
Interesting.
<nirvdrum>
I was just using the _erbout that ERB uses.
<thedarkone2>
it prob won't make much a difference, that repeated i-var read will be folded by graal (in the bench at least)
pawnbox has joined #jruby
<thedarkone2>
you should also probably make sure, that the final _erbout escapes (in case graal figures out that it doesn't), since this is what is going to happen in Rails
pawnbox has quit [Ping timeout: 276 seconds]
bb010g_ has quit []
bb010g has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
zacts has joined #jruby
pawnbox has joined #jruby
fuzzyhorns has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
yfeldblu_ has joined #jruby
yfeldblum has quit [Ping timeout: 276 seconds]
yfeldblu_ has quit [Ping timeout: 260 seconds]
fuzzyhorns has quit [Quit: Leaving.]
pawnbox has quit [Remote host closed the connection]
<fuzzyhorns>
my thought process was if i do become_java!(false) it should be on the JRuby class loader, which I can then add to the classpath of the classpool
<fuzzyhorns>
but ctClassOfEndpoint = pool.get("rubyobj.TestEndpoint") doesnt find it :c
johnsonch_afk is now known as johnsonch
brauliobo_ has quit [Ping timeout: 244 seconds]
lupine has left #jruby [#jruby]
rtyler has quit [Ping timeout: 260 seconds]
rtyler has joined #jruby
johnsonch is now known as johnsonch_afk
Prasun has joined #jruby
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
<GitHub57>
[jruby] nirvdrum pushed 2 new commits to master: https://git.io/vwLHj
<GitHub57>
jruby/master e25eac8 Kevin Menard: [Truffle] Added support for substring of MBC rope buffers.
<GitHub57>
jruby/master 946318a Kevin Menard: [Truffle] Fixed String#length for MBC rope buffers.
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
Prasun has quit [Ping timeout: 244 seconds]
pawnbox has quit [Remote host closed the connection]