github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke timotimo: any thoughts on github.com/MoarVM/MoarVM/pull/1073 ? 01:14
timotimo MasterDuke: i wonder if there are any stresstests that have abs_n in them 08:52
but otherwise if the tests all succeed, then the fabs and the interpreter implementation are probably equivalent (or we have some missing tests to write) 08:53
lizmat so I thought I'd let "zef" create a profile to find out what it does to install a distribution 13:54
so I added "--profile" to the #!/usr/bin/env perl6 shebang
this seems to *always* result in either a segfault or a MoarVM panic: Internal error: zeroed target thread ID in work pass 13:55
timotimo jnthn is this something should put in an issue, or is that something that is known already ? 13:56
also: for these cases, I think the --profile functionality should also be settable using an environment variable ?
ugexe i think that happens because zef uses exit(...) 14:16
you can comment them all out, or set &*EXIT to be a no op
and you dont need zef to be installed to profile it, you can just do `perl6 --profile -I. bin/zef install MyFoo`, so you dont have to keep reinstalling when making those changes 14:17
(comment out exit() or override &*EXIT in Zef::CLI)
lizmat that sorta implies that having started with --profile, should override &*EXIT ? 14:34
at least fro now ?
ugexe well it might just be &*EXIT should do exactly what it was told to do, just with a delay (i dont know if a delay solves this) 14:36
eh actually a delay probably doesn't help anything 14:37
it would just get profiled itself 14:38
lizmat perhaps a "die" inside the &*EXIT routine would do the trick, maybe not 14:50
AlexDaniel this ticket needs some help: github.com/MoarVM/MoarVM/pull/1072
I kinda want to just hit merge but it feels wrong to do that somewhat blindly 14:51
jnthn AlexDaniel: I'd agree with your assessment that we should benchmark it some more 15:06
That said, the vast majority of our short-lived allocations do *not* go through malloc
(Still more than would be ideal though) 15:07
AlexDaniel jnthn: am I right in thinking that 128KiB is way too low?
jnthn hah, I just read this bit from the linked article: "The manual is wrong! Analysis of the source code tells me that it frees all eligible OS pages, not just those at the top." 15:10
That makes it quite a lot more useful :P
The "best" value would probably depend on program behavior. Generally, programs that asked for memory once will ask for it again. 15:12
But it's of course an over-generalization; some programs have different phases with different memory behaviors.
timotimo i still want someone to put that malloc heap analyzer into moar :P 15:13
jnthn AlexDaniel: To be clearer: it depends on what kinds of allocations the program does. It's possible that a program could be doing lots of allocations, but moar satisfies them all out of the GC nursery or fixed size allocator and so never asks malloc for more. 15:18
My gut feeling would also be to set it a little higher than 128KB though 15:19
But I don't really have an intuition of the cost of being wrong. Just another page fault? 15:20
Or a lot more?
Also, I dunno the cost of calling malloc_trim :)
ugexe readdir isn't thread safe if two threads need to read from the same dirstream. does that mean this is not thread safe? `readdir(data->dir_handle);` 15:38
or is getting into that situation to begin with already a problem 15:39
jnthn I think from a Perl 6 perspective, such handles are never exposed anyway; `dir` always returns a new sequence that does an open/read*/close 15:43
ugexe ah right, directory handles can't be opened in Perl 6 16:14
ugexe libuv just added uv_fs_*dir() functions, but comparing implementation the main difference seems to be on windows it ignores ERROR_FILE_NOT_FOUND error specifically instead of breaking 16:29
break;ing ^ 16:31

Powered by Cro and the Raku® Programming Language.

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

Thank you!