00:51 pyrimidine joined 02:35 ggoebel joined 02:38 pyrimidine joined 02:46 agentzh joined 02:48 ilbot3 joined 03:25 lizmat joined 03:37 pyrimidine joined 04:07 pyrimidine joined 04:10 deepbook5broo joined, deepbook5broo left 04:39 MasterDuke joined 06:09 pyrimidine joined 06:38 pyrimidine joined 06:39 brrt joined
brrt timotimo: no, i need the upper 32 bits and the lower 32 bits in two different words 06:40
samcv timotimo, the new datastructure is way easier to debug than the if else change so i'm getting rid of the if else chain and waiting until i get perfect cp to bitfield rows for all cp 06:45
today got it working all the way up to where we start to have gaps (reserved characters) 06:46
never tried to split a 32bit across a word
oh you just need to split them from that value. i guess gcc determines it at compile time 06:47
07:15 pyrimidine joined 07:45 brrt joined
Geth MoarVM/even-moar-jit: d2d4ee0117 | (Bart Wiegmans)++ | 9 files
Implement ARGLIST-to-storage ref conversion step

The register allocator can work with the storage refs to determinehow to move values through the registers in order to compile function call arguments.		 08:25
brrt design question time, again
problem: I need a way to make the register allocator 'see' the special tiles and/or special tile register requirements 08:29
they can be 'skipped over' because the register allocator works from live range to live range and these only start at tiles that define a new value; tiles that use values (like ARGLIST) are never even seen 08:30
so there's two ways i can see to deal with that 08:31
a): detect those tiles during live range construction, and maintain a queue of them, and switch-iterate over that queue and the worklist 08:32
b): maintain an index 'last tile idx', that is updated for every live range to their start; and prior to allocating for a live range, iterate over the range between (last_idx and start_of_live_range], and handle special cases in this loop 08:34
they are equivalent, fwiw
one requires maintaining a queue and splits 'detection' and 'handling', the other does it in a single loop
moritz is a tile a struct?
brrt yeah, a tile is an object-representation of an instruction 08:35
moritz so could you give it a boolean (or a bit flag) marking it as special
so that the register allocator doesn't have to do extra logic
brrt well, yeah, it's easy enough to detect
there's actually two cases in which something can be special so far 08:36
moritz as you might gather from my questions, I have no idea what I'm talking about, just bouncing around ideas in the hopes that it helps you make a good decision :-)
brrt ':-) it's appreciated 08:37
one case: by pure semantics of the node it represents (e.g. argument lists, subroutine calls)
second case: by special register requirements of the instruction it represents (e.g. div, mul in x86) 08:38
either is a very cheap check
08:39 zakharyas joined
moritz sounds like a simple macro could do then? 08:39
brrt yeah. the question is reallly: which of the two loops should do the check 08:40
moritz which loop is hotter?
brrt one loop analyzes all code to construct a live range, other loop analyzes all live ranges (i.e. a smaller set) to allocate registers
makes no difference, both are O(N) to the size of the code 08:41
well, it makes some difference
the second loop is now O(number_of_live_ranges) and the first O(number_of_tiles) 08:43
number_of_tiles is strictly larger than number_of_live_ranges 08:44
moritz then it sounds like special detection should go into the loop over the live ranges
brrt but they are in the same order, really
moritz purely from a performance perspective
brrt well, i haven't explained the crucial bit 08:45
making the special detection changes the second loop also to O(number_of_tiles), because, well, it now has to loop over all tiles
moritz then don't do that :-) 08:46
brrt maintaining a queue isn't free, either 08:47
sorry, i can argue this any which way, and I'm not yet decided :-)
moritz I notice :-) 08:49
re queue isn't free, hence my question earlier if you could store the information in the tile itself
brrt well, it is already stored in the tile, so to speak
and pretty cheap to detect 08:50
moritz but not cheap enough to do it where you need the information?
brrt well, yes
okay, i guess the question i have to ask myself 08:51
if i put it in a queue, am i going to do something with that data structure or just iterate on it
is there additional cleverness that can be enabled by the queue, or do i just like queues and that's why i want one? 08:54
09:16 pyrimidine joined 09:32 geekosaur joined 10:33 geekosaur joined
jnthn A queue you just iterate over is called an array, no? ;) 10:47
moritz a qarray :-) 10:48
jnthn On modern hardware, computation is cheap compared to memory access, though 10:50
Which speaks somewhere against the queue
Unless the computation needs memory accesses itself on stuff you'd otherwise not be looking at
11:03 pyrimidine joined
timotimo i've seen an interesting article about a better scheme to locate a tree's nodes inside a flat array, that maximizes cache-locality; i'm sure that can be used for a priority queue 11:12
11:13 geekosaur joined
timotimo i think it was actually for an a,b-tree 11:13
there's a paper by erik demaine called "cache-oblivious b-trees": erikdemaine.org/papers/FOCS2000b/paper.pdf 11:14
oh, hold on
won't a priority queue based on a binary tree often pull things from way down below? 11:15
hm, i don't remember what the access pattern looked like
11:22 Ven joined
timotimo actually, thinking of it i seem to recall it just switches one from the bottom with one along the way each time you pull out one element 11:22
11:50 Ven joined
brrt jnthn: great, make it harder 11:53
dogbert17 hmm, we're beginning to run out of MoarVM panics and SEGV's, shocking :)
brrt well, it acts as a queue, don't it
:-P
so yeah
i would otherwise not be looking at the tiles inbetween that *aren't* special
jnthn dogbert17: Hm, I thought that RT had around 30 tickets tagged as SEGV, should perhaps check those? :) 11:57
(And if they no longer SEGV, we can mark them testneeded and remote the label) 11:58
*remove
12:07 geekosaur joined
dogbert17 jnthn: github.com/MoarVM/MoarVM/issues/538 is mildly interesting, there are several RT's describing similar problems 12:15
timotimo dogbert17: could you wrap big chunks of output in ``` ... ``` in github issues and such? 12:16
actually, apparently i'm allowed to edit your comment. but i won't, that'd be a bit rude
12:16 pyrimidine joined
dogbert17 timotimo: should I have used a gist instead? 12:16
timotimo no 12:17
it's okay to put it into the issue
unless it's three pages big
dogbert17 or is ``` ... ``` some sort of command of some sort
moritz it's markup
for code blocks
timotimo yeah, it's from github-flavoured markdown
moritz you can also indent them four spaces instead
dogbert17 hmm, let me try 12:18
ilmari git glog
EWIN
dogbert17 better? 12:19
timotimo lovely 12:24
i bet github put a "this issue was mentioned in issue 538" into issues 1 through 15 :D
dogbert17 thx, you learn something new every day :) 12:26
timotimo you can also turn on syntax highlighting in these blocks by putting the name of the language directly after the opening ``` 12:27
dogbert17 aha 12:30
here's a SEGV example from RT which I believe has been fixed, rt.perl.org/Public/Bug/Display.html?id=128705 (doesn't crash for me) 12:32
brrt jnthn, i have a MSVC related question 12:52
can MSVC compile assembly files, and if so, what syntax does it use 12:53
i'm betting it can't.... 12:54
jnthn Heh, the inline assembly only supports x86 12:55
timotimo m( m( m( m(
jnthn It does ship with an assembler though 12:57
ml64
msdn.microsoft.com/en-us/library/hb5z4sxd.aspx 12:58
brrt that's something 13:07
i'm planning to make a stack walker 13:08
so for that, i need a bit of assembly code
(the purpose is to figure out the current position of the program in case we're throwing an exception) 13:09
jnthn Aha :)
So we don't need to stash labels all over the code? :)
13:17 pyrimidine joined
brrt indeed 13:30
that should save a bit of runtime costs
jnthn Nice :) 13:31
brrt well, the cost is that you'll have to have -fno-omit-frame-pointer, which *costs* you a bit on runtime 13:41
how much exactly, i don't know
13:59 brrt joined
jnthn Could do a build each way and callgrind some things :) 14:04
IOninja Does MoarVM have some sort of catch phrase? Tag line? Moto? 14:06
jnthn We didn't even get to having a logo, let alone that ;-) 14:07
IOninja heh 14:08
jnthn Though I guess I've quipped a few times that a VM is doing its job right when language users don't know/think about it :-)
I mean, the typical Perl 6 user only really cares about MoarVM when it panics or SEGVs. ;-) 14:09
Or runs stuff too slowly ;-)
IOninja heh
IOninja tries to imagine what that would look like as a tagline... 14:10
timotimo "serving from the shadows" 14:17
IOninja That sounds like something the Protos would say.... 14:24
timotimo yup 14:25
like, the stalker for example
"i serve ... for now"
did you ever try to do something with the MVM crab concept?
IOninja Nope. But I'm working from home today and have the work laptop hooked up to big monitor so I can use the design software properly after work. Hence why I was asking about tag lines 14:28
Not gonna do the crab tho. Crabs are slow 14:29
timotimo *neat*
okay.jpg
BBL
(definitely not going to the corner to cry) 14:30
jnthn Ain't some crabs actually pretty speedy? :) 14:34
IOninja I see several mentions of 0.15m/s on Google. Not even 1km/h 14:36
jnthn Lame :) 14:38
nwc10 jnthn: valgrind (for 3 weeks or so) has not found problems in spectest6 15:05
ASAN barfs: paste.scsys.co.uk/553224
this seems to be a new variant backtrace
jnthn It looks like somehow, occasionally, the GC double-frees things :S 15:07
And only in a full collection
Well, either that or an old reference survives 15:08
timotimo there was a paste with a double free not too long ago; was that nwc or was it dogbert? 15:09
dogbert17 jnthn, timotimo: I might finally have something: gist.github.com/dogbert17/6cb41a1d...8ee886bfe4
dogbert17 or it might be useless junk
heh, the one I posted looks similar 15:11
jnthn Loks like the one nwc10 posted too 15:12
dogbert17 yeah, tried to debug lizmat's SEGV's that she's been complaining about 15:13
dogbert17 notes that full collections might be more common now, at least on 32 bit 15:14
it can't be my fault can it? github.com/MoarVM/MoarVM/commit/18...c0a477a67c 15:16
timotimo no, don't think so 15:17
i mean
even if your change caused full collections to finally happen during harness6, that just means we never gen2 collected during harness6 and it just ballooned bigger and bigger
dogbert17 that was indeed the problem I was suffering from before 15:18
timotimo oh, right
15:18 pyrimidine joined
timotimo i hadn't realized it was during harness6 15:19
oh, but
on 64bit systems it used to be just fine
dogbert17 so now we have both ASAN and gdb data, what else can we do expect contemplating the output over a cup of coffee or beer
s/expect/except/ 15:20
timotimo i haven't looked closely enough; we know what kind of object has been double-cleared, right? 15:21
how many threads does that actually start, btw? 15:33
just the event loop thread, i expect?
dogbert17 there are 17 lines in the gdb output like [New LWP xxxxx] 15:34
I ran harness6 with TEST_JOBS=5 15:35
15:38 brrt joined
timotimo i wonder if that's how it fork+execs the async processes? 15:39
dogbert17 tried a run with TEST_JOBS=4, worked like a charm. I usually run it with TEST_JOBS=2 which seems to work well 15:53
my $parser = TAP::Runner::Async.new(:$source, :@handlers, :$killed); 15:58
@working.push({ :$parser, :$session, :done($parser.waiter) });
next if @working < $!jobs;
await Promise.anyof(@working»<done>, $killed);
reap-finished(); 15:59
16:20 pyrimidine joined
timotimo so it only asplodes when the degree of concurrency increases? 16:25
dogbert17 i think so but that's speculation on my part 16:29
and it doesn't crash every run so its tricky to reproduce
got it again same gdb backtrace but MVM_dump_backtrace is totally different 16:55
219 method TOP($/) { # first entry in MVM_dump_backtrace (TAP.pm #219) 17:00
220 make @<line>».made;
221 }
gist updated, gist.github.com/dogbert17/6cb41a1d...8ee886bfe4 17:06
18:11 zakharyas joined 18:34 brrt joined 18:50 agentzh joined 21:16 agentzh joined 21:18 zakharyas joined 21:33 agentzh joined 21:37 pyrimidi_ joined 21:39 lizmat 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!