MasterDuke | there's nothing in the log with the name of the non-jitted function, so how do i know which bail is associated with it? | 01:57 | |
timotimo | is it speshed at all? | 01:58 | |
MasterDuke | nope | 01:59 | |
timotimo | well, there's your answer | ||
can't jit what isn't speshed | 02:00 | ||
one of the drawbacks of the current system, it's "all or nothing" | |||
in this case it's nothing | |||
MasterDuke | github.com/rakudo/rakudo/blob/nom/...ch.pm#L197 | ||
timotimo | it's currently quite difficult to figure out why spesh isn't doing something at all | 02:02 | |
maybe the spesh log of the frames that call into INTERPOLATE have a little something to tell us | |||
MasterDuke | INTERPOLATE shows up in the spesh log, but i know how to read it even less than the jit log | 02:05 | |
the code i'm running is: `my @l = "f.json".IO.lines; my $s = "name"; my @m = @l.grep(/ $s /); say +@m` | 02:07 | ||
playing around with rt.perl.org/Ticket/Display.html?id=127064 | |||
timotimo | hmpf. it has an interned callsite and it uses fastinvoke to call into INTERPOLATE | 02:11 | |
however the INTERPOLATE method itself doesn't show up at all | 02:12 | ||
i really should go to bed now though | 02:15 | ||
MasterDuke | lots of param_sn and throwpayloadlex in the BAILs | ||
timotimo | yeah | 02:17 | |
those are only interesting if the frames they bail out from take a significant amount of time | |||
ttyl! | 02:19 | ||
MasterDuke | later... | 02:20 | |
04:16
lizmat joined
05:53
statisfiable6 joined
06:09
brrt joined
|
|||
brrt | good * #moarvm | 06:21 | |
i know why param_?? and friends aren't JITted | 06:24 | ||
but why isn't throwpayloadlex | |||
06:39
domidumont joined
06:44
domidumont joined
06:46
lizmat joined
06:58
domidumont joined
07:14
brrt joined
07:29
zakharyas joined
07:46
lizmat joined
|
|||
brrt | good * lizmat | 07:55 | |
samcv | good * brrt | 08:10 | |
brrt | good * samcv | ||
jnthn | morning o/ | 08:45 | |
brrt: On throwpayloadlex, probably simply that nobody got to doing it yet | |||
brrt | i seem to recall timotimo did something with that and it burned | 08:46 | |
nwc10 | good *, * | ||
brrt | ohai nwc10 | 08:49 | |
jnthn | .oO( probably that nobody got to doing it right yet :P ) |
08:50 | |
samcv | was gonna get back to work on concatenation | 08:52 | |
jnthn planning to get back to work on spesh-worker | |||
lizmat | brrt: good *, wasn't actually here, but just the victim of a flaky wifi | 08:53 | |
jnthn | Though allowing myself to be at least for a little time distracted by rt.perl.org/Ticket/Display.html?id=131755 | ||
brrt | (either that or it exposed some broken assumption) | 08:55 | |
damn flaky wifis' | |||
brrt is looking forward to TPC | |||
samcv | same | 08:56 | |
brrt | i'm wondering if i can make a Makefile rule that will make | 08:57 | |
08:57
zakharyas joined
|
|||
brrt | foo.expr be automatically picked up as a dependency for foo.o | 08:57 | |
but only for foo.o | |||
and only if foo.expr really exists | |||
samcv | jnthn, so what is perl6's thing with opening something as '-' i heard it was special? and didn't actually open a file named '-'? | 08:58 | |
is this true? | |||
jnthn | samcv: Apparently it opens stdin or stdout... | ||
I think it's on the chopping block, though | 08:59 | ||
samcv | sadface | ||
i don't think anybody uses it. at all | |||
nwc10 | it's the classic Unix command line tool way of expressing STDIN or STDOUT | ||
samcv | yeah i know that... still tho | ||
nwc10 | ah OK. I didn't know that you know that. Now I know that you know :-) | ||
08:59
robertle joined
|
|||
nwc10 | and I agree - not really sure if anyone is still using it | 08:59 | |
samcv | yeah i totally *get* it i just hate it | ||
jnthn wonders if it's one of those "we did it in Perl 6 'cus Perl 5 does it" things | 09:00 | ||
brrt | why hate it? | ||
samcv | because i name all my files '-' | ||
brrt | i mean, it'd be wrong on certain places in the stack | ||
well, there's a classic unix trick for that too | |||
foo ā '-' | |||
or | |||
samcv | b-but this is perl 6! | ||
brrt | i like my classic unix hacks :-P | 09:01 | |
samcv | but yeah i know the - - thing too | ||
and cd -- - | |||
in scripts i usually use cd -- whenever i remember | |||
jnthn | I can't manage to get the example from the RT to work ever | 09:02 | |
valgrind just says we're passing -1 to the read syscall | |||
09:02
lizmat joined
|
|||
samcv | i need to go through and delete all my old branches | 09:02 | |
as they all won't fit on the screen with git branch for some time now | 09:03 | ||
jnthn | ah, if I stick a say $*IN.native-descriptor into the script just before the read from $*IN then it works | 09:05 | |
Odd | 09:06 | ||
aha, the close call is coming from a DESTROY method | 09:10 | ||
ahhh | |||
So the script makes the original $*IN unreachable | 09:11 | ||
Which means that it gets GC'd | |||
And the DESTROY method closes the file handle | |||
The timing of that is GC-sensitive, thus the timing oddities we see make sense | |||
But handles that use stdout/stderr/stdin are special in that they re-use the same underlying VM handle | 09:12 | ||
And the DESTROY is closing it | 09:13 | ||
jnthn will note this on the ticket | |||
There we go; analysis of the issue noted :) | 09:20 | ||
geekosaur | I would say it is good if the argv-files thing handles -, but it should be special cased for that. | 09:50 | |
that is, '-' is not a filename, it is part of command line processing | |||
brrt | that is true | 09:51 | |
geekosaur | perl 5 didn't do it that way, but perl 5 also thought filenames like 'foo|' were great | ||
and I think (hope!) we ditched that too | |||
samcv | great as in it made a pipe? | 10:02 | |
was that sarcasm? | |||
i've never tried to use odd filenames and just did the best practices ways of opening files with mulitple arguments | |||
brrt | well, it's one of those pretty-cool-in-a-tight-spot perl5 script handy things | 10:03 | |
but then | |||
geekosaur | if you use a name like that as a filename on the command line, it runs the command as a pipe and reads its output | ||
samcv | oh command line | ||
brrt | it's not compatible with perl-as-a-web-language thing | ||
geekosaur | (these days shells can handle both of those for you, but on systems without /dev/stdin or /dev/fd/* the shell's implementation may be even hackier than perl 5's way of handling it. see bash source for an example.) | 10:06 | |
mst | imgur.com/cKQrf | ||
geekosaur | in fact shells are even more evil than that; zsh came up with /dev/tcp/hostname:port some years back and bash adopted it later... | 10:07 | |
(I've always been afraid to ask how they deal with Solaris.) | 10:15 | ||
11:02
lizmat joined
|
|||
Geth_ | MoarVM/spesh-worker: f93757621e | (Jonathan Worthington)++ | src/spesh/dump.c Factor out dumping a spesh stats type tuple. |
11:03 | |
MoarVM/spesh-worker: 4e1b6ce67c | (Jonathan Worthington)++ | 3 files Implement observed type specialization planning. This is where the an observed type tuple gains a large enough share of the hits or OSR hits in order to win a specialization. This will no doubt receive further tweaks, but seems to produce fairly sensible initial results. |
|||
jnthn | Lunch time; bbiab | 11:05 | |
11:19
lizmat joined
|
|||
jnthn | Pondering over lunch a bit, I think I'll put off doing the fancier type planning and move on to getting the actual specialization work moved over to the worker | 12:04 | |
samcv | nice | 12:05 | |
jnthn | That gets me to a potentially mergeable result sooner | 12:06 | |
samcv | oh nice i can just do git branch --merged master and delete all those sweet | 12:25 | |
Geth_ | MoarVM/spesh-worker: 080d6b7cb6 | (Jonathan Worthington)++ | 3 files Track maximum simulated stack depth stats seen at. |
12:27 | |
MoarVM/spesh-worker: 797421020a | (Jonathan Worthington)++ | 3 files Include maximum applicable stack depth in plan. |
12:35 | ||
12:42
zakharyas joined
|
|||
Geth_ | MoarVM/spesh-worker: 8480011343 | (Jonathan Worthington)++ | src/spesh/plan.c Sort plan by stack depth descending. |
12:45 | |
jnthn | grmbl, got a small number of explodey spectests | 12:55 | |
12:58
domidumont joined
|
|||
Geth_ | MoarVM/spesh-worker: 409d06aa41 | (Jonathan Worthington)++ | src/core/frame.c Don't passa a real NULL into a LEAVE block. |
13:02 | |
jnthn wonders que passa with his typing... | 13:04 | ||
samcv | hehe | 13:09 | |
brrt | haha | ||
(though i must ask. why not qsort?) | 13:10 | ||
samcv | no pasa | ||
*passa | |||
jnthn | brrt: That is a quicksort? | 13:13 | |
brrt | it looks at first blush surprisingly like a quicksort | 13:14 | |
yes, you pick a pivot and swap over it | 13:15 | ||
and then recurse | |||
(you have a variant on that that is 'pick top n', implemented in nearly the same way) | |||
oh, hang on | 13:16 | ||
i mean to say | |||
why not use qsort(3), the C stdlib function | |||
jnthn | Maybe 'cus I didn't know it exists? :) | 13:17 | |
hm, MSVC even seems to have it | 13:18 | ||
For once | |||
brrt | :-) there's even, i think, on bsd-like platforms, a standard heapsort, and a standard mergesort | 13:19 | |
but those are nonstandard | 13:20 | ||
nwc10 | it wouldn't be very conformant C89 without it | ||
brrt | (nonstandard stdlib function) | ||
jnthn | nwc10: Heh, that was gonna be my next question, is it c89 or c99 | ||
mst | brrt: on the nearest debian box it appears to be in -lbsd | ||
brrt | that is pushing it a bit though | 13:21 | |
anyway, the 'normal' reason not to use stdlib qsort is that it incurs a function invocation for every comparison, and that is costly | 13:22 | ||
so i thought that would be it :-) | |||
jnthn | Grr, still got a few spectests that SEGV under spectest with by branch | ||
They're fine without it | 13:23 | ||
jnthn tries GC torture | |||
Zoffix | What standard does MoarVM follow C89 or C99 or newer? | ||
nwc10 | if you want torture I can lend you some image handling libraries | ||
jnthn | C89 for the sake of MSVC | ||
Zoffix | yikes | ||
mst | doesn't MSVC have, like, *most* of C99 at this point? | 13:25 | |
jnthn | mst: It's certainly got bits of it, and we're probably using parts that it does have. | 13:26 | |
The main annoyance is that it doesn't allow declarations anywhere except the top of a block | |||
mst | ow | ||
so no 'for (int i = 0; ...)' ? | 13:27 | ||
jnthn | Right | ||
mst | eww | ||
Zoffix | dammit RoarVM already exists: github.com/smarr/RoarVM | 13:28 | |
so much for MoarVM written in Rust :} | |||
jnthn | heh, never heard of that | ||
If there's a MoarVM successor it'll probably be called LessVM and written in Perl 6 :P | 13:29 | ||
Zoffix | heh | ||
Zoffix might try making it in Rust as a learning project of both MoarVM and Rust | 13:30 | ||
jnthn | (No, I've certainly no plans. :) More likely is MoarVM will gradually evolve to become smaller.) | ||
Writing a VM is a fun learning project :) | 13:31 | ||
oh hurrah, I got an explosion | 13:33 | ||
timotimo | cool guys don't look at explosions | ||
jnthn | Apparently somehow a callframe ends up containing a pointer to something from a past fromspace. | 13:34 | |
timotimo | is it a callframe that the spesh worker somehow owns but doesn't properly mark? | 13:35 | |
jnthn | No, doubt it | ||
Probably more likely a thinko in the interpreter | |||
Just found a likely candidate | 13:36 | ||
nwc10 | The aim is to converge on something the size of x.com/ ? | 13:37 | |
(might take a while) | |||
Zoffix | Why did Elon register it? | 13:38 | |
nwc10 | IIRC technically he didn't | 13:39 | |
oh wait, it was his startup | |||
paypal was what merged | |||
Zoffix | oh | 13:40 | |
jnthn | huh, it looks like it's always a frame that gets marked and its ->caller is an outdated pointer o.O | 13:49 | |
Hm, and MVM_SPESH_DISABLE doesn't make it go away | 13:51 | ||
Geth_ | MoarVM/spesh-worker: 8f066c33a4 | (Jonathan Worthington)++ | src/core/interp.c Make sure code won't be outdated if spesh log sent |
14:01 | |
jnthn | That fix is needed, but not it seems the bug that I'm hitting. | 14:02 | |
brrt | (making moarvm smaller)++ | ||
jnthn | Most odd. In both cases I look at so far it's the same caller/callee where the caller has an outdated caller point | 14:07 | |
Geth_ | MoarVM/spesh-worker: ad158f0792 | (Jonathan Worthington)++ | src/core/frame.c Correct a typo. |
14:17 | |
14:22
dogbert17 joined
|
|||
jnthn | Can't figure it out easily from the debugger, and know it works without my spesh-worker changes, so currently bisecting, fwiw | 14:27 | |
Apparently, ddca0e5f99021 is to blame | 14:46 | ||
14:47
brrt joined
|
|||
timotimo | but there's hardly any code in there?! | 14:47 | |
jnthn | That...doesn't make much sense :S | 14:48 | |
jnthn rebuilds Rakudo just in case | |||
timotimo | doesn't one of the extops use staticframes? | 14:50 | |
it grabs the outer, but it doesn't set anything | 14:51 | ||
jnthn | yeah, will see | ||
14:52
evanm joined
14:53
domidumont1 joined
|
|||
jnthn goes back one more commit from the one bisect found to try that | 14:53 | ||
14:53
AlexDaniel joined
|
|||
evanm | Hi, I have a question about MoarVM's internal string representation | 14:57 | |
timotimo | go ahead | ||
evanm | It looks like there's a repetition structure so that "abcde" and "abcde" x 10000 use the same amount of memory | ||
jnthn | What the heck, the one bisect found apparently really is it?! | 14:58 | |
evanm | But when I match the latter against a regex, it seems to get expanded into a flat representation first -- is that correct? | ||
jnthn | evanm: Yes. | ||
Strand-y strings get flattened out so they are cheaply indexable, for the sake of regex performance. | 14:59 | ||
The request to do that is implemented in, iirc, !cusror_init in the Cursor role in NQP | |||
timotimo | grep for "indexingoptimized" | 15:00 | |
evanm | Ok, thanks, I'll take a look. Are regexes capable of matching strand-y string directly? | 15:03 | |
timotimo | yep, they are | 15:04 | |
jnthn | I don't think there's any reason why at MoarVM level why it'd not work (just run slowly); it's not exposed as an option at Perl 6 level. The standy thing is really just an optimization, not part of the language. | ||
evanm | I'm just thinking ("abcde" x 10000) ~ "foo" ~~ "foo" takes longer than it should | ||
15:05
brrt joined
|
|||
evanm | Err you know what I mean | 15:05 | |
jnthn | Does that even use regex? | ||
evanm | time perl6 -e '("abcde" x 100_000_000) ~ "foo" ~~ /foo/' | 15:08 | |
3.25 real 2.13 user 1.09 sys | |||
time perl6 -e '("abcde" x 1_000) ~ "foo" ~~ /foo/' | |||
0.18 real 0.14 user 0.02 sys | |||
But I guess that might be asking for another layer of optimization | 15:09 | ||
brrt | jnthn, that moves the sequence number by 4 bytes, might that upset the JIT? | ||
jnthn | I think that's one of those cases where we'd maybe like the regex compilation to be smart enough to realize that the thing in question isn't really a regex | ||
brrt | i mean, it only would when the compile isn't clean | ||
jnthn | brrt: Shouldn't, but I'm running with MVM_SPESH_DISABLE and getting the crash anyway | 15:10 | |
brrt | okay, then i'm flabbergasted | ||
:-) | |||
jnthn | It gets better | ||
It's the addition to the struct that causes it. o.O | |||
brrt | oh, that's good | ||
jnthn | If I remove all the code that uses the addition we're good | ||
uh | |||
we're still not good | |||
brrt | hmmkay, why now? | 15:11 | |
jnthn | So a patch that just adds an extra entry to an MVMFrame is sufficient o.O | ||
That's bizzare | |||
I was gonna guess it's alignment, but it's added in the middle | |||
brrt | hmmm | 15:12 | |
jnthn | The thing ends with an 8-byte pointer | ||
brrt | anything in rakudo that uses that structure directly? | ||
.oO( let's all sponsor jnthn to kill the extops ) |
|||
i almost convinced someone to use perl6 today! | 15:14 | ||
by analogy: perl6 is to go what perl5 is to C (or C++) | |||
timotimo | huh | ||
.contains("foo") is actually a whole lot slower than ~~ /"foo"/ | 15:15 | ||
jnthn | I wonder if this is a result of MVMFrame passing a certain size | ||
timotimo | using indexingoptimized before contains is still slower than just regexing | ||
is something accidentally writing over the boundary of a struct value and it used to write into padding space so it did no harm? | 15:16 | ||
brrt | does valgrind know? or asan? | ||
timotimo | i don't think it would | ||
jnthn | It's at 288 bytes after the change fwiw | 15:17 | |
#define MVM_FSA_BINS 96 | 15:18 | ||
m: say 96 << 3 | |||
camelia | ===SORRY!=== Error while compiling <tmp> Unsupported use of << to do left shift; in Perl 6 please use +< or ~< at <tmp>:1 ------> say 96 <<ā 3 |
||
jnthn | m: say 96 +< 3 | ||
camelia | 768 | ||
brrt | ā¦ if i hadn't forgotten to download virtualbox, i would've had a fully functional dev vm by now | ||
jnthn | valgrind...seems to be hiding the problem entirely?! | 15:19 | |
grr | |||
brrt | (yolo) | ||
jnthn | Disabling the FSA makes no difference | 15:20 | |
m: say 288.base(2) | 15:22 | ||
camelia | 100100000 | ||
Zoffix | brrt: "almost" convinced? Why didn't they want it in the end? | 15:25 | |
brrt | a dayjob that wouldn't allow it | 15:27 | |
Zoffix | timotimo: looks like it depends on whether "foo" is at the start or at the end. When it's at the start, .contains takes .2s; when it's at the end, it takes 11s; and regex takes ~3s in both cases | 15:28 | |
say ("foo" ~ "abcde" x 100_000_000).contains: "foo" vs say ("abcde" x 100_000_000 ~ "foo").contains: "foo" I mean | |||
evalable6 | Zoffix, Full output: gist.github.com/e26bd3ba790cc8808d...f6d136ba53 | ||
(exit code 1) ===SORRY!=== Error while compiling /tmp/weXibWRGHc Two terā¦ |
|||
jnthn | Yup, and delte the field and it works just fine | ||
*delete | |||
Zoffix | evalable6: shoo | ||
evalable6 | (exit code 1) ===SORRY!=== Error while compiling /tmp/KRqexuaO4N Undeclared routine: shoo used at line 1 |
||
jnthn | It's possible that the frame size difference just impacts whether the past fromspace check catches it, I guess | 15:32 | |
The spectests that would fail don't without that field added, though | 15:39 | ||
Which kinda holes that theory | |||
:S | |||
jnthn puts this aside for a bit | 15:40 | ||
Maybe I'll think of something | |||
15:48
domidumont joined
|
|||
Geth_ | MoarVM/spesh-worker: 2d6a1b7797 | (Jonathan Worthington)++ | 2 files Eliminate calls into the specializer. These will be replaced with the specializations being performed and installed on the worker thread. For the moment, this disables all of the specialization. |
15:57 | |
MoarVM/spesh-worker: 3f805ef359 | (Jonathan Worthington)++ | 3 files Toss out now-unrequired call counting bits. |
|||
16:01
zakharyas joined
|
|||
Geth_ | MoarVM/spesh-worker: 4909bab4fd | (Jonathan Worthington)++ | src/spesh/dump.c Remove dump of soon-to-be-removed spesh log slots. |
16:10 | |
MoarVM/spesh-worker: 5504a0d23c | (Jonathan Worthington)++ | 3 files Remove spesh logging insertion code. |
|||
MoarVM/spesh-worker: 7b655eec86 | (Jonathan Worthington)++ | src/spesh/candidate.c Remove spesh log mentions from candidate setup. |
16:15 | ||
MoarVM/spesh-worker: a7528401ca | (Jonathan Worthington)++ | src/spesh/osr.c Remove mentions of spesh logging from OSR. |
|||
MoarVM/spesh-worker: 32f9f58423 | (Jonathan Worthington)++ | src/core/interp.c Gut two spesh ops that will be going away. |
16:16 | ||
MoarVM/spesh-worker: c201e7a93a | (Jonathan Worthington)++ | src/core/frame.h Remove now-unused spesh_log_slots from MVMFrame. |
16:17 | ||
MoarVM/spesh-worker: bed4731dc7 | (Jonathan Worthington)++ | 5 files Remove last mentions of spesh_log_idx. Which is a nice simplification and removes checks on various GC marking and invocation paths. |
16:27 | ||
MoarVM/spesh-worker: 25273e4ed4 | (Jonathan Worthington)++ | src/spesh/dump.c Toss another log slots mention from the dumper. |
|||
MoarVM/spesh-worker: 792ac61f30 | (Jonathan Worthington)++ | 2 files Eliminate log slots from candidate data structure. |
|||
MoarVM/spesh-worker: 6b80e45847 | (Jonathan Worthington)++ | 2 files Remove facts/optimize use of spesh logs. This will be replaced with obtaining data using the new spesh logging scheme. |
16:38 | ||
MoarVM/spesh-worker: b1b5377617 | (Jonathan Worthington)++ | 2 files Remove some of the last spesh logging mentions. |
|||
MoarVM/spesh-worker: 2226b9799c | (Jonathan Worthington)++ | 8 files Remove sp_log op. |
|||
16:44
domidumont joined
|
|||
Geth_ | MoarVM/spesh-worker: 4629ad79fe | (Jonathan Worthington)++ | 7 files Remove the OSR finalize op. We'll need the osrpoint op to poll for a ready replacement under the new scheme, so this op becomes redundant. |
16:45 | |
16:48
robertle joined
|
|||
Geth_ | MoarVM/spesh-worker: 9e8b9f804a | (Jonathan Worthington)++ | src/core/frame.h Remove now-unused osr_counter field from MVMFrame. |
16:53 | |
jnthn | Alrighty, I think I'll leave it there for today | 16:56 | |
Tomorrow I'll work at getting spesh working again on this branch, this time on the worker thread. Once I get the basic case working again, I'll look into getting OSR back in shape also | 16:57 | ||
17:03
zakharyas joined
17:20
ilmari[m] joined
17:32
lizmat joined
19:09
evanm joined
20:02
lizmat joined
|
|||
samcv | whoops i accidently deleted my master branch | 21:34 | |
fixd now :) | 21:35 | ||
22:03
lizmat joined
22:07
MasterDuke joined
|
|||
jnthn | samcv: haha, because --merged outputs the branch you're standing on too? :) | 22:31 | |
samcv | yes :) | ||
jnthn | No prizes for guessing how I suspected this ;) | 22:33 | |
rest time; more spesh hackery tomorrow :) | 22:41 | ||
samcv | so today i'm going to try and get my concat patch reading for merge | 22:57 | |
just running benchmarks and such. interestingly as i'd made other changes to reduce when re_nfg is triggered my old tests which showed a bigger improvement are now no longer as good :P | |||
so i'm having to manufacture some more that better trigger things hah | |||
ahhh i see why. damn optimizations not performing the concatenation every time :p | 22:59 | ||
mostly want to ensure that short concats are not any slower | 23:00 | ||
as i *know* long ones will be immensely faster | |||
ok.... this is weird | 23:03 | ||
how... | |||
ok i do this perl6 -e 'my $boy = "\c[BOY]"; for ^1000 { $ = "aa$boy" ~ "\c[ZWJ]" }' everything is fine | |||
i run it 10000 times instead. and i get a throw. because somehow it creates the replacement substring but it ends up with 0 codepoints | 23:04 | ||
wtf. | |||
howwwwwwwwww | |||
timotimo | use rr to figure it out! ;) | ||
samcv | rr? | 23:05 | |
i never even thought that'd ever get triggered. but i threw in a throw adhoc just because | 23:06 | ||
timotimo | yeah, it records your program execution and lets you replay as often as you like and also debug forwards and backwards, including watchpoints | ||
samcv | since if it's 0 for a or for c then it removes those strands | ||
as that moans the codepoinst from a or c were totally consumed | |||
so "\c[BOY]" ~ "\c[ZWJ]" would consume the first and second strings | 23:07 | ||
and remove those strands and not have it an offset or whatever | |||
but how does that happen for a string i created | |||
ah | |||
and why only when i run it enough times | |||
that is the string i create with MVM_unicode_codepoints_c_array_to_nfg_string | 23:08 | ||
so it should never be 0 codepoints | |||
dogbert17 | m: for (109..199) -> $num { my ($non-rep, $rep) = (1/$num).base-repeating(10); } | ||
camelia | ( no output ) | ||
dogbert17 | timotimo: this snippet fails when doing a profile, any idea why? | 23:09 | |
samcv | ok so at least it's not triggering when i throw in a throw when it's created | 23:10 | |
so somehow. uh | |||
something.... else. why | |||
timotimo | dogbert17: no clue | 23:11 | |
cannot call method "defined" on a null object? | |||
'tis a bug i've tried to find before in another program | |||
samcv | so uh | 23:12 | |
the string must be getting gc'd | |||
since it's not throwing when the string is created | |||
help | |||
something terrible must be happening | |||
but then i check and it's 0 in length like later on in the function | |||
but only when running it 10,000 times but not 1000 times | |||
timotimo, also how does MVMROOT work. the argument you supply to it. does it have to be the correct pointer already | 23:13 | ||
also. i have an issue because only *sometimes* will it ever hold a string. most cases it won't | |||
samcv doesn't completely know how MVMROOT works | 23:14 | ||
dogbert17 | timotimo: it's strange, the profiler is 'changing' how the program works | ||
samcv | sounds like physics | 23:15 | |
just stop watching it | |||
;p | |||
dogbert17, i've had things change how it works regarding GC at least. like running something in GDB i'd get no problem but not in GDB things would go wrong | |||
dogbert17 | I just figured out that with MVM_SPESH_DISABLE=1 the problem vanishes | 23:18 | |
timotimo | well, yeah, the profiler works by putting a bunch of ops into the code to do some measurements | ||
like "the code just allocated a Str" | |||
or "this routine was just entered in its speshed variant" | 23:19 | ||
dogbert17 | spesh seems tricky | ||
samcv | someone help me understand MVMROOT :| | ||
timotimo | samcv: it registers a location in memory as a) containing a pointer to an object that needs to be kept alive, and b) containing a pointer that needs to be kept up to date when things move | 23:20 | |
samcv | ok and the closure | ||
timotimo | this is done with a stack of pointers that gets pushed to at the beginning of mvmroot and popped at the end | ||
it's not actually a closure | |||
samcv | tell me about the closure and how inside and outside | ||
it's a macro | |||
timotimo | yup | 23:21 | |
samcv | i know that | ||
i just meant between the { } | |||
timotimo | the { } are only there to appease the syntax gods | ||
samcv | oh | ||
so it happens before the code in it | |||
timotimo | you can't put ; in between () of a macro i don't think | ||
samcv | and the end of the } doesn't change any state? | ||
timotimo | the end pops the pointer off the temporary roots stack | ||
samcv | oh ok | 23:22 | |
timotimo | other than that it doesn't do anything | ||
samcv | so it does change things | ||
timotimo | yeah, after that the pointer you rooted will no longer be kept updated when things move and objects you used to point to may be thrown away in a GC run | ||
samcv | so i must supply the actual pointer to the object to MVMROOT(tc, pointerhere, { } ); i.e. it can't be uninetialized? | ||
(spelling) | |||
trying to type badly | |||
timotimo | i think if you don't null the pointer the GC will get upset | 23:23 | |
samcv | lame | ||
oh | |||
wait. | |||
i mean what if it's null when you supply it to MVMROOT | |||
timotimo | upset as in "dereference a random memory location that might not even be valid" | ||
that should be fine | |||
samcv | ah | ||
geekosaur | you'd be telling gc to move around a block of memory at 0 | ||
samcv | so then what happens inside the MVMROOT if i don't even give it a real memory address | ||
geekosaur | and keep you updated on any such moves | 23:24 | |
timotimo | hm? can you clarify that? | ||
samcv | so how do i MVMROOT a variable that's only sometimes pointing to an actual MVM object | ||
timotimo | have it point at null, or have it point at VMNull | ||
btw, you wouldn't have an MVMROOT around the code that initializes the variable in question | |||
samcv | ok | ||
timotimo | i.e. i'd consider MVMROOT(tc, thing, { thing = MVM_gc_allocate(tc, blah) }); to be wrong | 23:25 | |
samcv | thanks | ||
that's what i thought too | |||
it'd be good if we null'd all our pointers | 23:26 | ||
on declaration | |||
especially ones that ever get passed to MVM ROOT | |||
but all sounds good | |||
ah actually this will be much easier than it was previously. as i've moved around code | 23:27 | ||
\o/ | |||
timotimo | you don't have to use mvmroot btw | ||
you can manually push and pop the temp roots | |||
samcv | oh. | ||
timotimo | you just need to (MVMCollectable **)&the_variable | 23:28 | |
samcv looks at code | |||
ok perfect | |||
lizmat | and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/07/17/...-released/ | ||
samcv | lizmat, you can also add that i greatly reduced the chances of strings needing renormalization on concatenation. and it now only triggers if the resulting string would be different, instead of in cases where it's possible it could become changed. | 23:30 | |
lizmat | is that already in nom ? | 23:31 | |
samcv | yes | ||
i'm working on even more improvements as well though :) | |||
lizmat | "if the resulting string would be different" ?? | ||
isn't that the point of concatenation ? | 23:32 | ||
samcv | the resulting sections i mean | ||
geekosaur | I think it's the normalization not the concatenatiojn | ||
samcv | before it would renormalize both string a and string b | ||
yes geekosaur | |||
geekosaur | "only normalize if it's known to actually need it" | ||
samcv | something like that yeah. before we would renormalize if there was a chance of it needing renormalization (i.e. the normalized result would be different than naively concating them together) | 23:33 | |
and now it only triggers if the result *is actually* going to be different than the current (normalization) | |||
lizmat | "Samantha McVey worked on string concatenation, making sure that no (potentially expensive) normalization of strings is done, unless it is actually necessary." | 23:36 | |
samcv | yes | ||
that is perfect | |||
lizmat | thank you :-) and thank YOU! :-) | ||
samcv | uh you can say that it reduced renormalization of random unicode by over 3x | ||
possibly more depending on the language | |||
at least in my testing on three different scripts. Korean Tibetan and Arabic | 23:37 | ||
i suspect it's actuall very much higher than that over 10x but at least 3x :P | |||
lizmat | I think most of the reader would be interested in knowing it would make appending a newline 3x faster :-) | 23:38 | |
samcv | heh. | ||
but it doesn't :P | |||
lizmat | :-( | ||
samcv | i don't think. i mean | ||
it's probably faster | |||
a little bit at least. but don't say it as i haven't tested | |||
lizmat | ok, well I don't think mentioning Korean, Tibetan or Arabic will help a lot either, so I'm letting it be perfect as it is :-) | 23:39 | |
samcv | ok :) | ||
what you wrote is true. and the user can apply to whatever they *actually* use | 23:40 | ||
because it was getting triggered in many needless circumstances and i can't possibly know all of them heh | |||
concatenation of emoji is faster? hah | 23:41 | ||
but as you wrote is perfect hah | |||
lizmat | ok | ||
on that note, I bid you all a good night! | 23:42 | ||
samcv | lizmat, that fix got in for release. also night! | ||
sleep well |