Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-06-16

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

All times shown according to UTC.

Time Nick Message
00:57 btyler joined #moarvm
01:13 FROGGS_ joined #moarvm
01:38 woosley joined #moarvm
02:50 daxim joined #moarvm
02:58 japhb brrt: I've actually been begging for a way to reinterpret 32 or 64 bits between integer and floating point forms (as a fast way of converting floats to and from network-serialized form), so if you get that as a side effect, I won't complain.  :-)
03:02 japhb Also, on Intel processors (since the 8087 days), the floating point registers are 80 bits wide ("long double" form) to prevent (or rather, reduce the probability of) certain types of precision losses during extended calculations.
03:03 japhb You *can* store the long doubles to RAM, but generally they're just used internally to a single calculation and then the result stored in 64-bit double form.
03:05 japhb You would need to store the extended form to RAM if you had to spill registers during the middle of a calculation when the programmer was expecting to stay in high-precision form.
03:16 daxim joined #moarvm
03:48 benabik joined #moarvm
05:52 cognominal joined #moarvm
06:53 FROGGS_ joined #moarvm
07:03 zakharyas joined #moarvm
07:08 jnthn moarning o-
07:08 nwc10 good *
07:08 jnthn eww, what keyboard layout...
07:09 nwc10 You're not in Sweden?
07:09 jnthn yeah...it was the Swedish one :)
07:10 nwc10 oh, so your keyboard has flipped layout? PEIK, not PEBKAC?
07:12 FROGGS_ moarning oß
07:12 jnthn No, just me not remembering I'm on a machine where they put images on taht default that way
07:12 jnthn oh joy, my presentation gadget has a flat battery
07:14 jnthn yay, new batteries. :)
07:17 jnthn It may be a good idea to bump NQP_REVISION and MOAR_REVISION, btw
07:17 jnthn So we get some testing on latest
07:17 jnthn Also, if anybould could check Panda builds OK on non-Windows on latest of everything that'd be great.
07:18 jnthn (I tried it yesterday on almost-HEAD on Windows and modulo a Panda patch we need on Windows, it worked well)
07:18 jnthn (Panda patch is backend-independent.)
07:18 * jnthn is teaching for the day but has evening tuits :)
07:19 FROGGS_ \o/
07:19 FROGGS_ I can check panda later
07:29 jnthn ok
07:29 jnthn teaching &
08:00 krunen joined #moarvm
09:23 oetiker joined #moarvm
09:51 lizmat am going to bump revisions now, ok?
10:12 lizmat revisions bumped
10:45 jnthn joined #moarvm
10:52 odc joined #moarvm
11:27 brrt joined #moarvm
11:27 brrt \o #moarvm
11:36 lizmat brrt o/
11:36 brrt how's it there? still in france?
11:37 lizmat no, back in Echt for now
11:38 brrt really? (ha ha)
11:39 brrt well, how was france, then? :-)
11:39 lizmat apart from the bombing of a bar, nothing much happened while we were away
11:39 lizmat well, the same more or less
11:39 tadzik bombing of a bar? :o
11:39 lizmat we've been to the Cite des Sciences many times already
11:40 lizmat two motorgangs are disputing the territory here
11:40 lizmat they've been thrown out of Germany, and are now trying to set up "shop" here
11:41 brrt annoying
11:41 lizmat yeah, but as long as they're not gunning each other down with machine guns, it's just that
12:02 lizmat spurious S17 errors did not seem to have disappeared  :-(
12:02 lizmat *do
12:11 FROGGS_ perhaps somebody needs to fix 'em?
12:11 FROGGS_ that is usually what somebody does with errors :o)
12:12 lizmat wish I had the know-how to
12:12 lizmat not something I can do about it at the rakudo level  :-(
12:14 brrt what are the s17 crashes about?
12:14 brrt locking, right?
12:15 * brrt finds concurrency fun
12:15 lizmat afaik, from talking with jnthn, some kind of memory corruption that happens under stress
12:18 * brrt things we should have something like the go race detector
12:18 nwc10 brrt: have you played with helgrind? Does it acchieve that?
12:20 brrt have never, no
12:20 brrt my debug toolbox is basically gdb and since recently, valgind
12:21 brrt (and printf, of course :-))
13:11 jnap joined #moarvm
13:23 flaviusb joined #moarvm
13:35 * jnthn wonders what nice JIT commits brrt++ will land today :)
13:35 jnthn lizmat: Thanks for the bump.
13:35 * brrt is a bit preoccupied in fact :-)
13:36 brrt i was thinking of doing the branching stuff today
13:36 brrt or at least
13:36 brrt the labeling-of-basic blocks
13:37 lizmat FWIW, spectest CPU usage seems to have gone down from ~1544 to ~1483
13:39 timotimo that could be inline landing?
13:42 FROGGS_ joined #moarvm
13:42 brrt conditional branches, fwiw, are awkward
13:43 FROGGS_ lizmat: you are right of course # META6.json
13:43 FROGGS_ err, ww
13:43 moritz are there non-conditional branches?
13:43 brrt in that moarvm expects you to put the result of a compare into a register - ok - and then to use the boolean result of said register to jump
13:43 brrt and that is all possible
13:44 brrt but the 'normal' way to do it is to compare, and then jump directly on basis of the flags register
13:44 brrt that said, its not particularly hard to do it as i described, just very roundabout
13:47 jnthn brrt: Sounds like a make-it-work-now, peephole-it-later situation
13:47 timotimo agreed
13:47 brrt agreed as well
13:48 brrt but awkward :-)
13:48 brrt moritz - a nonconditional branch is a goto :-)
13:48 brrt otherwise we'd have to call them goto and branch, now we just call them branch
13:49 brrt on the otherhand, qualifiying with '(un)conditional' isn't exactly succinct terminology either
13:51 FROGGS_ what's a pee phole?
13:52 nwc10 a "peep hole" with 2 characters transposed?
13:52 FROGGS_ meh
13:53 timotimo it's a type of optimizer that looks at a few opcodes in isolation
13:53 timotimo it looks at the opcode stream "through a little peep hole" so to speak
13:53 timotimo comparable to a "sliding window"
13:54 jnthn a...pee phole? :P
13:55 jnthn None of the mental images are good :P
13:56 timotimo a pee pole sounds even less good
13:56 * brrt wishes people had picked another name
13:56 lizmat Tea See Pee, I Pee
13:56 lizmat what can I say, the level is rising :-)
13:56 timotimo my initials are TCP :3
13:56 brrt its actually called a peephole optimizer - the optimizer runs over the bytecode in a small 'window', and tries to find things to optimize
13:57 brrt and most of the usable algorithms have to do multiple passes
13:58 btyler joined #moarvm
13:58 timotimo yeah, single-pass optimization is kinda hard
13:59 brrt and its not actually very easy to use it with the current version of the jit graph because it treats (for now) things like compare will be handled by primitives (i.e., not looked at on graph construction level)
14:00 brrt i.e. 'jit graph should be a real graph!' 'i know but i'll need register selection' - that discussion, again :-)
14:01 timotimo well, it would be easy to remember the "origin" instruction for each register/version and traverse that like a linked list when we find a conditional branch op
14:01 brrt yes, certainly
14:01 brrt def-use analysis, made more easy by the SSA form
14:01 timotimo aye
14:02 brrt block labeling is first, though
14:03 timotimo jnthn: what exactly forces the attribute access in cursors to be pessimal? that we access them late-bound by name?
14:05 oetiker joined #moarvm
14:06 jnthn no, that we use ::?CLASS
14:08 timotimo mhm
14:08 timotimo is that constant-per-callsite per chance?
14:16 jnthn constant per invocant type
15:00 jnthn decommutebeer &
15:03 lizmat beer on the train!
15:03 * lizmat recalls being on the commuter train to Antwerp
15:04 lizmat everybody ODing on coffee in the morning
15:04 lizmat and ODing on beer in the evening on the way home  :-)
15:04 lizmat .oO( happy hour for sure )
15:39 brrt lizmat - from roosendaal?
15:39 lizmat yup
15:39 lizmat in the blue "hondekop"
15:40 * brrt has been on the roosendaal train quite a few times himself
15:40 brrt but not on a blue train, actually
15:40 brrt red trains ride there nowadays
15:42 lizmat yeah  :-(
15:45 brrt (slowly)
16:25 brrt joined #moarvm
16:28 brrt left #moarvm
17:03 jnap joined #moarvm
17:04 flaviusb left #moarvm
17:25 jnthn No, it wsa beer at the pub by the station, before the train
17:28 jnap joined #moarvm
17:29 lizmat ah, using RPN then  :-)
17:29 jnthn Reverse Polish Notation? :)
17:29 jnthn oh :)
17:30 lizmat hehe
17:30 lizmat not &beerdecummute but decommutebeer&
18:02 vendethiel joined #moarvm
18:50 dalek MoarVM/moar-jit: bd6ecce | (Bart Wiegmans)++ | / (7 files):
18:50 dalek MoarVM/moar-jit: Add comparison operators before adding branching
18:50 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/bd6ecce3a6
18:50 brrt joined #moarvm
18:53 * brrt is becoming fond of asm
19:02 * brrt chuckles at the following comment: https://github.com/LuaDist/luajit/blob/master/src/vm_x86.dasc#L6243
19:04 rurban_ brrt: do you really need to add pseudo frames? They are only used for exceptions
19:04 brrt pseudo frames?
19:04 brrt thats not my code, btw :-)
19:05 rurban_ yeah, just to walk up the stack frame to find someone who can catch the exception
19:05 rurban_ sure. I do not support exceptions with native stack frames. way too fragile
19:05 brrt i... don't think that i do?
19:05 rurban_ I hope not.
19:06 brrt stack management is fragile per se :-)
19:06 rurban_ You can try to support dwarf2/dwarf3/llvm vs gcc, elf vs mach vs windows, mingw dwarf2 vs sjlj and many more
19:07 brrt yes... i suppose i can
19:07 rurban_ I hope not :)
19:07 brrt however, i'm already more than glad if i can support two different x64 ABI's :-D
19:08 rurban_ If you really need it, better call the assembler manually to produce those frames
19:08 brrt hmm but dynasm runs at runtime
19:09 rurban_ win64 vs amd64 is easy, just 2 different registers
19:09 brrt win64 also has more callee-save register (rsi and rdi)
19:09 brrt and fewer register arguments
19:09 brrt but i agree
19:09 brrt its doable
19:10 rurban_ yeah, my perl5 Jit compiles some crazy frames to .c and then .o and then gets the dwarf at run-time. just for debugging, gdb support, to get the symbol names.
19:10 brrt hmmm
19:10 rurban_ newer gdb's have better jit support already
19:10 brrt the moar-jit project works at a bit of a lower level, though
19:11 brrt ultimately, gdb support would be good, i agree
19:11 rurban_ you might need it later, when you want to step through it. single-step is a bit troubling
19:11 brrt then again, not as good - imho - as the generation of Very Fast Code :-)
19:12 brrt i use bytecode dumps that i dissassemble offline
19:12 rurban_ so with these dwarf frames you can add the lines and even variable names and types
19:12 brrt or
19:12 brrt i trap MVM_enter_jit in gdb and disassemble on-line
19:12 brrt that is pretty neat
19:12 * brrt should have that too :-)
19:13 brrt although i can promise it won't be a priority anytime soon :-)
19:14 brrt (and of course, i know the bytecode generation routines well enough to recoginse seperate fragments by hand, but that won't be true of anyone else)
19:14 jnthn The easy way to deal with exceptions initially is just deopt.
19:14 rurban_ I only implemented it when I could't properly debug mine anymore. And I'll probably such a think to the new (=old) parrot jit also.
19:18 brrt jnthn, i think / but i'm not sure - rurban_ means stack-unwinding exceptions, and since we don't have a deep c stack, walking isn't a problem, either
19:19 brrt i'll have the interpreter handle the frame walking / handler selection part
19:19 jnthn *nod*
19:19 jnthn Yeah, well, we basically never recurse on the C stack even if the code we're running does.
19:21 jnthn If the handler is in a caller, it's thus really easy to drop back to the interp. The only tricky one is when the handler is in the current frame, and you kinda need a deopt record to know where to fall back to, 'cus it can't just be inferred from the return addr or so.
19:21 jnthn Control exceptions in the same frame will want to become gotos at some point, I imagine.
19:21 jnthn But maybe that wants doing in spesh rather than the JIT per se.
19:21 brrt they can be equivalent to gotos
19:22 brrt goto's don't hurt me :-)
19:22 jnthn Well, we only need to do the full-blown thing if there's a CONTROL or so somewhere, but that's the uncommon case. :)
19:25 brrt i suppose so. i'm nowhere near exceptions now, though
19:26 jnthn aye :)
19:55 jnap joined #moarvm
20:25 dalek MoarVM: 462402b | jnthn++ | src/spesh/args.c:
20:25 dalek MoarVM: Missing NULL check in arg guard handling.
20:25 dalek MoarVM:
20:25 dalek MoarVM: Fixes a SEGV reported by Mouq++.
20:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/462402be7f
20:26 lizmat enough reason to bump?
20:29 lizmat jnthn: ^^^
20:30 jnthn lizmat: Well, figure I'll test Panda builds fine on this latest just in case I need to fix something there
20:30 jnthn I know there was a SEGV in that earlier on.
20:30 jnthn But I didn't reproduce it the other day
20:30 jnthn Gonna check it out now, anyways...
20:31 lizmat jnthn++
20:31 jnthn Oh, do you have a Panda commit bit?
20:32 lizmat no sure
20:33 lizmat I might need one soon :-)
20:33 jnthn I asked on #perl6
20:33 jnthn Just a patch I have that wants applying
20:35 lizmat nope, don't have a commit bit
20:36 lizmat guess I should ask tadzik for one
20:51 jnthn Looks like (with that Windows patch) Panda builds fine here.
20:51 jnthn So yeah, can bump.
20:55 lizmat ok, will do
21:41 donaldh joined #moarvm
22:07 brrt left #moarvm

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