github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:27 lizmat left 01:09 MasterDuke left 01:41 Kaiepi joined 02:07 lizmat joined 06:29 frost-lab joined 06:39 patrickb joined
patrickb Good *ning! 06:52
07:10 Geth left 07:12 domidumont joined 07:58 ChanServ left, camelia left, samcv left, klapperl left, domidumont left, releasable6 left, tellable6 left, statisfiable6 left, notable6 left, bisectable6 left, evalable6 left, benchable6 left, nebuchadnezzar left, nwc10 left, mtj left, eater left, vrurg left, dogbert17 left, krunen left, nativecallable6 left, bloatable6 left, coverable6 left, shareable6 left, unicodable6 left, committable6 left, sourceable6 left, squashable6 left, quotable6 left, greppable6 left, rba left, leedo left, moon-child left, sxmx left, mst left, avar left, linkable6 left, chansen_ left, kawaii left, Altreus left, ugexe left, bonsaikitten left, jnthn left, tbrowder left, SmokeMachine left, cog_ left, nine left, patrickb left, frost-lab left, leont left, japhb left, jjatria left, Kaiepi left, tobs left, Voldenet left, BinGOs left, jraspass left, [Coke] left, harrow left, sivoais left, timotimo left, bartolin_ left, lizmat left, sena_kun left, rypervenche left, jpf1 left, moritz_ left 08:06 nine joined, cog_ joined, harrow joined, SmokeMachine joined, tbrowder joined, jnthn joined, bonsaikitten joined, ugexe joined, Altreus joined, chansen_ joined, linkable6 joined, avar joined, mst joined, sxmx joined, patrickb joined, leont joined, japhb joined, jjatria joined, nativecallable6 joined, bloatable6 joined, coverable6 joined, shareable6 joined, unicodable6 joined, committable6 joined, sourceable6 joined, squashable6 joined, quotable6 joined, greppable6 joined, rba joined, leedo joined, moon-child joined, bartolin_ joined, camelia joined, [Coke] joined, jraspass joined, BinGOs joined, Voldenet joined, tobs joined, Kaiepi joined, sena_kun joined, lizmat joined, mtj joined, moritz_ joined, jpf1 joined, rypervenche joined, krunen joined, dogbert17 joined, rajaniemi.freenode.net sets mode: +o mst, vrurg joined, eater joined, klapperl joined, samcv joined, nwc10 joined, nebuchadnezzar joined, benchable6 joined, evalable6 joined, bisectable6 joined, notable6 joined, statisfiable6 joined, tellable6 joined, releasable6 joined, domidumont joined, ChanServ joined, rajaniemi.freenode.net sets mode: +o ChanServ 08:07 frost-lab joined 08:09 kawaii joined 08:15 brrt joined 08:20 frost-lab left, frost-lab joined 08:22 zakharyas joined 08:32 sena_kun left 08:34 sena_kun joined 08:35 squashable6 left 08:36 squashable6 joined
dogbert17 nine++, nice bughunting yesterday 08:45
and hello brrt :) 08:46
08:49 sivoais joined, timotimo joined
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
08:54 sivoais left, sivoais joined
nwc10 good *, #moarvm 09:02
has anyone mentioned t/spec/S32-temporal/juliandate.t yet?
09:12 brrt left
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
09:48 zakharyas left 09:57 zakharyas joined 10:37 zakharyas left
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
11:24 brrt joined 11:49 frost-lab left 12:48 brrt left, brrt` joined 13:11 cog_ left 13:12 cog joined
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
14:09 zakharyas joined
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
14:45 patrickb left
[Coke] checks out v5 to see if how borked it is against a recent raku 14:51
(it uses Panda, so probably a bit.)
15:17 domidumont left 15:26 brrt` left
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
17:28 brrt` joined
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!)
18:09 brrt` left
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
18:13 patrickb joined
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
18:46 MasterDuke joined
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
19:11 linkable6 left 19:12 linkable6 joined
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 ?
19:14 linkable6 left
MasterDuke could be that too 19:14
19:14 linkable6 joined
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
19:30 linkable6 left, linkable6 joined
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
19:49 dogbert11 joined
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
19:53 dogbert17 left 19:54 brrt` joined
MasterDuke that block is entered 22,180 times (when running time-t with a 10k csv file) with 9b94bab9eb2803e19c46 reverted 19:54
19:55 linkable6 left
MasterDuke 261,126 times at HEAD 19:55
so yeah, ~10x more
19:55 linkable6 joined 19:57 brrt` left, dogbert11 left
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
20:01 dogbert11 joined
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
20:16 dogbert17 joined
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
20:19 dogbert11 left
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
20:48 linkable6 left
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
20:49 zakharyas left
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
20:50 linkable6 joined
jnthn Enjoy 20:50
21:50 patrickb left
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
23:29 dogbert17 left 23:31 dogbert17 joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!