00:12 Unavowed_ joined 00:54 colomon joined 01:00 pochi_ joined 01:05 geekosaur joined 01:13 colomon joined 01:21 colomon joined 02:25 dalek joined, harrow` joined 03:06 mojca joined 03:09 geekosaur joined 04:42 geekosaur joined 06:59 domidumont joined, FROGGS joined
nwc10 I missed this (and thanks Google for always redirecting me to this TLD): morepypy.blogspot.co.at/2016/03/py...eased.html 07:00
version number acceleration - presumably 7.0 is pretty soon and their version numbers will be in ℵ not long after that 07:01
a commentator wondered where pypy3 5.0 is(n't), and no commentator there wondered where their STM work has got to 07:02
but I'm wondering this.
07:04 domidumont joined
moritz suspects that STM is a *hard* problem, and probably needs years to mature 07:43
nwc10 isn't even sure if a solution is useful in the general case. 07:44
One of jnthn's talks demonstrated a program that concurrently processed images and uploaded them 07:45
you can't do that with STM, because the "upload" side of it has actions that can't be rolled back
er you can't do that *concurrently* with STM
the pypy folks seem to have a design that lets them detect things that can't be run in a transaction, and ensure that they they never need to be rolled back
(that's cool) 07:46
but you can't do more than one of those things concurrently
(not so cool, and rather defeats the aim of having STM)
upshot - I'm not betting on STM being of practical use to me in the foreeable future.
other approaches will be 07:47
moritz it's kinda the antithesis to the GIL 07:50
the GIL works fine if you're IO bound, but not if you're CPU bound
STM seems to be a good approach for things that stay in the CPU and memory, but not good for IO bound workloads
nwc10 I'd never thought of it that way. That's a nice way of looking at it
moritz is proud to have some self-discovered insight at last :-) 07:53
08:17 Unavowed joined 08:18 zakharyas joined
lizmat in the original S17 draft I worked on in 2005, I saw STM as something that required cooperation of objects 08:39
in the current world I would say, they would need to have a role STM mixed in
if an object didn't have that role mixed in and was changed during a transaction, it would bomb 08:40
given this, I still think it would be relatively easy to implement STM in Perl 6 08:41
but there are more urgent matters now :-)
FROGGS could be an interesting experiment at least 08:57
that might also be a good spot where Perl 6 can become useful in studies, given it has proper meta models etc 08:58
studies/schools in general*
lizmat I guess it would be similar in approach as the debugger 09:00
09:36 diakopter____ joined 10:23 donaldh joined, zakharyas joined 11:25 domidumont1 joined 12:36 zakharyas joined
hoelzro o/ #moarvm 12:44
jnthn o/ hoelzro
hoelzro o/ jnthn 12:45
nwc10 good *, #moarvm 12:46
hoelzro o/ nwc10
jnthn On STM: it tries to make mutating shared state more manageable, but in Perl 6 we've kinda encouraged people to not have shared state and instead exchange messages. In no small part because the latter will scale better. 12:48
It's not an accident that things that are centered around mutable shared state management are in the ecosystem rather than in core (OO::Monitors for example) 12:49
nwc10 when I read "scale better" I assumed you meant to more CPU cores 13:26
but the next utterances suggest's it's equally about scaling to more wetware
jnthn It's both, I think :) 13:27
13:33 synopsebot6 joined 14:12 FROGGS joined 17:35 zakharyas joined 17:56 domidumont joined 19:06 lizmat joined 19:08 FROGGS joined
timotimo jnthn: what kind of questions does one want to answer by using a heap profiler? 19:19
i'm imagining you'd want to know how much memory in total a given object/root/frame/whatever directly and indirectly references, for example? 19:20
and i suppose you'd want to follow links from any given object through the whole object graph?
jnthn timotimo: Well, first of all I want to find out why we can't GC EVAL'd things :) 19:22
timotimo i imagine diffing between heap snapshots could prove extremely difficult 19:23
what with objects moving around in the nursery and spaces in the gen2 being re-usable, and objects not being uniquely identified in the heap snapshot 19:24
jnthn Yeah, though you can find trends more easily
timotimo at least the permanent roots are ... permanent :)
and unlikely to change
i already have a local change for rakudo to make its extension libs use the new API for gc perma roots, but i don't know how to properly #if to make the code backwards-compatible 19:26
so pushing that'll only happen to a branch, or after the heap profiler has been merged and we can bump
i imagine building the frontend in perl6 isn't very plausibly a good idea, given how much data we're talking about here ... 19:28
it'd probably also be hard to build it in JS ... the profiler already has big problems when its data files reach past a megabyte
so perhaps it's a job for C++ and Qt
jnthn timotimo: D'oh...I'll probably have to keep the existing API and add a new one too, since Moar is menat to keep working 19:30
With older Rakudos 19:31
We'd probably get away with it at the moment, though. :)
timotimo mhm
jnthn On frontends: I'll likely build one that serves my immediate needs, and will, as with most things I built, encourage others to build other frontends too :) 19:32
19:39 zakharyas joined 19:41 Ven joined 19:43 vendethiel joined 19:47 mojca joined
arnsholt For truly massive things, I guess there's always the old standby of dumping things to kcachegrind format and using that as a frontend 20:00
20:19 lizmat joined 20:24 vendethiel joined
timotimo good point 20:44
i've never used kcachegrind for memory profiling at all 20:45
arnsholt I've not used it for that either, but I'm pretty sure there's a bit of it for that 20:56
22:48 vendethiel 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!