02:09 vendethiel joined
dalek arVM: 4df2030 | hoelzro++ | src/io/procops.c:
Track process state when spawning children

This is prepare for a fix around closing standard input and race conditions 9befd69 | hoelzro++ | src/ (4 files): Revert "Track whether or not a capture owns its callsite"
This reverts commit 02d5241997ae7b5a2dc1ce1f1a8bd1fa3884258b.		 02:17
02:17 dalek joined 02:21 tokuhiro_ joined 06:25 Ven joined 06:55 FROGGS joined 07:54 FROGGS joined 07:59 brrt joined 08:26 Ven joined 08:39 Ven joined
Ven 's learning about all those weird registers things, on his way to enlightenment 'bout computers and VM... 09:25
I certainly understand more thing of that big JIT file now... But damn you, gnu asm...
timotimo++ for motivating me to do so :P 09:26
brrt Ven++ for trying to learn :-) 09:30
can i help you?
with anything?
for example, with the options to convert to intel asm format? :-)
Ven I've been given this great chart: upload.wikimedia.org/wikipedia/com...rs_svg.svg which has helped me a lot already :D 09:31
brrt oh, yes, that seems useful
Ven I got my code to do what I wanted it to do (store char in the stack, increment char unless char='z', then set it to 'a'; print it using a syscall). I'm trying to rewrite it to be a function call now
brrt that will be fun 09:32
Ven seems the output (with cat -e) is "M-I^B^B", I think I'm not really there now XD
brrt :-)
nwc10 hoelzro: unfortunately 02d5241997ae7b5a2dc1ce1f1a8bd1fa3884258b creates a use-after-free bug: paste.scsys.co.uk/499584 09:35
from that stack trace, I hope that the solution is simple. It looks like the use is just after the free, and so could be fixed by some re-ordering or somesuch 09:36
Ven wonders why gcc -O2 -S sometimes generates -4(%rbp), sometimes -1(%rbp) in the program, for what seemed to be equivalent 09:48
moritz moon phase
Ven aah, I got it. I forgot to fill %eax before using %al.. 09:50
brrt wonders why Ven is using lower registers at all 09:51
Ven it's just a char, so a byte
at least that's what I got..
ooh, I used cmp, not cmpb. fixed now! 10:10
10:49 Peter_R joined 10:53 zakharyas joined, mtj_ joined 10:58 mtj_ joined 11:21 Ven joined
brrt Ven: i can totally recommend intel syntax 11:22
in intel syntax, it's not movb
or cmpb
masak .oO( I can call you Betty, and baby, you can call me %al )
Ven yeah, that works :)
brrt but cmp byte foo, byte bar
actually, typcally
cmp byte [rbp-1], al;
lol masak
an anyway, i find it kind of handy when things like operand size are explicit rather than encoded into the operand in a single character 11:23
Ven well, it's supposed to be an exercise for the students: if they're done with the C version, they have to rewrite it. and the school decided to tell people to use gnu asm. so, I'm writing a correction in case any of them submits a solution
(they seem to prefer slacking to that. honestly, I can somewhat get it..)
brrt ....
well, yeah
anyway, i know this is officially a matter of taste 11:24
but i find intel asm to be *much* more legible and explicit about things
actually, just as explicit, but the explicit things are more visible, i guess
Ven yeah, from looking around the internet (trying to answer my questions), everybody recommended intel synta 11:31
+x. but oh well. I guess it's still very valuable an experience 11:32
brrt yes, i agree 11:34
and fun, if you get the hang of it
well, thats my opinion at least
Ven oh, I need to take a break every few hours because my head hurts a lot, but it's amazing at the same time :-) 11:45
11:50 co-gnome joined 12:04 co-gnome joined 12:27 co-gnome joined 12:31 mtj_ joined 12:55 Ven joined
cognominal_ watches the register chart. Things have evolved since the 6502 and Z80... 13:15
13:15 FROGGS joined
brrt yeah, although 'regular' code just uses xmm* and the gpr 13:16
13:43 synbot6 joined
hoelzro nwc10++ # running address sanitizers on spec tests 13:50
I'll revert that commit for now, and stuff it into a branch 13:51
timotimo or shall i just try to fix it? 13:52
13:53 tokuhiro_ joined
timotimo hoelzro: i wonder if it would have been easier to set up the tracking of malloc info via nativecall 13:53
hoelzro timotimo: possibly, but I didn't want any possible leaks with nativecall to interfere with my measurements 13:54
although I could've tested for that first =)
timotimo right
i'd be interested in such leaks with nativecall 13:55
dalek arVM/callsite-memory-leak: f7a176b | hoelzro++ | src/ (4 files):
Restore "Track whether or not a capture owns its callsite"

This reverts commit 9befd69353643bff3a529aa5bea8101cd574fa29.		 13:56
nwc10 hoelzro: couldn't you simply have branched that from the parent of the revert commit? 13:57
hoelzro I suppose so 13:59
then I could've just dealt with the restoration during the merge
timotimo huh, just some simple re-ordering? 14:01
i don't actually see how it's read just after being freed ā€¦
hoelzro I think it's another situation like copy_to
I haven't looked into this new situation, though
when I have time, I might just add a reference count to callsites 14:02
timotimo OK :)
... reference count :\
especially since that has some ramifications with multi-threading stuff 14:09
hoelzro eesh, good point 14:27
well, I'll have time to think about it =)
commute &
timotimo have a good one! 14:31
14:54 tokuhiro_ joined
hoelzro fg 15:04
15:30 Ven joined 15:55 Ven joined
timotimo jnthn: i didn't actually look yet, but i'm pretty sure the code i was talking about used failure to signal the fallback "outwards" 16:16
jnthn hmm 16:17
But they should get GC'd really
timotimo where should i look to find out if backtraces are being kept around and such?
jnthn So I'm curious how that can happen
Well, see how many MVMExceptions are alive maybe
timotimo i wonder if the existence of the DESTROY method tickles a bug somewhere?
jnthn Oh, 'cus it goes on the finalization queue? Maybe but I can't see quite how offhand. 16:18
timotimo right
hmm. see how many MVMExceptions are alive ... how exactly? :P 16:21
with the heap analyzer?
jnthn Doesn't the profiler track them? 16:23
And retention/promotion rates? :)
Maybe we don't label exception creation well enough?
timotimo i built something to that effect at some point, but it remained buggy
jnthn s/label/instrument/ 16:24
timotimo mhm
huh 16:25
it seems like we don't instrument those at all yet
jnthn wow :)
timotimo anything beyond newexception that needs that? 16:26
also, we don't specialize newexception into fastcreate?
ah, because it wants the stacktrace
bleh. i should have put this code into a git repository before doing so many different things with it 16:27
also, i should have it on my desktop, too %)
16:31 Ven joined
timotimo i don't actually see a "newexception" show up in the speshlog and a perl6 -e 'my @a; for ^1000 { @a[$_] // Inf }' doesn't show any exceptions allocated 16:38
jnthn hm, curious 16:39
dinner time &
16:52 ilbot3 joined 16:53 moritz joined 16:54 psch joined 16:55 tokuhiro_ joined
timotimo perhaps i shouldn't just have put more and more and more 0s at the end of that number? 17:01
17:07 Util joined
timotimo once in throw and once in THROW for each, it seems like 17:13
perhaps the nqp::isconcrete($!ex) is never 1? 17:14
@a[$_] actually just returns (Any), obviously 18:05
i would have to go for -1
the speed difference between accessing @a[-$_] and accessing @a[$_] is tremendous 18:06
at least this little "benchmark" shows the "gc times increase more and more" problem nicely 18:09
18:09 vendethiel joined
timotimo but the gen2 roots just fluctuate rather than growing steadily 18:10
on the other hand, about 800 KB end up promoted, which i don't really understand
wait what 18:20
we're allocating 19999 instances of Perl6::Metamodel::ModuleHow ?!
jnthn o.O
wtf!
HOW is that happening?!
timotimo am i seeing this right ?! 18:21
jnthn If so, then it's an interesting find... :)
bbiab
timotimo or is it just something returning an instance of ModuleHOW that gets interpreted as allocated?
nope, that's totally the method new from the ModuleHOW that's allocating these 18:24
lizmat timotimo: is ther much difference between @a.AT-POS($_) and @a.AT-POS(-$_) ? 18:38
18:38 FROGGS[tab] joined
FROGGS[tab] o/ 18:38
timotimo lizmat: i'm just investigating in another direction right now 18:40
which is: 18:42
why do we create two new ModuleHOW whenever we fail something
oh wow
fail() is more expensive than fail("test") in that way
perhaps it's the default value for the payload argument?
18:57 tokuhiro_ joined 18:58 cognominal joined
dalek arVM: c8173b7 | TimToady++ | src/6model/reprs/NFA.c:
log nfa offsets into string

this allows us to calculate how many times a position was lexed		 19:05
arVM: c393c4e | TimToady++ | src/ (2 files):
add rudimentary timing to dynvar logs
MoarVM: 3ffc453 | TimToady++ | src/ (3 files):
MoarVM: do better at not counting logging time
MoarVM:
MoarVM: (the old code assumed that it takes no time to log dynvar lookups)
jnthn Looks like somebody's gearing up for some perf work :) 19:32
timotimo i had dreamt about building a regex performance analysis thing that'd point out how hot each of the source characters is 19:46
okay, so why would self.bless(:$exception) cause ModuleHOW.new to be invoked twice? 19:47
jnthn Why do I immediately start thinking how to construct regexes that make certain letters hot to spell naughty things out of innocent words? :)
hoelzro cdn.meme.am/instances2/500x/2168198.jpg
jnthn timotimo: I...no idea...what is the BUILD doing?
:P 19:48
timotimo jnthn: i'm having a hard time finding that out ā€¦ 19:50
it kind of looks like a "die" is being called somewhere in there
"for good measure" ?!?
oh
Backtrace gets created via try { die() } 19:51
that at least explains why we get an X::AdHoc created for every exception we create
jnthn Every exception, or every Failure? 19:53
lizmat every Backtrace.new
timotimo what liz said
Failure's BUILD creates the new Backtrace object 19:54
lizmat I have no idea why it works that way
timotimo however
if $!exception is set, it uses its backtrace instead
lizmat that line is from 2011
comment on commit de3997a73635a627c007b: make Backtrace.new() DWIM 19:55
timotimo this still doesn't tell me how the flying fuck we end up creating new ModuleHOW instances :)
jnthn timotimo: Chase the callgraph until you find that node? :) 19:56
lizmat well, not having a die in there, would help speed up all warnings, I would think
timotimo tried to, failed 19:57
peppering the code with note("blah") at the moment 20:02
could perhaps have to do with Backtrace::Frame?
maybe we would have wanted to put that inside the Backtrace class instead?
soon it'll be food time and my search will be interrupted 20:04
jnthn timotimo: Maybe easiest is just to make ModuleHOW.new dump a backtrace every time it's called (you'll need to do it at NQP level) 20:05
timotimo i wanted to do that 20:07
i asked what the best way was, and i didn't get an answer :) 20:08
i've found the offending line
it's try { die() }
i'll have a look at how die() is implemented
jnthn Oh 20:09
try { nqp::die(''); CATCH { nqp::say(join("\n", nqp::backtracestrings($_))) } } 20:12
timotimo: ^^
timotimo thanks
that'll help a lot :) 20:13
i'm about to have noms 20:18
jnthn enjoy :) 20:19
timotimo gist.github.com/timo/a8ff4eb12e11f1d10db5
i think it's about the default value for die($payload = ...)
because it uses CALLER::CALLER::...
jnthn Oh...
timotimo the very same code is used in Failure and Exception a bunch of times 20:20
jnthn We should probably teach the static optimizer to simplify CALLER::CALLER::symbol
(Into the nqp ops) 20:21
timotimo something involving nqp::callerctx(nqp::callerctx(nqp::curctx))?
okay, AFK for noms now
jnthn right 20:22
20:24 vendethiel joined 20:30 Ven joined 20:34 colomon joined 20:45 tokuhiro_ joined, leont joined
lizmat jnthn: perhaps putting in those nqp ops now would already help ? 21:00
timotimo that'd be nice, especially since this is perhaps the only place we really stumble over this
jnthn lizmat: Could do, otoh relying on an optimization in CORE.setting is a great way to make sure it keeps working :P 21:07
tadzik oh, exploitable :) 21:08
lizmat jnthn: I just wanted to speed up things now... if we can wait for the static optimizer to pick up on this, that's fine by me too :-) 21:09
leont jnthn: what is the current state of the async io? (specially processes, but the rest too)?
How feasible would it be for someone who isn't particularly familiar with moar to help out on it?
jnthn lizmat: I think the static optimizer patch will be relatively easy 21:10
leont: Depends what you are familiar with, I guess. If working with the libuv API is already something comfortable, that helps. 21:11
leont I've looked over it before, it looked straightforward enough
jnthn leont: The processes bit I know a copule of people have been polishing of late, to deal with various corner caess. 21:12
timotimo lizmat: i'd personally appreciate if you put that in
jnthn leont: So far as I can tell it's in decent shape.
leont Should recompile I guess, last time I tried I hit issues 21:13
timotimo lizmat: in the mean time, i'll check @a[-$_] vs @a[$_] against @a.AT-POS(-$_) vs @a.AT-POS($_)
jnthn Also, I've been continuing to hunt down and fix pesky concurrency bugs.
(Such wonders as type finalization timing issues in concurrent GC sweeps...) 21:14
timotimo jnthn: did you see hoelzro's problem about callsites we're leaking? 21:15
jnthn timotimo: Yeah, but I simply don't have the brane for it this week with teaching, travel, etc. 21:16
timotimo totally acceptable 21:17
hoelzro timotimo: I dug in a bit earlier; I think that callsites are shared more than my patch accounts for 21:19
timotimo mhh 21:22
hoelzro my patch only deals with CallCapture objects that refer to the same callsite 21:23
I'm pretty sure frames do a lot moar
timotimo mhh, i see 21:24
lizmat: the difference between [] and AT-POS is negligible
lizmat ok, that's good to know...
timotimo right 21:25
the difference is most probably just the crazy overhead from the whole failure thing
lizmat if there was a significant difference, we would have a problem :0)
timotimo this is 80 seconds vs 0.8 seconds for 100_000 accesses
that's negative indices vs positive indices
lizmat and posiitive indices with [] vs positive indices with AT-POS ? 21:26
timotimo 0.84 vs 0.83 21:27
lizmat I guess you need to increase until a runtime of several seconds :-)
timotimo sure 21:28
jnthn It'll still be similar percentage wise :P
lizmat well, it's really .74 vs .73 :-)
jnthn *nod* 21:29
Mostly these are just "wait for MoarVM's inliner to get smarter" though :)
lizmat true 21:30
timotimo 33.3s vs 29.14s for 5_000_000 accesses
these are accesses to not-yet-existing elements, fwiw
so scalars with a whence and all that 21:31
lizmat m: say .73/74; say 29.14/33.3
camelia rakudo-moar dd46c3: OUTPUTĀ«0.009865ā¤0.875075ā¤Ā»
jnthn Odd that the difference increaess...
timotimo could be that the gc hadn't kicked in before or something like that? 21:32
21:32 colomon joined
jnthn Mebbe 21:32
timotimo can i simply translate CALLER::CALLER:: to nqp::callerctx(nqp::callerctx(nqp::ctx)) in CALLER::CALLER::.EXISTS_KEY(...) and ::('...')? 21:35
or do i need a ctxlexpad there? 21:36
i probably do
jnthn I'd just look for cases that end in an indexing operation 21:37
An even then maybe only constant ones
e.g. when we would never actually expose a pseudo-package
timotimo oh, i was going to do the hand-optimization first
jnthn ah :) 21:38
Then yeah, can do it that way
jnthn should rest up for tomorrow's class
'night
timotimo i'm apparently syntax-wronging right now
good rest, jnthn!
have fun in class :)
ah, preclimit trouble, probably 21:39
it didn't like "and", so i used && instead 21:44
time perl6 -e 'my @a; for ^100_000 { @a.AT-POS(-$_) // Inf };' 21:45
47.61user 0.30system 0:48.03elapsed 99%CPU (0avgtext+0avgdata 851208maxresident)k 21:46
that's not quite 2x better, but it's noticable
but anyway, improving &fail is probably worthwhile
we want people to use this facility, too
in this case it's about improving die, actually 21:47
maybe we shouldn't be using a perl6-level die() to create & throw the exception we use to get the backtrace from
lizmat perhaps we need fail to be cheaper, only create the Backtrace if really necessary
timotimo whoa 21:48
lizmat whoa ?
timotimo the run time for that is 70% GC
lizmat yeah, lot's of garbage created in a fail
timotimo 9899901 Scalars getting allocated from inside BUILDALL 21:49
sorry
not scalar, BOOTCode
so closures being taken
only 299997 + 299997 Scalars from BUILDALL and another 299997 from backtrace (Exception's backtrace method; why does it allocate scalars??) 21:50
hash's AT-KEY allocates another 299997 21:51
fail also allocates scalars: 199998 of them
ah, ok, the number of gen2 roots is climbing a whole lot again there 21:53
the last ~50 gc runs (out of 719) take >100ms each
[Coke] I'm having trouble githubbing from hack. 22:00
hoelzro [Coke]: what kind of trouble? 22:01
hoelzro just cloned rakudo on hack sans problems
[Coke] just hangs.
timotimo i wonder how that one anon block inside BUILDALL gets to deopt 22:02
hoelzro [Coke]: what operation(s) hang? 22:03
[Coke] git push; git pull --rebase 22:10
hoelzro both of them hang? 22:12
22:25 oetiker joined
timotimo so here's a data point 22:33
using NativeCall to get at puts() is quite a bit faster than nqp::say
but NativeCall also has a whole bunch of overhead still
so we^WI really need to put in direct synchronous I/O 22:36
lizmat :-) 22:46
22:51 tokuhiro_ joined
timotimo huh 23:25
actually
it seems like libuv also offers synchronous IO - at least on files - and we're using that
huh. but only for files, not for streams 23:26
right, our implementation of say() will epoll_wait between every instance of say 23:27
leont That makes sense 23:35
timotimo it does? 23:40
epoll_wait(5, {}, 1024, 0) = 0
what does that even mean?
hm, well, at least it won't block or wait at all 23:41
leont It means it did a non-blocking wait for at most 1024 events 23:47
And it didn't return any events
timotimo ok, that's what i expected 23:54

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!