01:01 colomon_ joined 01:07 lizmat_ joined 01:56 ilbot3 joined 07:36 domidumont joined 07:45 domidumont joined 08:17 robertle_ joined 08:32 domidumont joined 08:48 Kaiepi joined 08:54 domidumont joined 10:09 evalable6 joined 10:22 AlexDaniel joined 11:09 FROGGS joined 12:06 lizmat joined 14:02 ggoebel joined
Kaiepi might be a dumb question but for support for wide strings and multi-byte strings would it be a better idea to support it from moar or make a cpan module to deal with it? 14:30
maybe i should open an issue about it 14:59
wait i forgot nqp and the js compilers don't have a way to support wint_t and mbstate_t 15:15
s/nqp/jvm/ 15:16
timotimo how so?
they just need to get the info fed to them somehow
we do have a build step for those two backends, too, which is where we could figure out that info 15:17
Kaiepi we do?
timotimo we build that stuff with makefiles
Kaiepi i was thinking that because com.sun.jna.NativeLong and com.sun.jna.Native don't support wint_t
but makefiles would work
would it be possible to handle mbstate_t the same way? it's a cunion that differs between platforms 15:18
timotimo have it in a module that has a sub EXPORT and decide programmatically which one is right, maybe? 15:19
Kaiepi that sounds pretty complex 15:20
it's not something that entirely needs to be supported natively, since it's used sort of like FILE
afaik 15:21
i need to look more into this though, i'm not as familiar with mbstate_t 15:24
yeah, it's an opaque pointer 15:29
wait i could add support for wint_t to jvm since the dependency it relies on is up on github 15:34
nine I got the first patch that can give us backtraces even for inlined frames in JIT compiled code! 15:40
Kaiepi sweet
nine It's not something that I would commit as-is, but it shows that I know what's going on and now just need to find a prettier way.
Also I think I now fully understand how terrible cur_frame->jit_entry_label is and that we need to get rid of it ;) 15:41
16:02 releasable6 joined, shareable6 joined 16:31 eater joined 16:47 Kaiepi joined 16:57 domidumont joined 16:59 bisectable6 joined, committable6 joined, squashable6 joined 17:09 Kaiepi joined 17:11 Kaiepi joined 17:58 Kaiepi joined 18:25 Kaiepi joined
robertle_ schroot -r -c $sessionid 18:35
sorry
18:49 domidumont joined, FROGGS joined 18:58 Kaiepi joined 19:21 Kaiepi joined 19:24 zakharyas joined, Kaiepi joined 19:36 ilmari[m] joined 19:50 Kaiepi joined 20:14 AlexDaniel` joined, wictory[m] joined 20:17 brrt joined
brrt \o 20:17
nine++
re: the jit_entry_label; yes, it is a hack, but it does serve one 'good' purpose
which is that it allows us to 'trampoline' to and fro the interpreter at virtually any point in the code 20:18
so i'm not really intending to get rid of it fully, but i do intend to get rid of the periodic updating of it on the entry of every basic block 20:19
... and of using it directly to get the current inlines' position 20:30
well, for frames up the stack, it's not really a problem though
Geth MoarVM/jit-expr-optimizer: 14 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/9...807ddb7d41		 20:38
timotimo more than just a rebase? 20:39
brrt no, that's a rebase 20:42
i've got some plans to bring it further though :-)
timotimo nice 20:43
brrt i've thought a bit about something i've been rambling about earlier 20:44
the tl;dr
i can (probably) encode all we currently use MVMJitNExprodeInfo (a structure) for, in a union, that is 32 bits wide 20:45
i thought some more about it, and i can also use a bit more space, say, 64 bits 20:46
in the latter case, I don't need bitfields in structs
i'm not sure it matters a thing, with regards to memory traffic
timotimo is the jit actually slow? 20:48
brrt the correct answer to that is, we currently don't really know, although we could find out 20:49
spesh log has plenty of information to tell us
timotimo i still have to figure out the problem with osr hits not matching the actual callsite ... 20:50
that's causing spesh to use rather bad amounts of cpu time
brrt hows that work?
timotimo not entirely sure what causes it, but right now we're sometimes in a loop with an osrpoint and we log lots of hits, but the specialization we make won't get selected at the osrpoint when polling for a specialization, because the callsite in the guard tree doesn't match the caller frame's cur_args_callsite 20:51
and so we end up consuming one log after another as fast as we can while the code-running thread generates more and more logs 20:52
brrt i'm thinking of callsite interning 20:58
timotimo that's not actually the problem here, though 20:59
the callsites are fundamentially different 21:00
the number of args doesn't match, iirc
brrt that is odd? 21:01
how do we end up speshing the wrong thing?
timotimo that's what i haven't figured out yet
you know a little bit how the log is built?
there's a log for entering a frame and there's a log for hitting an osrpoint 21:02
the entering-a-frame entry has the callsite in it, the osrpoint one doesn't, it just has the spesh correlation id
brrt dnf has a nodejs module for lowercasing a string 21:05
timotimo dnf? 21:06
brrt i mean, the fedora package system :-) 21:07
fedora has an rpm package for a nodejs module for lowercasing strings
timotimo ah 21:08
Kaiepi typical type of npm package
brrt 'nodejs-is-glob.noarch : Returns `true` if the given string looks like a glob pattern' 21:09
Kaiepi wait a string in js or
timotimo better have these packages once in the system rather than fifty-seven times in every node_modules folder on the system
brrt oh, but that will still happen
timotimo version differences, right? 21:10
21:13 Kaiepi joined
japhb Some of those are just the minimum packages necessary to get npm bootstrapped. 21:13
Installing npm and nodejs on an empty Debian-based system results in a LOT of packages getting installed.
Kaiepi installing npm and nodejs on openbsd results in spending half an hour of googling and then uninstalling when npm fucks up while updating itself 21:15
not my favourite package manager as you can see 21:16
timotimo they probably still have tooling that we lack with, for example, zef 21:18
Kaiepi true 21:20
brrt there is indeed an npm module to read the arguments to npm, so i guess that's true 21:24
Geth MoarVM: f2b9b7f4f0 | (Bart Wiegmans)++ | src/spesh/candidate.c
[JIT] Measure and report time spent on JIT compilation

We need to know how much time we're spending before we can meaningfully talk about improving it.		 22:02
brrt seems like nqp and rakudo reliably spend a bit more time on spesh than on the jit 22:04
that comparison is totally meaningless, of course
but the JIT is not the resource hog we might have imagined it to be, at least
of the rakudo build, we spend about 17s in total in spesh/jit 22:05
that is the full build including CORE.setting 22:06
timotimo right, and all that happens in parallel to the other stuff, of course 22:07
say, how's the memory allocation behaviour of the jit?
i'm wondering if we should on principle keep around a few blocks that the spesh allocator got already 22:08
so we don't free at the end and malloc at the beginning of every single piece of work
perhaps if we're finished with one batch and we don't have more work in the queue we should deallocate so we free memory that'd otherwise be unused for multiple seconds?
anyway, rsi rest break time
i mean, surely it'll barely make a difference, but maybe nulling out the spesh memory area is cheaper than freeing and mallocing again 22:19
22:49 ZofBot joined 22:52 ZofBot joined
timotimo i wonder how big the difference is between outputting a spesh log and not outputting a spesh log; we currently can't see if the spesh log has an impact on the performance because we only see the timings when the spesh log is requested :D 22:57
23:07 nativecallable6 joined, notable6 joined, unicodable6 joined, committable6 joined, evalable6 joined, bloatable6 joined, greppable6 joined, coverable6 joined, quotable6 joined, reportable6 joined, benchable6 joined, shareable6 joined, bisectable6 joined, squashable6 joined, releasable6 joined, statisfiable6 joined
MasterDuke perf or callgrind could show that, right? 23:13
timotimo valgrind would be difficult, as it serializes multithreaded code 23:18
23:46 ZofBot 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!