00:29 committable6 joined 00:30 coverable6 joined, bloatable6 joined, releasable6 joined, bisectable6 joined, nativecallable6 joined 01:06 nwc10 joined 01:10 bloatable6 joined, unicodable6 joined, quotable6 joined, evalable6 joined, committable6 joined, benchable6 joined, bisectable6 joined, releasable6 joined, greppable6 joined, nativecallable6 joined, squashable6 joined, statisfiable6 joined 01:11 coverable6 joined 01:56 ilbot3 joined
MasterDuke i just now realized the value inlined into MVMP6bigintBody is only 32bits (i'm assuming because we have 64bits to work with, and that's the largest single type less than 64) 02:47
and then the other 32bits is used as a flag 02:48
would it be worth the trouble to break it down further, e.g., make it a 32bit + 16bit value and a 16bit flag? 02:49
so we get more possible values inlined, but the code the get/set them is more complex 02:50
03:25 solarbunny joined 03:27 AlexDaniel joined 05:39 domidumont joined 05:46 domidumont joined 06:06 brrt joined
brrt good * #moarvm 06:06
MasterDuke: i feel like, ironically, there is not going to be a lot of values that are between 2^32-1 and 2^48-1 that are actually going to be used 06:16
so you'd a huge amount of complexity for relatively little benefit 06:17
06:37 domidumont joined 07:12 brrt joined 07:18 zakharyas joined
samcv good * brrt 07:50
brrt good hi samcv 07:52
samcv :-)
07:53 HTTP_____GK1wmSU joined, leont joined
brrt i was writing up the documentation for the register allocator recently. did you know i implemented two versions before the current one? 07:57
07:59 zakharyas joined
samcv no i didn't 08:09
did those help you write the current iteration?
08:20 zakharyas1 joined
brrt i guess, ultimatley, yes 08:25
i learned a bunch of things
for one thing, the current viteration assigns registers to instructions at the same time that it allocates the register for the value
that way, any instruction always has the allocated register for the values it uses; if we need to spill a register, we split the live range of that value into 'atomic' units 08:26
for which we allocate a new register once they become live 08:27
(atomic meaning, they can't be 'split' themselves, because they are started directly before the using instruction, so it never makes sense to spill them)
08:28 zakharyas joined
samcv ah i see 08:43
in general things get better as you redesign them :)
brrt yes :-) 08:44
samcv i know i had many different iterations of my collation algorithm. some things you only learn when implementing really. but as long as you make progress that is what counts. though it is frustrating things not working as you'd want at first
"making sure the values goes in the right place" as it were. i think you said similar to something like that a few months ago 08:45
the first collation iteration was simplistic and couldn't handle sequences. but was helpful as it let me lay the foundations for how we would configure sort order and how it'd relate to the keys. the 1? 2nd iteration of the full type implementation. wow it like *mostly* worked but the code scared me 08:46
way too many branches that made it hard to follow, and i thought prone to programming errors as i could hardly tell which place it went except for having put a ridiculous amount of logging in 08:47
never have i used so many printf's :) as it's a pretty complicated thing. it'd dump the stack at the end. i'd be like. wait. why isn't that right...
and gdb was rarely helpful except in rare cases
and then i rewrote it again, and that time it was much simpler, but my test failures shot wayyyy up. then went down again and it stayed much neater 08:49
i mean it's still a lot of moving parts but i can describe what all the code does and why it's there :)
brrt hehe, that's pretty much how i feel about the register allocator as well 08:55
08:56 domidumont joined
jnthn MasterDuke: The 32-bit limit isn't primarily about storage, but about calculation: as most operations on 2 32-bit values won't overflow a 64-bit integer, we can do them in at 64-bit width and then see if the result needs to be promoted to a bigint or not. There's no portable way to do overflow detection based on flags, which is what'd limit some other strategy here. 09:04
samcv++ brrt++ # not settling on the first design, but hunting down a better one 09:06
samcv jnthn, i wanted to have our prepend detection in the normalizer instruct the synthetic creation if it needed to do extra checks, but that would have involved tons of code everywhere... so we have one property check for each synthetic being created so that's not too bad 09:09
may eventually have some MVM_MIN_PREPEND and MVM_MAX_PREPEND so we can do some bound checks before checking the property. or even since the number of them isn't that much i don't know it could be faster to check bounds and if they match check against the like 10 that exist with some if conditionals 09:10
not totally sure. but i went the way of doing that for the uca checks, where it checks if something is in a certain block or not. though haven't yet optimized it at all to do a bounds check before checking more heavily. in any case it doesn't seem to slow it down much. wonder if compiler does optimizations like that? if none of the conditionals checks have side effects 09:12
09:13 zakharyas joined
samcv well it only does that for things that don't return a value for the MVM collation values 09:13
jnthn C compilers do all kinds of smarts. :) 09:14
samcv oh i can also fix casechanges too 09:15
nine I notice how amazing they are every time I need to run a --debug moar ;)
samcv m: "\c[arabic number sign]a".uc.say
camelia Ų€a
Geth MoarVM: f8a639e205 | (Samantha McVey)++ | 3 files
Fix ignoremark with Prepend characters and ordbaseat op

Previously ordbaseat would return the first codepoint in the Synthetic instead of the correct base character. Now, when we add a Synthetic, we check if the first codepoint is Prepend, and if so we keep going until we find the last Prepend character.
This builds on the recent change so that synthetics are a single array instead of storing the base codepoint separately (3bd371f1).		 09:16
MoarVM: db3102c452 | (Samantha McVey)++ | src/strings/nfg.c
For degenerate Synth's with Prepend and Extend set base cp to 1st cp

If we have a degenerate that starts with Prepend and follows with Extend, this commit sets it so that its base character will be the first one, instead of the one following the last Prepend. I also set up a cache so we don't have to repeatedly get the property values repeatedly in case the user has the same codepoint repeating a large number of times. ... (9 more lines)
samcv is it at all beneficial jnthn to declare something const if you don't need the value to stay the same between invocations 10:03
i see that in some places of the code. i mean for variables inside of functions 10:04
jnthn It may in some cases let the optimizer do a better job, but to me `const` everywhere quickly becomes a lot of clutter. 10:14
Modern compilers are good at alias analysis, so can figure out a lot of "what might change", "what won't change", etc.
Especially on local variables 10:15
10:22 zakharyas joined 11:08 timotimo joined
MasterDuke i've updated gist.github.com/MasterDuke17/9bd82...0210817b32 with a diff of what my MVM_fixed_size_realloc(_at_safepoint)? looks like now. anybody have comments? 11:08
lizmat samcv: is it correct there are no roast tests yet for .collate ? 11:09
timotimo it's just missing support for the fsa debug mode
MasterDuke yeah, i haven't looked at what the other function do with that yet 11:10
samcv lizmat, well i just got it merged in (the full thing) but there will be shortly
uhm but it's still under use experimental though. not sure what the policy is for that lizmat
lizmat samcv: is there a reason we have a method collate in List that is identical to the one in Any ?
MasterDuke timotimo: but it looks reasonable otherwise? 11:11
lizmat good question: we have tests for pack/unpack in roast, but I guess that's a historical artefact
11:12 Skarsnik joined
samcv maybe we need an experimental folder? until it graduates? dunno 11:12
i could put it in there. or in rakudo 11:13
or just put it under the proper S or whatever
the only thing possibly not stable might be $*COLLATION. otherwise it's ready for use
i forget what TimToady mentioned we might want to change for that eventually 11:14
he had some comments on that
lizmat I was thinking that .collate should allow named params, like :!secondary, :!tertiary, which would then set $*COLLATION in that scope
samcv i could hide accesing $*COLLATION elements with experimental? 11:15
hm
yeah that sounds like a good idea
but yeah the reason tit was in both files is because i had planned on making the list one have more in it so it'd be faster than calling sort with a different sub 11:16
we would get the value of $*COLLATION and save it in a variable as a native int and have some raw unicmp function that has extra arguments for options 11:17
lizmat, how do you feel about me removing experimental from .collate?
lizmat I would be ok with it 11:18
samcv ok cool 11:19
i'll keep $*COLLATION experimental though. but let the function work without exp
timotimo MasterDuke: i think it looks okay. worst case, you'll find out when you use it in MVMArray and valgrind or asan complain :) 11:20
lizmat m: use experimental :collation; say "ʏ" unicmp "E" # samcv: what would needed to have that say Same ? 11:21
camelia More
lizmat if ever ? 11:22
brrt jnhtn: i'm sometimes using const to declare that stuff can live in the rodata section of the process and be shared and stuff
jnthn ^
i read that this was important somewhere on the internets so i believed it 11:23
but that's for staticly compiled data though
MasterDuke timotimo: heh, you mean getting some C code to compile doesn't guarantee it'll work perfectly? then why would anyone use such a language?! 11:24
samcv m: for <PRIMARY SECONDARY TERTIARY> { my $a = "ʏ"; say $a, ' ', $a.uniprop("MVM_COLLATION_$_") }
camelia ʏ 7460
ʏ 33
ʏ 9
samcv m: for <PRIMARY SECONDARY TERTIARY> { my $a = "E"; say $a, ' ', $a.uniprop("MVM_COLLATION_$_") } 11:25
camelia E 7441
E 33
E 9
samcv well you'd have to disable primary and disable quaternary
quat breaks ties by cp
timotimo MasterDuke: feel free to rewrite moarvm completely in rust or something :)
samcv MasterDuke, hush! if it compiles it works! 11:26
Skarsnik hm do you think I can get a moarvm function addr in NC (rakudo side)? 11:28
jnthn brrt: Yes, my answer was about local variables 11:30
MasterDuke ha. i have a friend who's always going on about how much he loves Rust. i'm happy people are using it for critical stuff, i don't have any particular interest though 11:31
jnthn Skarsnik: Probably doing the usual trick of "load a symbol in this process" would work
I think just `is native` or `is native(Nil)` or some such
lunch & 11:32
Skarsnik Yeah but I want the addr of a function to pass it as a pointer (in a cstruct) to pass it to C code 11:33
like give Moar alloc and free function to a lib x)
timotimo might be able to use cglobal with int64 for that 11:34
Skarsnik Oh right cglobal give a symbol addr?
jnthn really hopes code doing that won't make it into the module ecosystem 11:35
timotimo oh, addr
d'oh, it wouldn't do that
it'd give you the first 64 bits of the function instead 11:36
well, you can still nativecall into dlsym itself
Skarsnik m: use NativeCall; my $mv_free := cglobal('MVM_free', size_t, '')
camelia ( no output )
Skarsnik m: use NativeCall; my $mv_free := cglobal('MVM_free', size_t, ''); say $mv_free;
camelia Cannot unbox a type object (NativeCall::Types::size_t) to a str.
in block at /home/camelia/rakudo-m-inst-1/share/perl6/sources/24DD121B5B4774C04A7084827BFAD92199756E03 (NativeCall) line 517
in block <unit> at <tmp> line 1
Skarsnik what
timotimo it returned a null for you 11:37
Skarsnik Oh yeah, I don't like these unbox error x)
it's MVM_Free ? 11:38
timotimo no, MVM_free
Skarsnik m: use NativeCall; my $mv_free := cglobal('', 'MVM_free', size_t); say $mv_free;
camelia Must specify something as a path: did you mean '.' for the current directory?
in sub guess_library_name at /home/camelia/rakudo-m-inst-1/share/perl6/sources/24DD121B5B4774C04A7084827BFAD92199756E03 (NativeCall) line 231
in block at /home/cameliaā€¦
Skarsnik m: use NativeCall; my $mv_free := cglobal(Any, 'MVM_free', size_t); say $mv_free;
camelia Cannot locate symbol 'MVM_free' in native library ''
in block at /home/camelia/rakudo-m-inst-1/share/perl6/sources/24DD121B5B4774C04A7084827BFAD92199756E03 (NativeCall) line 517
in block <unit> at <tmp> line 1
Skarsnik m: use NativeCall; my $errno := cglobal(Any, 'errno', int32); say $errno; 11:40
camelia 0
Skarsnik hm it's weird it can't find a symbol of libmoar 11:41
11:46 timotimo joined
MasterDuke brrt: there are definitely deminishing returns, but just `perl6 -e ''` makes 4 calls to MVM_bigint_to_str with an actually-big int (plus 46 more with an actually-small int). and the value returned by nqp::objectid would fit in 2^48-1 12:01
but jnthn++ pointed out it would be pretty difficult to implement 12:02
nine MasterDuke: 50 calls doesn't sound like all that much? 12:03
brrt hmmm 12:04
MasterDuke to do nothing?
brrt i think i see where you are going
MasterDuke i don't think it's the single most expensive function you can call in moarvm or anything like that, i was just hoping it was one of the easier ones to optimize 12:05
brrt we could, with aggressive memory management, make those objectids reliably fit in 48 bits 12:06
stressing reliable :-)
MasterDuke i noticed a heaptrack report for a test script said MVM_bigint_to_str was one of the top causes of temporary allocations
nine Taking a step back, there's actually nothing _requiring_ an objectid to be a pointer, is there?
brrt nine: no 12:07
we could have atomic sequence numbers
or
thread-local sequence numbers
nine Was just gonna suggest the latter :)
brrt with, say, the upper 16 bits for the thread that allocated it, and the lower 48 for the sequence number itself
if someone ever runs out of one of those, well, i think we should say we are succesful 12:08
nine Or just give each thread a range of 24 bits or so and have it allocate a new block of numbers when it runs out. Only block allocation would have to lock something or use atomics. 12:09
But I guess we're a long way from nqp::objectid becoming a bottleneck :) 12:10
[Coke] (experimental) isn't the forthcoming 6.d a good point to make things not experimental? 12:11
(samcv jnthn lizmat ^^) 12:12
also mebbe zoffix
MasterDuke nine: nqp::objectid (and MVM_bigint_to_str) definitely aren't bottlenecks, but a lot of the times i ask about such things it's because they look like something simple enough i might be able to work on them 12:14
lizmat well, if 2017.10 is going to be 6.d, then just after the release of 2017.09 would be the right time, no ?
[Coke] ... it is? 12:15
I didn't realize we were committed to that timing. If so, then sure, though, yes.
lizmat well, I dunno, I think we all agree we want 6.d rather sooner than later
and no, no formal commitment has been made... I'm just putting a bit of pressure on it here :-) 12:16
[Coke] I haven't seen any work on roast cleanup. is the plan to take 'whatever's in master' ?
anyway, if it's tied to a spec bump, +1 from me. 12:17
jnthn Well, in good news for 6.d I do now have some resources to try and carry the non-blocking await a bit further forward 12:28
Together with making the scheduler smarter
[Coke] \o/ 12:29
jnthn I'd really, really like to see .hyper and .race sorted out this side of 6.d also 12:32
timotimo <3 12:34
Skarsnik nine, maybe we can start a NC apiv2 or whatever it can be called x)
MasterDuke (.hyper, .race).race(*++) 12:40
is there any reason not to use the FSA for (nearly) everything in VMArray.c? is that what jnthn means here? irclog.perlgeek.de/moarvm/2017-09-11#i_15146218 12:53
timotimo when we already easily have the current allocation size on hand it's probably good to use the FSA 12:54
otherwise, don't
is my approximation
MasterDuke hm. definitely not quite fully understanding what he meant/is involved with using FSA. can i keep the existing functionality pretty much identical, just swapping in FSA functions, and then implement what he said? 12:59
jnthn MasterDuke: Approximately yes 13:00
But
You need a flag bit somewhere (perhaps in the object header)
That indicates whether or not the FSA is being used
Since sometimes we populate a buffer from memory we were given by, say, libuv
And we have to do a normal MVM_free of it in that case 13:01
I'd kinda like to switch all of those cases to MultiDimArray in the future
MasterDuke ah, was trying to figure out why that flag was needed
jnthn And have them fixed size and immutable
But that's a bigger step
MasterDuke so what would need to be changed to read that flag? 13:03
jnthn Everything that might allocate/free the buffer 13:04
MasterDuke done by implementing the check in VMArray's gc_free? 13:05
jnthn There it'd be needed
But also in the resize operation
MasterDuke and copy_to i assume? 13:06
jnthn Well, there we have a choice
We could always use the FSA in the destination array
And we don't touch the source array
Just read it
MasterDuke right
jnthn And the flag won't be copied automatically
So I don't know that needs to check/set it 13:07
MasterDuke cool. many thanks, everyone here is very helpful 13:08
jnthn From memory, unshift may also need a look
Maybe or maybe not splice, but I think splice isn't yet optimized enough to need it 13:09
14:20 stmuk joined 15:26 brrt joined 15:40 Skarsnik_ joined
Geth MoarVM: 49b90b99db | (Samantha McVey)++ | src/strings/nfg.c
Fix case change when base cp isn't the first cp in synthetic

Now the base codepoint will change case even if there are Prepend codepoints in front of it. Now updated to use our updated Synthetic representation.		 16:00
16:00 dogbert17 joined 16:13 buggable joined, huggable joined, Geth_ joined, ZofBot joined 16:14 SourceBaby joined 17:21 leont joined 18:40 domidumont joined 18:51 domidumont joined 19:04 dogbert17 joined 19:38 Skarsnik_ joined 20:19 domidumont joined 21:21 zakharyas joined 21:48 dogbert17 joined 23:03 bisectable6 joined 23:37 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!