Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-18

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

All times shown according to UTC.

Time Nick Message
00:07 lizmat joined #moarvm
03:46 FROGGS_ joined #moarvm
07:05 zakharyas joined #moarvm
07:17 Ven joined #moarvm
07:23 Ven joined #moarvm
07:24 brrt joined #moarvm
07:25 brrt \o
07:25 brrt .tell timotimo that a): the JIT (and the interpreter) both require alignment of basic blocks, moreso than having goto's in basic blocks
07:25 nwc10 .tell brry that there appears to be no bot
07:25 nwc10 er,
07:25 nwc10 brrt
07:25 brrt so that you could plausibly replace all gotos
07:25 brrt oh
07:25 brrt yes
07:26 brrt shall i repeat on #perl6, or do you think he'll backog
07:26 nwc10 I can't tell you for sure
07:29 brrt well, just put it on #perl6 :-)
07:29 brrt where there are bots
07:34 FROGGS joined #moarvm
07:50 brrt joined #moarvm
09:09 brrt joined #moarvm
10:32 Ven joined #moarvm
10:47 brrt left #moarvm
11:29 brrt joined #moarvm
12:00 Ven joined #moarvm
12:51 lizmat joined #moarvm
12:52 brrt quiet today
12:59 timotimo i most usually backlog
13:00 brrt :-)
13:01 brrt although, yes, that's probably your issue, assigning to pred[num_pred] is an overflow :-)
13:08 timotimo right; in the other code i saw it had a -- at the very beginning of the file where it was assigned to a variable
13:08 brrt also a null?
13:09 zakharyas1 joined #moarvm
13:30 timotimo yeah
13:32 brrt ok, now that i actually have a decent internet connection
13:32 brrt i'm curious what you were / are trying to do with the union_goto branch
13:41 FROGGS uff, just seen this in my bash:
13:41 FROGGS malloc: unknown:0: assertion botched
13:41 FROGGS free: called with already freed block argument
13:42 brrt in bash, or in moar?
13:49 FROGGS bash
13:50 FROGGS on a production server :S
13:50 brrt oh, that doesn't surprise me
13:50 brrt i've seen ssimilar behaviour from bash often enough :-)
13:57 FROGGS that's the first time for me...
13:57 FROGGS and it scares me a little
14:05 brrt do you have sufficient free memory?
14:06 FROGGS on the server yes
14:06 FROGGS but just recognized that my own hard disk was full...
14:09 brrt some days :-)
14:43 timotimo well, i *thought* i could get the resulting jit code improved by reducing the overall number of gotos; especially in the jumplist case
14:43 timotimo but since the jumplist implementation actually uses these BBs with only goto instructions for doing the jump, that's not useful at all
14:43 timotimo i would have to do some analysis to see how often we end up with blocks that jump to a block that only does another jump
14:54 TimToady joined #moarvm
14:57 brrt i see
14:58 brrt any other place than jumplist, that's probably a good idea :-P
15:02 timotimo only if it's worth much :)
15:02 brrt yeah, sure
15:02 * brrt read the article about linear scan register allocation today
15:03 brrt good news, it means register allocation can be done much simpler than with graph coloring, and the output will in all likelihood be very suitable
15:05 TimToady joined #moarvm
15:05 moritz and what's the bad news? :-)
15:08 brrt second time somebody asks me that today, with the same answer
15:08 brrt there is no bad news
15:09 timotimo poletto & sarkar?
15:09 brrt probably, yes
15:09 brrt i had it from the luajit site
15:10 timotimo http://www.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf - i have this one open right now
15:10 brrt either that, or one that looks very much like it, yes :-)
15:11 brrt of course, the spill part of that algorithm spills to MVM memory 'registers', not to stack (in general)
15:11 timotimo of course
15:12 brrt in our case
15:12 brrt except when it doesn't, as in threadcontext and frame pointers
15:12 brrt hmmm
15:12 brrt :-)
15:17 timotimo i hadn't considered the tc register to be spillable up until now
15:19 brrt well....
15:20 brrt in the unlikely chance we never need it, it'd be a waste to keep it into a register forever
15:20 timotimo yes
15:20 brrt especially in a special callee-save register
15:20 brrt although that will probably be the reality for a long time to come
15:20 timotimo especially if we have tight numerical code the TC is likely not needed for almost all of the time
15:21 brrt if possible it'd be nicest to keep it in rcx all the time and not do any moves for calling a c function
15:21 brrt but, i don't know yet
15:22 timotimo how well does the algorithm cope with "and now we need to move these virtual registers into these exact real registers because we want to do a C call"?
15:31 brrt that's just a spill
15:31 brrt you implement the spilling yourself :-)
15:32 brrt oh, no, i'm wrong
15:32 brrt you mean the opposite
15:33 brrt that's also just loading, and since you spill before doing a C call (as one must), that won't pose a problem either
15:34 brrt but there's a reason i calculated time for doing a proof-of-concept
15:35 timotimo right
15:35 timotimo it's a good decision, IMO, to do a POC first
15:35 timotimo there's any number of screws one could adjust
17:33 colomon joined #moarvm
17:55 FROGGS joined #moarvm
18:11 colomon joined #moarvm
19:48 nwc10 jnthn: from last night, not sure if http://irclog.perlgeek.de/moarvm/2015-05-17#i_10617824 is a bug (but suspect it is) and it might have performance implications (probably small)
20:37 japhb joined #moarvm
20:54 japhb joined #moarvm
23:02 vendethiel joined #moarvm
23:23 LLamaRider joined #moarvm

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