timotimo i wonder how come we've gotten faster at the rational benchmarks 00:04
rat_mul_div_cancel
it's interesting that we get improvements across the board 00:06
00:06 raiph joined
jnthn Could be that it inlines something now it hadn't used to 00:06
timotimo ah, good point 00:07
jnthn Time for some rest here :)
'night
01:07 FROGGS__ joined 03:10 raiph joined 06:06 FROGGS__ joined 07:10 ventica joined 08:35 ventica2 joined 10:11 brrt joined
brrt \o 10:11
i can't pretty well figure out how to build moar on windows-64 10:14
i do have the visual studio tools installed and Configure.pl does recognise the toolchain, but probe.pm crashes for some reason 10:16
brrt afk for a bit 10:19
10:25 carlin_ joined, tgt joined
carlin brrt: have you run vcvarsall.bat in the VC directory? 10:27
FROGGS either that or use the developer console 10:49
11:00 Ven joined
jnthn brrt: How does it crash? 11:41
12:25 raiph joined 12:27 Ven joined 12:42 tgt joined 13:10 brrt joined 13:12 brrt left 13:13 brrt_ joined
brrt_ oh, after a reboot it apparantly all works 13:14
jnthn Such Windows... :P
brrt yes, such windows indeed 13:16
or you know, not, apparantly i don't have winsock.h
jnthn ...what... 13:17
Try vcvars64.bat 13:18
brrt ok, how do i include that?
jnthn jsut run it
as a command
Should set uip various envvars
brrt uh, let's see
jnthn What are you running this all at, though? Normal command prompt? 13:19
There's a Visual Studio Command Prompt you are given normally
Which has stuff set up
brrt well, i tried the normal command prompt + finding some vcvars, but now i run via the visual studio command prompt
and i'm using the 'x64 cross compiler' because the
'regular' command prompt only has x86 support
apparantly MS is all hot on x86 again, mostly because pointers are half the size 13:20
jnthn wtf... 13:21
brrt that was my reaction as well
jnthn You don't have a native 64-bit one? 13:22
brrt i've installed just visual studio express 2013
and it contains the 'microsoft optimizing compiler for x64' but only as part of a 'cross compiler toolchain
well, the regular 'native' toolchain basically has the same problem: can't compile libuv (it seems) because I don't have the winsock headers 13:25
oh, i installed visual studio express for windows btw, not the for web version
jnthn Maybe missing Windows SDK, somehow? www.microsoft.com/en-us/download/de...px?id=8279 13:26
brrt probably
i'm downloading that now
i'm mildly pleasantly surprised by the whole windows system 13:30
jnthn ;) 13:31
FROGGS brrt: yes, windows 7+ in combination with visual studio is kinda pleasing :o)
brrt :-) 13:34
although i /still/ can't compile it
i'm going to restart and see if that does anything
carlin just keep restarting until it works 13:36
jnthn works on a Moar thing timo has been asking for for ages... :)
13:43 Juerd joined 14:25 Ven joined 14:31 lizmat joined 14:37 woolfy joined 14:44 brrt joined
dalek arVM: 50640b8 | jnthn++ | src/ (4 files):
Allow us to add temporaries when optimizing.

Some optimizations we wish to do will need an extra temporary register to store something in. This patch enables us to have such registers. It also provides an acquire/release model so we can re-use these temporaries, minimizing the number we need to add.		 14:44
arVM: beca0b2 | jnthn++ | src/spesh/args.c:
Specialize unboxing of incoming object args.
15:18 daxim joined
timotimo i don't thoroughly understand the code you added; did we previously bail out if we would have had to unbox an int/num/str from a passed argument? 15:56
but now i understand how we do the temp register stuff :) 15:57
jnthn timotimo: yes, we bailed 16:01
timotimo: I've got code for the boxed case locally
timotimo cool :)
more spesh stuff
we don't have a bail-log-like thing for spesh, aye?
jnthn Well, it wasn't a total bail 16:02
More like "don't spesh the args at all" bail
timotimo ah
that's harder tolog of course
jnthn Yeah
The boxed case transform works, but something doesn't get the number of locals correct somewhere, somehow... 16:03
So we get SEGV at some point in GC marking
Well, dinner...bbiab
timotimo bon appetit :)
optimize_can_op is still commented; i wonder if we can figure out what's wrong with it by now 16:16
maybe having to bail a lot less will let us find the error more often
now that we have the SSA form, wouldn't it be easy-ish to figure out when a local is read for the very last time and then re-use the local, so that we get smaller frames as well as considering objects un-used (for GC purposes) earlier? 16:22
16:33 Ven joined
timotimo should i look into optimizing iffy when the type is known so it'll become an unbox_i/unbox_s/unbox_n/... plus an if_i/unless_i? 16:35
sounds strenuous :\ 16:36
feeling pretty drained from my ear infection adventures tbh :|
FROGGS :/ 16:37
jnthn timotimo: Yes, if_o and unless_o and istrue/isfalse can be optimized in taht kinda way 16:39
timotimo i suppose if i just take it slow, i'll be fine 16:40
which do you think is the juicier target?
jnthn if_o/unless_o are likely the easier ones 16:41
timotimo OK
jnthn uh
harder ones
but also more common
timotimo of course %)
jnthn some istrue you can do without an extra reg anyway 16:42
istrue_I for bigint spec for example
timotimo right, unbox_i for example should work
ah, there's already an istrue optimization in there
i can probably extend that to cover isfalse and put a negation in there in those cases 16:43
that ought to be simple-ish if i specify a register to put the result into and if it's isfalse, i just set that to an allocated temp register 16:44
actually, that part is already in there 16:45
but it just re-uses the existing register so far
jnthn grmbl 17:08
Fixed various places with badass umptions with regard to locals only growing if we inline, and it still gets the frame size wrong... 17:09
timotimo d'oh (:
:(
17:14 btyler joined
jnthn duh 17:17
I was asking for a temp reg of the wrong type 17:18
timotimo oops :)
jnthn hm, it can inline some things now it couldn't before also :) 17:21
japhb Started backlogging this channel ... I see you ran afoul of the bugs in the charrange benchmarks. Did you work those out already, or do I need to fix them? 17:25
timotimo "the bugs"? you know of them? 17:27
i didn't quite know what exactly happened there 17:28
the graph does look very weird
maybe it's just that the new implementation is just so ridiculously much better now than it was before
japhb timotimo: FROGGS committed without testing, because I convinced him to share his WIP, but I forgot to tell him to mark them disabled if he didn't think they would work. And I noticed the problem just before getting rather sick in a way that made computer use cause vertigo, so I didn't push a fix. 17:30
timotimo yikes
japhb So I'll look at it today and see what I can do.
timotimo did you see the graph? 17:31
17:31 raiph joined
timotimo i definitely like the performance scoring thingie 17:31
and the commandline comparison thingie is also much nicer than i thought
japhb No, I haven't seen the graph yet 17:32
link?
timotimo t.h8.lv/p6bench/2014-07-27-long-time-rakudo.html 17:33
japhb "commandline comparison thingie"?
timotimo the output you get with "compare" without a --format argument 17:34
with the scoring at the bottom
dalek arVM: 5835e19 | jnthn++ | src/ (3 files):
Cope with locals resizing without inlining.

In a few places we assumed only inlining could do this. That's not true any more, however, now that we have the ability to add extra temporaries.		 17:37
arVM: 3827560 | jnthn++ | src/spesh/args.c:
Specialize boxing of args also.
japhb Oh, yes. That's a rather unappreciated feature, methinks. :-)
timotimo jnthn: should i be putting any energy/thought into making frames re-use their "registers" if they can? 17:39
17:40 woolfy joined
jnthn timotimo: I'm worried that will be rather fragile 17:40
timotimo fair enough
i suppose the jit will be doing a good job with that anyway when we have proper register allocation?
jnthn Well, also we're relatively good about register use in initial code-gen anyway 17:42
timotimo oh? i didn't know that
i thought we were just throwing them around like they cost nothing at all :)
jnthn No; we release them as soon as we don't need them 17:43
timotimo okay, so that's already pretty good
jnthn If you look at any sizable piece of code in spesh you'll see there's a lot of versions per variable.
And many of them come from the fact that it's re-using relatively well during code-gen.
japhb Gah, system acting weird, looks like I'll be rebooting. :-(
timotimo i haven't looked at non-spesh'd code dumps in a long time, i think 17:44
i think it's time for a nap :S 17:46
jnthn Hope you'll be feeling better soon. 17:47
timotimo me, too :)
this is mostly about catching up on sleep, as i had none last night
and then it'll be time to take another round of meds, so i'll probably feel all right tonight :)
jnthn :) 17:48
carlin does it matter that moar segfaults doing open('a_directory').lines on OpenBSD, since it's not supposed to be valid anyway? 17:51
here's a backtrace anyway: gist.github.com/carbin/bb85811a95404d87861a 17:52
17:54 woolfy left
jnthn It really shouldn't SEGV 17:54
18:06 woolfy joined, woolfy left 18:08 japhb joined 18:13 raiph joined
dalek arVM: 0e1d782 | jnthn++ | src/spesh/args.c:
Specialize boxing of named args.
 18:14
arVM: 78cdd80 | jnthn++ | src/spesh/args.c:
Specialize unboxing of named args.
 18:33
jnthn Well, that nails all the permutations. :)
18:58 colomon joined
[Coke] ff 18:58
18:59 Ven joined
timotimo and now we inline all the frames forever? :) 19:24
jnthn Well, it stops things like need to box/unbox from keeping us from inlining at least. 19:28
Why the heck is infix:<eq>'s proto use the slow path binder... 19:31
timotimo how can you find that out? 19:32
jnthn oh...it's on a bind error 19:34
Well, I was looking into the palindrome RC thing
timotimo ah, ok 19:35
jnthn To see why it deopted a lot
And found it spent a load of time in the slow-path binder
oh 19:38
It's junction fallback
And unbase has an optimizable (so far) Junction 19:39
timotimo last time i looked, i didn't even understand what unbase is supposed to do
ah, if we rewrite that to the form with | between " " strings, it would turn into a sequence of || operators 19:41
would you like to do that?
or like me to do that, i suppose
jnthn That's an option, yeah.
Well, there's another option
Which is to realize any is being given a Parcel of literals.
timotimo mhm
jnthn Which would be a more general improvement 19:42
timotimo yes, it would
jnthn Anyway, I just looked at ff.p6, one of our slowest benchmarks
And step does this:
for ^$!height X ^$!width -> $i, $j {
19:42 brrt joined
jnthn And on the inside 19:42
brrt \o #moarvm
jnthn any(@!neighbors[$i][$j]) === Burning
timotimo o/ brrt
jnthn At some point
hi brrt 19:43
brrt btw, it may be obvious now, but i'm not on a holiday after all :-)
timotimo aaw :(
brrt ­it's ok :-)
jnthn I couldn't tell if it was that or you just missed hacking while on holiday :) 19:44
timotimo jnthn: is there something about that that could be optimized?
brrt well, both would've been plausible, but I wouldn't have had the computer with me 19:45
fwiw, I can now finally build moar \o/
(on windows, that is)
timotimo for ^number X ^othernumber -> $a, $b could surely be turned into a loop in a loop, if we're careful with redo/continue/last/...
jnthn timotimo: That ain't my point
carlin brrt: how many restarts did it require? :p
brrt the secret is installing visual studio for windows desktop rather than any visual studio for windows
jnthn My point is that every step does 100+ runs through the slow binder
brrt too many :-)
timotimo your point is "damnit! why are junctions so slow!"
jnthn Well, my point is that this might be *why* Junctions are so slow 19:46
timotimo can we somehow get junctions to not go through the slow binder?
jnthn Well, I am starting to wonder why they do it every single time
timotimo spesh could know there's a junction there that ought to be autothreaded and not go through the binder instead 19:47
jnthn We should be installing a junction dispatcher in the multi cache that skips all of this...I thought, anyway.
timotimo that would certainly improve this specific kind of problem
jnthn oh, but wait...
Hmmm
That'll never happen, will it. 19:48
'cus we auto-thread on the proto
timotimo doesn't know :\ 19:49
jnthn So we never end up multi-dispatching on a Junction itself
19:49 brrt left 19:50 brrt joined
timotimo it's kinda bad our primitive for checking if something is in a list is going through junctions 19:51
brrt anyway, now i'm wondering how to make moarvm run nqp
19:51 raiph joined
jnthn brrt: git clone nqp, and then perl Configure.pl --backend=moar --prefix=c:\path\to\moar\install 19:52
brrt aha, i see
timotimo maybe we could have a simple implementation of any that takes list, operator, comparison and does the comparison directly
that could maybe even be in-lined
20:24 ilbot3 joined 20:41 zakharyas joined 20:52 ventica2 joined
brrt windows debugger is weird 20:52
21:09 ggoebel111118 joined
brrt afk 21:23
timotimo hah,i hoped by napping i'd see another cool piece of work done by jnthn %) 22:25
jnthn does have something in the works 22:27
timotimo nap driven development ... 22:30
carlin like coding in your sleep
dalek arVM: 0513b67 | jnthn++ | lib/MAST/Nodes.nqp:
Some MAST::Nodes optimizations.

Provide a way to construct MAST::[Ext]Op faster when we already have an array of operands, and sprinkle a few native types.		 22:46
[Coke] the uniq.t spec test failures are a segv. 23:11
jnthn Hmm 23:14
Odd...passes here. :S
If we're lucky somebody with ASAN might provide a useful report.
[Coke] I can get you a backtrace, but it's about 100 lines to get a reproducable segv 23:17
running moar thru lldb is a pita 23:34
timotimo jnthn: running benchmarks with the new changes now :) 23:35
[Coke] oh, wait, it's easy as pie: 23:38
gist.github.com/coke/42dc068d6845f5b5a240
timotimo Failed to run command: install/bin/perl6 --optimize=3 -e "\c[2694536175]" ~~ /<[\c0..\c[2694536175]]>/ 23:44
haha
unicode doesn't actually have enough characters yet %)

Powered by Cro and the Raku® Programming Language.

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

Thank you!