Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-01-22

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

All times shown according to UTC.

Time Nick Message
01:09 lue joined #moarvm
01:35 lue joined #moarvm
01:59 ingy1 joined #moarvm
02:07 camelia joined #moarvm
04:00 tadzik joined #moarvm
06:42 rurban joined #moarvm
08:02 nwc10 jnthn: I think your list is incomplete - also, a year ago, we didn't have Rakudo working, did we?
08:07 zakharyas joined #moarvm
08:11 FROGGS joined #moarvm
08:18 kjs__ joined #moarvm
09:09 kjs__ joined #moarvm
09:16 jnthn nwc10: Perhaps not fully; I think the first monthly went with the first Rakudo release that had some level of support.
09:30 brrt joined #moarvm
09:53 timotimo congratulations all around
09:54 timotimo "sp_guad"? :)
09:54 jnthn Context? :)
09:55 timotimo the changelog
09:55 FROGGS what changelog?
09:56 FROGGS this? https://github.com/MoarVM/MoarVM/blob/master/docs/ChangeLog
09:56 jnthn http://cdn.meme.am/instances/500x/58344467.jpg
09:57 FROGGS :P
09:57 timotimo the last dalek message
09:57 jnthn Found it :)
09:58 jnthn hah, the typo was from the commit log :)
09:58 dalek MoarVM: d1ed753 | jnthn++ | docs/ChangeLog:
09:58 dalek MoarVM: Fix typo; timotimo++.
09:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d1ed7537bc
10:05 * timotimo is AFK again
10:35 LLamaRider joined #moarvm
12:12 brrt joined #moarvm
12:27 rurban joined #moarvm
13:57 zakharyas joined #moarvm
14:04 jnthn Anyway have any release blockers?
14:07 dalek MoarVM: 104e48e | jnthn++ | VERSION:
14:07 dalek MoarVM: Bump VERSION.
14:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/104e48e949
14:18 jnthn Well, clean NQP and Rakudo spectest with that commit (on Linux).
14:22 jnthn http://moarvm.org/releases/MoarVM-2015.01.tar.gz
14:23 lizmat jnthn++  :-)
14:24 jnthn Tagged in the git repo also.
14:44 dalek moarvm.org: 1cfbe69 | jnthn++ | / (3 files):
14:44 dalek moarvm.org: Update site for 2015.01 release.
14:44 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/1cfbe6985d
14:45 nwc10 Result: PASS
14:45 nwc10 (also Linux)
14:47 jnthn phew ;)
14:47 jnthn OK, release process done.
14:47 jnthn Time to break stuff again! :P
14:50 FROGGS declaration after code ftw! /o/
14:52 brrt joined #moarvm
14:55 brrt ehm... what would be a really convincing reason *not* to redo the whole JIT using llvm
14:56 brrt context: i'm writing a blog post on future JIT improvements, and I find I'm not so well able to answer this question
14:57 brrt more context: I want to make these plans in the open, so as to hopefully inspire people to hack on perl6 and the moar-jit
15:04 moritz llvm is a big dependency, for one
15:05 moritz second, redoing sounds like a whole lot of work
15:07 brrt true....
15:07 JimmyZ well, it's very easy, it's C++, and jnthn++ doesn't like it.
15:08 JimmyZ :P
15:08 brrt on the other hand... moarvm has a history of using modern libraries rather than reinventing the wheel
15:09 brrt is 'it's very easy' a reason or your judgement of the reasons
15:09 brrt i'm not very fond of C++ myself
15:09 brrt i'm trying to make the case as an disinterested outsider
15:09 brrt :-)
15:12 brrt s/an/a/
15:12 nwc10 summon leont
15:12 brrt where does he lurk
15:12 moritz #p5p?
15:12 nwc10 and #perl6
15:13 brrt i'll take this to #perl6 then
15:30 jnthn The issue isn't whether I like C++, it's whether I know it well enough or have the experience to make good design decisions if we build stuff using it. I don't.
15:31 jnthn We use modern libraries where it's in a non-strategic area, for sure.
15:32 jnthn Abstracting I/O, threads, and atomic ops, or building a better hash implementation, or FFI implementation, is not core domain.
15:33 jnthn We don't use, say, ICU, 'cus that's an area we're looking to do something innovative (of note, NFG)
15:33 jnthn And the dynamic optimization and JIT stuff is also quite core.
15:43 brrt fair enough. but you could argue that dynamic optimization is core and yet code generation is not
15:44 jnthn You could
15:49 jnthn But then, we ain't re-invented the whole wheel there either.
15:49 jnthn (Using dynasm)
15:49 brrt that is true
15:49 jnthn Which is a very light dependency.
15:49 moritz brrt: what are the arguments in favor of using LLVM?
15:49 moritz brrt: and what has changed since the original implementation?
15:50 jnthn I know some time back, LLVM + precise GC could be some fun; maybe things are better there now.
15:50 brrt the argument is basically this - if we want moarvm to be faster, we'll need to move from our current JIT representation to something that is much closer to the metal
15:51 brrt what has changed is that the original implementation is half a year old and we're ever looking for improvements :-)
15:53 brrt so, suppose I'd tell an outsider 'our JIT is much to simplistic and can't do any optimizations', they'd be likely to answer 'why don't you just use LLVM'
15:53 brrt the GC issue is an issue, yes
15:54 brrt *not* that i'd like to throw away all the hard work done on the JIT just yet :-)
15:55 jnthn Well, when most people say JIT they mean not just the code-gen, but also the bits we tend to call spesh
15:55 jnthn It's the code-gen that doesn't yet do any optimizations.
15:56 * brrt nods
15:57 brrt that is very much true. And if we'd ever do a 'trace JIT', then we'd almost certainly do the trace part on the spesh level
15:57 jnthn Aye
15:58 brrt which, I think, is a pretty good design, all things considered
16:02 rurban joined #moarvm
16:04 dalek MoarVM: e7fb495 | Carlin++ | src/ (2 files):
16:04 dalek MoarVM: replace some rogue free()s with MVM_free()
16:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e7fb4953fb
16:04 dalek MoarVM: c43f6a9 | jnthn++ | src/ (2 files):
16:04 dalek MoarVM: Merge pull request #169 from carbin/free-as-in-mvm_free
16:04 dalek MoarVM:
16:04 dalek MoarVM: replace some rogue free()s with MVM_free()
16:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c43f6a9848
17:18 zakharyas joined #moarvm
17:27 tgt joined #moarvm
17:52 njmurphy joined #moarvm
18:32 FROGGS joined #moarvm
18:33 FROGGS_ joined #moarvm
19:25 kjs__ joined #moarvm
20:11 brrt joined #moarvm
20:37 timotimo oops, two of these were mine
20:37 japhb joined #moarvm
20:38 jnthn Rouge coder!
20:48 kjs__ joined #moarvm
21:21 kjs__ joined #moarvm
21:23 japhb Rouge coder?
21:24 TimToady better red than dead code
21:25 timotimo the best code is read code
21:26 japhb "read code" sounds like someone with a head cold saying "head cold"
21:37 dalek MoarVM: b40762a | jnthn++ | Configure.pl:
21:37 dalek MoarVM: Bump default optimization level to -O2.
21:37 dalek MoarVM:
21:37 dalek MoarVM: We've been on -O1 for a while. Bumping to -O2, Rakudo and NQP build
21:37 dalek MoarVM: and spectest/test just fine with both clang and GCC these days,
21:37 dalek MoarVM: maybe thanks to the Great Warnings Fixing. Since this is happening
21:37 dalek MoarVM: post-release, there's maximal time for feedback if it causes anyone
21:37 dalek MoarVM: issues.
21:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b40762a2e8
21:38 timotimo fwiw, i've been building on -O3 for the longest time
21:38 jnthn m: say 766900362 / 854208697
21:38 camelia rakudo-moar 23c963: OUTPUT«0.8977903933␤»
21:38 jnthn 10% less instructions ran at startup just by switching to -O2 from -O1.
21:38 jnthn timotimo: Ah, maybe if all is well with -O2 this month, we can try -O3 next... :)
21:40 timotimo :)
21:40 timotimo does going to -O2 make the recent patches by nicholas less "effective"? :)
21:44 jnthn Hard to say; MVM_serialization_read_varint drops lower still in the table
21:50 timotimo how far down is it, ooc?
21:50 jnthn It's 8th
21:51 jnthn So really quite hot
21:51 jnthn Though that doesn't say anything about actual time
21:51 timotimo oh my
21:51 timotimo fair enough
21:51 jnthn bind_key is top
21:53 timotimo mhm, we stash lots of stuff into hashes
22:14 jnthn m: say 760773418 / 766900362
22:14 camelia rakudo-moar 23c963: OUTPUT«0.9920107692␤»
22:15 japhb Is that for -O3?
22:15 jnthn No
22:15 jnthn It's for me not being a moron when doing graph programming.
22:15 japhb Go on, drop the other shoe ....
22:15 japhb heh
22:15 japhb Moron penalty: 0.8%
22:16 dalek MoarVM: 961f584 | jnthn++ | src/spesh/graph. (2 files):
22:16 dalek MoarVM: Cache rpo_idx on BBs, rather than recomputing it.
22:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/961f5842bd
22:16 dalek MoarVM: a29eaa9 | jnthn++ | src/spesh/graph.c:
22:16 dalek MoarVM: Inline rpo_idx; it's far neater this way.
22:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a29eaa9581
22:16 jnthn Dominance is a bit less time-consuming now. :)
22:18 japhb I read a story a long time ago, where one of the authors of x264 had a big wall chart of all the functions that made up the core encoding loop, and he had them marked with little squares, each of which indicated 100 CPU cycles per macroblock.
22:18 japhb As he optimized, he would cross off each square he managed to remove from the core loops.
22:18 japhb (And I sometimes wonder if he had thresholds for celebration as well.)
22:18 jnthn :)
22:19 timotimo is that noticable?
22:19 timotimo just the instruction count seems not as amazing, but it doesn't 1:1 cpu time of course
22:19 jnthn I didn't really check, though it was hunting through an array and so somewhat memory-bound.
22:20 japhb True, but 1:1 is actually not a bad first approximation for a modern processor, not counting context switches and other cache-destroying events
22:20 timotimo fair enough :)
22:44 rurban joined #moarvm
23:00 kjs__ joined #moarvm
23:00 brrt joined #moarvm

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