01:34 colomon joined 01:58 colomon joined 02:28 camelia joined 05:47 sivoais joined 05:57 sivoais joined 06:07 diakopter joined 06:12 brrt joined
brrt good * 06:21
08:14 brrt joined 08:28 danaj joined 09:01 dalek joined
timotimo good ** 10:12
10:44 brrt joined 12:36 brrt joined
jnthn good * * * 13:07
brrt did you know that stack overflows, in C, are really funky? 13:19
look like any other memory corruption, but suddenly, your stack variables are unreadable 13:20
dalek arVM/even-moar-jit: ec738f3 | brrt++ | / (5 files):
Tiles need access to nonterminal values

A tile may refer to (non)terminals many layers deep in the tree. The tiler table generator knows which nonterminals these are, and is perfectly capable of generating 'traces' that show the JIT where to find them. So I do that.
jnthn Unreadable in the debugger? 13:22
brrt aye
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
brrt stack values become unreadable, yes :-) 13:24
and you get a segv
but it's nonobvious that it comes from an overflow :-)
jnthn Oh?
Odd, the MSVC debugger is always quite sure which one it is. 13:25
14:44 lucasb joined
lucasb libuv 1.7.0 is out; was there too many errors when brrt++ tried 1.6.1? 14:49
14:52 colomon joined
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
we'd have less security issues in C if that weren't the case
well, first it clobbers your return address, which is how most of those exploits work 14:55
jnthn wonders where "heap grows up, stack grows down" originates... 14:57
lizmat jnthn: 1K memory :-) 15:01
I remember expanding one of my terminal games: adding features would crash the terminal 15:02
until I figures that the stack was running into the heap with the larger memory footprint :-(
*figured
jnthn eek 15:04
:)
Well, lots still to do, but I have a first working .race
dalek arVM/vs2015-fixes: 7928a44 | hoelzro++ | src/strings/unicode_db.c:
Use binary search rather than if/else chains for Unicode block lookup

A large number of if/else chains breaks the VS 2015 compiler. The binary search is quite fast, but it loses to if/else chains in speed in a few cases. We can optimize later if this becomes an issue		 15:09
arVM/vs2015-fixes: de0b40e | hoelzro++ | src/strings/unicode_db.c:
Address MVM_unicode_is_in_block memory leak
arVM/vs2015-fixes: d9277bb | hoelzro++ | tools/ucd2c.pl:
Generate MVM_unicode_is_in_block to use binary search
MoarVM/vs2015-fixes: 8217892 | hoelzro++ | src/strings/unicode_ (2 files):
hoelzro good moarning, #moarvm! 15:32
I fixed up src/strings/unicode.c so that MoarVM compiles on VS 2015, but now running NQP gives me an access violation =/
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:33
15:57 brrt joined 16:56 brrt joined 17:37 zakharyas joined
dalek arVM/even-moar-jit: 31f5d5d | brrt++ | / (9 files):
Add MVMJitTile data structure
 18:02
brrt so the good bit about this is that it makes implementing tiles that much simpler 18:07
18:36 raiph joined
timotimo o/ 18:51
nwc10 jnthn: paste.scsys.co.uk/496892 -- t/spec/S17-supply/start.t seems to be able to deadlock with 3 threads waiting 19:04
jnthn That pretty much has to be a Rakudo-level rather than Moar-level bug 19:09
nwc10 OK
jnthn made a nice hang with cond-vars while working on race today... :) 19:13
19:42 zakharyas joined
nwc10 hoelzro: ASAN (on Linux) can't spot any problems with your branch :-( 19:57
dalek arVM/even-moar-jit: cd727b7 | brrt++ | / (5 files):
Add value type to tile

This signals to the register allocator whether we should allocate a register and whether we should free it.		 20:33
hoelzro nwc10: thanks for checking! 20:42
jnthn Pro tip: beer spashed in eye less pleasurable than beer splashed in mouth 20:44
hoelzro jnthn: sounds unpleasant =/ 20:48
jnthn Nothing too serious. :) 20:50
hoelzro jnthn: do you mind if I merge that VS 2015 compiler fix? 21:12
jnthn hoelzro: Hm, I should probably see if it explodes on Windows 21:13
hoelzro jnthn: I managed to compile MoarVM with the fix, but running MoarNQP results in an access violation =/ 21:14
I'm not sure if that's the compiler's fault, my system, or what
jnthn Taht sounds nasty
*that
I'll check an NQP build quickly now 21:15
hoelzro ok, thanks!
jnthn hoelzro: NQP build and passed make test here with that branch 21:18
(On Windows, VS 2013)
hoelzro ok, thanks for checking!
if you don't mind, I'll push that work into master then
jnthn How bad is the performance loss you noted? 21:19
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%
(on just that function) 21:21
on most inputs, bsearch is actually faster
jnthn ah, ok
then go for it :)
hoelzro \o/
jnthn hoelzro++ 21:22
timotimo "on 6 inputs"?
dalek arVM: 7928a44 | hoelzro++ | src/strings/unicode_db.c:
Use binary search rather than if/else chains for Unicode block lookup

A large number of if/else chains breaks the VS 2015 compiler. The binary search is quite fast, but it loses to if/else chains in speed in a few cases. We can optimize later if this becomes an issue
arVM: de0b40e | hoelzro++ | src/strings/unicode_db.c:
Address MVM_unicode_is_in_block memory leak
MoarVM: d9277bb | hoelzro++ | tools/ucd2c.pl:
MoarVM: Generate MVM_unicode_is_in_block to use binary search
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
timotimo ah 21:23
hoelzro out of the 195 distinct inputs in roast + rakudo build, 6 were slower with bsearch
most were something like 4x faster
but we're talking 17 vs 20 ns
hoelzro .oO( assuming my timing routines were correct ) 21:24
timotimo wow, 4x 21:26
that's pretty nice
hoelzro yeah, I'm actually surprised
I would expect bsearch to have some overhead from all the function calls its doing 21:27
I'm tempted to dig into how glibc implements it
jnthn I'd guess iteratively and compactly
CPUs like tight loops
hoelzro yeah, must be 21:28
jnthn They can keep their ops decided on the mu-op cache
*decoded
Also, CPUs don't much like branches
And a big load of them will bloat up the branch predictor
hoelzro it was something like consistently 40% faster than my naive binary search impl
jnthn wow
hoelzro I kind of want to run perf on mine, see what it says
jnthn :)
hoelzro and mine didn't use any function calls! 21:29
I think you're right, jnthn; it comes down to compactness and branch prediction
jnthn On function calls - C compilers can be pretty great at inlining :) 21:30
hoelzro yeah, but via a function pointer? 21:31
hoelzro is ignorant of how one could inline that
jnthn ah, yeah... 21:32
You can't easily do those 21:33
Only if you can prove there's only one possible thing it could be
hoelzro hmm 21:34
you *could*, as the compiler developer, recognize a call to bsearch, and generate custom code
but that's crazy 21:35
hoelzro , however, notices a lot of crazy in compiler land ;)
jnthn :)
OK, I'm off for the night... o/ 21:37
hoelzro night jnthn 21:39
timotimo did you know compilers have "memcpy detection"? 21:43
22:06 TEttinger joined
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. 22:22

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!