Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
MasterDuke this time i caught an `MoarVM panic: non-AsyncTask fetched from eventloop active work list` in t/spec/S32-io/IO-Socket-Async.t and did an `rr pack`, so hopefully it can be more easily diagnosed 01:14
MasterDuke it got an MVM_REPR_ID_MVMNull instead of an MVM_REPR_ID_MVMAsyncTask 01:40
but i know essentially nothing about the io socket async stuff, so i'll try again to catch one of the other errors. but if anybody wants the rr replay i'll save it 01:46
MasterDuke just caught a fail in t/spec/S02-types/mix.t 02:49
not ok 126 - .roll(100) (2)
# Failed test '.roll(100) (2)'
# at t/spec/S02-types/mix.t line 283
lizmat MasterDuke: don't worry about that one, it will fail about 1% of the time 06:18
it's hard to write a test involving randomness
nine github.com/Raku/roast/commit/48466a57d0 should help with that 07:39
lizmat well... I originally chose 100 because the *failure* of the test every now and then, actually ensures the test is correct 07:50
if we're going to make that chance really negligible then we might as well remove that test
nine I don't understand that argument. Nothing changed with regards to the statistical analysis. It still checks whether the element that should make up ~1/3 of the result makes up less than 3/4. 07:56
lizmat sorry, I mistook the test, I thought we were talking about the next block of test 08:03
the my $m = {b => 1, a => 100000000000, c => -100000000000}.Mix; one
:q 08:04
cause if that one for some reason just starts producing "a"'s always, we will never know that we have a bug 08:07
but that most definitely is not a hill I want to die on :-) 08:08
timo we might get some benefit from checking out all the extra stuff mimalloc has to offer 09:24
for example, mimalloc offers "heaps", which can replace the spesh allocator, since it offers the "free all at once" feature that we made the spesh allocator for 09:25
timo and we should also use the "good alloc size" and "usable size" functions for our growing arrays 09:25
[Coke] I am all for taking advantage of other people's code if we can. 13:55
timo though i'm not sure if mimalloc can actually beat the spesh allocator, we can save a tiny bit on code size perhaps? 13:57
since the spesh alloc uses bump-the-pointer and doesn't support freeing individual things at all, which i think the mimalloc heap api still supports
on the other hand, we still support building moar without mimalloc
timo we can combine both; allocate the pages for the spesh allocator with a heap id, and when destroying everything we don't have to walk the linked list and call free a bunch of times, instead we just call "free the heap" once 18:32
lizmat what would be the benefits? less CPU usage, less memory ? 18:37
timo could be less cpu usage, but probably not much, and it's in the spesh thread anyway, so wouldn't make programs finish much faster 18:42
lizmat well, if we could get memory usage down, that would be good 18:50
nine I'd be surprised if there's much to gain there though 18:57