github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
patrickb Good *ning! 06:52
dogbert17 nine++, nice bughunting yesterday 08:45
and hello brrt :) 08:46
dogbert17 oh, it's timotimo 08:49
brrt ohai dogbert17 and timotimo
patrickb o/ 08:50
dogbert17 hello brrt, are you interested in some light work?
if so you might want to take a look at github.com/MoarVM/MoarVM/pull/1465 08:53
nwc10 good *, #moarvm 09:02
has anyone mentioned t/spec/S32-temporal/juliandate.t yet?
jnthn good * 09:26
nwc10: I've not seen a mention of that here, though I'm sure I saw some recent Rakudo issues about date stuff... 09:27
nwc10 with all the spesh nodelay stuff, for some runs, it can wedge a CPU at 100%
seeming same backtrace (deep down in arrays from the JIT)
different subtest numbers at which it hangs
have not investigated furtehr 09:28
need to write a mail to shut up/shut down the well meaning but, um, this is logged right, ignorant person writing Perl 5 threading fan fiction on p5p 09:29
lwn.net/Articles/754577/ and lwn.net/Articles/754163/ are interesting. Not directly releveant
(Python, the GIL, other optimisations tried) 09:30
jnthn That's a curious new genre of horror fan fiction, I guess... :)
jnthn looks ofrward to reading the mail 09:31
uh, forward
nwc10 it might actually be sort of interesting, as it's sort of Off Topic, as a chunk of it is summarising "removing the Python GIL failed" 09:34
nwc10 Oh my, got to chrisseaton.com/truffleruby/rubyco...-cexts.pdf -- 2.1 billion lines of code in RubyGems, 0.5 billion of it is C extension code 10:45
jnthn Wow. 10:46
I wonder what the CPAN ratio would be. 10:47
dogbert17 nwc10; it seems that t/spec/S32-temporal/juliandate.t has a tendency to gobble up all memory (I have 12 gig) 10:49
lizmat started a spectest last night, went to bed and found almost all applications OOMed 11:14
except, curiosly, the IRC client 11:15
nwc10 www.youtube.com/watch?v=YLtjkP9bD_U 13:38
is really fun.
you can s/Ruby/Perl/ and it wouldn't be much different.
and I did like the way that JRuby repeated the C Ruby extension API mistake. Oops. :-/ 13:39
I found it understandable at 1.5x speed
www.nntp.perl.org/group/perl.perl5...59770.html -- you're not adding any value. Please stop. 13:51
(to be clear, that's the TL;DR summary of my rather long message there, which is also about removing the Python GIL and some Ruby things) 13:52
[Coke] Wow, that's an essay. :) 13:55
[Coke] watches a few minutes of the rubyconf youtube and has the takeaway: write more in rakudo, not C. 14:00
jnthn I had to read one part a couple of times because I was like "how can you have a problem running the same sub on two threads but not have a problem with recursion" :) 14:12
Then realized I misunderstood the data structure that was described a few lines above, and it'd never occurred to me to implement it in that way.
And now I'm curious if that design is how things worked out because recursion was once not supported. 14:13
nwc10 I don't think so. A lot of things changed from Perl 4 to Perl 5. I think that 1 => 2 and 2 => 3/4 were more incremental 14:14
and I don't remember "Recursion" being in the "what's new for 5"
(I claim that) there has been so much "noise" in that thread already we need some "signal" to balance it up 14:16
I wonder if anyone is going to complain about the last github link I put in the message :-) 14:21
[Coke] checks out v5 to see if how borked it is against a recent raku 14:51
(it uses Panda, so probably a bit.)
nwc10 [Coke]: that's probably a good thing to do (or at least scope out) - thanks for looking at it. 15:28
But I fear that the person writing the perl 5 threading fan fiction didn't even acknolwedge my suggestion of (roughly) "maybe you want to prototype it in v5" 15:30
I'm glad he's only saying "I remain confident someone out there will have an then it's progress." and not "I find your lack of faith disturbing" 15:31
pants. retry
I'm glad he's only saying "I remain confident someone out there will have an epiphany." and not "I find your lack of faith disturbing"
anyway, we're having Eid next, aren't we? At some point...
jnthn At some point. 15:46
jnthn is near the end of current big $dayjob project and looking forward to more time for new-disp and rakuast :)
dogbert17 here's what it looks like when t/spec/S32-temporal/juliandate.t hangs and gobbles up all memory: gist.github.com/dogbert17/73bad49a...c52bb6d925 17:03
lizmat re use v5: after rakuast lands, that may be a thing to pursue again 17:27
but not before that
and the original issue of XS remains 17:28
nwc10 we just need to implement an LLVM IR interpreter in NQP. How hard could that be? :-) 17:30
lizmat medium ? 17:34
leont Given that Damian already implemented a p5 grammar in p5 regexps (PPR), a frontend to use v5 could be written with that as a starting point, even if there isn't any backend yet 17:46
lizmat last time I asked Damian that question, he suggested against doing just that 17:47
as there is apparently so much jumping through Perl hoops in there... 17:48
but of course, if someone would like to go that avenue, more power to them!
nwc10 I'm astounded by the size of the team(s) working on TruffleRuby. It's not *literally* a cast of thousands 18:03
But in the slides there are 16 people in the picture, 91 names in "Acknowledgements", and it sounded like 7 people directly working on it (in 2016)
brrt` my (cynical) observation on the matter - by the time TruffleRuby makes Ruby fast, is fast ruby going to be relevant still (in a commercial sense)? 18:04
bonsaikitten brrt`: if it's compatible enough ... I mean, there's tons of legacy ruby code out there that won't be rewritten
nwc10 unclear. You might know more of the state of things that I do. But it's 5 years since that and it's not taking over the world
*and* Shopify, who now employ the speaker, seem to be funding other work on a JIT for MIR (er, technically YARV, isn't it) 18:05
the IBM project mentioned in that talk seemed to die
it seems to be a bit like a summary in a Python talk - naming all the abandoned projects to make python faster 18:06
[Coke] hard for us to throw stones there. 18:08
(not that we should be throwing stones!)
nwc10 yes-and-no. They have had seeming several researcher/developer decades poured into this. 18:09
and they don't seem to be any nearer to world domination than we are
bonsaikitten afaict there's not much PR for it, and no showcase / tech demo to attract people 18:13
nwc10 It's funded by Oracle. It doesn't *need* to attract contributors 18:15
jnthn Yes, but it does need to attract *users*, who should do the migration work, and I think that probably breaks down in 3-ish ways of interest 18:21
1. Those doing bits of scripting and mostly running small throwawy things. If those are performance bound, it's low risk, but many such tasks aren't performance bound 18:23
2. Those with at lesat somewhat complex applications but who don't have the scale that they'll save significant amounts of money on servers etc. if they do migrate, and thus there's not much reward for the cost/risk. 18:24
3. Those who do have the scale. Shopify, for example. There's only so many of these. 18:25
moritz_ the real target market is those with high performance requirements but moderate complexity. If the complexity is too low, you could just do it in C. If it's too high, the risk of porting is also high 18:26
jnthn I would imagine that for anyone with a non-trivial application, it'll never be a true "drop-in" replacement, because these things never are if you have enough gnarly stuff, which becomes innevitable with application size.
It also seems to me that those ecosystems where competing compilers and VMs are commonplace achieved this relatively early in their language lifetime. 18:28
nwc10 it might also be that as Truffle and Graal are from Oracle, that folks don't trust the licencing. (ie, the price now might not stay that price) 18:31
jnthn With C it's typical, but these days there's probably less C compilers that one's code could be expected to build on than a decade or so ago. JavaScript had the browser wars. Java had commercial JVM alternatives within 5-6 years. 18:32
(I was actually expecting to write 10 years there, then went to check, and was surprised.)
nwc10: In this particular case, yes, though I think the "it's hard to prise users off The Original if it's been The Only for long enough" holds up more widely. 18:33
nwc10 yes, and I'd not considered that until you mentioned it. Thanks for that insight. (And everyone else) 18:34
bonsaikitten if it were a proper drop-in replacement the migration cost would be low 19:06
but there's usually some sharp edges to discover with the palm of your hand ;) 19:07
lizmat looks like Rakudo's MoarVM bump of a9490436e649df95b34ff8b is the cause of the performance drop of test-t from 1.9 -> 2.3 seonds 19:10
MasterDuke hm, i think that's the one that moves the unicode hashtable to MVMInstance? 19:12
lizmat anything merged after April 3 really 19:13
9b94bab9eb2803e19c46 could be ? 19:14
logging actual deconting ?
MasterDuke could be that too 19:14
lizmat I mean, it was not the backtrace fixes nine did 19:14
afaics 19:15
and the other fixes don't seem to be related to hot code
nine m: say $*PERL.compiler.version 19:19
camelia v2021.03.142.gb.4813.bbdb
nine Camelia's up to date again :)
lizmat whee!
nine Firewall rules were just in the wrong order so NAT64 was not active for camelia 19:20
MasterDuke btw, looks like geth is down again 19:21
what's the quick way to run just test-t? 19:22
lizmat raku -Ilib test-t.pl <hello.csv 19:23
in the Text::CSV repo dir
I use this to create the hello.csv file: 19:27
$*OUT = open("hello999.csv",:w); say q/hello,","," ",world,"!"/ for ^10000
MasterDuke yep. 1.4s at HEAD, 1.05s with 9b94bab9eb2803e19c46 reverted 19:30
lizmat ok, cool 19:31
then I don't need to look further :-) 19:32
MasterDuke heh. with that reverted, there are 9k deopts. without it reverted, only 5 deopts 19:37
lizmat yeah, not arguing it is doing a good thing 19:38
but apparently comes at a price :-(
MasterDuke but...3,822,149 frames entered with the logging, only 1,752,809 after the revert 19:39
lizmat ah, so it's setting something off elsewhere
?
that's more than 2x as many!
MasterDuke so 2x more frames, 1800x fewer deopts 19:40
frames (at least the ones added) are obviously much more costly 19:41
lizmat so, is the "if (MVM_spesh_log_is_logging(tc))" introducing an extra frame ? 19:43
nine no
lizmat ok, didn't expect it to, but wanted to be sure
so MoarVM frames rather than C frames
nine yes :)
It would be so useful to have more than just 1 benchmark, so we could see if the commit actually brings benefits as well 19:44
Which it totally should
lizmat agree... 19:46
MasterDuke committable6:  9b94bab9eb2803e19c46~1,9b94bab9eb2803e19c46 my $v = -1; sub bar() { $v }; sub foo() { my $i = 0; for ^1_000_000 { $i += $v.abs } }; foo(); $v = -1.5; foo(); say now - INIT now
committable6 MasterDuke, ¦9b94bab9eb2803e19c46~1: «Cannot find this revision (did you mean “cb1fbf6”?)» ¦9b94bab: «Cannot find this revision (did you mean “353334f”?)»
MasterDuke whoops, it doesn't know moarvm 19:47
committable6:  a9490436e649df95b34ff8b~1,a9490436e649df95b34ff8b my $v = -1; sub bar() { $v }; sub foo() { my $i = 0; for ^1_000_000 { $i += $v.abs } }; foo(); $v = -1.5; foo(); say now - INIT now
committable6 MasterDuke, ¦a9490436e649df95b34ff8b~1: «3.429306905␤» ¦a949043: «5.43289969␤»
MasterDuke that's an example i was using that had a ton of deopts before, almost none after 19:48
lizmat but the one without deopts is the slower one, right? 19:49
MasterDuke but somehow that perf difference seems greater than i remember. i feel i would have said something if i'd realized 19:49
yeah
lizmat is there a way to find out the amount of logging changed ? 19:50
I mean, if the decont logging added would 10x the amount of logs, that could be an explanation ?
MasterDuke or the different stats cause different optimized code to be genned 19:51
lizmat deconting is a *very* often ocurring operation 19:52
any method call will do one for self 19:53
MasterDuke that block is entered 22,180 times (when running time-t with a 10k csv file) with 9b94bab9eb2803e19c46 reverted 19:54
MasterDuke 261,126 times at HEAD 19:55
so yeah, ~10x more
nine I suggest reverting it for the release and investigate this thoroughly. Something just doesn't add up here 19:59
MasterDuke i wonder if i'd see the same perf difference with a moarvm/rakudo from when i was first experimenting with that 20:01
MasterDuke MVM_spesh_arg_guard_run and MVM_multi_cache_find_callsite_args are a bunch higher percent in a perf report at HEAD compared to with that commit reverted 20:07
i think i've seen MVM_multi_cache_find_callsite_args pop up a bunch recently, but iirc jnthn said not to spend much time on since it'll change/go away with new-disp 20:10
nwc10 chrisseaton.com/truffleruby/deoptimizing/ -- set_trace_func can be implemented using the same technique as we did for monkey patched methods. Effectively we always have a Proc installed but it does nothing by default and is inlined, which means it generates no machine code. When a new Proc is installed it’s as if we are defining the current Proc, so the implementation is very similar. 20:13
might already be "obvious", but I liked the trick of having an implicit empty method and inlining it (to become nothing but deoptimisation metadata) 20:14
MasterDuke i'm amazed by the performance of truffle stuff. even the very incomplete truffle branch of nqp is faster than regular jvm and moarvm backends at some things (and with a high enough iteration count) 20:17
lizmat incomplete implementations often are: look what adding correct decont logging just did :-) 20:19
MasterDuke true, but incomplete also can mean unoptimized
lizmat also true :-) 20:28
MasterDuke from the article nwc10 just posted: "deoptimization is relatively slow". the funny thing is hearing that (not just from there) is what prompted me on this remove-opts-if-too-many-deopts path, but so far i think i've made more things slower than faster... 20:33
lizmat it's a slippery path :-) 20:34
lizmat is too tired to code so calls it a day 20:38
jnthn MasterDuke: Block entered more because of less inlining? 20:44
MasterDuke In total, 1752809 call frames were entered and exited by the profiled code. Inlining eliminated the need to create 9522048 call frames (that's 84.45%). 20:45
In total, 3822149 call frames were entered and exited by the profiled code. Inlining eliminated the need to create 7452708 call frames (that's 66.1%).
looks like yes
jnthn Eek, yes, that'll hurt
Is this due to backing out things that deopt too much, or due to the extra decont logging? 20:46
Or "don't know yet"?
MasterDuke this is just the extra decont logging, not on the remove-opt branch
jnthn Hmmm. 20:47
MasterDuke the remove-opt branch wouldn't be any different in this case, because now with the extra logging there aren't many deopts in the first place
jnthn Curious. Any idea how many more log entries the change results in? 20:48
MasterDuke Of 11227425 specialized or JIT-compiled frames, there were 9903 deoptimizations (that's 0.09% of all optimized frames).
Of 11225720 specialized or JIT-compiled frames, there were 5 deoptimizations (that's 0% of all optimized frames).
jnthn Yeah, that's a quite low rate
MasterDuke 10k is with decont logging the way it was before, 5 is after extra decont logging 20:49
jnthn Could try tweaking the log sizes or number of outstanding log buffers a thread can have before it stops
jnthn I think those are in src/spesh/log.h, but it's been a while :) 20:49
MasterDuke cool, will play with that later (or probably tomorrow), off to watch falcon+winter soldier 20:50
jnthn Enjoy 20:50
MasterDuke jnthn: btw, don't think i exactly answered your question about how many log entries. assuming each call to MVM_spesh_log_decont creates one, then it's 22k (just from decont logging, no idea total) just logging actual deconts, 260k logging all cals 22:13
*calls