Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-08

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

All times shown according to UTC.

Time Nick Message
01:34 colomon joined #moarvm
01:58 colomon joined #moarvm
02:28 camelia joined #moarvm
05:47 sivoais joined #moarvm
05:57 sivoais joined #moarvm
06:07 diakopter joined #moarvm
06:12 brrt joined #moarvm
06:21 brrt good *
08:14 brrt joined #moarvm
08:28 danaj joined #moarvm
09:01 dalek joined #moarvm
10:12 timotimo good **
10:44 brrt joined #moarvm
12:36 brrt joined #moarvm
13:07 jnthn good * * *
13:19 brrt did you know that stack overflows, in C, are really funky?
13:20 brrt look like any other memory corruption, but suddenly, your stack variables are unreadable
13:20 dalek MoarVM/even-moar-jit: ec738f3 | brrt++ | / (5 files):
13:20 dalek MoarVM/even-moar-jit: Tiles need access to nonterminal values
13:20 dalek MoarVM/even-moar-jit:
13:20 dalek MoarVM/even-moar-jit: A tile may refer to (non)terminals many layers deep in the tree.
13:20 dalek MoarVM/even-moar-jit: The tiler table generator knows which nonterminals these are, and
13:20 dalek MoarVM/even-moar-jit: is perfectly capable of generating 'traces' that show the JIT
13:20 dalek MoarVM/even-moar-jit: where to find them. So I do that.
13:20 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ec738f338b
13:22 jnthn Unreadable in the debugger?
13:22 brrt aye
13:23 brrt not sure... if my tiling logic is now fully correct. but i hope it
13:23 jnthn I guess it ends up with the stack pointer being into unreadable memory, and then can't figure out what to do
13:24 brrt stack values become unreadable, yes :-)
13:24 brrt and you get a segv
13:24 brrt but it's nonobvious that it comes from an overflow :-)
13:24 jnthn Oh?
13:25 jnthn Odd, the MSVC debugger is always quite sure which one it is.
14:44 lucasb joined #moarvm
14:49 lucasb libuv 1.7.0 is out; was there too many errors when brrt++ tried 1.6.1?
14:52 colomon joined #moarvm
14:54 TimToady if you're on a stack-downward machine, overflowing a buffer really goes off into your caller's part of the stack, not into the unallocated stack
14:54 TimToady we'd have less security issues in C if that weren't the case
14:55 TimToady well, first it clobbers your return address, which is how most of those exploits work
14:57 * jnthn wonders where "heap grows up, stack grows down" originates...
15:01 lizmat jnthn: 1K memory  :-)
15:02 lizmat I remember expanding one of my terminal games: adding features would crash the terminal
15:02 lizmat until I figures that the stack was running into the heap with the larger memory footprint  :-(
15:02 lizmat *figured
15:04 jnthn eek
15:04 jnthn :)
15:04 jnthn Well, lots still to do, but I have a first working .race
15:09 dalek MoarVM/vs2015-fixes: 7928a44 | hoelzro++ | src/strings/unicode_db.c:
15:09 dalek MoarVM/vs2015-fixes: Use binary search rather than if/else chains for Unicode block lookup
15:09 dalek MoarVM/vs2015-fixes:
15:09 dalek MoarVM/vs2015-fixes: A large number of if/else chains breaks the VS 2015 compiler.  The
15:09 dalek MoarVM/vs2015-fixes: binary search is quite fast, but it loses to if/else chains in speed
15:09 dalek MoarVM/vs2015-fixes: in a few cases.  We can optimize later if this becomes an issue
15:09 dalek MoarVM/vs2015-fixes: review: https://github.com/MoarVM/MoarVM/commit/7928a44d4e
15:09 dalek MoarVM/vs2015-fixes: de0b40e | hoelzro++ | src/strings/unicode_db.c:
15:09 dalek MoarVM/vs2015-fixes: Address MVM_unicode_is_in_block memory leak
15:09 dalek MoarVM/vs2015-fixes: review: https://github.com/MoarVM/MoarVM/commit/de0b40e440
15:09 dalek MoarVM/vs2015-fixes: d9277bb | hoelzro++ | tools/ucd2c.pl:
15:09 dalek MoarVM/vs2015-fixes: Generate MVM_unicode_is_in_block to use binary search
15:09 dalek MoarVM/vs2015-fixes: review: https://github.com/MoarVM/MoarVM/commit/d9277bb4f8
15:09 dalek MoarVM/vs2015-fixes: 8217892 | hoelzro++ | src/strings/unicode_ (2 files):
15:32 hoelzro good moarning, #moarvm!
15:32 hoelzro I fixed up src/strings/unicode.c so that MoarVM compiles on VS 2015, but now running NQP gives me an access violation =/
15:33 hoelzro would someone else running Windows checkout the vs2015-fixes branch and verify that I didn't break Windows builds entirely? it runs fine on my Linux box
15:57 brrt joined #moarvm
16:56 brrt joined #moarvm
17:37 zakharyas joined #moarvm
18:02 dalek MoarVM/even-moar-jit: 31f5d5d | brrt++ | / (9 files):
18:02 dalek MoarVM/even-moar-jit: Add MVMJitTile data structure
18:02 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/31f5d5d929
18:07 brrt so the good bit about this is that it makes implementing tiles that much simpler
18:36 raiph joined #moarvm
18:51 timotimo o/
19:04 nwc10 jnthn: http://paste.scsys.co.uk/496892 -- t/spec/S17-supply/start.t seems to be able to deadlock with 3 threads waiting
19:09 jnthn That pretty much has to be a Rakudo-level rather than Moar-level bug
19:09 nwc10 OK
19:13 * jnthn made a nice hang with cond-vars while working on race today... :)
19:42 zakharyas joined #moarvm
19:57 nwc10 hoelzro: ASAN (on Linux) can't spot any problems with your branch :-(
20:33 dalek MoarVM/even-moar-jit: cd727b7 | brrt++ | / (5 files):
20:33 dalek MoarVM/even-moar-jit: Add value type to tile
20:33 dalek MoarVM/even-moar-jit:
20:33 dalek MoarVM/even-moar-jit: This signals to the register allocator whether we should allocate
20:33 dalek MoarVM/even-moar-jit: a register and whether we should free it.
20:33 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/cd727b7dc1
20:42 hoelzro nwc10: thanks for checking!
20:44 jnthn Pro tip: beer spashed in eye less pleasurable than beer splashed in mouth
20:48 hoelzro jnthn: sounds unpleasant =/
20:50 jnthn Nothing too serious. :)
21:12 hoelzro jnthn: do you mind if I merge that VS 2015 compiler fix?
21:13 jnthn hoelzro: Hm, I should probably see if it explodes on Windows
21:14 hoelzro jnthn: I managed to compile MoarVM with the fix, but running MoarNQP results in an access violation =/
21:14 hoelzro I'm not sure if that's the compiler's fault, my system, or what
21:14 jnthn Taht sounds nasty
21:14 jnthn *that
21:15 jnthn I'll check an NQP build quickly now
21:15 hoelzro ok, thanks!
21:18 jnthn hoelzro: NQP build and passed make test here with that branch
21:18 jnthn (On Windows, VS 2013)
21:18 hoelzro ok, thanks for checking!
21:18 hoelzro if you don't mind, I'll push that work into master then
21:19 jnthn How bad is the performance loss you noted?
21:20 jnthn Drop in the ocean, or soemthing that anybody will likely notice?
21:20 hoelzro tiny; bsearch is slower on 6 inputs, IIRC, and it's 5-10%
21:21 hoelzro (on just that function)
21:21 hoelzro on most inputs, bsearch is actually faster
21:21 jnthn ah, ok
21:21 jnthn then go for it :)
21:21 hoelzro \o/
21:22 jnthn hoelzro++
21:22 timotimo "on 6 inputs"?
21:22 dalek MoarVM: 7928a44 | hoelzro++ | src/strings/unicode_db.c:
21:22 dalek MoarVM: Use binary search rather than if/else chains for Unicode block lookup
21:22 dalek MoarVM:
21:22 dalek MoarVM: A large number of if/else chains breaks the VS 2015 compiler.  The
21:22 dalek MoarVM: binary search is quite fast, but it loses to if/else chains in speed
21:22 dalek MoarVM: in a few cases.  We can optimize later if this becomes an issue
21:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7928a44d4e
21:22 dalek MoarVM: de0b40e | hoelzro++ | src/strings/unicode_db.c:
21:22 dalek MoarVM: Address MVM_unicode_is_in_block memory leak
21:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/de0b40e440
21:22 dalek MoarVM: d9277bb | hoelzro++ | tools/ucd2c.pl:
21:22 dalek MoarVM: Generate MVM_unicode_is_in_block to use binary search
21:22 hoelzro timotimo: I took a record of all the inputs with which MVM_unicode_is_in_block is called, and benchmarked various implementations with 1000000 calls
21:23 timotimo ah
21:23 hoelzro out of the 195 distinct inputs in roast + rakudo build, 6 were slower with bsearch
21:23 hoelzro most were something like 4x faster
21:23 hoelzro but we're talking 17 vs 20 ns
21:24 * hoelzro .oO( assuming my timing routines were correct )
21:26 timotimo wow, 4x
21:26 timotimo that's pretty nice
21:26 hoelzro yeah, I'm actually surprised
21:27 hoelzro I would expect bsearch to have some overhead from all the function calls its doing
21:27 hoelzro I'm tempted to dig into how glibc implements it
21:27 jnthn I'd guess iteratively and compactly
21:27 jnthn CPUs like tight loops
21:28 hoelzro yeah, must be
21:28 jnthn They can keep their ops decided on the mu-op cache
21:28 jnthn *decoded
21:28 jnthn Also, CPUs don't much like branches
21:28 jnthn And a big load of them will bloat up the branch predictor
21:28 hoelzro it was something like consistently 40% faster than my naive binary search impl
21:28 jnthn wow
21:28 hoelzro I kind of want to run perf on mine, see what it says
21:28 jnthn :)
21:29 hoelzro and mine didn't use any function calls!
21:29 hoelzro I think you're right, jnthn; it comes down to compactness and branch prediction
21:30 jnthn On function calls - C compilers can be pretty great at inlining :)
21:31 hoelzro yeah, but via a function pointer?
21:31 * hoelzro is ignorant of how one could inline that
21:32 jnthn ah, yeah...
21:33 jnthn You can't easily do those
21:33 jnthn Only if you can prove there's only one possible thing it could be
21:34 hoelzro hmm
21:34 hoelzro you *could*, as the compiler developer, recognize a call to bsearch, and generate custom code
21:35 hoelzro but that's crazy
21:35 * hoelzro , however, notices a lot of crazy in compiler land ;)
21:35 jnthn :)
21:37 jnthn OK, I'm off for the night... o/
21:39 hoelzro night jnthn
21:43 timotimo did you know compilers have "memcpy detection"?
22:06 TEttinger joined #moarvm
22:22 japhb Part of the problem with early compiler benchmarks like Dhrystone and Whetstone was that the compiler vendors would recognize the benchmark code and replace it with hand-written assembly.

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