01:48 ilbot3 joined 03:37 harrow joined 05:32 domidumont joined 05:37 domidumont joined 05:58 TimToady joined 06:02 domidumont joined 06:04 domidumont joined 06:31 lizmat joined 07:06 domidumont joined 07:24 zakharyas joined 08:16 lizmat joined 08:18 domidumont joined
jnthn moarning o/ 09:12
moritz moarnthn! 09:16
09:54 domidumont joined 10:22 zakharyas joined 10:46 brrt joined
brrt \o 10:48
brrt has a sneaking suspicion the new write barrier in bindlex may be the place where we get the segv 10:49
jnthn o/ brrt 10:50
brrt good * jnthn 10:51
that said, the check_wb macro is clearly wrong
but i don't know how to unwrong it without introducing labels
jnthn Wouldn't it always need labels? 10:53
*have always needed :)
brrt yes
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
or, i'd need to allocate some more labels
which i can in even-moar-jit, because the dynasm object is aliased to the compiler object, but not in the old jit
(dynamic labels) 10:56
which is why i did it without labels to start with
jnthn Hm
brrt which was wrong :-)
jnthn I guess as a stop-gap we can have bindlex as a function?
brrt rather not... 10:57
too often used
otoh, the write barrier already introduces a number of basic blocks
jnthn Well, it's only a stop-gap until even-moar-jit lands :) 10:58
brrt true 10:59
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
eh, did you perchance get arround to changing the signatures of bindlex named ops in graph.c? 11:06
jnthn I thought so? 11:09
lunch, bbi20
brrt see you 11:15
11:43 brrt joined, flaviusb joined
nine_ brrt: how's even-moar-jit doing anyway? 11:52
brrt ehm, well, good question
of the three essential components that we needed, 2 are in good shape 11:56
namely, the expression builder and the tiler
the tiles themselves, that generate code, are very simple 11:57
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
i have done some of the essential things to prepare for it, such as the tile linearisation 11:58
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
because they work on the expression tree
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
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:00
as a matter of fact, you could merge it today, it would just not be a win 12:01
and it'd need a large overhaul to be production-ready
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:02
nine_: hope that answers it :-) 12:03
jnthn OK, finally...some time for Moar/Perl 6 things :) 12:51
dalek arVM/reframe: 96b74d9 | jnthn++ | src/gc/roots.h:
Fix confusing indentation.
 12:56
13:08 brrt joined
nine_ brrt: Oh yes, many thanks :) 13:09
brrt :-)
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
i guess that is not unreasonable.... 13:11
let me ponder about that for a bit :-)
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
oh, that is basically the other thing; just invoking check_wb won't do, because it'll need a hit_wb as well 13:14
timotimo what's the problem with just putting labels with very high numbers into the write barrier macro? 13:16
oh, those are per "frame" 13:17
only being allowed a single write barrier per frame is ... suboptimal :)
brrt if they are dynamic labels, then they need to be allocated, and that allocation may not compete with other allocators
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
in fact, 9 is already taken
timotimo 0-9? that's surprisingly few
we need OID support for labels in dynasm
brrt yeah, those are the throwaway, local labels 13:20
i should figure out how much i'm using anyway
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...
timotimo jnthn: hooray, now you have a much newer, shinier kernel :P
jnthn Everything is way faster too :P
jnthn suspects epic fragmentation :)
timotimo have you put in an SSD yet?
jnthn Had one for ages 13:22
:)
Just wish it was bigger
timotimo allegedly, those make fragmentation a non-issue
jnthn RAM fragmentation :)
timotimo yeah, gigantic SSDs became crazy cheap just recently
oh!
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 :)
jnthn I think doing the equivalent of that accidentally may have caused much of the trouble in the first place :)
brrt har har har
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
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
jnthn It's a hard problem. :)
brrt yeah, that was interesting
what would be a good thing to do scraping with today 13:25
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
brrt :-P 13:27
no, i mean like WWW::Mechanize
timotimo thankfully i haven't had to work with websites in that way in a loooooong time 13:30
brrt i want to copy data from tables on the electricity sector in saudi arabia 13:31
interestingly, saudi arabia is a weird country
jnthn Isn't it just... 13:32
jnthn wonders if curl has fetch-many-things capabilities
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:33
i'm not sure curl does 13:34
timotimo wget does, in any case
brrt libcurl has asynchronous polling requests
jnthn brrt: Guess they have loads of oil money... :)
brrt they do... of course
no water, though
jnthn will have some numbers on how much reframe in its current state (all frames GC allocated, no JIT) costs us soon. 13:47
gist.github.com/jnthn/e733a3fb29c6...af03bf9055 13:53
m: say 34.4/38.1 13:54
camelia rakudo-moar 475063: OUTPUT«0.902887␤»
jnthn m: say 109/130
camelia rakudo-moar 475063: OUTPUT«0.838462␤»
jnthn m: say 568/612
camelia rakudo-moar 475063: OUTPUT«0.928105␤»
jnthn So for stage 2 of reframe. :) 13:58
*time for
timotimo that's a surprisingly cheap impact
i would have expected something more like 2x
jnthn timotimo: Yeah, I thought it might be more. 13:59
Note that all those atomic ops are gone.
On frame ref counts.
So we save some there.
But of course, we're putting a ton more pressure on the GC 14:00
timotimo ah, yes 14:01
i've said in the past that i find the atomic ops too costly :)
why in the hell would it generate a full mfence anyway?!
that seems ridiculous 14:02
14:02 tbrowder joined 14:09 zakharyas joined 14:43 dalek joined 14:50 brrt joined
nine_ I don't need to MVMROOT a pointer that's still in a register, do I? 15:36
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
timotimo but if you have a local copy of the pointer value ...
jnthn But if you are keeping the pointer on the C stack, yes
My latest blog post talked about MVMROOT a little, fwiw :) 15:38
nine_ Ah, because it's not so much about keeping it from getting collected as it is about the pointer changing 15:41
jnthn Right :) 15:42
nine_ jnthn: you ok with me adding the part of your blog post to docs/gc.md?
jnthn Sure :) 15:44
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:49
jnthn ah, yes :) 15:52
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:56
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
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?
jnthn Yeah, but presumably you're wanting to eliminate taking the ref :) 15:59
timotimo ah, quite
well, that'll be communicated to us by an extra +1 usage
jnthn But I guess we already have the "use over a deopt point creates a usage bump"
So I think that'd handle it
timotimo that's right
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:00
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
jnthn om nom buffer 16:11
nine_ So I just malloc a buffer and copy the input?
MVM_malloc
jnthn Yeah
We can't really trust that the person who gave us the buffer won't go and change the bytecode under us.
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.
.oO( if you liked it should put a seal on it )
timotimo if you don't like it any more, tough luck, 'cuz now there's a seal on it
wait a minute 16:13
aren't we already at the mercy of other code changing our bytecode under us?
or do we set some flag that makes our mmap of the file unique via COW or something? 16:14
dalek arVM/reframe: 0239e47 | jnthn++ | / (6 files):
Sketch in call stack region data structure.
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
so it doesn't protect you against other people writing to the file (whether via write(2) or mmap(..., MAP_SHARED))
jnthn Hm, curious :) 16:22
jnthn will continue with the frames stuff tomorrow 16:23
Can't concentrate any more today :( 16:24
moritz tomorrow is holiday here \o/ 16:25
nine_ And bingo! The strange failures are gone :) 16:26
jnthn Not here
It is up in .se though
bbl 16:30
16:30 zakharyas joined 17:26 domidumont joined 18:21 dalek joined 20:36 colomon joined 20:54 colomon joined 20:58 colomon joined 22:36 colomon 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!