github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 reportable6 left 00:03 reportable6 joined 00:06 dogbert17 joined 00:07 dogbert11 left 00:16 Kaiepi left 00:17 Kaiepi joined 00:18 Kaiepi left, Kaiepi joined 01:06 vrurg joined 01:11 vrurg left, vrurg joined 01:19 vrurg left 02:42 squashable6 left 02:44 squashable6 joined 05:23 Geth left 06:02 reportable6 left 06:03 reportable6 joined 06:16 vrurg joined 06:20 vrurg left 07:11 frost-lab joined 07:30 domidumont joined 07:50 domidumont left
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
09:25 linkable6 left, linkable6 joined 09:37 Geth joined
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
10:47 vrurg joined 10:52 vrurg left
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
12:02 reportable6 left, reportable6 joined 12:36 vrurg joined 12:40 vrurg left 12:59 domidumont joined 13:29 domidumont left 13:37 domidumont joined 14:13 frost-lab left
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
16:13 Kaiepi left, Kaiepi joined 16:15 zakharyas joined 16:52 vrurg joined 16:54 vrurg left
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
17:13 lucasb joined 17:30 patrickb joined 17:32 vrurg joined
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
17:53 domidumont left 18:02 reportable6 left 18:03 reportable6 joined 18:24 vrurg left
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
18:56 Kaiepi left 18:57 Kaiepi joined 19:10 MasterDuke joined 20:00 zakharyas left 20:01 zakharyas joined 20:18 MasterDuke left 20:29 patrickb left 20:32 zakharyas left 22:08 dogbert11 joined 22:11 dogbert17 left 22:16 dogbert17 joined 22:18 dogbert11 left 22:29 dogbert11 joined 22:32 dogbert17 left 23:55 dogbert17 joined 23:59 dogbert11 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!