01:04 FROGGS_ joined
dalek arVM: 39c0a4d | jimmy++ | src/6model/ (5 files):
Removed [read|write]_int[16|32] code from serialization
 01:34
01:41 xiaomiao joined 01:52 btyler joined 06:55 zakharyas joined 07:03 FROGGS joined 07:45 brrt joined
nwc10 jnthn: will you have time at some point soon to sketch out your idea on how struct { MVMint32 sc_idx; MVMint32 idx; } might be got down to a single thing? 08:02
IIRC you thought it was possible, but more fiddly what you did to get to O(1)
timotimo O(1)? i thought this was O(n) now? 08:21
nwc10 Maybe I'm wrong 08:22
jnthn improved it from O(bad) to O(better)
I'd like to stick at O(better) and use less RAM
jnthn Well, what we need to be able to do is take an object and do a lookup of what SC it's in and that index in the SC it lives at during serialization and code-gen. 08:34
The O(n) was doing a linear search in the SC to find the index 08:36
O(1) could be achieved by a hash table, but objects can move...
nwc10 OK. Hmm. One crunchy way would be to burn another header flag, and for 32-bit platforms make the offsets 16 bit, and if either overflows, instead flag that we have a pointer to an 8 byte structure with the real thing 08:39
I'm running an optimised build on the Pi with the Object header padded to 8 byte alignmet to get a feel for the slowdown versus the old header size
I have no idea if it's better or worse, as I was doing debugging builds, and they stink (or rattle) 08:40
in that Webit blog, llvm.experimental.patchpoint looks a bit crazy, and llvm.experimental.stackmap really crazy 08:44
jnthn gate & 08:52
10:29 woolfy left 10:57 odc left, odc joined 11:04 brrt joined 11:39 brrt left 11:43 FROGGS joined 13:50 btyler joined 14:05 FROGGS joined 14:32 FROGGS joined 14:48 FROGGS joined 16:33 odc joined 17:38 woolfy joined
nwc10 jnthn: on x86 linux, Stage parse and Stage mast are both about 10% slower if I hack MVMObject to be 1 pointer larger 17:39
which makes me think that going the other way, shaving 4 bytes, will be a win just from better cache use 17:40
jnthn ah 17:43
well 17:44
and also we will be chewing through the trhingy faster
uh
the nursery
nwc10 anyway, unless anyone has a better plan for a structure, I was going to explore the idea of a flag, and either two 16 bit indexes or a pointer to an allocated bigger thing 17:45
jnthn That could work. 17:46
nwc10 but not guaranteed to be tonight
jnthn *nod*
nwc10 it's annoying that it uses another flag bit
jnthn Also, worse, the patches I did so far seem to break stuff :(
nwc10 well, ARM, certainly.
32 bit Win32 also unhappy? 17:47
PPC64 seems to be unrelated
jnthn No, folks on Linux even see it, building Panda 17:48
And I reproduced it on my Linux VM last night at home too
nwc10 Oh, OK, hmmm
18:07 isBEKaml joined
isBEKaml Hi, is Moar known *not* to build on cygwin? 18:08
FROGGS not sure... 18:09
nwc10 if libuv doesn't support MoarVM, then that's the blocker
isBEKaml let me paste something - it seems to be fialing with libuv.
pastebin.com/0YLXbhuL 18:10
FROGGS isBEKaml: read the comment from tjfontaine: github.com/joyent/libuv/issues/845 18:14
isBEKaml FROGGS: that's sad. What's the version of libuv included in MoarVM? 18:20
I do have msys installed here - though I use it rarely. Let me see if I can make it build.
FROGGS isBEKaml: v0.11.19 18:21
this revision: github.com/joyent/libuv/commits/666aa2f
isBEKaml FROGGS: thanks - It's a bit late in here. I'll figure something out tomorrow. Thanks again! 18:34
FROGGS k :o)
isBEKaml :-) 18:35
nwc10 jnthn: highest numer of SCs seems to be 149 19:55
highest index within an SC is 150230
20:35 john3213 joined 20:40 john3213 left
timotimo that's not even a small number 21:36
jnthn Well, it's likely CORE.setting. 21:51
mmmm...I have a Polish stout 21:53
21:58 woolfy joined 22:33 cognominal joined
[Coke] jnthn: BEER! 22:44
I like the way you think.
[Coke] wanders off to beer.
23:24 woolfy left

Powered by Cro and the Raku® Programming Language.

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

Thank you!