github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:12 Kaiepi joined 06:28 vesper11 left 06:39 vesper11 joined 07:40 Ven`` joined 08:08 patrickb joined
patrickb o/ 08:08
08:25 Ven`` left
patrickb I'm currently trying to iron out unicode in path stuff. 09:50
Currently I'm looking at github.com/MoarVM/MoarVM/blob/mast...ile.c#L457
That's the `open` implementation. It's directly using the C API `open()` function instead of libuv `uv_fs_open`. 09:51
09:51 chloekek joined
patrickb I think `open()` on windows is ignorant of utf-8. Instead one needs to use _wopen() and convert the path string to wchar_t before. 09:52
Is libuv somehow forbidden in syncfile? (because of the 'sync' part?) 09:54
What would be a good way forward? rewrite to use `_wopen()` on Windows and convert the path to wchar_t, or use libuvs `uv_fs_open`? 10:04
It seems libuvs implementation does some other nifty stuff to prevent locking problems as well.
nine patrickb: jnthn++ removed libuv usage from syncfile 2 years ago, but the commit messages don't say why that was good 10:09
patrickb nine: Thanks! 10:12
I'll wait for more input and do other stuff in the meantime.
10:21 chloekek left
timotimo for syncfile stuff, using libuv meant overhead from going through starting and stopping eventloops for every operation 10:44
11:10 dogbert17 joined
dogbert17 nine: if you're bored I have one more fromspace error you can sink your teeth into :) 11:10
patrickb so `MultiByteToWideChar()` and `_wopen()`is the way to go I guess... 11:12
11:12 patrickb left
nine dogbert17: that might be less frustrating than trying to find that elusive segfault in Inline::Perl5. But I also have to leave soon 11:13
dogbert17 nine: when you have the time then: set nursery to 2048 bytes, MVM_GC_DEBUG=1 and run t/spec/S12-meta/primitives.t 11:18
nine That...kinda looks familiar 11:24
dogbert17 it has been mentioned before 11:26
12:03 patrickb joined 12:10 sena_kun joined 12:28 lucasb joined
Geth MoarVM: cfc5d00061 | (Timo Paulssen)++ | src/core/nativecall_libffi.c
give error message improvement to libffi as well
 12:36
MoarVM: ee18678e91 | (Timo Paulssen)++ | README.markdown
Update "Features" part of readme

Unicode 10 -> 12.1 MAST compiler is no longer in moarvm scalar replacement and PEA heap snapshots remote debugger
13:29 sena_kun left 13:30 sena_kun joined
patrickb May I encourage anyone with some knowledge of how Linux user permissions work to have a look here: colabti.org/irclogger/irclogger_lo...08-30#l122 13:51
timotimo hm, can root open a file that's -r for everything? 13:53
apparently so 13:54
patrickb afk for a bit 13:55
timotimo lol
if i'm root and the file doesn't belong to me, i can cat it
13:55 sena_kun left
timotimo if i'm root and it's root:root and 000 i am not allowed to cat it 13:55
13:56 sena_kun joined 14:10 sena_kun left 15:53 domidumont joined 15:57 MasterDuke joined
MasterDuke can anyone explain the appveyor warning i get here? github.com/libtom/libtommath/pull/330 15:58
the const qualifiers look the same to me...
timotimo what does MP_WUR expand to? 16:01
MasterDuke oh, easier to see just my changes here github.com/libtom/libtommath/pull/331
`define MP_WUR __attribute__((warn_unused_result))` 16:02
timotimo ah
so one is mp_err mp_todecimal(const mp_int *a, char *str)
ļæ¼
mp_err mp_todecimal(const mp_int *a, char *str) MP_WUR; 16:03
ļæ¼
is the other
MasterDuke huh 16:04
16:06 domidumont left, domidumont joined
MasterDuke think i found it, i was missing the const in tommath_private.h 16:08
timotimo ooh
MasterDuke arg, nope, not it 16:09
timotimo anything related to the macro that used to be there?
MasterDuke i don't think so...now it's pointing to `if ((err = mp_neg(number, number)) != MP_OKAY) {` as the problem (same error though) 16:10
oh, maybe because mp_neg only has the first argument const? 16:11
in it's signature
timotimo yeah, you can't pass something that's const to a parameter that isn't const 16:12
MasterDuke any way around having to create a new mp_int just to put the negative into?
timotimo because that means the function will want to modify it
though you can pass a non-const to a const parameter by casting it i think?
MasterDuke don't think that helps me 16:14
timotimo OK
MasterDuke ha, i think that just uncovered a bug in my code though 16:17
if a number is negative i turn it positive to go though my new functions and manually stick a '-' in the front 16:18
but i never turn it back positive at the end
so i'd either have to know to turn it back negative at the end, or just copy it into a new (non-cont) mp_int 16:19
timotimo mhm
16:46 chloekek joined 17:31 chloekek left 18:48 domidumont left 19:00 chloekek joined
nine Oooh...progress on the GC issue in t/spec/S12-meta/primitives.t! 19:22
This can allocate: github.com/MoarVM/MoarVM/blob/mast...gin.c#L404 and it will change tc->plugin_guards before that. The plugin_guards are saved to the local MVMSpeshPluginGuard *prev_plugin_guards but that's not rooted so it may become out of date. 19:26
dogbert17 brilliant, I have a vague memory that I looked at that function but was unable to figure out why things went wrong 19:31
nine There's also a mark_plugin_sr_data that marks the prev_plugin_guard_args but not the prev_plugin_guards 19:32
Seems like a little reshuffeling of the code can ensure that the guards get marked. That saves me from having to write lots of code to push all the objects pointed to by the guards to the temp roots :) 19:35
dogbert17 sounds as if the bug will soon be a distant memory :) 19:53
Geth MoarVM: b2287bc413 | (Stefan Seifert)++ | src/spesh/plugin.c
Fix possible memory corruption of spesh plugin guards by untimely GC

setup_for_guard_recording can allocate and it will change tc->plugin_guards before doing so. The plugin_guards are saved to the local MVMSpeshPluginGuard
  *prev_plugin_guards but that's not rooted so it may become out of date when
the GC moves objects pointed to by such guards.
... (8 more lines)		 19:56
nine Why would "using a null string to access a hash does not segfault" in t/spec/integration/weird-errors.t suddenly fail? 19:58
The test is from 2016
nothing to do with my commit btw
20:00 patrickb left
nine Ah, timotimo, it's because of github.com/MoarVM/MoarVM/commit/3f...7f27158e7d 20:00
It segfaults on trying to get the debug name of a NULL object 20:01
Geth MoarVM: 289ccd8c97 | (Stefan Seifert)++ | src/6model/6model.h
Don't segfault when trying to get the debug name of a NULL object

Fixes regression in "using a null string to access a hash does not segfault" test in t/spec/integration/weird-errors.t		 20:03
20:18 brrt joined
brrt \o 20:21
MasterDuke brrt: just curious, what's next now that the float stuff has been merged? 20:25
brrt MasterDuke: good quesiton 20:27
so there's three things that I want/need to do, that are sort of orthogonal
one, we need to support irregular register requireemnts for arbitrary tiles 20:28
that's a easy-medium problem
MasterDuke what causes an irregular register requirement? 20:29
brrt that'd be something like the integer division operator 'div'
in x86-64
but also, shift-left and shift-right, iirc 20:30
this may cause some spilling and shuffling and I think that can be handled by refactoring the same logic for function calls
two, I want to start optimizing expression IR. But that turns out to be blocked by the current IR not recording the relative order of oeprations (thereby making it impossible for optimizations to take them into account) 20:32
dogbert17 nine++, there's a chance that we're now out of fromspace errors ...
brrt three, there are a number of instances where there are integrations with the legacy JIT (e.g., subroutine invocation, repr-based devirtualizzation), and things that the expr jit doesn't handle yet (deopt), that should be rewritten to use the expr JIT 20:36
of those, subroutine invocation is decently far advanced, but there's a use case (nativecall) that I can't figure out how to test 20:37
repr-based devirtualization I'm currently working on mostly because timotimo asked for it
and because it's quite doable I think :-)
MasterDuke would that last one help with jitting setmethcach, ctxouter, throwpayloadlexcaller, param_*, etc? 20:39
and/or creating templates for prepargs, sp_*, *attr*, etc? 20:44
brrt maybe 20:48
no, not prepargs
well, yes prepargs
not some of the attr_ stuff
some of the sp_bind and such stuff, those could be jitted already 20:51
timotimo when something turns into an sp_bind or so, especially the numeric ones, it's already pretty much as good as we can get 21:03
devirtualization is for reprops like elems, atpos/atkey, existspos/existskey, push/unshift, pop/shift, many more 21:04
nine: thanks for catching that. i was convinced it'd already be safe, but clearly it wasn't :) 21:05
brrt the thing is that the sp_bind is not really high on the list.. mostly because it's so easy to do 21:09
MasterDuke sp_getlex_o, sp_fastbox_i_ic, sp_getvt_o, sp_get_i64, sp_getlex_ins are some of the top missing templates 21:10
timotimo will exprjit be smaller than the code we're currently compiling in graph.c for all the "call a c function" things? 21:11
brrt I hope so timotimo
the idea is that it can be cleverer about loading and moving stuff about
timotimo MasterDuke: how much faster is base 16 btw, compared to torad and todec? 21:23
and todec_fast 21:24
i imagine it can be blazing fast
MasterDuke don't know. i mean, it just uses toradix also, so i can't imagine it's all that fast 21:25
timotimo time perl6 -e '((2 ** 500000)).base(16).chars.say' vs the same with base 10 is 1.3s vs 10.8s 21:28
MasterDuke huh 21:29
timotimo no clue how it fares against the faster todec
brrt I just realized that it'd be possible for a throwish / invokish opcode, to return a value. and that value would never be assigned to the correct register 21:30
does that ever happen? šŸ˜¬
timotimo invoke_o is invokish? 21:31
decont is invokish and regularly returns something 21:32
brrt i think decont has an explicit output argument, so that's not a problem, and invoke_o does the same thing 21:33
(also, we don't exprjit invoke_o yet)
so the assignment of anything actually invokish, is done when the invokish thing returns
throwpayloadlex also has the same thing, I think 21:34
(late assignment)
yeah, okay, so this makes sense
this must always be the case. If it's actually invokish, it can't assign directly when it returns 21:35
it must always pass the target register as an address
phew
sanity prevails.
MasterDuke timotimo: todec becomes faster than tohex at 2**16384 21:41
timotimo that is todec with barrett?
MasterDuke yeah 21:42
timotimo converting to hexadecimal should be impossible to overtake, honestly :)
MasterDuke they seem open to PRs... 21:44
timotimo i see it's really dividing by the base over and over and just grabbing the right letter 21:46
with bases 2 and 16 and probably also 8 you can get much faster
MasterDuke yeah, toradix is not really optimized at all 21:47
timotimo: some timings. however, these are done on my laptop, so shouldn't be compared with my other timings (the ones in the PRs) gist.github.com/MasterDuke17/d29b8...a29fafb606 21:50
21:53 brrt left
timotimo m: say 3.6 / 4.8 22:07
evalable6 0.75
timotimo that's the very naive version 22:08
i should really be iterating over the digits inside the number directly 22:10
that'd also allow working without reversing the string at the end
don't really have the energy for that now, though 22:13
MasterDuke nice 22:18
timotimo i could imagine there'd be a factor of 10 in there, if not 100
i don't see any shift ops except for shifting by entire mp_digits 22:20
MasterDuke i think i use mp_div_2d instead of shifting 22:22
timotimo right
ah, this uses mp_div_d
oh, that is a shift! 22:23
i think i might have done it wrong 22:33
MasterDuke that sounds unpromising 22:34
timotimo it looks kind of like the majority of the time is spent creating the number, actually 22:37
i'm timing this inside of perl6
can has your test script? %) 22:38
or something else went wrong 22:40
OK, looks like i made it slower actually 22:41
i think i saw a "is power of two" check in mp_div_d 22:42
MasterDuke timotimo: it's not pretty at all, but gist.github.com/MasterDuke17/a93f1...c3d182edf3 22:55
timotimo i actually reverted my changes already
they weren't good
MasterDuke well i'm off to sleep, but good luck 22:57
timotimo good night!
22:58 AlexDaniel joined, AlexDaniel left, AlexDaniel joined, chloekek left 23:02 MasterDuke left 23:38 lucasb left 23:58 AlexDaniel 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!