Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-17

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:12 Unavowed_ joined #moarvm
00:54 colomon joined #moarvm
01:00 pochi_ joined #moarvm
01:05 geekosaur joined #moarvm
01:13 colomon joined #moarvm
01:21 colomon joined #moarvm
02:25 dalek joined #moarvm
02:25 harrow` joined #moarvm
03:06 mojca joined #moarvm
03:09 geekosaur joined #moarvm
04:42 geekosaur joined #moarvm
06:59 domidumont joined #moarvm
06:59 FROGGS joined #moarvm
07:00 nwc10 I missed this (and thanks Google for always redirecting me to this TLD): https://morepypy.blogspot.co.at/2016/03/pypy-50-released.html
07:01 nwc10 version number acceleration - presumably 7.0 is pretty soon and their version numbers will be in ℵ not long after that
07:02 nwc10 a commentator wondered where pypy3 5.0 is(n't), and no commentator there wondered where their STM work has got to
07:02 nwc10 but I'm wondering this.
07:04 domidumont joined #moarvm
07:43 * moritz suspects that STM is a *hard* problem, and probably needs years to mature
07:44 * nwc10 isn't even sure if a solution is useful in the general case.
07:45 nwc10 One of jnthn's talks demonstrated a program that concurrently processed images and uploaded them
07:45 nwc10 you can't do that with STM, because the "upload" side of it has actions that can't be rolled back
07:45 nwc10 er you can't do that *concurrently* with STM
07:45 nwc10 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
07:46 nwc10 (that's cool)
07:46 nwc10 but you can't do more than one of those things concurrently
07:46 nwc10 (not so cool, and rather defeats the aim of having STM)
07:46 nwc10 upshot - I'm not betting on STM being of practical use to me in the foreeable future.
07:47 nwc10 other approaches will be
07:50 moritz it's kinda the antithesis to the GIL
07:50 moritz the GIL works fine if you're IO bound, but not if you're CPU bound
07:50 moritz STM seems to be a good approach for things that stay in the CPU and memory, but not good for IO bound workloads
07:50 nwc10 I'd never thought of it that way. That's a nice way of looking at it
07:53 * moritz is proud to have some self-discovered insight at last :-)
08:17 Unavowed joined #moarvm
08:18 zakharyas joined #moarvm
08:39 lizmat in the original S17 draft I worked on in 2005, I saw STM as something that required cooperation of objects
08:39 lizmat in the current world I would say, they would need to have a role STM mixed in
08:40 lizmat if an object didn't have that role mixed in and was changed during a transaction, it would bomb
08:41 lizmat given this, I still think it would be relatively easy to implement STM in Perl 6
08:41 lizmat but there are more urgent matters now  :-)
08:57 FROGGS could be an interesting experiment at least
08:58 FROGGS that might also be a good spot where Perl 6 can become useful in studies, given it has proper meta models etc
08:58 FROGGS studies/schools in general*
09:00 lizmat I guess it would be similar in approach as the debugger
09:36 diakopter____ joined #moarvm
10:23 donaldh joined #moarvm
10:23 zakharyas joined #moarvm
11:25 domidumont1 joined #moarvm
12:36 zakharyas joined #moarvm
12:44 hoelzro o/ #moarvm
12:44 jnthn o/ hoelzro
12:45 hoelzro o/ jnthn
12:46 nwc10 good *, #moarvm
12:46 hoelzro o/ nwc10
12:48 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:49 jnthn 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)
13:26 nwc10 when I read "scale better" I assumed you meant to more CPU cores
13:26 nwc10 but the next utterances suggest's it's equally about scaling to more wetware
13:27 jnthn It's both, I think :)
13:33 synopsebot6 joined #moarvm
14:12 FROGGS joined #moarvm
17:35 zakharyas joined #moarvm
17:56 domidumont joined #moarvm
19:06 lizmat joined #moarvm
19:08 FROGGS joined #moarvm
19:19 timotimo jnthn: what kind of questions does one want to answer by using a heap profiler?
19:20 timotimo 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 timotimo and i suppose you'd want to follow links from any given object through the whole object graph?
19:22 jnthn timotimo: Well, first of all I want to find out why we can't GC EVAL'd things :)
19:23 timotimo i imagine diffing between heap snapshots could prove extremely difficult
19:24 timotimo 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
19:24 timotimo at least the permanent roots are ... permanent :)
19:24 timotimo and unlikely to change
19:26 timotimo 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 timotimo so pushing that'll only happen to a branch, or after the heap profiler has been merged and we can bump
19:28 timotimo 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 timotimo 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
19:28 timotimo so perhaps it's a job for C++ and Qt
19:30 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:31 jnthn With older Rakudos
19:31 jnthn We'd probably get away with it at the moment, though. :)
19:31 timotimo mhm
19:32 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:39 zakharyas joined #moarvm
19:41 Ven joined #moarvm
19:43 vendethiel joined #moarvm
19:47 mojca joined #moarvm
20:00 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:19 lizmat joined #moarvm
20:24 vendethiel joined #moarvm
20:44 timotimo good point
20:45 timotimo i've never used kcachegrind for memory profiling at all
20:56 arnsholt I've not used it for that either, but I'm pretty sure there's a bit of it for that
22:48 vendethiel joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary