Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2018-01-09

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

All times shown according to UTC.

Time Nick Message
01:09 lizmat joined #moarvm
01:16 nativecallable6 joined #moarvm
01:17 unicodable6 joined #moarvm
01:17 quotable6 joined #moarvm
02:19 FROGGS joined #moarvm
02:27 Kaiepi joined #moarvm
03:04 ilbot3 joined #moarvm
03:04 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:57 bloatable6 joined #moarvm
06:41 domidumont joined #moarvm
06:49 domidumont joined #moarvm
07:01 brrt joined #moarvm
07:16 ggoebel joined #moarvm
07:31 domidumont joined #moarvm
07:42 brrt good * #moarvm
07:51 domidumont joined #moarvm
08:16 brrt joined #moarvm
08:30 domidumont joined #moarvm
08:46 zakharyas joined #moarvm
09:04 zakharyas joined #moarvm
09:05 zakharyas joined #moarvm
10:12 jnthn o/ #moarvm
10:40 zakharyas joined #moarvm
11:22 zakharyas joined #moarvm
11:35 Geth ¦ MoarVM/jit-expr-optimizer: f6a2d57e0a | (Bart Wiegmans)++ | 2 files
11:35 Geth ¦ MoarVM/jit-expr-optimizer: JIT - use apply_template_adhoc everywhere
11:35 Geth ¦ MoarVM/jit-expr-optimizer:
11:35 Geth ¦ MoarVM/jit-expr-optimizer: Much nicer than constructing an array and pushing it, and more importantly,
11:35 Geth ¦ MoarVM/jit-expr-optimizer: I plan to start packing a good deal of information in the expression node
11:35 Geth ¦ MoarVM/jit-expr-optimizer: itself, which would need cooperation of the template
11:35 Geth ¦ MoarVM/jit-expr-optimizer: review: https://github.com/MoarVM/MoarVM/commit/f6a2d57e0a
11:35 brrt \o jnthn
11:36 brrt jnthn; any opinion on the use of bitfields in structs
11:38 jnthn brrt: Hm, I think they're fairly widely supported, so should be fine to use?
11:42 brrt yeah, i think so to
11:43 brrt they're probably nicer to use than 'raw' bitpacking
11:43 jnthn *nod*
12:15 domidumont joined #moarvm
12:56 brrt joined #moarvm
14:08 domidumont joined #moarvm
14:19 ggoebel joined #moarvm
14:19 committable6 joined #moarvm
15:05 zakharyas joined #moarvm
15:34 * [Coke] reads https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/
15:39 jnthn Interesting post
15:39 brrt hmm, maybe i should read that as well
15:40 brrt btw
16:05 jnthn Looks like we need to put something into our make release target that explodes if the work tree isn't clean: https://github.com/MoarVM/MoarVM/issues/778
16:05 [Coke] ooooops
16:08 jnthn Possibly also a 2017.12.1
16:11 brrt joined #moarvm
16:11 squashable6 joined #moarvm
16:21 zakharyas joined #moarvm
16:44 brrt1 joined #moarvm
17:02 AlexDaniel` can't see why 2017.12.1 would be needed, what am I missing?
17:02 AlexDaniel` the tar is wrong, just fix it?
17:05 AlexDaniel` 2017.12.1 point release would mean… a release on exactly the same commit?
17:05 AlexDaniel` and then people will be asking why is there a 2017.12.1 moar but no rakudo…
17:05 [Coke] a 2017.12.1 *tar* is needed to fix the tar, yes? nice to also have a corresponding git commit to track against.
17:06 [Coke] (since we don't want to have two tars with the same name)
17:07 [Coke] We have had in the past, releases where there was a point release of one of the 3 components, but not all 3. I think that's explainable.
17:07 AlexDaniel` yeah also, the same release (but correct tar) is available on github
17:07 AlexDaniel` sooo…
17:07 jnthn But missing 3rdparty/
17:07 AlexDaniel` just fix the file
17:08 AlexDaniel` hmm
17:08 jnthn That's why we do our own tarballs
17:09 AlexDaniel joined #moarvm
17:09 jnthn It's generally understood that release tarballs are immutable, however; I'd rather not violate that.
17:10 [Coke] jnthn++ for restating my intent clearly. :)
17:10 jnthn As for explaining stuff, 2018.01 is like, a week or so away, I guess? :)
17:10 AlexDaniel right
17:10 AlexDaniel releasable6: next
17:10 releasable6 AlexDaniel, Next release in 11 days and ≈1 hour. No blockers. Unknown changelog format
17:11 AlexDaniel but still, uh… rakudo 2017.12 is supposed to work with 2017.12 MoarVM
17:11 AlexDaniel at least, that's what the VERSION file says
17:13 AlexDaniel so… why don't we need rakudo 2017.12.1 then?
17:13 [Coke] VERSION is used by the 'make' process that invokes git, yes? so that part is still fine
17:14 [Coke] (or is VERSION somehow used when building from tarballs?)
17:14 AlexDaniel no, but as a human I'd be using the same tarballed version that is claimed…
17:14 jnthn No, you'd fetch and build the 3 tarballs independently if doing that. If there was a 2017.12 Rakudo Star, *that* would be impacted, however, since it bundles Rakudo/NQP/MoarVM
17:15 AlexDaniel maybe no need to be pedantic about that though…
17:16 jnthn Given the next release is ~10 days away, I don't think so
17:16 AlexDaniel jnthn: So I was thinking… what about having all three releases (moar, nqp, rakudo) done in one go in an automated way?
17:17 AlexDaniel like, it would avoid things like this, possibly
17:17 jnthn AlexDaniel: I'm OK with that in principle.
17:17 jnthn Well, this would have been avoided by a sanity check in "make release" also
17:17 jnthn I don't have time to make it happen, but I'm all for release automation if somebody has the time/motivation to work on it.
17:18 AlexDaniel well, I have a sakefile that I've been using for nqp+rakudo
17:18 AlexDaniel extending it to moarvm should take very little time
17:19 jnthn And uploading the tarball is just a commit to the MoarVM website git repo
17:19 AlexDaniel at the time I was sure that we're doing moarvm releases separately for some good reason?
17:19 jnthn I don't think there was any good reason
17:20 jnthn It's just the way things were :)
17:20 AlexDaniel hmmm ok
17:20 AlexDaniel I'll see what I can do then
17:20 jnthn The MoarVM release was something that I Just Did for some years, and it was pretty easy so I didn't mind :)
17:21 jnthn But I don't in the slightest bit mind having less release chores :)
17:23 coverable6 joined #moarvm
17:23 benchable6 joined #moarvm
17:39 bisectable6 joined #moarvm
17:43 zakharyas joined #moarvm
18:19 zakharyas joined #moarvm
19:39 greppable6 joined #moarvm
20:48 brrt joined #moarvm
20:53 Voldenet joined #moarvm
20:53 Voldenet joined #moarvm
20:59 evalable6 joined #moarvm
21:20 Ven`` joined #moarvm
22:23 brrt joined #moarvm
22:29 TimToady joined #moarvm
22:30 timotimo brrt: i regret that i don't have any good ideas for how to go on with the jit
22:31 brrt ah, but, then i can probably help
22:32 brrt but first, why the question?
22:32 releasable6 joined #moarvm
22:32 statisfiable6 joined #moarvm
22:32 reportable6 joined #moarvm
22:35 brrt or the statement, really
22:35 brrt anything in particular you'd like to achieve
22:38 timotimo no, just you asking about the lisp cond support
22:41 timotimo bbiab
22:51 brrt oh, the cond idea is just a simplification measure
22:51 brrt the idea being that we can express all if/when constructs as COND blocks
22:52 brrt which means that the optimizer can be more regular in the implementation
22:52 brrt or at least, something like that
22:52 brrt wasn't a terribly well-defined idea, in fact
22:53 brrt and the drawback is that COND in it's normal form consists of pairs of ((condition?) (statement))
22:53 brrt well, that doesn't parse in the expr JIT compiler
22:54 brrt so it'd have to be (COND (WHEN (condition?) (STATEMENT)) (WHEN (...) (...)))
22:55 brrt which is fine and still regular, but then we have the second problem, which is that this would naively compile to a conditional jump -> block -> jump -> label ... sequence, and .. i thought you would have fewer jumps by grouping all the conditions
22:56 brrt and the statements
22:56 jnthn Yeah, branches are costly
22:56 brrt i'm not exactly sure what i thought is true
22:56 jnthn So when we can spot opportunities to do calculation instead of flow control, it's preferable
22:57 jnthn A representation that makes that easier for an optimizer to spot opportunities for would seem good
22:57 brrt hmmm
22:59 brrt one way to ensure the grouping of conditions in the generated code is to have the tiler use a specific iteration order for COND
22:59 brrt which, in terms of complexity, has a very water-bed like quality :-)
23:00 brrt jnthn: i found a tidbit you might find interesting
23:04 brrt it turns out the java implementation of HashMap uses a bucket design with a red-black tree to implement the per-bucket set
23:04 brrt since recently, instead of a LinkedList
23:06 jnthn Oh, interesting.
23:06 brrt and at first i thought that it made no sense, because whenever your hash table would be so overfilled as to make this make a difference, you should probably increase the number of buckets rather than switch data structures
23:06 jnthn Indeed
23:06 jnthn But? :)
23:06 brrt however i thought some more about it
23:07 brrt this obviously gives you a O(n log n) worst-case retrieval and modification cost
23:09 brrt and that, in turn, can protect you from some forms of DoS attacks (that would happen if i knew the hash algorithm, and/or hashes wouldn't be sufficiently randomized)
23:09 jnthn Oh, right. Interesting.
23:09 brrt now, nobody does that kind of attack on perl anymore because in perl hashes are randomized
23:09 brrt and i would suspect java hashes are also randomized
23:11 brrt but, what's different is that java programs tend to be relatively long living, and hash tables might be relatively long-living as well, in which case randomization is not sufficient protection anymore
23:12 brrt also, the additional cost of using a binary tree over a linked list, again in java, is not so large (just one more pointer)
23:13 brrt so actually, this kind of makes sense
23:27 jnthn Hm, interesting.
23:37 brrt by the way, do we still do lexical autoviv of objects on first access?
23:37 brrt as in, internally to the VM, rather than with an explicit condition?
23:41 timotimo i only know we'll throw out attribute autoviv
23:44 brrt then, i am all for throwing out lex autoviv as well
23:49 jnthn Yeah, we still do it
23:50 jnthn I'd like not to, but $/ and $! exist in every routine, and not allocating a Scalar every time for them was a big win
23:50 jnthn We need to be sure we can eliminate that in other ways
23:53 brrt well, the obvious other way is to have codegen
23:54 brrt insert an explicit check
23:54 brrt and set
23:54 brrt but that is going to make frames much larger
23:56 jnthn I was more thinking we always allocate them
23:56 jnthn And then if spesh can prove they are never accessed, it just tosses the initialization
23:56 brrt i like that idea
23:59 brrt my alternative idea was to have a sp_getlex that would not autovivify, combined with an autogenerated conditional block with a bindlex
23:59 brrt hmm, doesn't even have to be a full block though
23:59 brrt could be an sp_getlex and an sp_lexautoviv

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