Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-27

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

All times shown according to UTC.

Time Nick Message
00:29 hoelzro joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:28 zakharyas joined #moarvm
05:57 domidumont joined #moarvm
06:01 domidumont joined #moarvm
07:20 domidumont joined #moarvm
09:04 jnthn morning, #moarvm
09:05 moritz \o jnthn
09:20 nwc10 you stop reading it for 2 days because nothing happened, and then something does: https://blog.pyston.org/
09:23 dalek MoarVM: ae8d383 | (Pawel Murias)++ | src/6model/serialization.c:
09:23 dalek MoarVM: Serialize hll role.
09:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ae8d383863
09:23 dalek MoarVM: 94ade9f | (Pawel Murias)++ | src/6model/serialization.c:
09:23 dalek MoarVM: Remove an empty else branch.
09:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/94ade9f269
09:23 dalek MoarVM: 134ed39 | jnthn++ | src/6model/serialization.c:
09:23 dalek MoarVM: Merge pull request #370 from pmurias/serialize-hll-role
09:23 dalek MoarVM:
09:23 dalek MoarVM: Serialize hll role.
09:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/134ed39562
09:24 jnthn And ruling on the versioning question is in the issue. :)
09:25 nwc10 http://hhvm.com/blog/ still dull
09:28 jnthn I guess that kinda drives home that the choice between refcounting and tracing is not something you can abstract away for real world programs.
09:42 nwc10 yes
09:43 nwc10 and I guess what you said is another way of thinking what I thought - once you've set off down the road of "reference counting", and exposed the side effects of the behaviour of it to your API users, there's really no going tback
09:44 jnthn Right.
09:45 nwc10 except pypy seems to think otherwise (on the "no going back")
09:45 nwc10 so I wonder how this will pan out
09:45 nwc10 useful that both are re-implementations of the same language
09:50 jnthn Another thing worth noting is that it was C extension support that seemed to partly push them towards refcounting
09:50 jnthn At least iiuc
09:51 jnthn " But applying a tracing GC to a refcounting C API, such as the one that Python has, is risky and comes with many performance pitfalls."
09:51 jnthn Not sure if there's another way to read that
09:51 nwc10 yes. I'd missed that nuance.
09:51 nwc10 But pypy thinks that it can do clever hacks in its GC to support the C API
09:51 nwc10 maybe they can
09:52 nwc10 maybe it's that they aren't starting out from the "can we run CPAN" equivalent
09:52 dalek MoarVM: 6627a8a | jnthn++ | src/ (6 files):
09:52 dalek MoarVM: Avoid VMNull setup memcpy/loop in spesh'd frames.
09:52 dalek MoarVM:
09:52 dalek MoarVM: Just shove in `null` instructions for all object registers when we
09:52 dalek MoarVM: compute the CFG, but before forming SSA. Then, let dead instruction
09:53 dalek joined #moarvm
09:54 jnthn Feels like the Perl 6 approach (you write things with native parts using NativeCall, rather than as VM extensions) is side-stepping those things fairly nicely.
09:55 jnthn Those commits were a rebase/merge of jnthn/opts that I worked on last week but didn't want in before the release
09:55 jnthn I see a couple of seconds off Rakudo build time
09:55 jnthn And around 30 KB off Rakudo base memory
09:57 cognominal joined #moarvm
10:03 arnsholt Heh, a high-performance compiler moving from tracing GC to refcounting is pretty amusing
10:04 arnsholt But given that they want 100% compatibility with CPython, I can see why you'd end up doing that
10:12 dalek MoarVM/fix_cache_sc_idx: 628f734 | diakopter++ | src/6model/s (2 files):
10:12 dalek MoarVM/fix_cache_sc_idx: write sc idx when deserializing, repossessing, and preparing to serialize
10:12 dalek MoarVM/fix_cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/628f734671
10:12 jnthn So, that's a rebase of a patch from diakopter++ that shaves a LOAD of Rakudo build time, but breaks all the nativecall tests on my Windows box. Going to see if I can figure out why so we can get the nice win :)
10:23 jnthn Explodes in my Linux VM too.
10:36 moritz what LOAD are we talking about?
10:40 jnthn 11s
10:40 jnthn m: say 101 / 112
10:40 camelia rakudo-moar 5638a1: OUTPUT«0.901786␤»
10:40 jnthn 10%
10:40 jnthn oh, and s/LOAD of/LOAD off/ :)
11:07 jnthn hm, I may have fixed it :)
11:08 dalek MoarVM/fix_cache_sc_idx: 3d8c9cd | jnthn++ | src/6model/sc.c:
11:08 dalek MoarVM/fix_cache_sc_idx: Only used cached SC index if SC itself matches.
11:08 dalek MoarVM/fix_cache_sc_idx:
11:08 dalek MoarVM/fix_cache_sc_idx: This fixes various mis-lookups that result from repossession.
11:08 dalek MoarVM/fix_cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/3d8c9cd6ef
11:08 dalek MoarVM/fix_cache_sc_idx: 400569f | jnthn++ | src/6model/sc.c:
11:08 dalek MoarVM/fix_cache_sc_idx: Add missing index update after repossession.
11:08 dalek MoarVM/fix_cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/400569f693
11:10 nwc10 jnthn: will let current test finish before testing that
11:10 nwc10 I wonder if the Pyston reference counting "thing" is also part of the more general problem of "how do you wrap a C API in a language with managed memory"
11:11 nwc10 because even if you have a good ffi interface, the wetware has to (correctly) parse the documentation to work out the semantics of who owns memory and how it should be freed
11:11 nwc10 `char **` doesn't tell you very much
11:11 jnthn Yeah, that problem doesn't go away
11:12 jnthn And, with C's type system, can't
11:14 jnthn I was more claiming that a different problem went away (C library bindings have a coupling to the VM)
11:14 jnthn (Because the glue code you write couples to the VM)
11:17 jnthn Yeah, seems much better after my fixes
11:20 * jnthn does a panda install, given these changes affect precomp related cdoe
11:28 jnthn Darn. Tests for NativeHelpers::Blob explode
11:28 jnthn In the same place the ones I fixed earlier
12:03 dalek MoarVM: 306289f | (Jimmy Zhuo)++ | src/ (4 files):
12:03 dalek MoarVM: add a missing prefix for some function
12:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/306289fd8e
12:08 dalek MoarVM/fix_cache_sc_idx: c06b519 | jnthn++ | src/6model/sc.c:
12:08 dalek MoarVM/fix_cache_sc_idx: Missing index update when repossessing STable.
12:08 dalek MoarVM/fix_cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/c06b5198a9
12:15 jnthn That fixes things pretty well
12:27 jnthn JimmyZ: That wasn't really an improvement and created me a conflict to solve :/
12:31 jnthn And fixes post-merge
12:31 jnthn That was about the pessimal time to do that change.
12:31 jnthn Now I should probably retest things
12:31 jnthn But at least I can bitch on IRC while I wait :P
12:32 dalek MoarVM: 628f734 | diakopter++ | src/6model/s (2 files):
12:32 dalek MoarVM: write sc idx when deserializing, repossessing, and preparing to serialize
12:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/628f734671
12:32 dalek MoarVM: 3d8c9cd | jnthn++ | src/6model/sc.c:
12:32 dalek MoarVM: Only used cached SC index if SC itself matches.
12:32 dalek MoarVM:
12:32 dalek MoarVM: This fixes various mis-lookups that result from repossession.
12:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3d8c9cd6ef
12:32 dalek MoarVM: 400569f | jnthn++ | src/6model/sc.c:
12:32 dalek MoarVM: Add missing index update after repossession.
12:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/400569f693
12:32 dalek MoarVM: c06b519 | jnthn++ | src/6model/sc.c:
12:32 dalek MoarVM: Missing index update when repossessing STable.
12:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c06b5198a9
12:32 dalek MoarVM: b0c26d6 | jnthn++ | src/6model/s (2 files):
12:32 dalek MoarVM: Merge branch 'fix_cache_sc_idx'
12:33 jnthn Testing welcome. Shaves a good 10% off Rakudo builds here.
12:34 nwc10 if you make this too fast, no-one will ever be able to get coffee again.
12:35 jnthn I think we've plenty of room for improvement in Rakudo build times still ;)
12:35 jnthn I mean, sure, a full Rakudo build is under 2 minutes, and an NQP build is 35s, but... :)
12:36 JimmyZ jnthn: sorry, I didn't see you your commit before my push
12:36 jnthn JimmyZ: np, I fixed it all up
12:36 jnthn I'm just grumpy today.
12:37 nwc10 I hope you remembered to eat lunch
12:37 jnthn Yes :)
12:37 nwc10 good
12:39 jnthn The butcher I order lamb from (can't really find it in supermarkets here) turned out to also have potato dumplings filled with smoked meat, which you just have to drop in boiling water for 15 minutes :)
12:39 jnthn Saves me making potato dough
12:40 jnthn Which is a bit tedious :)
12:40 nwc10 you have to know where to find lamb here too
12:40 nwc10 I think I've spotted more horsemeat butchers than places I know that sell lamb
12:40 jnthn Yeah...I was surprised how hard it was to track down.
12:41 lizmat our local sheep herder recently went out of business
12:41 jnthn Aww :(
12:41 lizmat mostly because he actually wasn't allowed to sell the lamb meat
12:42 lizmat from what I understand, that is true for most sheep herds in the NL
12:42 jnthn Oh...
12:42 jnthn Curious.
12:43 jnthn lizmat: btw, if you've a moment and fancy trying a build with MoarVM HEAD, you should see a nice improvement to CORE.setting build time
12:43 lizmat some health regulation based on: we don't know where the sheep have been
12:43 nwc10 cows don't have this problem?
12:43 lizmat jnthn: am in the midst of working on List/Array.iterator
12:43 jnthn lizmat: No hurry :)
12:43 lizmat nwc10: no, because they're always in the "same" meadow
12:45 nwc10 and deer aren't consisdered to be domestic animals, so it doesn't matter where they've been? or are they also not allowed to be sold?
12:45 lizmat most deer that you buy in a shop actually *are* domesticized
12:46 lizmat aka, lived in a single meadow for most of their lives
12:46 lizmat at least over here in the NL
12:46 nwc10 ah OK.
12:49 nwc10 this sounds very much like a rule made up by folks who don't actually understand farming. Presuambly it's very important to have an ISO 9000 audit trail too. Because that's what makes the difference between a quality product and rubbish
12:54 lizmat yup, something like that
13:08 domidumont joined #moarvm
13:11 patrickz joined #moarvm
13:17 jnthn Man, callgrind is fine but slow... :)
13:18 [Coke] (get coffee again) dammit, I'm already out.
13:40 jnthn m: say 417780695 - 416958586
13:40 camelia rakudo-moar a80414: OUTPUT«822109␤»
13:40 jnthn m: say 822109 / 417780695
13:40 camelia rakudo-moar a80414: OUTPUT«0.0019678004␤»
13:40 jnthn Hm, rather modest :)
13:43 nwc10 presumably it's still 0.2% in the right direction
13:46 jnthn Indeed
13:46 jnthn m: say 17855658600 - 17624207945 # for a program sat in a loop invoking lots
13:46 camelia rakudo-moar a80414: OUTPUT«231450655␤»
13:46 jnthn m: say 231450655 / 17855658600
13:46 camelia rakudo-moar a80414: OUTPUT«0.01296231409␤»
13:47 jnthn More than 1% there
13:50 dalek MoarVM: e2e8e03 | jnthn++ | src/core/args.c:
13:50 dalek MoarVM: Remove a memset to clear the args buffer.
13:50 dalek MoarVM:
13:50 dalek MoarVM: The idea of it was to ensure the GC never saw junk there. However, as
13:50 dalek MoarVM: there's no point during argument setup that GC could run, this could
13:50 dalek MoarVM: never happen anyway. Saves a call to memset for every single invoke.
13:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e2e8e03739
13:50 jnthn The first number was for Rakudo startup, fwiw
14:14 brrt joined #moarvm
14:16 nwc10 brrt: I think https://blog.pyston.org/ will interest you
14:16 brrt yes
14:16 brrt yes it does
14:17 brrt it was from reading the backlog that i came here, in fact
14:17 brrt :-)
14:17 brrt i think... i claimed, some months ago, that the end stage of Pyston is as a CPython module
14:17 jnthn ooh, brrt
14:17 brrt ohai jnthn, nwc10 :-)
14:17 jnthn Maybe you can tell me why my JIT patch is silly and fails :)
14:18 brrt which patch is that
14:19 jnthn brrt: https://gist.github.com/jnthn/59bcc1dd9eb348ca60ebc78b678f25b4
14:20 jnthn I got rid of the memset in MVM_args_prepare, making it tiny
14:20 jnthn Inlining that C function into the interpreter was easy enough
14:20 jnthn Then I figured we can get rid of a call in the JIT too and save a bunch of instructions per invocation :)
14:21 brrt ok, got it :-)
14:21 jnthn But I think I'm doing something wrong
14:21 jnthn In the JIT bit
14:21 jnthn I don't see what :)
14:21 jnthn The symptom is almost as if the "mov FRAME:TMP5->cur_args_callsite, CALLSITE:TMP6;" doesn't happen
14:22 brrt hmmm
14:23 brrt not sure if the CALLSITE: before TMP6 is necessary
14:23 jnthn I wasn't either, that was added to see if it was to blame :)
14:23 jnthn Well, if it's ommision was to blame :)
14:23 jnthn Am I doing that array lookup right above it?
14:24 brrt not 100% sure
14:24 brrt let me check the docs
14:24 jnthn Certainly, if in
14:24 jnthn | mov TMP6, CALLSITE:TMP6[callsite_idx];
14:24 jnthn I remove CALLSITE, then the build explode
14:24 jnthn *explodes
14:25 jnthn (Fails at the dynasm stage)
14:25 brrt https://corsix.github.io/dynasm-doc/reference.html#_type
14:25 brrt the thing is, CALLSITE:TMP6[callsite_idx] expands to
14:25 brrt [reg + sizeof(ctype)*imm32]
14:26 jnthn Oh
14:26 brrt which in this case is [reg+sizeof(MVMCallSite)*imm32]
14:26 jnthn And this is an array of pointers to callsites
14:26 brrt aye
14:26 brrt that should make some difference
14:27 brrt and CALLSITE:TMP6 should expand to 'name:reg...[reg + (int)(ptrdiff_t)&(((ctype*)0)...)]'
14:27 jnthn Indeed, it works now I fix that :)
14:27 brrt which isn't what you want either; you just want the pointer itself
14:27 brrt ok, great :-)
14:28 jnthn Yeah, now I got
14:28 jnthn +|.type CALLSITEPTR, MVMCallsite*
14:28 jnthn And
14:28 jnthn +    | mov TMP6, CALLSITEPTR:TMP6[callsite_idx];
14:28 jnthn :)
14:28 jnthn Thanks!
14:28 brrt great :-) yw
14:29 * brrt is always happy when folks work on the JIT without my intervention :-)
14:30 brrt ok, the really interesting bit about Pyston is written almost between the lines
14:30 brrt performance in python is numpy performance
14:31 brrt all the rest doesn't really matter
14:32 brrt everything that can't be solved efficiently with numpy (or other compiled libraries like pygame) can be solved by using A Better Algorithm
14:32 brrt and you know, that is pretty much true; that's is precisely what I also found in using python for network analysis
14:33 brrt so any python runtime that makes numpy slower isn't going to be used by the only people who care about python performance in the first place....
14:34 colomon joined #moarvm
14:34 brrt but, it is fascinating work, and i especially admire their (for lack of a better word) 'agile' adaptation against changing conditions
14:34 timotimo that incidentally means that perl6 is fast enough for all things python is fast enough for by using Inline::Python :P
14:36 brrt perl6 is fast enough once we port numpy?
14:36 brrt nump6
14:36 brrt we should totally have that
14:36 jnthn m: say "Another {416958586 - 416859701} CPU cycles off startup"
14:36 camelia rakudo-moar e5bd09: OUTPUT«Another 98885 CPU cycles off startup␤»
14:36 jnthn But I didn't expect much there :)
14:37 brrt \o/
14:37 brrt what kind of percentage is that
14:38 jnthn m: say "Another {17624207945 - 17534022355} off the hot invoke loop program"
14:38 camelia rakudo-moar e5bd09: OUTPUT«Another 90185590 off the hot invoke loop program␤»
14:38 jnthn m: say 90185590 / 17624207945
14:38 camelia rakudo-moar e5bd09: OUTPUT«0.00511714287␤»
14:38 brrt 0,5%
14:38 jnthn That's in addition to the earlier larger win from removing memset
14:38 brrt little bits help, at least when they multiply
14:39 jnthn m: say 17855658600 - 17534022355
14:39 camelia rakudo-moar e5bd09: OUTPUT«321636245␤»
14:39 jnthn m: say 321636245 / 17855658600
14:39 camelia rakudo-moar e5bd09: OUTPUT«0.01801312694␤»
14:39 jnthn 1.8% overall
14:39 brrt not bad, not bad
14:39 timotimo i almost didn't get to open up my laptop yesterday during the GPN
14:39 timotimo but now i get to build all these nice patches y'all have :D
14:40 dalek MoarVM: 494b4e4 | jnthn++ | src/ (4 files):
14:40 dalek MoarVM: Inline args preparation into interpreter, JIT.
14:40 dalek MoarVM:
14:40 dalek MoarVM: Shaves some more instructions off every invocation. The C compiler
14:40 dalek MoarVM: may have got to the inline into interp.c anyway, but the JIT one will
14:40 dalek MoarVM: certainly save a bunch of instructions per invocation.
14:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/494b4e44cf
14:43 jnthn Hm, wow, all the lookups of &EXHAUST being late bound costs us a bit
14:44 brrt lizmat: we still have a herder in Groningen, for grass cutting without trimmer noise
14:45 timotimo jnthn: can you tell me how you measured that/figured it out?
14:46 jnthn callgrind showed MVM_frame_find_lexical_by_name up, I added a printf
14:47 timotimo ah, makes sense
14:58 brrt anyway, i'm off
14:59 brrt just to make you jealous, i'll tel you i'm making falafel
14:59 brrt see you :-)
15:00 jnthn ooh :)
15:00 jnthn Though talking of nice food things, I got a fresh bag of dried kashmiri chillies delivered today :)
15:05 jnthn Wow. We don't even inovke EXHAUST on Moar
15:05 jnthn Or JVM
15:05 jnthn That approach dates back to the Parrot days o.O
15:05 jnthn So that code is doing nothing at all
15:06 nwc10 what *is* EXHAUST? or shall I wait for the blog post? :-)
15:06 nwc10 (google failed me)
15:08 jnthn I'm still getting to the bottom of it :)
15:08 psch i remember trying to figure out what EXHAUST does a few times
15:08 jnthn But in summary: the original way return was done on Parrot was you took a "continuation"
15:09 jnthn That when invoked would go to a return handler
15:09 psch but if it's not invoked on either current backend...
15:09 jnthn And then you stored it in a lexical
15:09 jnthn And so you could properly, lexically, resolve returns, not dynamicly
15:10 jnthn Now, at the point of an actual return happening that was replaced by &EXHAUST
15:10 jnthn Which if invoked would say "you already returned from this routine"
15:11 jnthn To be a better error than "you aren't even in a routine at all"
15:11 nwc10 OK, I think that makes sense.
15:11 nwc10 first reference to EXHAUST that I find is commit dc16a4fc72a1eaa8309b7de948607a9ca7c0a1e4
15:11 jnthn But it turns out EXHAUST threw the exact same error as not being in a routine at all
15:11 nwc10 +sub EXHAUST(|$) {
15:11 nwc10 +    die "Attempt to return from exhausted Routine"
15:11 nwc10 +}
15:12 jnthn And we didn't actually invoke it
15:12 jnthn And there's surely a lot of better ways to handle this :)
15:12 * jnthn does the smallest fix first
15:13 nwc10 a ristretto? :-)
15:13 jnthn Except that small thing busts it too. o.O
15:21 jnthn Um...unovers a spesh inline bug, it seems
15:26 jnthn Which I think I'm a bit tired to find right now :)
15:26 jnthn But generally I think `return` handling wants a larger look over
15:26 jnthn In so far as it'd be nice if we could kill off the whole lexotic thing in favor of a normal exception handler
15:27 jnthn Since we already have have those resolved as static rather than dynamic
15:27 jnthn That in turn means that we can look at inlining return
15:28 jnthn Since we could turn it into a normal multi
15:28 jnthn And that in turn means spesh should be able to, maybe with a little more effort, rewrite the return into a "goto"-alike
15:29 jnthn Anyway, think that's for next week.
15:29 jnthn When I'll have a good bit more Perl 6/MoarVM time than this week.
16:32 domidumont joined #moarvm
17:05 timotimo great. i know from experience that eliminating returns at the end of a sub was always a noticable improvement in performance
17:05 timotimo and i never really understood how EXHAUST etc really worked
19:12 mohij joined #moarvm
20:18 patrickz joined #moarvm
21:20 janktopus joined #moarvm
22:13 vendethiel joined #moarvm
22:49 Ven joined #moarvm
22:49 ggoebel114 joined #moarvm
22:55 Ven joined #moarvm

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