Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:03 reportable6 left 01:04 reportable6 joined 02:04 linkable6 left, evalable6 left 02:05 linkable6 joined 02:06 evalable6 joined 04:44 linkable6 left, evalable6 left 04:47 linkable6 joined 05:46 evalable6 joined 06:04 reportable6 left 06:06 reportable6 joined
Nicholas good *, #moarvm 07:53
jnthnwrthngtn: *NQP* build failure? For me NQP is fine. Rakudo 6.c setting goes boom with "Language revision must be a concrete string" 07:54
and did on the previous commit, IIRC
nine jnthnwrthngtn: if you're seeing "Attribute '$!result_reg' not declared" as well, that seems to be caused by inlining gen/moar/stage2/NQP.nqp:546 (pkg_add_attribute) into variable_declarator 08:20
Or method new of QAST::Stmts, that's also inlined with unspecialized inlining active. 08:42
MasterDuke nine: do you have any thoughts re making ex_release_mutex an array vs passing the particular mutex down to where the exeption is thrown vs something better? 08:44
nine I hope we can come up with something better. Alas yesterday evening my creativity was sapped by a 3 course dinner 08:48
lizmat
.oO( the horror! )
 08:50
08:59 linkable6 left, evalable6 left 09:01 evalable6 joined 09:32 patrickb joined
jnthnwrthngtn moarning o/ 09:43
Nicholas \o
jnthnwrthngtn Nicholas: It doesn't break because the lines that break it are communt out
Nicholas ah OK
so, for me, setting build failed. With all the MVM ENV stuff set
I'm a bit busy with $other so wasn't digging hard 09:44
jnthnwrthngtn nine: Yes, exactly that, and I'd got it to variable declarator too, but it looked about right in the spesh log
10:00 linkable6 joined
nine Yeah, haven't found anything obvious either 10:03
10:30 sena_kun joined
nine jnthnwrthngtn: one thing I do find odd. The inline log says that it inlines unspecialized pkg_add_attribute and unspecialized new but both inlined graphs do look specialized. There are a lot of sp_ ops in both 10:33
Ah, because it gets optimized after picking 10:35
jnthnwrthngtn Yes, what it should really say is it wasn't specialized before we came to trying to inline it 10:44
nine Well it's definitely inlining of pkg_add_attribute, not of method new that's causing it 10:46
Oh, one more thing: in pkg_add_attribute, there are 2 calls. The second one is sp_dispatch_v lits(lang-meth-call), callsite(0x24f4d10, 5 arg, 5 pos, nonflattening, interned), sslot(0), litui32(3), r8(2), r7(2), r6(5), r1(2), r5(2) 10:47
jnthnwrthngtn OK, that's more than I knew. (I've got a few other things to work on this morning, so I'm not actively looking into it yet. Thanks for doing so.)
Yeah, I didn't figure out if it somehow passes along the wrong name for the attribute or some such 10:48
nine The r6(5) argument is sslot(1) which is an NQPClassHOW in the inlined graph. The inlined version passes r110(5) there which is sslot(59) which is Instance (NQPRoutine) 10:49
Are we picking the wrong spesh slot here?
jnthnwrthngtn Oh. This sounds ungood.
nine Actually no spesh slot of the resulting graph at all holds an NQPClassHOW 10:50
jnthnwrthngtn o.O
Then something is very wrong
I just...can't imagine where/how/why right away 10:51
nine Also no register fact talks about NQPClassHOW despite the inlinee having 2 registers with known values of type NQPClassHOW
All the more curious since AFAICT you didn't change anything about inlining mechanics like merging of spesh slots or renumbering of registers 10:52
jnthnwrthngtn No, exactly 10:53
oh, oops 10:54
This doesn't explain things too well but
It seems that I forgot to stack up the guards ahead of the inline 10:55
That does seem to fix it 10:58
nine \o/ 10:59
jnthnwrthngtn (I forgot because a) late, but b) I restructured the optimization process so that we don't insert guards if we can't actually do an optimization, which we would in the previous impl, but the previous one was a bit fiddly to do the re-org)
Sorry for the wild goose chase. Although tbh I still don't understand why the problem caused the symptoms you saw 11:00
nine Both calls in pkg_add_attribute have the comment # [000] Never dispatched 11:01
Could it be that those new guards actually prevent the faulty code from running? 11:02
jnthnwrthngtn I think it's a lie.
Though let me check 11:03
Yeah, it's a very dubious claim indeed. 11:04
When we produce the specialization like this, we don't have any stats to hand
And it doesn't differentiate that from "we have stats and they're all zero" 11:05
nine Ah, of course, that makes sense 11:06
With that fixed we're now at <43s for stage parse 11:08
Geth MoarVM/new-disp: 2ecb380497 | (Jonathan Worthington)++ | src/spesh/optimize.c
Fix and re-enable inlining without specialization

It didn't work because the guards weren't added; d'oh.
MoarVM/new-disp: f08c7f9332 | (Jonathan Worthington)++ | src/spesh/disp.c
Less confusing spesh comment when no stats
jnthnwrthngtn nine: What did you have before this? 11:09
And what is master's time on your machine? 11:10
nine Got between 43 and 44s before this. master's at 34 11:11
jnthnwrthngtn Getting closer :) 11:12
We don't have JIT re-enabled yet
And there's not a good solution for the megamorphic exploision in !protoregex yet 11:13
And I've not even looked at new-disp under the eye of callgrind yet
And - though it's probably a drop in the ocean - we've still got branching all over the place for legacy vs. new calling convs
(About JIT: not re-enabled in so far as we don't yet JIT any of sp_dispatch, sp_runbytecode, nor sp_runcfunc) 11:14
(Which will limit many things)
sena_kun has started Blin for new-disp 11:15
jnthnwrthngtn Cool, hopefully callwith being present will help some of them
sena_kun btw, is it known the spectest hangs as bug-coverage.t hangs? 11:16
jnthnwrthngtn Yes 11:17
It's a code-gen bug that exists on master 11:19
sena_kun yup, heard about it, though maybe was fixed already, thanks for the info 11:20
jnthnwrthngtn But on master we get "lucky" and it doesn't result in an infinite loop
Nicholas And we now have to distract timo's cat long enough for timo to implement some JIT? 11:37
jnthnwrthngtn That'd be one approach. :) I'm quite sure most people would choose petting a cat over writing x64 assembly. 11:44
lizmat aahh...the days when I was able to write 8086 machine code using integers only :-) 11:52
(1986-1993 abouts)
the language in question had a Buf like data structure that you just could tell it to run it on the processor 11:53
MasterDuke you had integers! back in my day we only had natural numbers 11:55
jnthnwrthngtn I got the idea to run callgrind on the CORE.setting build while I had lunch. Lunch is finished. It's still running. 11:56
In stage optimize, mind
Nicholas clealy you need one of those 3-course lunches 11:57
jnthnwrthngtn Only 1 more week until vacation, and then I'll at least get 4 course dinners... :) 11:58
MasterDuke i'm currently waiting for pypandoc to convert a bunch of files from .md to .rst. it takes about 50m for ~140 files totaling ~115kb
i have no idea how it can be this slow
jnthnwrthngtn Wow
I think I could get a decent way through the job by hand in that time :P
MasterDuke i did seriously consider it 11:59
Nicholas is there a pypypandoc that goes much faster once the JIT is done?
MasterDuke ha. i've never actually used pypy. i assume it runs on windows? 12:01
12:02 reportable6 left 12:05 reportable6 joined
Geth MoarVM/new-disp: 134ed518ed | (Stefan Seifert)++ | src/jit/x64/tiles.dasc
Support loading values from int16 arrays in expr JIT
 12:07
MoarVM/new-disp: c54d49adc1 | (Stefan Seifert)++ | 2 files
Expr JIT templates for sp_getarg_* ops
nine That was quite a bit harder than expected... 12:08
jnthnwrthngtn nine++ 12:09
Are you looking at the lego JIT of sp_dispatch and friends?
(If not, I was just about to.) 12:10
nine Well I'm getting reaquainted with JITing things by doing the seemingly simple ones first :) 12:11
Geth MoarVM/new-disp: 91e5b144d9 | (Jonathan Worthington)++ | src/jit/graph.c
Throw out dead code
 12:14
sena_kun ⏳ 1569 out of 1676 modules processed 12:20
the rest are fighting over a small number of alive builds, but we can already get some stats out of it
the callsame ones are gone (yay!), though there are now some with :CallsameIsNotInTheDynamicScope and some with :NextsameIsNotInTheDynamicScope. 12:21
nine jnthnwrthngtn: is it me, or will JITing dispatch be much easier than invoke?
jnthnwrthngtn nine: I think quite a lot easier, especially as it's one instruction 12:24
nine: The part I'm currently trying to figure out is where to store the argument maps
ah cool, maybe in a data section 12:25
nine well it is data after all :) 12:26
Good thing we have extops, since it looks like that's what we have support for data sections in the lego JIT for 12:28
jnthnwrthngtn Yes!
I was just looking at that 12:29
sena_kun MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer when trying to install Prometheus::Client 12:34
jnthnwrthngtn nine: If you're interested to work on JIT of those, I'd happily look at something else instead. 12:38
i mean, I can do it, it's just not...very fun...for me :)
It seems runbytecode and runcfunc will be the easier of the two 12:40
nine jnthnwrthngtn: sure, I'd be happy to give it a go. Will try runcfunc first as that comes first in the spesh logs I'm looking at. 12:41
jnthnwrthngtn OK, thanks 12:42
For the data segment, I think the stuff to stick in there is just going over the applicable operands and pulling out the 16-bit .reg.orig 12:43
nine Of course with runcfunc and runbytecode the interesting part starts at how to actually pass that MVMArgs struct by value 12:52
If the size of the aggregate exceeds two eightbytes and the first eight- 12:55
byte isn’t SSE or any other eightbyte isn’t SSEUP, the whole argument
is passed in memory.
So I think it's passed in memory and not split up into registers 12:56
Nicholas structs by value - dyncall *that*!
jnthnwrthngtn Sigh, and it may be different on Windows too 12:58
Maybe we should make MVM_frame_dispatch a wrapper that unpacks and passes on the components to a real underlying impl 12:59
And maybe make the wrapper a static inline, to make sure it doesn't ever really make two levels of call
nine Windows: "Structs or unions of other sizes are passed as a pointer to memory allocated by the caller. For these aggregate types passed as a pointer, including __m128, the caller-allocated temporary memory must be 16-byte aligned."
At least for a first version, having a wrapper that puts the individual values into a stack allocated would get us off the ground 13:01
jnthnwrthngtn Yeah, I'd do that 13:02
MasterDuke there are some existing moarvm (or maybe nativecall) issues about passing structs by value (requesting that i think) 13:04
jnthnwrthngtn Just been looking over the callgrind output. The interpreter is the top thing by far so more JIT will help
The second is running dispatch programs. A better solution for megamorphic things will no doubt help a lot. 13:05
MasterDuke just did a new-disp build. stage parse of 56s vs 44s for master 13:09
jnthnwrthngtn Another task for those looking to help with speed: MVM_disp_program_run can make use of computed goto when available. 13:10
See interp.c for inspiration
It's the second most hot thing after the interpreter itself, so likely worth doing 13:11
nine MasterDuke: it's kinda impossible to pass a struct by value in NativeCall, but the show stopper there is there's no way to specify a struct as a value in the first place. We interpret MyStruct as Pointer[MyStruct]. That's in the vast majority of cases what you want, but not in all of them
MasterDuke jnthnwrthngtn: i suspect this is no different than what you have, but this is what perf has to say about building CORE.c gist.github.com/MasterDuke17/e7fe2...c904cd0e3a 13:13
jnthnwrthngtn MasterDuke: Those are exclusive times? 13:16
MasterDuke yeah
`perf report --call-graph=none --no-children`
i added just a plain `perf report` to the gist 13:17
13:22 [Coke]_ joined
timo 1% on interning callsites, that's curious 13:24
jnthnwrthngtn Dispatch programs are pretty into those, but yeah, it's a new hotspot I suspect 13:25
Maybe worth looking at
Trying to figure out a good design for the megamorphic situation 13:26
I guess I'll just do it with resumption in the first pass and then we'll see
How well we can opt that
MasterDuke timo: github.com/MoarVM/MoarVM/blob/new-...#L210-L217 here's an opt for you 13:30
13:34 [Coke] left
timo i wonder how often that flag is set that's checked on the inner side 13:57
"force" 13:58
also, i wonder how big that storage tends to become for each of the arities 14:00
and what percentage has named argument strings in them at all, but probably the vast majority 14:01
Nicholas jnthnwrthngtn: seems that MVM_SPESH_NODELAY=1 breaks the Rakudo setting build. 14:11
sena_kun ~80 out of 1676 modules (that's the upper estimate) modules have some issues with new-disp. 14:12
jnthnwrthngtn That's quite a lot less than last time, I think? 14:13
sena_kun I don't remember the exact previous number, alas, but it's smaller, yes. 14:15
The pool of failures is similar, though.
The callwith is replaced with a smaller number of "not in the dynamic scope" for callwith/nextwith, the rest are similar: issues with type checks (bind, param), too many/little params etc (not surprising). 14:17
if anyone fancies some spesh there is a "unhandled case of return_o" 14:18
jnthnwrthngtn Ah, those are because we don't yet do subsignature-based multiple dispatch
Nicholas " MVM_str_hash_fetch_nocheck called with a stale hashtable pointer" implies a bug in concurrent code, where 2+ threads are accessing the same hash without locking it 14:19
MasterDuke sena_kun: btw, looks like the bump was one behind 2ecb380497, which was a fix
sena_kun MasterDuke, a fix for? return_o?
MasterDuke some problem with spesh inlining 14:20
jnthnwrthngtn Nicholas: I suspect that will be for debugging next week
Geth MoarVM/new-disp: 8ec4f60215 | (Jonathan Worthington)++ | 5 files
Provide introspection to identify megamorpism
 14:25
jnthnwrthngtn sigh, spelling 14:26
Geth MoarVM/new-disp: 1d70be9a63 | (Jonathan Worthington)++ | 5 files
Provide introspection to identify megamorphism
nine Writing assembly: fun. Debugging assembly: ... 14:44
jnthnwrthngtn painful 14:47
MasterDuke but hey, your recent jit work might mean you're another person besides brrt to help with gist.github.com/MasterDuke17/6529d...363b16b392 (adding new shl/shr operators) 14:50
nine Ooooh...looks like we're at least calling something. Possibly even the correct function (just with wrong args). Progress! 14:58
jnthnwrthngtn Yay 15:04
Meanwhile, I'm making progress on letting us stick a lookup table into a dispatch program for handling megamorphic by method name sites
dogbert17 MoarVM oops in spesh thread: Spesh inline: unhandled case of return_o 15:05
MasterDuke what do you mean megamorphic by method name? i thought a callsite was always just for one method, it'd just be the num+types of the invocant+args that'd differ? 15:06
sena_kun dogbert17, where? We have such one in the last Blin run, if there is a golf that's cool. 15:07
jnthnwrthngtn MasterDuke: $obj."$name"() 15:08
dogbert17 It's from one of the spectests
MasterDuke ah 15:09
jnthnwrthngtn !protoregex does exactly that
We thus end up stacking a HUGE load of disaptch programs there
Up to the max of 64 entries, and then we try all 64 linearly... :)
And 64 is still way too many
dogbert17 e.g. t/spec/S32-str/sprintf.t, note that I ran with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1
I've also seen: 'Internal error: inconsistent bind result' 15:10
MasterDuke runbytecode_ins->info->opcode always seems to be 921 in those cases. i also saw a `===SORRY!=== 15:17
Cannot find method 'push_code_object' on object of type Perl6::World` when i ran without the BLOCKING
i think 921 is MVM_OP_sp_runbytecode_s 15:20
timo runbytecode_ins->info->name should say that 15:24
but there's also a #define you should be able to find by searching for the number 15:25
that is runbytecode_s indeed
MasterDuke cargo-culting from rewrite_str_return, just adding `case MVM_OP_sp_runbytecode_s` right above `case MVM_OP_sp_runbytecode_o:` seems to work 15:26
well, is rakudo's `make m-test` supposed to be ok now? 15:27
jnthnwrthngtn MasterDuke: One failure 15:45
So the good news is that the ability to do a method lookup table deals nicely with the !protoregex situation 15:46
MasterDuke ok, i still see that one failure in test, but there are also a bunch in spectest 15:47
jnthnwrthngtn The bad news is that we get a lovely blow-up around the new/bless transition, although I note NQP lacks the obvious opt that Rakudo enjoys and could really cheat a bit more
MasterDuke blow-up == failure? or another megamorphic case? 15:50
jnthnwrthngtn The latter
MasterDuke ah
i see a bunch of the same fails in a spectest without my change, so maybe it is valid 15:51
Geth MoarVM/new-disp: 6da8ac9b1c | (Jonathan Worthington)++ | 3 files
Provide lookup tables in dispatch programs

So that a callsite that is megamorphic in method names is able to install a lookup table, guard on the type, and then enjoy O(1) lookup at that location.
MasterDuke jnthnwrthngtn: is adding MVM_OP_sp_runbytecode_s to this case github.com/MoarVM/MoarVM/blob/new-...ne.c#L1125 correct? 15:52
nine Turns out it's just not possible to load a 64 bit constant into a register directly 16:00
timo oh, you always have to load lower and upper separately? 16:01
jnthnwrthngtn nine: mov64 16:04
Geth MoarVM: MasterDuke17++ created pull request #1524:
Handle sp_runbytecode_s like *_o in rewrite_obj_return		 16:07
jnthnwrthngtn MasterDuke: Well, it's correct to add that case, but it needs to insert an unbox
You can't just put a `set`, otherwise probably things go quite badly later 16:08
nine jnthnwrthngtn: mov64 doesn't seem to work on immediates 16:09
MasterDuke huh. the comment for return_to_set says '...doing any needed boxing or unboxing"
nine From what I read on the internets, it should be possible. But I can't get it to work. It always only reads the lower 32 bits and sign extends. Which is not that useful for addresses 16:10
jnthnwrthngtn nine: Hm, curious, I see stuff like `| mov64 TMP6, arg.v.lit_i64;`
MasterDuke: I think the comment is about the whole bunch of functions that follow 16:11
nine Ah darn...yes, mov64 does work. But the compiler only allows reading ints, not pointers 16:12
jnthnwrthngtn Ah, so it needs a cast to MVMuint64 maybe?
nine yes 16:13
MasterDuke ah. so a `return_to_unbox` needs to be added and used?
timo this is for the callsites that we pretend are numbers but really are pointers?
jnthnwrthngtn MasterDuke: Yes but I'm a bit curious why we didn't really need this before...
A bit more time off the CORE.setting build thanks to doing better at, or having less, megamorphic points. 16:24
All those that remain are about flattening, which is going to need some thought
nine timo: yes
timo i wonder if during one spesh run we see the same callsite a whole bunch of times and can be smarter about interning? or are the intern attempts coming from somewhere else? 16:26
the interned callsites are already stored in multiple areas based on what arity they have, so i'm guessing that's already relatively quick 16:28
jnthnwrthngtn timo: Very likely the majority of them happen during the recording of dispatch programs 16:30
Well, notably, when we finish the dispatch program
MasterDuke what would the `target_facts->type` be for the unbox case?
jnthnwrthngtn MasterDuke: It's an unboxed value, so it doesn't have a type (it's a native implied in the register) 16:31
timo: One thing I considered before but didn't do was a means - for small callsites with only positions - is to keep some kind of data structure for handling transforms 16:32
*positionals 16:33
timo: Since we do a lot of callsite transforms. That would mean we could finish up with an already interned one in many situations at the end of recording a dispatch program
MasterDuke oh, master doesn't have a return_to_unbox either... 16:40
timo ah, so like we'd intern at the start and have a lookup structure that immediately gets us from one interned callsite to the interned callsite that results from the same transformation
kind of like the "with_invocant" pointer
nine All I need now is that argument map
jnthnwrthngtn timo: yeah, although it'd be nice if it's not "inside" the callsite 16:45
timo yes 16:46
Geth MoarVM/new-disp: a292856744 | (Jonathan Worthington)++ | src/6model/sc.c
Optimize MVM_sc_find_code_idx

The indirection shows up relatively high in a profile of a CORE.setting build.		 16:48
jnthnwrthngtn Hm, I wonder why we bother interning all these intermediate callsites 16:54
I'm pretty sure that's pointless makework
Since it's only really result ones that end up in dispatch programs that need to be interned 16:55
For those made while we're working on the dispatch it doesn't matter at all
So I think we can just not do most of this work at all
Rather than trying fancy opts :)
nine Huh.... I got the map in the data section and it looks ok. I get register number 14 for arg 0 which looks sensible. However an object like the one we're looking for is actually in register 15 16:56
And since we're looking for an iterator, that's probably the one we need
I wonder how I can get that kind of off-by-one error here. gist.github.com/niner/f566f86fc525...92cbca20f9 16:58
Geth MoarVM/new-disp: 84a5c1c3a8 | (Jonathan Worthington)++ | src/core/callsite.c
Don't do lots of throwaway callsite interning

We don't need the intermediate ones interned, and the places that do need it already make sure it's the case.		 16:59
jnthnwrthngtn nine: |.word (MVMuint16)runcode->map[i].lit_ui16; 17:01
I think that should be
|.word (MVMuint16)runcode->map[i].reg.orig
| mov FRAME:TMP5->cur_args_callsite, TMP6; 17:02
And cur_args_callsite isn't needed under the new calling convs
So that instruction can go away
nine Indeed! 17:03
Geth MoarVM/new-disp: b61e45a4fa | (Stefan Seifert)++ | 5 files
First JIT support for sp_runcfunc_i

Won't work on Windows yet as it's using POSIX calling conventions.		 17:13
sena_kun no idea if this info is interesting, but stage parse time increased (sic) for 1s on average for me with the "don't do lots of throwaway" commit. 17:14
nine The other runcfunc and runbyte ops should be fairly trivial now as they hardly differ from runfunc_i :) 17:15
Alas, gotta prepare dinner
sp_dispatch isn't that far off either 17:16
jnthnwrthngtn sena_kun: That's...weird 17:17
Is it really more than noise?
I'll have to look at another callgrind output after these tweaks, maybe that'll reveal something
I'm easily getting ~1s variance build to build, fwiw 17:18
sena_kun yes, pretty much. I did 2 runs for each without any load, the two without the commit are 42.030 and 42.607, while after the commit it becomes 43.429 and 43.134.
maybe just the noise, never mind it then
Geth MoarVM/new-disp: 1b3fe9f209 | (Jonathan Worthington)++ | src/core/args.c
Optimize arg processing handling

  * We know there's no flattening at this point in the new calling
   conventions, so do a cheaper calculation of the number of named
   arguments
  * No need to zero out something we'll never look at again		 17:20
jnthnwrthngtn OK, enough for now 17:48
Home time for me
o/
17:52 sena_kun left
MasterDuke nine: `src/jit/compile.c:101:13: warning: implicit declaration of function ‘MVM_jit_emit_runcode’; did you mean ‘MVM_jit_emit_invoke’? [-Wimplicit-function-declaration]` 17:54
18:02 reportable6 left 18:05 reportable6 joined 18:29 [Coke]_ is now known as [Coke]
Geth MoarVM/new-disp: 2193a6506e | (Stefan Seifert)++ | src/jit/internal.h
Add missing forward declaration of MVM_jit_emit_runcode

  MasterDuke++ for the heads up		 18:38
MoarVM/new-disp: a3c5efb5d2 | (Stefan Seifert)++ | src/jit/graph.c
Extend JITing to other sp_runcfunc_ variants
 18:50
MoarVM/new-disp: af8eae171f | (Stefan Seifert)++ | src/jit/x64/emit.dasc
Hopefully fix MVM_jit_emit_runcode on Windows

Windows requires structs and other aggregates to be put into caller allocated memory and a pointer to this memory passed as an ordinary argument. On POSIX we put the struct's fields individually onto the stack. Since the stack is memory and as such guaranteed to be available until the caller exits, we can use it for Windows as well. So all that should be needed is that pointer.
Completely untested, as I don't have Windows available.		 18:57
MasterDuke hm, for return_to_unbox, since we don't need to look up the type, we don't need to add the unbox, we can just overwrite the return, correct? 19:02
i.e., return_to_box == return -> type lookup + box, but return_to_unbox == return -> unbox 19:04
Geth MoarVM/new-disp: af79f12518 | (Stefan Seifert)++ | 6 files
JIT support for sp_runbytecode_*
 19:40
MoarVM/new-disp: f597e4053c | (Stefan Seifert)++ | 6 files
JIT support for sp_runbytecode_*
 19:44
20:29 linkable6 left, evalable6 left 20:31 linkable6 joined
jnthnwrthngtn nine++ 21:00
MasterDuke: yes 21:03
It should be like the set code, except emitting an unbox 21:04
MasterDuke jnthnwrthngtn: thanks, github.com/MoarVM/MoarVM/pull/1524 updated 21:35
no longer get the oops in t/spec/S32-str/sprintf.t. same fail in m-test, looks like same other fails in m-spectest 21:36
21:39 patrickb left
jnthnwrthngtn Cool 22:19
[Coke] Do we need a windows canary for new-disp? 22:26
jnthnwrthngtn Could be useful info. At some point CI will tell us I guess. 22:27
Curiously, the JITting ends up slower so far as wallclock goes; I'm doing some measurements with callgrind to see if there's any clues
[Coke] I can try to do a build, will report back. 22:29
jnthnwrthngtn Where "doing measurements" mostly means doing other things while callgrind runs for a long while :)
23:30 evalable6 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!