Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-09-06

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

All times shown according to UTC.

Time Nick Message
00:29 itz joined #moarvm
00:34 lastofthe pew! pew! pew! see you, -Wpointer-sign
00:34 * lastofthe may be dancing in front of the mirror before the party
00:35 lastofthe But things are further along, at least
00:38 lastofthe Dare I spectest?
00:40 TimToady Are you of clan Korval?
00:42 lastofthe I'm not, I'm a Hunter nee Brunton.
00:44 TimToady if your clan's slogan is not "I Dare" then you shall have to dare on your own :)
00:45 lastofthe Nice!, now I want to know clan Korval!
00:48 TimToady well, they're in the Liaden Universe, so you can only know them in books, alas, unless you are also in a book
00:49 TimToady in which case, you're still knowing them in a book, but might not be aware of that contingency :)
00:50 TimToady but they are good books, in any case
00:50 TimToady very much about knowing when to dare :)
00:52 lastofthe Some of my favorite folks are in a book, but I think I've only really been in a book once, and I had a fever, and was young.
00:52 lastofthe I like the sounds of this place.
00:55 TimToady http://en.wikipedia.org/wiki/Liaden_universe
00:55 TimToady I recommend reading in publication order
00:56 TimToady the prequels are not spoiled by the originals :)
00:57 lastofthe Heh, good to know :)
01:00 lastofthe I'm getting ready for a trip to see a brother and a sister-in-law of mine.  I'll bet my bottom dollar between them they have "Agent of Change" on a shelf.  Between turns throwing a pick (I'm gonna be out there digging a hole) I bet they'll let me turn a few pages.
01:03 itz_ joined #moarvm
01:17 lastofthe Is there are version of 'make spectest' that does a parallel run?
01:19 timotimo you can set the environment variable TEST_JOBS
01:19 lastofthe Sweetness, thank you.
01:19 timotimo YW :)
01:21 lastofthe ps wwaux | grep perl6 | grep spec | wc -l
01:21 lastofthe 4
01:21 lastofthe *ahhhhh*
01:33 JimmyZ joined #moarvm
01:46 lastofthe Whew.  pew! pew! pew!  see you, -Wpointer-sign
01:48 * lastofthe has his eyes on "gcc -Wall -Werror", and whatever becomes of clang thusly.
01:50 lastofthe my dancing in front of the mirror before the party is hot.
01:56 FROGGS_ joined #moarvm
02:04 itz joined #moarvm
02:15 cognome joined #moarvm
03:03 colomon joined #moarvm
03:13 JimmyZ_ joined #moarvm
03:26 itz_ joined #moarvm
03:28 lastofthe joined #moarvm
03:30 cognome joined #moarvm
04:04 JimmyZ_ joined #moarvm
04:30 itz joined #moarvm
04:33 jnthn Very sleep...
04:46 itz_ joined #moarvm
04:57 itz joined #moarvm
04:57 JimmyZ_ joined #moarvm
04:59 JimmyZ__ joined #moarvm
05:02 JimmyZ__ joined #moarvm
05:03 JimmyZ_ joined #moarvm
05:08 jnthn FROGGS_: Did you spectest Rakudo on Windows after the libuv bump?
05:09 jnthn It seems many tests that spawn are exploding...
05:10 itz_ joined #moarvm
05:54 JimmyZ_ joined #moarvm
06:27 woolfy left #moarvm
06:51 lastofthe joined #moarvm
07:04 nwc10 jnthn: for me, if libuv is built with ASAN, it seems that all the tests that spawn end up hanging.
07:04 nwc10 if libuv is built normally, ASAN build of the rest, and all is good
07:06 jnthn nwc10: OK. On Windows the result is a SEGV
07:06 nwc10 jnthn: PPC bug I described last night is at Moar 645e0ef3b2d5 NQP ba3354c330e5 rakudo deef0e308c80
07:07 nwc10 which was the oldest version I could get to build (was trying to find the point where the bug was introduced)
07:08 nwc10 I was assuming that it is the cause at HEAD but I realised after I went to bed that I don't know this for sure. So you might recognise it as "fixed"
07:13 lizmat joined #moarvm
07:19 JimmyZ_ joined #moarvm
07:30 dalek MoarVM: 97adcd6 | jonathan++ | src/io/procops.c:
07:30 dalek MoarVM: Workaround for Windows explosions in spawn.
07:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/97adcd6a1b
07:32 * jnthn files an issue since this needs a closer look
07:32 jnthn But at least now spectest isn't a huge mess on Windows
07:32 dalek MoarVM/moritz/debian: d03e1ea | moritz++ | debian/ (2 files):
07:32 dalek MoarVM/moritz/debian: do architecture amd64 for now
07:32 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/d03e1ea8fe
07:34 FROGGS_ jnthn: I've tested both on linux and windows
07:35 jnthn Urgh
07:35 jnthn So why is it so busted on my box...
07:37 FROGGS_ I think I've seen fails about progname.t and args.t, but I had the impression that they've always failed
07:38 nwc10 jnthn: the ASAN-built libuv fails on linux made me wonder if libuv has a race condition, and the different timings with ASAN find it.
07:38 nwc10 but that's like "#11907 Looking for a compiler bug is the strategy of LAST resort. LAST resort."
07:38 synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=11907
07:39 nwc10 dear synopsebot, the link you want is http://dave.org.uk/klortho/?n=11907
07:39 * lizmat wouldn't be surprised if the rakudo thread load issues are in fact libuv issues under stress
07:59 FROGGS jnthn: I reported it upstream
08:00 FROGGS I perhaps bisect libuv this weekend
08:08 jnthn FROGGS: Awesome, thanks!
08:16 FROGGS jnthn: shall I pass an argument to the --debug option on windows?
08:16 jnthn I jus do --debug
08:16 FROGGS k
08:16 FROGGS last time I used the msvc debugger was when we had nqp-cc O.o
08:20 FROGGS the debugger is telling me that it is exploding here: https://github.com/MoarVM/MoarVM/blob/master/src/io/syncstream.c#L202
08:21 FROGGS (without your patch)
08:24 jnthn Hmm
08:25 jnthn For args.t it was blowing up where I commented out the line
08:43 nwc10 confirm, SEGV bug is spesh of MVM_OP_getattrs_n on PPC
08:47 FROGGS that's weird
08:48 FROGGS jnthn: your patch makes it exit with 0 in the debugger, but in the console I still do not get any TAP output
08:48 FROGGS when running perl6-m t/spec/S29-os/system.t
08:54 * nine just bought Agent of Change Kindle edition for EUR 0,00 on amazon.de
08:55 brrt joined #moarvm
08:55 brrt \o
08:56 jnthn FROGGS: Urgh
08:56 jnthn FROGGS: Also, socket tests explode even with my patch
08:56 jnthn walk &
08:56 FROGGS :o(
08:57 FROGGS the socket stuff might be due to api changes...
08:57 brrt oh, libuv change
08:57 brrt annoying
08:57 FROGGS perhaps we have to pass another uv_buf_t where we pass a char*
08:57 FROGGS will investigate in a bit
08:57 FROGGS bbi1h
09:09 nwc10 so, as per http://irclog.perlgeek.de/moarvm/2014-09-05#i_9305662 why is a value being written to the .lit_i16, but read from the .lit_str_idx ?
09:11 brrt hang on
09:11 brrt well
09:11 brrt that'd be wrong in general
09:11 brrt lit_str_idx is 32 bits
09:11 brrt alignment issues may cause.. issues
09:13 brrt i.e. will cause issues
09:13 nwc10 it is causing a SEGV
09:13 nwc10 this is why I know about it
09:13 brrt but yeah
09:13 brrt ok, hmm
09:13 brrt where does this happen?
09:14 nwc10 t/spec/S32-trig/sin.t and likely othrs
09:14 nwc10 I think I've answered most questions in the backlog
09:14 brrt okok i'm going to look for it
09:15 brrt hey i recall seeing that argument :-)
09:15 nwc10 thanks for trying to take a look
09:15 nwc10 specifically, here it's MVM_OP_getattrs_n
09:16 nwc10 but I suspect that all of MVM_OP_getattrs_* might be "at risk"
09:35 nwc10 this libuv is not as good as the old one. On PPC:
09:35 nwc10 moar: 3rdparty/libuv/src/unix/signal.c:166: uv__signal_handler: Assertion `r == sizeof msg || (r == -1 && ((*__errno_location ()) == 11 || (*__errno_location ()) == 11))' failed.
09:35 nwc10 Aborted (core dumped)
09:35 nwc10 for 3 NQP regression tests
09:35 JimmyZ_ joined #moarvm
09:37 brrt fuuuu
09:51 brrt i'm wondering what would be making or dealing with MVM_OP_getattrs_n
10:10 brrt hmm
10:11 brrt i can't find any evidence of anybody writing lit_i16 where an lit_str_idx is expected
10:13 itz joined #moarvm
10:13 brrt then again, that is basically the only explanation of what happens
10:15 brrt oplist is basically correct
10:17 brrt ok, nwc10: what happens in getattrs_n (basically from p6opaque, at any rate) is that MVM_spesh_get_string is /not/ called
10:23 brrt oh, i see
10:24 brrt i'm wrong
10:24 brrt terribly wrong
10:27 dalek MoarVM: ed2227e | (Bart Wiegmans)++ | src/6model/reprs/P6opaque.c:
10:27 dalek MoarVM: Use indirect name for slot in p6opaque getattrs_n
10:27 dalek MoarVM:
10:27 dalek MoarVM: This caused issues on PPC because the value of the register
10:27 dalek MoarVM: is encoded in 16 bits while a string index is 32 bits wide.
10:27 dalek MoarVM: This should have caused more issues, I might add. nwc10++
10:27 dalek MoarVM: for finding the bug.
10:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ed2227e6c9
10:28 brrt basically, MVM_spesh_get_string isn't supposed to be called there, that's what the indirection throught spesh_attr_name is for
10:28 brrt through
10:28 brrt it is a lucky (or unlucky) coincidence this didn't cause as much problems as it should have
10:29 brrt because you're basically looking into the slots table with a string that might or might not exist there
10:29 nwc10 I was wondering if it was something like that
10:29 nwc10 something more wrong than my diagnosis
10:30 brrt anyway, should be fixed now
10:30 brrt :-)
10:31 lizmat does this warrant a MOAR_REVISION bump ?
10:31 brrt eh
10:31 brrt dunno
10:31 brrt maybe :-)
10:31 brrt lunch &
10:31 brrt (maybe not because jnthn was looking into libuv issues still?)
10:33 lizmat trying build with master, master to see what happens
10:41 lizmat datapoint: master/master hangs when building the restricted settings
10:47 JimmyZ_ joined #moarvm
10:53 jnthn lizmat: Ouch..
10:54 jnthn Maybe time to go back to a working libuv in master, and work on the bump in a branch...
11:02 nwc10 brrt++
11:02 FROGGS daxim: would it be possible for you to bundle libuv 0.11.18? 0.11.28 seems to be buggy in several ways
11:02 nwc10 With that fix (cherry picked onto the commit before the libuv bump) nearly everything passes on PPC
11:02 nwc10 for some reason t/spec/S32-hash/delete-adverb.t seemed to go SEGV in the spectest
11:03 nwc10 other failures are consistent with problems seen on x86_64
11:05 nwc10 odd, malloc corruption in t/spec/S32-hash/delete-adverb.t on PPC
11:05 nwc10 but valgrind can't spot it
11:21 lastofthe joined #moarvm
11:25 brrt joined #moarvm
11:37 daxim joined #moarvm
11:46 FROGGS the on_write callback we pass has a wrong signature...
11:49 lastofthe left #moarvm
11:50 FROGGS ohh, no, I am wrong
12:07 zakharyas joined #moarvm
12:32 Ven joined #moarvm
12:39 woolfy joined #moarvm
12:41 FROGGS jnthn: with your patch system.t outputs stuff when run using the debugger, but there is nothing when run in cmd.exe
13:01 cognome joined #moarvm
13:07 JimmyZ_ joined #moarvm
13:25 JimmyZ https://github.com/joyent/libuv/compare/666aa2f0683dc8b80954c01e5799d476e4068350...49cb40c47902dd04c7787e6543e9e13368dc1840#diff-993e2d1f75ebf418adfbe81df8050a95R431 # looks like this change causes some lock, which spawn hangs on
13:26 JimmyZ qx// doesn't work on ubuntu 14.04 too, revert updating libuv and rebuild works
13:27 FROGGS jnthn: now, after doing a realclean again (I was about to automate a bisect), the system.t passes again
13:28 * JimmyZ tries
13:28 FROGGS JimmyZ: do you have a one-liner that does not work? I am on 14.04 since like 20 hours...
13:29 JimmyZ perl6 -e 'qx/umask/'
13:30 FROGGS perl6 -e 'say qx/umask/'
13:30 FROGGS 0002
13:31 FROGGS that was with jnthn's patch, now I build HEAD^
13:32 FROGGS JimmyZ: it still works with HEAD^ of MoarVM and libuv latest
13:32 JimmyZ hmm, doesn't works here :(
13:33 JimmyZ with HEAD of MoarVM
13:33 FROGGS JimmyZ: what happens?
13:34 JimmyZ don't know, reverting updating libuv and it works
13:39 FROGGS jnthn: even the socket tests now pass here
13:39 FROGGS ... on windows
13:39 brrt joined #moarvm
13:41 brrt \o
13:41 FROGGS hi brrt
13:41 brrt hi FROGGS
13:41 brrt anything broken still? :-)
13:42 FROGGS brrt: not on my boxes
13:42 brrt that is something at least
13:42 FROGGS for me a realclean in MoarVM helps on windows and linux
13:42 FROGGS using MoarVM HEAD^, aka without jnthn's latest patch
13:45 FROGGS spectest details and version summary for windows: https://gist.github.com/FROGGS/fa7a4a88317676fd36b9
13:45 FROGGS (linux in the works)
13:47 JimmyZ FROGGS: still hangs
13:47 JimmyZ (gdb) bt
13:47 JimmyZ #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
13:47 JimmyZ #1  0x00007ffff79ff21d in uv.epoll_wait () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
13:47 JimmyZ #2  0x00007ffff7a0a249 in uv.io_poll () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
13:48 JimmyZ #3  0x00007ffff7a00927 in uv_run () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
13:48 JimmyZ #4  0x00007ffff79a49ca in read_to_buffer () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
13:48 FROGGS hmmm
13:49 FROGGS testing on an linux x86 now...
13:50 lastofthe joined #moarvm
13:51 JimmyZ x86_64 :P
13:53 FROGGS my host is 64bits where all is fine... going to test on 32bit
13:54 FROGGS jnthn: only a single spectest fail on my linux box: https://gist.github.com/FROGGS/fa7a4a88317676fd36b9
14:04 FROGGS rakudo also compiles on a 32bit linux
14:05 FROGGS spectesting now
14:05 nwc10 FROGGS: that failing spectest is unfortunately a known SEGV (or ASAN barf)
14:06 nwc10 FROGGS: do the NQP tests pass on your box?
14:06 FROGGS nwc10: do you have anything that explodes due to the libuv upgrade?
14:06 nwc10 PowerPC fails assertions in libuv
14:07 FROGGS nwc10: and did you realclean in moarvm?
14:07 nwc10 x86_64 was fine once I didn't build libuv itself with ASAN
14:07 nwc10 git clean -dxf
14:07 nwc10 that may not be exactly the right answer
14:07 FROGGS nwc10: does that cleanup submodules?
14:07 nwc10 No. Which is why I repeatedly get annoyed about git submodules
14:07 nwc10 or, amongst the reasons
14:08 FROGGS it would be very very awesome if you could realclean, make install, and test the failing test again
14:09 lastofthe joined #moarvm
14:09 FROGGS I hope jnthn's patch does not do any harm, since I tested the revision before his patch fine on my boxes
14:10 FROGGS nwc10: can I run that powerpc stuff in a virtual box on an intel laptop or do I need proper hardware?
14:11 JimmyZ ah.... git clean -xdf doesn't clean submodules!
14:11 FROGGS gah! I was talking about REALCLEAN! :P
14:11 JimmyZ after make reaclean and it works
14:11 FROGGS \o/
14:11 FROGGS I have a good feeling now :D
14:11 JimmyZ I thought git clean -xdf cleans submodules
14:12 FROGGS well, submodules are something like repositories on its own, so...
14:12 nwc10 I thought that git clean -xdff did, but it doesn't seem to
14:27 dalek MoarVM: cf8088a | (Tobias Leich)++ | Configure.pl:
14:27 dalek MoarVM: forcing a realclean to get rid of old libuv
14:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cf8088a28e
14:28 dalek MoarVM: 78ab168 | (Tobias Leich)++ | src/io/procops.c:
14:28 dalek MoarVM: Revert "Workaround for Windows explosions in spawn."
14:28 dalek MoarVM:
14:28 dalek MoarVM: This workaraound is not needed when we remove old libuv files.
14:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/78ab168456
14:28 FROGGS now I am eager to hear from jnthn
14:32 nwc10 I am more eager for him to have a good night's sleep :-)
14:32 FROGGS yes, of course :o)
14:33 FROGGS it is just that I have no idea how late it is there
14:33 nwc10 Well, we know that the timezone is +08:00 but that's not actually that helpful
14:36 lizmat he's +6 hours from nwc10 and FROGGS and me :-)
14:36 lizmat 22:36 or so
14:37 FROGGS k, thanks :o)
15:34 zakharyas joined #moarvm
15:41 vendethiel joined #moarvm
15:47 woolfy joined #moarvm
15:48 woolfy left #moarvm
16:07 Ven joined #moarvm
16:09 jnthn FROGGS: Am trying cleaning things up now and rebuilding, will let you know soon
16:13 jnthn FROGGS: Yes, HEAD plus realclean works \o/
16:13 brrt joined #moarvm
16:15 FROGGS \o/
16:16 FROGGS jnthn: Configure.pl does that for you now since my last commit
16:16 FROGGS so innocent ppl should be kinda safe
16:16 FROGGS (that's a relief)
16:17 jnthn Yay, I qualify as an innocent person \o/
16:17 TimToady you are guilty of being innocient
16:18 TimToady *cent
16:20 FROGGS *g*
16:20 FROGGS jnthn: no, you're not :P
16:22 lastofthe Some time ago I was walking by a garden in Silver Lake (Los Angeles, CA, USA) and reached out to grab a prickly pear.  I didn't think, I just reached and grabbed, it was ripe and pretty.
16:23 lastofthe Some of the pricles have since decided I'm not a good host, and are working their ways out of me.
16:24 lastofthe This is true, and remarkably similar to how I feel about the warnings I'm squashing.
16:26 lastofthe I can't decide if prickly pear puss or a silenced warning is more exciting to me right now, so I'm giving them both play.
16:28 lastofthe Relatedly, is github the only convenient way to share patches?  Or is a branch that is available to the public also convenient?
16:28 lastofthe (or patch files, or ...)
16:28 TimToady we often use branches
16:29 lastofthe Oh, that's kind.
16:29 TimToady and pull requests for people who haven't got a commit bit yet
16:31 lastofthe You may have heard me correctly, in which case I apologize for shouting, but I meant to say: "Can I submit a branch for review from outside github's purview"
16:32 TimToady I don't know how to do that, other than with a diff
16:33 * TimToady heard no SHOUTING... :)
16:33 lastofthe Someone should write a utility to patch those into an existing codebase.
16:33 lastofthe :)
16:34 [Coke] if you're already working with git, then the easiest thing for us is for you to use github's pull request mechanism.
16:34 TimToady yeah, why hasn't anyone thought of that before now? :)
16:35 lastofthe Sometimes I think I'm old and inflexible for thinking that I shouldn't have to become a member of something in order to submit code to a project
16:35 [Coke] Amnesiator? I think I'd remember inventing something THAT useful.
16:35 [Coke] yes, but it's not about you. it's about the project. :)
16:35 lastofthe It is, you're totally right.
16:35 [Coke] it raises the barrier of entry for us to look at your code.
16:36 lastofthe It raises the barrier of entry to submit code to look at.
16:36 [Coke] Yes. and from our standpoint, that's probably a good thing, right?
16:36 lastofthe Sometimes that's a barrier that folks aren't ready to cross, for many reasons.  Sometimes completely unrelated to quality.
16:36 TimToady it's slightly intentional in this case, since the earlier <mmmph mmmph> had the opposite failure mode
16:37 [Coke] Note: I'm just a dude, I'm not the patch police.
16:37 lastofthe We're all just dudes, even the patch police :)
16:38 lastofthe And I mean "dude" as a multi there.
16:38 TimToady hopefully in the west coast genderless sense, yes :)
16:38 TimToady Dude!
16:38 lastofthe Heh, yes indeed.
16:38 [Coke] as an east coaster, I'm getting sick and tired of your west coast high and might stuff. :P
16:39 [Coke] *y
16:39 lastofthe Heh
16:39 TimToady nah, it's low and sneaky
16:39 jnthn I thought the west coast was sliding into the sea?
16:39 TimToady insidious surfers
16:39 lastofthe hah!, low and sneaky, yes.
16:39 TimToady jnthn: strike/slip faults go sideways, not up and down
16:39 lastofthe jnthn: but we don't even care
16:40 jnthn TimToady: Ah, right. So if you're on the right side of it, and a little patient, you get to be in Alaska... )
16:41 lastofthe Left side of it, methinks.
16:41 jnthn lastofthe: Generally, those submitting a sequence of patches that Do The Right Thing find themselves landed with a commit bit... :)
16:41 TimToady much of the US can be explained in terms of older, middle, and younger child dynamics :)
16:41 jnthn Yes, I meant "correct" by that :)
16:41 TimToady lastofthe: only if you're facing north
16:42 * TimToady is facing south currently
16:42 * lastofthe begins to wonder about his feng shui
16:43 * TimToady worries more about his zanshin
16:44 lastofthe jnthn: re patches: rockin'.  If I'm to be completely honest, I was looking for an excuse to cry about the centralization that github has imposed (on a decentralized protocol) to modern open source projects.  It rubs me wrong, but I'll get used to it.
16:44 lastofthe And to be completely honest, that wasn't completely honest.  Just an approximation.
16:45 lastofthe recur()
16:48 lastofthe And when I say "protocol" I mean "git", but I also mean "emergent social behaviour" :)
16:49 TimToady well, perhaps you'll be a part of the eventual decentralization after this swing of that pendulum :)
16:50 timotimo joined #moarvm
16:50 TimToady that one always goes back and forth every half-generation or so
16:51 lastofthe TimToady: Until then, I for one, ...
16:53 lastofthe It sure does seem to wobble.  It's hard for me to forget that the whole idea was about making it easy to share information.
16:53 lastofthe But I most certainly digress
16:54 TimToady nah, that's just half the idea; since information only flows easily downhill, you also need economic drivers for information to flow uphill
16:55 TimToady we wouldn't have google without ads
16:56 lastofthe I've never been a fan of dams.
16:57 lastofthe And now that DoubleClick owns search, I'm less of a fan of it
16:57 lastofthe (both)it
16:58 TimToady nonetheless, you probably turn on the light switch, and do other things to enforce the laws of thermodynamics :)
16:58 jnthn Yowser, the dynamic gen2 tuning from timotimo++ makes some good difference to CORE.setting build time...
16:59 jnthn And also a "read a million lines" benchmark
16:59 TimToady yes, we noticed that at the beginning when you were distracted
16:59 jnthn Since we end up with .lines keeping all the darn lines it ready around somehow :/
16:59 jnthn Another issue we need to solve in the list refactor.
17:00 jnthn TimToady: Hopefully the improvemnet is just as good with my re-worked version of the patch. :)
17:00 lastofthe TimToady: I knew Woodie Guthrie before I knew I missed salmon, for sure :)
17:00 * lastofthe sings *Roll on Columbia* and gets back to silencing warnings
17:02 * TimToady will be driving from younger child to older child for most of the next two weeks, but will continue thinking about the list refactor
17:02 * TimToady really wants Perl 6 to run fast, for some unfathomable reason
17:02 timotimo huh, you mean you *still* didn't give up on Perl 6??
17:03 timotimo clearly you must be Stark Raving Mad
17:03 TimToady indubitably
17:04 TimToady up till now, I've been the only person who is not allowed to give up on Perl 6, but jnthn++ is in grave danger of falling into that category now :)
17:05 timotimo i'm not sure if i understand what that's supposed to mean
17:06 lastofthe Moar and friends are close, and getting closer
17:06 * lastofthe thinks
17:07 dalek MoarVM: 7e8304d | jonathan++ | src/ (4 files):
17:07 dalek MoarVM: Base full collections of promotion rate.
17:07 dalek MoarVM:
17:07 dalek MoarVM: There's no point doing a full GC every N collects if we're promoting
17:07 dalek MoarVM: very little data each time. This patch, largely from timotimo++, uses
17:07 dalek MoarVM: tracking of the number of bytes promoted to gen2 to decide when to do
17:07 dalek MoarVM: it. This version of the patch correctly copes with blocked threads by
17:07 dalek MoarVM: moving where we clear and contribute the promoted bytes.
17:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7e8304dd66
17:08 jnthn *of, d'oh...
17:08 timotimo ah, very good
17:08 timotimo i wasn't entirely sure i did the per-thread stuff correctly
17:09 timotimo decrement_total_promoted_by is now a dead variable fwiw
17:09 jnthn oh, darn, I thought I removed that...
17:09 timotimo and you're saying this improves the timing of the core setting compilation? :)
17:10 timotimo maybe we need the pruning of excessive call graphs soon for the profiler
17:10 jnthn Yeah
17:10 timotimo did you see avuserow and me try to get a profile of the core setting compilation up? :D
17:10 jnthn Also
17:10 jnthn The profiler lies.
17:10 timotimo AHA!
17:11 jnthn Not on execution times
17:11 jnthn But on allocations
17:11 timotimo oh
17:11 timotimo that's interesting
17:11 jnthn It doesn't know about some of our allocate-y extops
17:11 timotimo oh, so we're actually allocating even more than it already shows?
17:11 jnthn Potentitially yes
17:12 jnthn Well
17:12 jnthn The GC numbes are always correct
17:12 jnthn But the Allocations tab mises some things.
17:13 timotimo right, makes sense
17:13 timotimo so ... the html file avuserow pried out of the profiler's smoldering remains was 1.1gb big. it took "only" 22 hours and 59 minutes to finish up ...
17:14 jnthn o.O
17:14 timotimo how do you feel about we directly print out the data into the file instead of  concatenating strings together?
17:14 jnthn Did anybody have a web browser that could load a 1.1GB file? :)
17:14 timotimo that may improve things
17:14 timotimo i tried it with firefox and chrome, both didn't want to
17:14 timotimo firefox seemed to just ignore the script outright
17:14 timotimo chrome very quickly said "oops, this tab has crashed. want to try again?"
17:15 jnthn So much for web scale... :P
17:15 timotimo no, this is already Big Data
17:16 jnthn Quick! To the cloud!
17:16 timotimo it ballooned up to 40 gig of maxrss i believe
17:16 jnthn o.O
17:16 timotimo anyway, gotta BBL :)
17:16 timotimo it == the profile dumping thingie
17:16 jnthn Nice box avuserow++ has...
17:16 timotimo aye
17:16 jnthn And that he set it on this
17:16 timotimo we shouldn't require that kind of box to profile the core setting compilation, though :)
17:17 jnthn Yes.
17:17 jnthn I think I need to look at pruning the graph
17:17 timotimo hah! i managed to convince you! ;))
17:18 jnthn The million lines thing goes from 52.165s to 43.998s with the gen2 tuning :)
17:20 jnthn It was 71.016s at the start of the day, before my take patches, then lizmat++'s many patches.
17:33 timotimo sweet!
17:35 jnthn Another 1.5s off with local patches
17:37 timotimo it's kind of sad, that we can't benefit from our ropes for doing the chomp thing
17:42 lastofthe Y'all here might be the folks to ask this question of, and it's one that's been on my oatmeal lately...
17:43 lastofthe I came here via Julia, because it has multimethods.  I wondered, "who else"
17:44 timotimo i recently attended a little presentation of julia by a friend, who's a physicist
17:44 lastofthe and found lisp (CLOS) and ocaml and a couple others, but perl 6's multis seem special to me in that parameter values can be used for dispatch
17:44 timotimo i need to finally get off my lazy butt and do the ipython protocol thing, god damn it.
17:45 lastofthe And I thought, "that must be hard to optimize", but when I thought about that some more, I couldn't figure out why I thought that.
17:46 timotimo heh.
17:46 timotimo we're quite fortunate that we are allowed to assume multi subs are "fixed" at the time we encounter them in the optimizer
17:46 timotimo but multi methods are, of course, virtual
17:47 lastofthe Are they fixed because the parameters are unboxed and inspected before they are passed along?
17:47 timotimo oh, no, not like that
17:47 * lastofthe realizes he might just be using words, here
17:47 timotimo i meant the list of candidates cannot be changed "afterwards"
17:48 timotimo so if we see an 1 + 1 we can already go ahead and look for the right candidate of &infix:<+> and we even inline small subs like that
17:48 lastofthe Oh.  Can multis not be punched into the symbol table at runtime?
17:48 timotimo they can, but then you get zero guarantees for runtime behavior
17:49 lastofthe behavior or performance?
17:49 timotimo if you invoke the multi sub indirectly, it'll likely be fine
17:49 TimToady lexical scopes are officially immutable once finished compiling
17:49 timotimo right, was just about to correct my claim there
17:49 lastofthe Cool, I dig it.
17:50 lastofthe And can thusly be passed around, I imagene.
17:50 TimToady and we make a very careful separation between things that belong to the current language, and are fixed in the current lexical scope, vs things that belong to the objects, which are virtual by default
17:50 * lastofthe even imagines
17:50 TimToady operators belong to the current language, methods belong to the objects
17:50 timotimo you can probably dig deep into VM internals to F with a multi sub's candidate list, but at that point, any given call to that sub may already have been inlined or candidate-decisioned (o_O) at that time and may not even know what multi they'd *have* to look at
17:52 TimToady at the end of compilation, the compiler is also allowed to close and finalize classes that haven't been pried open or already derived from
17:52 TimToady but we don't do that optimization yet
17:52 TimToady in fact, we don't even implement the LINK phaser yet, which is when that would happen
17:52 lastofthe TimToady: okay.  When one multifies an operator, does that push it over a boundary?
17:53 * lastofthe needs to read some specs, probably
17:53 timotimo no, it does not
17:53 TimToady only the boundary that it is legally a double dispatch, first to the proto, and then the proto redispatches to the multis
17:53 TimToady but that's almost always optimized away
17:53 timotimo the operator has to be declared "multi" or a "proto" has to be created on the first definition for that operator
17:53 timotimo (or you can override a previously multi operator with a non-multi operator in a lexically "inner" scope with the "only" keyword)
17:54 timotimo (or by providing a new proto, i believe)
17:54 TimToady .oO(if you cannot afford a proto attorney, one will be provided for you)
17:55 lastofthe That's fantastic.
17:55 TimToady well, we think so, but we're known to be prejudiced in the matter
17:56 timotimo i don't think i can provide an outsider's view on perl 6 any more, even though i've only been involved some 2 years
17:56 timotimo (has it been that long already? wow.)
17:56 TimToady we have been thinking about this a goodly long time now, so we'd like to think we've got a few things right by now :)
17:56 TimToady and still have a few things wrong we want to fix
17:57 zakharyas joined #moarvm
17:58 lastofthe By all rights, you all have!  Multimethods seem to be a bit of a tough thing for folks outside of a world that intersects with ML/CLOS to get right, I'm sure I didn't get the right in my head until I instersected with those worlds.
17:58 lastofthe s/right/Mu/
18:00 lastofthe (..you all have!): got some things right, that is
18:01 brrt joined #moarvm
18:03 TimToady well, and we don't think CLOS got multis right either :)
18:03 TimToady our rules are agnostic to parameter order, unlike CLOS
18:04 lastofthe No, but one could make them right :)
18:04 TimToady (Int,Num) and (Num,Int) are both considered the same distance from any (X,X)
18:05 TimToady so formally ambiguous
18:05 timotimo ah, that. of course.
18:05 TimToady whereas CLOS, iiuc, would pick the left one over the right one
18:06 TimToady well, Int and Num are a bad example maybe
18:06 TimToady since they are only cousins
18:07 TimToady but yeah, CLOS does more cascading decisions left-to-right, and we don't
18:08 lastofthe That's also fantastic.
18:08 TimToady but that's sort of the historical FP bias coming through of priviledging the car over the cdr
18:10 lastofthe Which makes not having syntax easy, which is maybe an odd thing to optimize.
18:11 TimToady if we all optimized for the same things, life would be kinda boring :)
18:11 lastofthe Can I get an ...
18:12 TimToady m: say 0,1,*+* ... *
18:12 camelia rakudo-moar 4a7429: OUTPUT«0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 17711 28657 46368 75025 121393 196418 317811 514229 832040 1346269 2178309 3524578 5702887 9227465 14930352 24157817 39088169 63245986 102334155 165580141 267914296 433494437 701408…»
18:13 lastofthe Show off :)
18:14 TimToady ayah...
18:14 teodozjan joined #moarvm
18:16 timotimo m: say 1 , *.rand ... 0.0001
18:16 camelia rakudo-moar 4a7429: OUTPUT«1 0.185797766360854 0.134341292914885 0.0126081342347814 0.00654983537965583 0.00357668111091382 0.00240665709688171 0.00113202482912126 5.32329151742171e-05 3.44407453064244e-05 9.11938041984839e-06 7.08717585672882e-06 8.48999551213041e-07 4.502952053892…»
18:17 lastofthe My new seed for everything
18:19 timotimo m: say (1, 1 , *.rand + *.rand ... 0.0001)
18:19 camelia rakudo-moar 4a7429: OUTPUT«1 1 1.28732767501881 0.712114840272033 1.32522605348956 0.904939122185709 0.885580364714935 0.912687391448989 1.11714281386194 0.805584158737667 1.41191989868245 1.03590889369564 0.310556727034583 0.362401945299584 0.270688460496896 0.334274831310506 0.443…»
18:19 timotimo pretty <3
18:30 FROGGS joined #moarvm
19:00 brrt ugh, i'm into java distributed systems middleware land tonight, wish me luck
19:21 lastofthe joined #moarvm
19:29 vendethiel joined #moarvm
19:29 xiaomiao joined #moarvm
20:11 brrt left #moarvm
20:17 lastofthe joined #moarvm
20:32 lizmat joined #moarvm
20:33 woolfy joined #moarvm
20:50 lastofthe joined #moarvm
21:47 avuserow timotimo:  it's might be worth mentioning that "my" machine (at $dayjob) with lots of memory is fairly old so it's not very fast, at least CPU-wise. I think it's 2009-vintage. Plus it's actually a VM, so I figure it might be up to ~10% slower for CPU/memory
21:55 timotimo oh, hm
21:55 timotimo fair enough
21:55 timotimo but we *still* need to make it faster :D
21:55 timotimo did it swap memory out, btw?
21:55 avuserow I think it swapped out some of the base system but not moar
21:56 avuserow since it had a few MB of swap used when I came back, but the time output didn't say any swaps happened
21:56 avuserow I've noticed Linux does that as a precaution when memory gets used a bunch (for certain values of "a bunch")
22:10 [Coke] had to skip a a few commits doing this rakudo-jvm bisect, another weird build failure showed up.
22:12 timotimo :<
22:55 nebuchadnezzar joined #moarvm
23:55 colomon joined #moarvm

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