samcv nice timotimo thanks for the tips :) 00:18
so i'm getting a 2.4x speed boost with this:
my $boy = "\c[BOY]"; for ^100000 { $ = "aa$boy" ~ "\c[ZWJ]" }
that's not even that long a string even 00:19
timotimo nice. 00:20
samcv yeah 2.4 ran again got 2.5x
looks like 4x faster concatting "$boy" and "\c[ZWJ]"
i have to put in a variable or it won't concat each time
timotimo right, it probably does that at compile time or something 00:26
well, optimize time raelly
samcv yep 00:30
timotimo, i want to pop before return and before throwing? 00:31
timotimo yes 00:33
having the temporary root on the stack while the stack frame it belongs to is gone is a very bad idea
samcv yep 00:34
timotimo, whelp. now i get segfault when compiling rakudo 00:50
and failing nqp tests 00:51
well segfault on the tests
i think i figured out what i did wrong though 00:54
timotimo sounds good, then 00:55
i'll hopefully get to bed soon 00:56
01:03 lizmat joined
samcv ok i was running strandcheck before i poped it 01:03
and it was very not happy
01:33 lizmat joined 02:09 jnthn_ joined 02:14 timotimo joined 02:53 evanm joined 02:58 ingy joined 03:22 evanm joined 03:33 lizmat joined
samcv ok my concatenation patch is ready for people to look at it 04:46
Geth_ MoarVM: samcv++ created pull request #615:
Don't re_nfg string a + string b when concatenating in many cases, instead add only the section needing renormalization in as another strand		 04:50
06:09 brrt joined 06:22 domidumont joined 06:29 domidumont joined
brrt good * 06:38
i'll take a look as well if you don't mind samcv 06:40
Geth_ MoarVM/even-moar-jit: c98e59b119 | (Bart Wiegmans)++ | 3 files
Move macros from parser to the expr compiler

The syntax is entirely application-dependent so it doesn't really belong in the parser. In preparation for enabling an 'include:' statement, which should enable reuse of macros.		 06:54
07:01 domidumont joined 07:13 brrt joined
samcv thanks brrt :) 07:30
brrt hmm. i can't say i dare make an assesement 07:36
07:50 zakharyas joined, committable6 joined 07:51 unicodable6 joined, bisectable6 joined, coverable6 joined, quotable6 joined, evalable6 joined, greppable6 joined, bloatable6 joined, benchable6 joined, statisfiable6 joined 07:54 lizmat joined
samcv :P 08:23
jnthn_ can maybe do it
08:40 lizmat joined
jnthn_ morning o/ 08:46
nwc10 good *, * 08:48
jnthn tries to figure out what he can maybe do :) 08:55
Ah, the concat PR
:)
samcv it's ready for review. haven't yet squashed it but 09:00
jnthn Yeah, reviewing it now :) 09:08
09:10 lizmat joined
jnthn Review done :) 09:20
samcv cool 09:25
is MVMROOT ok if i pass it NULL ?
because it's going to be NULL in most cases
tht's why i didn't use MVMROOT
jnthn Yeah 09:26
The MVMROOT macro actually shoves an & in front of its second argument for you
So it's really pushing the address of the variable which just happens to be NULL
(It needs the address so that if there is an object there and GC moves it, then it can update the pointer.) 09:28
Geth_ MoarVM/spesh-worker: 9897b37826 | (Jonathan Worthington)++ | 2 files
Remove spesh candidate logging leftovers.
 09:36
samcv jnthn, well it seems to work 09:45
jnthn The NULL thing? Yeah, we rely on it in various places :)
samcv :) ok 09:46
09:49 domidumont joined
Geth_ MoarVM/spesh-worker: a85ea214a2 | (Jonathan Worthington)++ | src/gc/worklist.h
Add thread ID range check to GC debug mode.

Catches adding to worklist with obviously out of range owner, rather than discovering this later on in the work pass code when we've no idea where the bad memory address came from.		 10:04
MoarVM/spesh-worker: 4632487481 | (Jonathan Worthington)++ | src/spesh/stats.c
Don't dupe-mark the by offset section of stats.
 10:13
samcv jnthn, making a strand_move function and running spectest again 10:17
jnthn samcv++ # nice :) 10:20
samcv all good so far 10:22
valgrind is ok at least 10:25
Geth_ MoarVM/spesh-worker: 024d04a1aa | (Jonathan Worthington)++ | 2 files
Add GC/spesh debug flag to stats/planning stage.
samcv jnthn, ok any other changes needed now? pushed the update 10:26
jnthn Yeah 10:28
renormalized_section = MVM_unicode_codepoints_c_array_to_nfg_string(tc, last_a_first_b, 2);
My comment on that line (that it allocates an MVMString and so may invalidate a and b, which are not rooted at that point) still stands 10:29
10:29 zakharyas joined
samcv so should i move MVMROOT earlier for a and b? 10:44
yeah i saw that
jnthn Well, except then you've got the return problem
I'd just root them around that one line 10:45
samcv ah ok
jnthn Yes, we have to do it again later, but it's not all that costly
Especially given that if we're on that path we're already doing the more costly ne-normalizing
timotimo if we know we've just popped a temporary root and are about to add another, we could totally do an unchecked assignment into the stack since we know it's already big enough 10:46
and save like a hundred cpu cycles every billion trillion cpu cycles
samcv jnthn, do you think it's a good idea to return a new string for string a and string b both being one codepoint 10:50
i guess i can time it easily
jnthn I'd meassure, and see what it adds to the implementation complexity 10:51
Geth_ MoarVM/spesh-worker: cd292bcf05 | (Jonathan Worthington)++ | src/spesh/plan.c
The spesh plan must get its own type tuple copy.

Otherwise we run into memory management problems.		 10:54
MoarVM/spesh-worker: d2c1726e68 | (Jonathan Worthington)++ | 3 files
Create/dump/destory spesh graph per planned spesh
MoarVM/spesh-worker: 797bdc8f4f | (Jonathan Worthington)++ | src/spesh/candidate.c
Optimize graph per plan and dump it out.
 11:02
samcv ok so i get 1.13s instead of 0.87s so slower
though idk how it translates since we have to squash things less? idk 11:03
jnthn goes for lunch 11:05
brrt argh, ffs mscv 11:39
MSVC doesn't take kindly to inline struct declarations it seems
jnthn back 11:50
The joy of MSVC...
brrt okay, so, hmmm
MSVC does accept them in another script... 11:51
egh, script, source file
jnthn ;)
brrt that's odd though 11:52
in an isolated source file, i don't get the same weird error at all 11:57
(MSVC seems to struggle with MVM_VECTOR_DECL(struct { int foo; int bar; }, quam); 11:58
jnthn Hm, darn, just realized that we hold references into the spesh candidates array so I can't grow it as needed without changing that... 12:12
12:14 evanm joined
nwc10 jnthn: I tried building your branch: 12:14
src/spesh/candidate.c: In function ‘MVM_spesh_candidate_add’:
src/spesh/candidate.c:88:18: error: ‘guard_dump’ undeclared (first use in this function) MVM_free(guard_dump);
jnthn nwc10: Yeah, not sure how I managed to commit that 12:15
nwc10 in the rush for lunch?
jnthn Probably :)
samcv sleep & 12:16
jnthn Rest well, samcv
brrt sleep well yes 12:23
(jnthn, the old array+offset trick then?)
jnthn brrt: Yeah, but later :) 12:28
Geth_ MoarVM/spesh-worker: a4234e8641 | (Jonathan Worthington)++ | src/spesh/candidate.c
Code-gen and install planned specializations.

With this, spesh now starts to work again, with other threads able to run the specializations generated by the worker thread. It still only does a single collection/planning run, however, and all of the logged data is not yet being incorporated into the facts yet. OSR will also need to be put back in place.		 12:35
MoarVM/spesh-worker: 3ababe8ffb | (Jonathan Worthington)++ | src/core/frame.c
Remove no longer applicable comment.
jnthn Yes, that means that spesh/JIT are now - at least to a limited degree - done on the worker 12:36
timotimo fantastic 12:39
brrt \o/ 12:40
brrt sips orange juice to celebrate
12:40 lizmat joined
nwc10 so soon MoarVM will be able to utilise both cores of the smartwatch, even for single threaded user code :-) 12:41
jnthn :-)
nwc10 eat that Perl 3
jnthn Perl 4 could use both cores of the smartwatch for single threaded user code already? :) 12:42
timotimo now we can even allow ourselves to spend way more time doing spesh compared to before
Geth_ MoarVM/spesh-worker: f99d66ff9b | (Jonathan Worthington)++ | 3 files
Remove synchronous candidate production from OSR.

This re-works the OSR code in preparation for it obtaining specialized code produced by the worker thread. The installation code remains as it was, though it's easier now as we don't have to do a logging and then a final installation. The polling for a result will come later; this just removes OSR's calls to the previous specialization handling.		 12:51
nwc10 jnthn: (at the previous commit in MoarVM) was it supposed to SEGV whilst compiling the setting?
jnthn No, though I only tried the NQP test suite so far 12:52
nwc10 ah OK
also, I'm failing to figure out a witty response to the Perl 4 question.
jnthn "It was a marketting release, so it only had to sound good?" :P
(If I'm remembering my history correctly, anyways... :)) 12:53
nwc10 that was the only topic that seemed to have any traction
(because it was/you are - the version number was bumped for the book)
Geth_ MoarVM/spesh-worker: 8087af0534 | (Jonathan Worthington)++ | 2 files
Remove synchronous spesh setup/finalize code.
 12:55
MoarVM/spesh-worker: 10db2b0c4b | (Jonathan Worthington)++ | 5 files
Candidates no longer hold a spesh graph.

This was only needed thanks to the graph surviving for some time while we did spesh logging. Now logging is done differently, this is no longer needed.		 13:01
jnthn Always nice when a new design removes checks from a hot path
jnthn tries a Rakudo build with HEAD to see what happens 13:02
SEGV
nwc10 mine was this paste.scsys.co.uk/564630
but that's from MoarVM about 3 commits back 13:03
with
+#define MVM_ARRAY_CONC_DEBUG 1
+#define FSA_SIZE_DEBUG 1
because I like pain
jnthn Ah 13:04
I think it's 'cus we now won't always have a type tuple
But the args code still assumes we will
13:11 robertle joined
Geth_ MoarVM/spesh-worker: 017751504a | (Jonathan Worthington)++ | src/spesh/args.c
Make args spesh cope with no type information.

This happens when we are producing certain specializations (which do not use logged types) - something that could not happen before the recent spesh changes.		 13:16
MoarVM/spesh-worker: e8fe33e486 | (Jonathan Worthington)++ | src/spesh/args.c
Remove lonely comment; tweak another.
MoarVM/spesh-worker: 2ce14767d5 | (Jonathan Worthington)++ | src/spesh/arg_guard.c
Support arg guards for certain specialization.

By allowing a type not to be provided. This will need some further work, since we want to treat this as a fallback, meaning we need to further tweak the tree. For now, it unbusts things.		 13:25
jnthn That gets Rakudo building again for me.
Though seems some spectests aren't happy 13:26
oh, it's about the thing that's next in my todo list anyway :) 13:28
nwc10 "drink tea" ?
jnthn No, more like "don't produce specializations we already did produce 13:29
brrt (on my to do list; make even-moar-jit compile under msvc; support include: statement for expr tree compiler, validate types for expr tree templates, validate types for tiles) 13:31
jnthn Ah, though turns out that right now I'm meant to go take some documents to $lawyer so she can watch me sign them, which apparently imbues my signature with magical properties. :)
++brrt :)
brrt good luck with the magic 13:32
jnthn bbiab
nwc10 good luck with forging your own signature
(I'm not very good at doing mine reliably) 13:33
dogbert17 Tried the spesh-worker branch. Building MoarVM went well as did building Rakudo. The install step, i.e. 'make install' failed with the message 'MoarVM panic: Spesh arg guard: trying to add duplicate result for same guard' 14:02
14:13 zakharyas joined 14:48 brrt joined
jnthn back 14:50
dogbert17: Yup, that's 'cus the planner doesn't check if it's already done the work yet :) 14:51
dogbert17 cool, so it's not quite in a testable condition currently then? 14:52
jnthn No, not really 14:54
Though it turns out you can only really trip over the missing piece when the program runs multiple threads. 14:57
Which is why so much works despite something so important being missing. :)
15:05 brrt joined
brrt in msvc's defense, it did find actual bugs 15:14
or at least, things that obviously weren't correct
in nmake-s undefence, it doesn't understand inference rules 15:19
which explains why these weren't used
15:20 brrt joined
brrt srsly though... 15:23
mst nmake is fucking terrible 15:24
lots of people seem to've decided they prefer dmake on win32
I don't do enough win32 to have an informed opinion
brrt nmake is a disaster 15:32
jnthn It is, alas, what's in the Win32 SDK 15:34
brrt … hmmm
15:44 zakharyas joined
brrt so, that takes some dumbing down of the makefile 15:52
but i can eventually get it to build
Geth_ MoarVM/spesh-worker: 8e6f7b81d1 | (Jonathan Worthington)++ | src/spesh/arg_guard.c
Add missing `static` markers.
 15:53
jnthn bah, it forgot about one commit :P 15:54
github.com/MoarVM/MoarVM/commit/51...4da60e8cc8 fwiw
Geth_ MoarVM/spesh-worker: 8cc5c26ee7 | (Jonathan Worthington)++ | 6 files
Enable collection of spesh log data over time.

This establishes a kind of quota mechanism so that we can fill up to 3 (by default) buffers of log data per thread. The thread sending will decrement the quota when it sends a buffer. Once the spesh worker has processed a buffer, it increments the quota again. This limits the amount of logged data around at the same time, but allows us to keep accumulating data and doing more specialization over time.		 16:34
jnthn This also utterly busts things because it makes almost certain we run into the guard tree bug, but I ain't got the energy to hunt that one down today. So, tomorrow. 16:35
17:01 domidumont joined 17:16 zakharyas joined 17:24 statisfiable6 joined 18:20 domidumont joined 18:40 deep-book-gk_ joined 18:42 deep-book-gk_ left 19:07 domidumont joined 19:10 lizmat joined 19:13 zakharyas joined 19:39 hoelzro joined 19:40 lizmat joined 20:40 lizmat joined 21:10 lizmat joined 21:59 lizmat joined
samcv good * 22:33
yoleaux 18:44Z <AlexDaniel> samcv: Any chance you have a quick answer for github.com/perl6/whateverable/issues/167 ? Unicodable adds ◌ for combiners, but how can I easily know if ◌ should be prepended? Like, is there some property or something? Or is there any other check I can perform? Like “(“◌” ~ $x).chars == 1” or something?
22:40 unicodable6 joined 23:29 lizmat joined 23:54 MasterDuke 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!