github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine dogbert17: timotimo got it. I'm not surprised that c395a48b8a causes us to lose some performance. It's performance we should have never had though :/ 09:24
Geth MoarVM/fpclassify: 5 commits pushed by (Nicholas Clark)++ 10:06
timotimo mhhh, forbidden performance 10:24
if someone were inclined, they could diff the spesh logs from before and after that commit and see where the biggest deviations are
perhaps there's a situation or two that we can do better on without too much effort 10:25
dogbert17 nine: ok, it obviously has to do with what the program is doing but sometimes the hit is quite noticable, e.g. from 3.5s to 6.5s in one case 10:57
timotimo dogbert17: do you happen to have that available? 15:31
dogbert17 timotimo: indeed I do, gist.github.com/dogbert17/0c20f82c...efcff83df9 15:36
timotimo that runs for multiple minutes on my machine, is that wrong? 15:40
it's got tracy in it but thats not supposed to add that much overhead 15:46
wow i recompiled without tracy and it just took a couple of seconds wtf 15:56
nine To get NativeCall's memory management in order, I need to associate strings with their encoded C strings and know whether we're responsible for free()ing the latter or not. 15:58
We already have a CStr repr that stores pointers to char* and the HLL string and can easily be extended to store a managed flag. 15:59
To spare the user from having to create such CStr objects when passing strings to native functions or when storing them in e.g. CStructs, I figured our lovely coercion types could do the job: CStr(Str) 16:00
However coercion only works on assignment, not when binding (which...is probably not that surprising once one things about this).
For assignment one needs a container to assign into. In P6opaque objects we auto-vivify such containers based on information passed to compose. 16:01
CStruct does not have this information (yet), but adding this is not that difficult.
Since coercion types are full type objects in their own right nowadays, we need to communicate the actual target type to the VM so it can map it to the proper C type. That requires some meta model trickery but is doable. 16:02
But even after all that is taken care of, there's still the tiny issue that the CStruct doesn't actually see the value that's assigned into the auto-vivified container, so it cannot update the char* stored in the C struct. 16:03
I wonder if I will end up turning CStr itself into a container. 16:06
timotimo tracy can record stack traces for most of the functions it offers, like when you record an allocation or free 16:54
but the performance hit is no joke, for real
timotimo do we care that MVM_LOG_DEOPTS leaks the name and cuuid strings for recreated frames? 17:39
lizmat is that something you can activate without a debug build ? 17:43
timotimo no, you need to edit the source code to get it 17:48
dogbert17: with your code i see that it submits a boatload of spesh logs during the final stretch; Any-iterable-methods's push-all from IterateOneWithoutPhasers gets a huge amount of OSR hits, which means we're running the unoptimized code there, not entering an optimized version 17:49
i did not compare against the earlier moarvm without the fix .. or was i running the one that is faster? 17:50
lizmat if IterateOneWithoutPhasers is not optimized, that will affect just about any for loop 17:51
timotimo AFKBBL 17:52
dogbert17 timotimo: which version of MoarVM are you using? 18:41
timotimo my own patched version lol 18:42
hey dogbert17 could it be @a.grep(1^..*) is much much faster than @a.grep(-> $num { $num > 1 })? 18:43
do we have a grep candidate for ranges yet? 18:44
well, that part only takes a fractoin of the total time anyway 18:52