Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-04

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:37 harrow joined #moarvm
05:32 domidumont joined #moarvm
05:37 domidumont joined #moarvm
05:58 TimToady joined #moarvm
06:02 domidumont joined #moarvm
06:04 domidumont joined #moarvm
06:31 lizmat joined #moarvm
07:06 domidumont joined #moarvm
07:24 zakharyas joined #moarvm
08:16 lizmat joined #moarvm
08:18 domidumont joined #moarvm
09:12 jnthn moarning o/
09:16 moritz moarnthn!
09:54 domidumont joined #moarvm
10:22 zakharyas joined #moarvm
10:46 brrt joined #moarvm
10:48 brrt \o
10:49 * brrt has a sneaking suspicion the new write barrier in bindlex may be the place where we get the segv
10:50 jnthn o/ brrt
10:51 brrt good * jnthn
10:51 brrt that said, the check_wb macro is clearly wrong
10:51 brrt but i don't know how to unwrong it without introducing labels
10:53 jnthn Wouldn't it always need labels?
10:53 jnthn *have always needed :)
10:53 brrt yes
10:55 brrt ok, thing is, i'd need to use local labels, and that is not possible without knowing which labels are used in context
10:55 brrt or, i'd need to allocate some more labels
10:55 brrt which i can in even-moar-jit, because the dynasm object is aliased to the compiler object, but not in the old jit
10:56 brrt (dynamic labels)
10:56 brrt which is why i did it without labels to start with
10:56 jnthn Hm
10:56 brrt which was wrong :-)
10:56 jnthn I guess as a stop-gap we can have bindlex as a function?
10:57 brrt rather not...
10:57 brrt too often used
10:57 brrt otoh, the write barrier already introduces a number of basic blocks
10:58 jnthn Well, it's only a stop-gap until even-moar-jit lands :)
10:59 brrt true
10:59 brrt i've read the paper on linear scan allocation on ssa form; it had some useful ideas, but i'm not sure all of it is directly applicable
11:06 brrt eh, did you perchance get arround to changing the signatures of bindlex named ops in graph.c?
11:09 jnthn I thought so?
11:09 jnthn lunch, bbi20
11:15 brrt see you
11:43 brrt joined #moarvm
11:43 flaviusb joined #moarvm
11:52 nine_ brrt: how's even-moar-jit doing anyway?
11:52 brrt ehm, well, good question
11:56 brrt of the three essential components that we needed, 2 are in good shape
11:56 brrt namely, the expression builder and the tiler
11:57 brrt the tiles themselves, that generate code, are very simple
11:57 brrt the third is the register allocator, and i've been whining about that for a while, and the truth of the matter is i haven't found the time to focus on that in the last months
11:58 brrt i have done some of the essential things to prepare for it, such as the tile linearisation
11:59 brrt the other components, namely the type specializer and the optimizer, are probably where we will find the greatest wins, but they are not essential, nor do i expect them to be very complex
11:59 brrt because they work on the expression tree
11:59 brrt so, the answer is, even-moar-jit is mergeable as soon as it gets a register allocator that knows how to deal with basic blocks correctly
12:00 brrt and that shouldn't be all that hard, really, now that i've prepared for it, it's just something that requires a lot of focus :-)
12:01 brrt as a matter of fact, you could merge it today, it would just not be a win
12:01 brrt and it'd need a large overhaul to be production-ready
12:02 brrt my intention is to have something that is open for hacking, i.e. where other people can come in and add bits and pieces and gain credit for the improvements
12:03 brrt nine_: hope that answers it :-)
12:51 jnthn OK, finally...some time for Moar/Perl 6 things :)
12:56 dalek MoarVM/reframe: 96b74d9 | jnthn++ | src/gc/roots.h:
12:56 dalek MoarVM/reframe: Fix confusing indentation.
12:56 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/96b74d997f
13:08 brrt joined #moarvm
13:09 nine_ brrt: Oh yes, many thanks :)
13:09 brrt :-)
13:10 nine_ brrt: if even-moar-jit is at least not worse than the current jit and the bindlex issue is more easily solvable in even-moar-jit, maybe an early merge would still be a good idea?
13:10 brrt hmm
13:11 brrt i guess that is not unreasonable....
13:11 brrt let me ponder about that for a bit :-)
13:12 nine_ happy to :)
13:12 brrt i've written a write-barrier macro for the expr jit already, so for expression-compiled things, that will eventually be much simpler
13:14 brrt oh, that is basically the other thing; just invoking check_wb won't do, because it'll need a hit_wb as well
13:16 timotimo what's the problem with just putting labels with very high numbers into the write barrier macro?
13:17 timotimo oh, those are per "frame"
13:17 timotimo only being allowed a single write barrier per frame is ... suboptimal :)
13:17 brrt if they are dynamic labels, then they need to be allocated, and that allocation may not compete with other allocators
13:18 timotimo mhm
13:18 brrt if they are local labels, then they need to be unique, so i'd need to assign some space within 0-9 for this purpose
13:18 brrt in fact, 9 is already taken
13:18 timotimo 0-9? that's surprisingly few
13:18 timotimo we need OID support for labels in dynasm
13:20 brrt yeah, those are the throwaway, local labels
13:20 brrt i should figure out how much i'm using anyway
13:21 timotimo we could split the write barrier into multiple parts and force the user of the macro to put the labels and label-using instructions in between :\
13:21 * jnthn finally gave in and rebooted after 2 months...
13:21 timotimo jnthn: hooray, now you have a much newer, shinier kernel :P
13:21 jnthn Everything is way faster too :P
13:21 * jnthn suspects epic fragmentation :)
13:21 timotimo have you put in an SSD yet?
13:22 jnthn Had one for ages
13:22 jnthn :)
13:22 jnthn Just wish it was bigger
13:22 timotimo allegedly, those make fragmentation a non-issue
13:22 jnthn RAM fragmentation :)
13:22 timotimo yeah, gigantic SSDs became crazy cheap just recently
13:22 timotimo oh!
13:23 jnthn So it swapped for no good reason on all sorts :S
13:23 timotimo maybe you should have just put in a process that swallows up all ram until the page file is full, then quits ... then programs might pull their chunks back in a sensible order and fill in the gaps :)
13:23 jnthn I think doing the equivalent of that accidentally may have caused much of the trouble in the first place :)
13:23 brrt har har har
13:24 timotimo i heard memory management isn't terribly good on windows
13:24 brrt because, timotimo, programmers have written their programs to take care of allocating stuff in a sensible order
13:24 timotimo but then again, we just had the epic "the linux kernel's default scheduler wastes cores in many cases" thing over in linux land
13:24 jnthn It's a hard problem. :)
13:24 brrt yeah, that was interesting
13:25 brrt what would be a good thing to do scraping with today
13:26 timotimo what, like scratching your back? there's telescopic thingies for that :P
13:26 * jnthn is currently testing two Rakudo patches on master/nom, then will try out reframe/reframe to see how the build time is before I do the call stack thingy
13:27 brrt :-P
13:27 brrt no, i mean like WWW::Mechanize
13:30 timotimo thankfully i haven't had to work with websites in that way in a loooooong time
13:31 brrt i want to copy data from tables on the electricity sector in saudi arabia
13:31 brrt interestingly, saudi arabia is a weird country
13:32 jnthn Isn't it just...
13:32 * jnthn wonders if curl has fetch-many-things capabilities
13:33 brrt well, what is weird about it, is that there is parts of it that are highly modern, and at the same time, it is very strictly religious
13:34 brrt i'm not sure curl does
13:34 timotimo wget does, in any case
13:34 brrt libcurl has asynchronous polling requests
13:34 jnthn brrt: Guess they have loads of oil money... :)
13:34 brrt they do... of course
13:34 brrt no water, though
13:47 * jnthn will have some numbers on how much reframe in its current state (all frames GC allocated, no JIT) costs us soon.
13:53 jnthn https://gist.github.com/jnthn/e733a3fb29c6fb884571f7af03bf9055
13:54 jnthn m: say 34.4/38.1
13:54 camelia rakudo-moar 475063: OUTPUT«0.902887␤»
13:54 jnthn m: say 109/130
13:54 camelia rakudo-moar 475063: OUTPUT«0.838462␤»
13:54 jnthn m: say 568/612
13:54 camelia rakudo-moar 475063: OUTPUT«0.928105␤»
13:58 jnthn So for stage 2 of reframe. :)
13:58 jnthn *time for
13:58 timotimo that's a surprisingly cheap impact
13:58 timotimo i would have expected something more like 2x
13:59 jnthn timotimo: Yeah, I thought it might be more.
13:59 jnthn Note that all those atomic ops are gone.
13:59 jnthn On frame ref counts.
13:59 jnthn So we save some there.
14:00 jnthn But of course, we're putting a ton more pressure on the GC
14:01 timotimo ah, yes
14:01 timotimo i've said in the past that i find the atomic ops too costly :)
14:01 timotimo why in the hell would it generate a full mfence anyway?!
14:02 timotimo that seems ridiculous
14:02 tbrowder joined #moarvm
14:09 zakharyas joined #moarvm
14:43 dalek joined #moarvm
14:50 brrt joined #moarvm
15:36 nine_ I don't need to MVMROOT a pointer that's still in a register, do I?
15:37 timotimo if it's a moar frame register, then no, those are marked for you
15:37 jnthn Well, you don't need to root the register itself
15:37 timotimo but if you have a local copy of the pointer value ...
15:37 jnthn But if you are keeping the pointer on the C stack, yes
15:38 jnthn My latest blog post talked about MVMROOT a little, fwiw :)
15:41 nine_ Ah, because it's not so much about keeping it from getting collected as it is about the pointer changing
15:42 jnthn Right :)
15:42 nine_ jnthn: you ok with me adding the part of your blog post to docs/gc.md?
15:44 jnthn Sure :)
15:49 nine_ Though I guess in my specific case, I don't need the MVMROOT, because all reading of said pointer happens before I call MVM_cu_from_bytes which would be the first function that may allocate.
15:52 jnthn ah, yes :)
15:56 timotimo is there anything to worry about when turning a decont_* on a *LexRef into a getlex? i seem to recall getlex is usually followed by a deopt point; is that just because we decorate every getlex with a log call in the logging phase?
15:57 jnthn timotimo: Assuming the *LexRef was known to be made in the current frame, yes? :)
15:57 timotimo "is there anything to worry about" - "yes" :P
15:58 jnthn You do have the uninlining-might-make-that-not-be-so issue :)
15:58 timotimo don't we exit the current candidate when we uninline anyway?
15:59 jnthn Yeah, but presumably you're wanting to eliminate taking the ref :)
15:59 timotimo ah, quite
15:59 timotimo well, that'll be communicated to us by an extra +1 usage
15:59 jnthn But I guess we already have the "use over a deopt point creates a usage bump"
15:59 jnthn So I think that'd handle it
15:59 timotimo that's right
16:00 timotimo it'll potentially cause a whole lot of things to not get eliminated until we actually have that "deopt bridge" mechanism i was talking about making ...
16:07 nine_ Oh, of course! MVMCompUnit won't GC mark the byte code as until now it came straight from an mmaped file and not some GC allocated buffer!
16:07 timotimo ah, yes, quite
16:11 jnthn om nom buffer
16:11 nine_ So I just malloc a buffer and copy the input?
16:11 nine_ MVM_malloc
16:11 jnthn Yeah
16:11 jnthn We can't really trust that the person who gave us the buffer won't go and change the bytecode under us.
16:12 timotimo on linux, we can ask the giver to use memfd and put seals on it :3
16:12 jnthn We'd have a SEGV/security hole if we assumed that.
16:12 jnthn .oO( if you liked it should put a seal on it )
16:12 timotimo if you don't like it any more, tough luck, 'cuz now there's a seal on it
16:13 timotimo wait a minute
16:13 timotimo aren't we already at the mercy of other code changing our bytecode under us?
16:14 timotimo or do we set some flag that makes our mmap of the file unique via COW or something?
16:14 dalek MoarVM/reframe: 0239e47 | jnthn++ | / (6 files):
16:14 dalek MoarVM/reframe: Sketch in call stack region data structure.
16:14 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/0239e477b8
16:18 ilmari if everyone maps the file with MAP_PRIVATE, their writes will be COWed, but «It  is  unspecified  whether  modifications to the underlying object done after the MAP_PRIVATE mapping is established are visible through the MAP_PRIVATE mapping.»
16:18 ilmari so it doesn't protect you against other people writing to the file (whether via write(2) or mmap(..., MAP_SHARED))
16:22 jnthn Hm, curious :)
16:23 * jnthn will continue with the frames stuff tomorrow
16:24 jnthn Can't concentrate any more today :(
16:25 moritz tomorrow is holiday here \o/
16:26 nine_ And bingo! The strange failures are gone :)
16:26 jnthn Not here
16:26 jnthn It is up in .se though
16:30 jnthn bbl
16:30 zakharyas joined #moarvm
17:26 domidumont joined #moarvm
18:21 dalek joined #moarvm
20:36 colomon joined #moarvm
20:54 colomon joined #moarvm
20:58 colomon joined #moarvm
22:36 colomon joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary