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
04:57 unicodable6 left, bloatable6 left, quotable6 left, undersightable6 left, reportable6 left, nativecallable6 left, coverable6 left, squashable6 left, statisfiable6 left, releasable6 left, benchable6 left, committable6 left, greppable6 left, bisectable6 left, notable6 left, shareable6 left, evalable6 left 04:58 evalable6 joined, squashable6 joined, reportable6 joined, releasable6 joined 04:59 statisfiable6 joined, greppable6 joined 05:00 undersightable6 joined, notable6 joined, benchable6 joined, bisectable6 joined 05:01 committable6 joined, unicodable6 joined, quotable6 joined 05:02 bloatable6 joined, coverable6 joined, nativecallable6 joined, shareable6 joined 05:06 harrow left 05:11 harrow joined 06:24 domidumont joined 07:14 domidumont left 07:29 domidumont joined 08:13 nebuchadnezzar left, nebuchadnezzar joined 08:20 harrow left 08:30 harrow joined 08:47 robertle_ joined 08:48 squashable6 left 08:51 squashable6 joined
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
09:26 zakharyas joined 10:52 domidumont left 11:54 zakharyas left 12:42 domidumont joined 13:01 lucasb joined 13:44 zakharyas joined
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)
14:22 AlexDaniel joined
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
15:00 robertle_ left 15:02 robertle_ joined
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 :)
15:23 AlexDani` joined 15:24 AlexDaniel left 15:25 sivoais left 15:26 sivoais joined, camelia left, camelia joined
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
15:52 robertle_ left 16:04 robertle_ joined 16:07 Guest5277 left
ugexe ah right, directory handles can't be opened in Perl 6 16:14
16:19 robertle_ left 16:24 squashable6 left 16:28 squashable6 joined
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
16:33 zakharyas left, domidumont left 16:35 AlexDani` left 17:25 domidumont joined 18:09 squashable6 left 18:14 squashable6 joined 19:14 squashable6 left 19:19 squashable6 joined 19:30 AlexDani` joined 19:44 squashable6 left 19:49 squashable6 joined 20:14 domidumont left, AlexDani` left 20:20 lucasb left 23:10 camelia left, camelia joined 23:14 camelia left 23:45 AlexDani` joined 23:46 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel 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!