Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-01-24

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

All times shown according to UTC.

Time Nick Message
00:37 TimToady %-15f, heh, won't ask who installed that one...
01:03 Mouq joined #moarvm
01:32 d4l3k_ joined #moarvm
01:34 diakopter TimToady:
01:43 lue joined #moarvm
01:47 TimToady .oO(Nobody strikes again!)
02:12 jnap joined #moarvm
02:51 Mouq joined #moarvm
03:28 ozmq joined #moarvm
03:30 ozmq everybody++ for release
04:10 ozmq joined #moarvm
04:39 Mouq joined #moarvm
06:27 Mouq joined #moarvm
08:13 FROGGS joined #moarvm
08:15 Mouq joined #moarvm
08:26 odc joined #moarvm
09:05 cognominal joined #moarvm
09:16 Mouq joined #moarvm
13:09 Mouq joined #moarvm
13:43 bibifuc_ joined #moarvm
13:52 ggoebel1112 joined #moarvm
14:02 camelia joined #moarvm
14:57 Mouq joined #moarvm
14:58 ggoebel1112 joined #moarvm
15:07 jnap joined #moarvm
16:45 Mouq joined #moarvm
16:56 timotimo in MVMString.h there's a reference to "lower_index" and "higher_index" that's supposed to be in the MVMStrand struct
16:56 timotimo those do not currently exist there
16:56 timotimo what'll it be?
16:58 FROGGS could be about unicode codepoints <=0xFFFF and >0xFFFF too, no?
16:58 FROGGS not looked at the code though
17:07 FROGGS[mobile] joined #moarvm
17:07 diakopter no
17:07 diakopter the .h comments are out of date, not speculative
17:08 diakopter or they were renamed
17:12 timotimo right.
17:13 timotimo can you update them?
17:13 diakopter the 'no' was to Froggs
17:23 timotimo ah
17:24 FROGGS[mobile] tss
17:36 [Coke] moar at to 28673 today.
17:36 [Coke] s/to//
17:39 ggoebel1112 joined #moarvm
17:57 timotimo (gdb) print *result
17:57 timotimo "r(NQPCORE)(.setting.moarvm)"
17:57 timotimo that's the result of a concatenation :)
17:57 timotimo a rope! :D
18:03 timotimo okay, so a pretty printer for string, that's done
18:03 timotimo now i suppose i can display some extra info for MVMObject*
18:04 [Coke] timotimo++
18:07 FROGGS joined #moarvm
18:09 timotimo i forgot again: how exactly do i get to the name of something?
18:12 timotimo i know how to get the name of the repr, so that much is known
18:19 jnthn timotimo: With difficulty at present, if you're in C land.
18:19 jnthn timotimo: 'cus you'd have to call .name on the meta-object, but that'll drop you back into the runloop.
18:20 jnthn timotimo: For these kinda things I've pondered having a way to set a debug name on an STable, which we hold as a simple C string (in utf-8)...
18:24 timotimo hm, right
18:25 timotimo is there a sane way to have an inferior runloop like what i've heard exists somewhere in parrot land?
18:25 timotimo don't we need something like that for callbacks from c land anyway?
18:26 jnthn There's no sane way to have inferior runloops.
18:27 TimToady that depends on whether the subcode expects it to run immediately, or can just schedule it to run
18:27 TimToady if you can just schedule it, then it's not an inferior runloop
18:27 timotimo hehe.
18:27 jnthn Moar doesn't have them at all. We may allow a *very* limited form for callbacks from C land that must execute synchronously, but it will be deliberately written as unreusable code to make sure people don't use it for anything else.
18:28 TimToady "Here be dinosaurs!"
18:28 jnthn Parrot made inferior runloops easy and the consequences were...painful.
18:29 jnthn r: sub foo($x = take 42) { }; say gather foo()
18:29 camelia rakudo-parrot 8ae2de, rakudo-moar 8ae2de: OUTPUT«42␤»
18:29 camelia ..rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤  in sub foo at /tmp/tmpfile:1␤  in block  at /tmp/tmpfile:1␤␤»
18:29 jnthn r: sub foo($x = take 42) { say "and we got here" }; say gather foo()
18:29 camelia rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤  in sub foo at /tmp/tmpfile:1␤  in block  at /tmp/tmpfile:1␤␤»
18:29 camelia ..rakudo-parrot 8ae2de, rakudo-moar 8ae2de: OUTPUT«and we got here␤42␤»
18:29 jnthn I'm a little surprised that one works out on Parrot :)
18:29 FROGGS jnthn: it works!!
18:30 jnthn r: sub foo($x = take 42, $y = take 43) { say "and we got here" }; say gather foo()
18:30 camelia rakudo-parrot 8ae2de, rakudo-jvm 8ae2de, rakudo-moar 8ae2de: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/tmpfile␤Variable '$y' is not declared␤at /tmp/tmpfile:1␤------> [32msub foo($x = take 42, $y[33m⏏[31m = take 43) { say "and we got here" }; s[0m…»
18:30 jnthn r: sub foo($x = (take 42), $y = take 43) { say "and we got here" }; say gather foo()
18:30 camelia rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤  in sub foo at /tmp/tmpfile:1␤  in block  at /tmp/tmpfile:1␤␤»
18:30 camelia ..rakudo-parrot 8ae2de, rakudo-moar 8ae2de: OUTPUT«and we got here␤42 43␤»
18:30 jnthn Yeah, I'm a bit surprised Parrot manages that one :)
18:30 jnthn I thougth there'd be a continuation barrier there.
18:31 jnthn Oh, but it's done with coroutines, which aren't implemented atop of continuations
18:31 jnthn So we perhaps get away with a bit more. :)
18:32 jnthn r: sub foo($x = (take 42), $y = take 43) { say "and we got here" }; my @a := gather foo(); say @a[0]; say 'here'; say @a[1]; # curious about this one
18:32 camelia rakudo-jvm 8ae2de: OUTPUT«control operator crossed continuation barrier␤  in sub foo at /tmp/tmpfile:1␤  in block  at /tmp/tmpfile:1␤␤»
18:32 camelia ..rakudo-moar 8ae2de: OUTPUT«42␤here␤43␤»
18:32 camelia ..rakudo-parrot 8ae2de: OUTPUT«42␤here␤43␤Nominal type check failed for parameter '$y'; expected Any but got Mu instead␤»
18:32 jnthn Oh my. :)
18:38 TimToady it's not clear to me that gather/take should be implemented with a control exception in any case
18:40 TimToady especially if that implies a stack search every take
18:45 TimToady well, I suppose the destination can be cached locally
18:46 jnthn Yeah, I think control exception is probably the right way, and then find a caching approach.
18:47 jnthn We need a caching approach for dynamic variables too, I think.
18:47 TimToady that could be a big speedup in spots
18:47 jnthn getdynlex used to be a whopping 5% of the entire CORE.setting compilation time on Moar
18:48 TimToady depending on depth of nesting of dynamic scopes
18:48 jnthn It's down to a still-too-high 2.something% now, after I implemented caching of hash coes for strings...
18:48 jnthn *codes
18:48 TimToady well, find some more 20%ers first :)
19:13 FROGGS multithreaded NFA evaluation!
19:20 jnthn If you think NFA evaluation is a bottleneck, you didn't read the profile yet :P
19:22 FROGGS hehe
20:01 jnap joined #moarvm
20:49 jnap joined #moarvm
20:59 diakopter read what profile
21:08 diakopter (did I miss an url?)
21:08 FROGGS there was none
21:10 jnthn diakopter: Just meant a profile of CORE.setting compilation
21:10 diakopter do you have a screenshot or xls or something? :)
21:10 jnthn 'fraid not...
21:10 jnthn Just been looking at it in VS
21:11 * diakopter finally gets to working on the hll profiler again
21:12 * diakopter reads http://kcachegrind.sourceforge.net/html/CallgrindFormat.html
21:18 diakopter hm, incomplete
21:19 [Coke] jvm still borked. parrot now in the lead, followed by moar.
21:19 [Coke] s/still/re-/
21:21 diakopter jnthn: should all the profiling options be configure-time, or just 1 configure-time and most others invoke time?
21:22 FROGGS [Coke]: I just unborked jvm
21:22 FROGGS 25 minutes ago, to be exact
21:23 [Coke] FROGGS++
21:23 jnthn diakopter: What kind of options do you have in mind?
21:24 jnthn diakopter: Is the Configure time one you had in mind "build with profiling support"?
21:25 diakopter the default would be to count/time callsites|staticcode tuples and its tree (or graph!), but then optionally also count/time each opcode
21:26 diakopter could also count reprops, ish
21:26 diakopter yes, one configure-time to enable the profiling checks overall
21:26 jnthn The first is probably good enough to get some decent data.
21:26 jnthn Could per-op be a big slowdown?
21:27 jnthn (if not in use)
21:27 diakopter yeah, would need to be configure time
21:28 jnthn yeah, that was my guess
21:28 jnthn well, maybe a if (profiling_ops) at the top of the runloop could be fast enough to have it runtime configurable if you already did a profiling build.
21:29 diakopter well, rebuild is plenty fast :P
21:30 diakopter esp if you don't change any .h
21:30 jnthn aye
21:30 jnthn Aside from the link time opts...
21:30 diakopter well, or .c :)
21:32 diakopter my idea was to use averaging to summarize >1000 invocations, while still retaining the 2% of outliers on both ends, to avoid huge data explosion of the timings
21:33 Mouq joined #moarvm
21:34 diakopter that assumes single-hump distribution though, so there should also be an option to allow the data to asplode :D
21:36 diakopter jnthn: does that seem sane?
21:37 jnthn diakopter: Seems like you're better at statistics than me :)
21:37 jnthn diakopter: It *sounds* sane but I'm pretty bad at knowing what's reasonable when it comes to these things :)
21:38 diakopter maybe a smart bucketing system would be better
21:40 diakopter it's just I HATE that visual studio uses like 500MB of disk per second to profile.
21:40 diakopter an instrumented build I mean
21:41 diakopter I mean, seriously.
21:41 FROGGS SSD ftw
21:42 diakopter yeah but it also adds 10-20x slowdown overhead to do so. so a 4-second program run takes 30GB
21:42 diakopter (an otherwise 4-second program, I mean)
21:43 diakopter that's with an SSD.
21:47 FROGGS yeah, I know what you mean
21:47 FROGGS and then you actually have a problem to read in these 30gig, especially on windows
21:47 diakopter a sampling build/profile is much more efficient, but far less precise and informative
21:48 jnthn I've found them quite informative.
21:48 jnthn Agree they can't get the precision to the same level, though otoh they are less invasive...
21:50 diakopter could also trivially have it annotate a --dump output with the timings also, optionally, so once you're looking at the kcachegrind visualization, you can refer back to the dumped assembly view to see what each callsite called and its timings
21:53 diakopter for that matter... could intersperse the original source code into the assembly view :) or vice versa.
21:54 diakopter "hmm, this 1 line of Perl 6 code created 46 static code frames and 9973 moarvm opcode instructions..."
21:55 diakopter "that's a lot of inline/implied closures!"
21:56 FROGGS O.o
22:38 jnthn Ooh, a 301s spectest. That's a new record...
22:38 FROGGS joined #moarvm
22:40 [Coke] S05-mass ?
22:41 jnthn [Coke]: ?
22:43 jnthn Does dir.t work for anybody at all?
22:43 jnthn I think I've heard folks say it does, so I guess the explosion I'm seeing is just on Windows.
22:45 FROGGS joined #moarvm
22:46 jnthn nqp-m: my $h := nqp::opendir('.'); say(nqp::nextfiledir($h))
22:46 camelia nqp-moarvm: OUTPUT«.lesshst␤»
22:46 jnthn nqp-j: my $h := nqp::opendir('.'); say(nqp::nextfiledir($h))
22:46 camelia nqp-jvm: OUTPUT«./.lesshst␤»
23:00 dalek MoarVM: 8286436 | jnthn++ | src/io/dirops.c:
23:00 dalek MoarVM: At least somewhat unbust dir on Windows.
23:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8286436507
23:14 diakopter 500 error on https://github.com/perl6/nqp/commits/master
23:15 diakopter 500 error on all the things
23:30 timotimo secmoar now forks a new moarvm, runs code in it and then fails waiting on it because the forked moarvm thinks its stdin wasn't initialised
23:33 diakopter TimToady had a trick to fix that
23:42 timotimo i think the handles are being overwritten, but i actually hacked a check in there :\
23:58 timotimo i made a very dumb mistake to cause this
23:59 * jnthn just made one of those too :)

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