|
00:48
lee_ joined
01:17
rurban_ joined
07:21
FROGGS joined
08:12
FROGGS joined
08:28
odc joined
11:05
_sri joined
11:26
donaldh joined
11:31
donaldh joined
11:37
lizmat joined
|
|||
| nwc10 | good *, #MoarVM | 11:47 | |
| timotimo | hello you! :) | ||
|
12:55
tgt joined
13:28
colomon joined
13:35
JimmyZ_ joined,
dagurval_ joined,
cxreg2 joined
13:39
eternaleye_ joined
13:46
woolfy1 joined
13:48
_sri joined,
lue joined
14:09
colomon joined
14:14
jnap joined
|
|||
| hoelzro | is there a tool for dumping moarvm bytecode into some human-readable format? | 14:18 | |
| timotimo | there is moar --dump foo.moarvm | 14:20 | |
| hoelzro | thanks timotimo | ||
| timotimo | that reminds me i wanted to build a perl6 script that syntax-highlights and otherwise improves the display of the bytecode dump | 14:27 | |
| one thought i had was to put four colored blocks in front of everything that refers to something that comes up again and use the hash of the name to determine the colors) | |||
| :) | 14:28 | ||
| hoelzro | that's a neat idea | 14:29 | |
| I just looked at the dump | |||
| and I have no idea where to start on this null object thing =/ | |||
| is there a place I can put a bounty on a bug? =) | 14:31 | ||
| I understand that the moar-conch stuff is cool, but I'd like to see a working URI | |||
| timotimo | dunno, but there is gittip, which is kind of the opposite approach :P | ||
| hoelzro | heh | 14:34 | |
| hoelzro .oO( QuestHub idea: tipping for quests ) | |||
|
17:05
lizmat joined,
FROGGS joined,
tokuhirom joined,
nwc10 joined
17:06
colomon joined,
eternaleye joined,
JimmyZ joined,
rurban_ joined,
lee_ joined
17:29
japhb_ joined
17:44
ggoebel1117 joined,
ingy1 joined
17:48
colomon joined
17:59
FROGGS joined
|
|||
| FROGGS | hoelzro: you are trying to hunt #121298 down, right? | 18:09 | |
| (RT #121298) | |||
| ohh, synopsebot is not here | |||
| rt.perl.org/Ticket/Display.html?id=121298 | |||
| tadzik | I should send it here, maybe | 18:12 | |
| FROGGS | please do :o) | ||
| tadzik: have you seen the PR to panda btw= | 18:13 | ||
| s/=/?/ | |||
| tadzik | FROGGS: nope. Will look at it tomorrow, going to a concert now | ||
|
18:14
synopsebot joined
|
|||
| tadzik | synopsebot is here :) | 18:14 | |
| FROGGS | \o/ | ||
| tadzik++ | |||
|
18:39
tgt joined
|
|||
| nwc10 | www.google-melange.com/gsoc/org2/g...oc2014/tpf | 19:03 | |
| [Coke] | \O/! | 19:09 | |
| timotimo | hoelzro: have you tried reverse-debugging yet? | 19:10 | |
| or "backwards debugging" or whetver it's called | 19:12 | ||
| FROGGS | nwc10: we are on that list?? | 19:19 | |
| nwc10 | let me try that again: www.google-melange.com/gsoc/org2/g...oc2014/tpf | 19:20 | |
| [Coke] | please consider volunteering as a mentor for the moar/perl6 projects. | 19:23 | |
| FROGGS | indeed we are on that list! | 19:24 | |
| done. | 19:28 | ||
| timotimo | FROGGS: please take out at least the peephole optimizer idea, too. jnthn said it's a bad idea | ||
| and i'm not sure the JIT idea was received well as well? but i'm not sure | |||
| FROGGS | k | 19:29 | |
| done | |||
|
19:30
ashwinik_ joined
|
|||
| timotimo | the whole string_offset and compare_offset thing confuses me a tiny bit, i have to admit | 19:44 | |
| do i really have to subtract the compare_offset of the first string from the compare_offset of the second string? | 19:48 | ||
| hm, i suppose that makes sense | |||
| if the compare_offsets are in "rope-string-coordinates" | |||
| aaw, my fast path is not being hit | 19:58 | ||
|
20:00
tgt joined
|
|||
| timotimo | meeeeeh, somehow strings are getting corrupted or something :( | 20:13 | |
|
20:18
tgt joined
|
|||
| masak | nwc10++ # tpf | 20:21 | |
| timotimo | valgrind: the 'impossible' happened: | 20:24 | |
| Killed by fatal signal | |||
| dalek | arVM/flatten_fastpath: 40738ed | (Timo Paulssen)++ | src/strings/ops.c: implement a fast-path for 2-strand int32 string flattening |
20:30 | |
| arVM/flatten_fastpath: 72a1339 | (Timo Paulssen)++ | src/strings/ops.c: fix & precedence and 32bit address calculations |
|||
| timotimo | jnthn: spectests on flatten_fastpath are clean. should i merge? | 20:48 | |
| nwc10 | I'm only the messenger | 20:50 | |
| and really only "first post" | |||
| timotimo | nwc10: huh? | ||
| nwc10 | what masak said | ||
| "Said" | |||
| timotimo | ah | 20:51 | |
| masak | nwc10: I see. still, very nice. | 20:55 | |
| nwc10 | IIRC "blame" mdk and Leto | ||
| jnthn | timotimo: Wait for feedback from lue first? | ||
| timotimo | will do | ||
| it's hard to benchmark these things without pushing the commits up first :P | 20:56 | ||
| that's why i'm trying to teach perl6-bench to do parameterized builds | |||
| i did a small local test that gave me about 10x faster on ~32000 concats | |||
| nwc10 | I found perl6-bench a lot easier to read with the release names. Which I take it are tags | ||
| timotimo | yeah, i also want to teach it to alias commits to user-specified names | 20:57 | |
| nwc10 | that would be awesome | ||
| the graphs were showing a pleasing speedup for MoarVM for the for tests, I thought | |||
| timotimo | i also want a TUI interface to perl6-bench to make running the tests much less hassle-y | 20:58 | |
| rurban_ | I'm also working on some perl6-bench improvements this week. more perl5 implementations | 21:02 | |
| And I don't like the alias test | |||
| timotimo | seems like rakudo-m is only 2x slower at concating a string with a single char 32768 times than rakudo-p is | 21:03 | |
| as in: appending a single character to the accumulation string at a time | 21:04 | ||
| oh wow | 21:05 | ||
| it uses 2 gigabytes of ram for that, though | |||
| jnthn | Whee | 21:06 | |
| Well, it's 'cus it won't go collecting the buffers until the next GC run. | 21:07 | ||
| timotimo | probably :\ | ||
| jnthn | And the buffers aren't chewing through the nursery itself | ||
| timotimo | it doesn't contribute to .. yeah | ||
| jnthn | Which normally is a good thing :) | ||
| Since it means we don't have to collect anything like so often. | |||
| timotimo | aye | 21:08 | |
| jnthn | Anyway, there's a lot of things that can help with that. | ||
| nwc10 | that reminds me a lot of a parrot GC bug | ||
| IIRC it was that Strings didn't trigger GC runs | 21:09 | ||
| PMC exhaustion did | |||
| jnthn | nwc10: Right. Same thing here. | ||
| nwc10 | (and GC runs collected both Strings and PMCs) | ||
| or something like that | |||
| result was if the code was String heavy, it could chew a lot of resouces | |||
| timotimo | mhm | ||
| jnthn | Yeah. It's a trade-off. | 21:10 | |
| For this particular benchmark, proper ropes can mitigate it. | |||
| timotimo | i'm glad it's not something i messed up | ||
| jnthn | Heck, if I can ever be convinced to do OSR, then escape analysis can too... | ||
| timotimo | that'd be great | ||
| nwc10 | OSR? | 21:11 | |
| timotimo | then we could even cheat more heavily | ||
| jnthn | In fact, the specializer will be a little unhelpful for a lot of p6bench without OSR... | ||
| nwc10: "On stack replacement" | |||
| nwc10: Optimizing code when the callframes are already on the stack. | |||
| nwc10: Which is...evil. :) | 21:12 | ||
| timotimo | we need different benchmarks anyway; the current microbenchmarks are pretty unhelpful in any case | ||
| except for hunting very specific regressions and performance bugs | |||
| jnthn | Well, they serve a purpose, but yeah, we need a broader range, for sure. | 21:13 | |
| timotimo | fo' sho' | ||
| jnthn | (I've nothing against OSR, it's just a little fun to implement.) | ||
| timotimo | okay, so lue isn't benefiting from the patch very much | 21:15 | |
| but the benchmark still is | |||
| 21s before patch, 1.4s after patch | |||
| jnthn | uh, yeah, that's a win :) | 21:16 | |
| lue | I wonder if starting up a new instance of perl6-m for each synopsis is what's causing the most pain in the process... | ||
| timotimo | startup time of moarvm-rakudo is pretty excellent. how many synopsis files are you actually working with? | 21:17 | |
| FROGGS | hmmmm, I don't think that matters much | ||
| lue | There are 36 synopses in the specs repo (that's counting both S17s) | 21:18 | |
| timotimo | nah, that should contribute about 60 seconds or so :P | ||
|
21:19
d4l3k_ joined
|
|||
| timotimo | jnthn: should i try for a fast path in subst, repeat or join? | 21:25 | |
| hm. there is wmemset for wchar_t, but that's 16bit, not 32bit :( | 21:27 | ||
| so a super fast fastpath for repeat of single characters wouldn't be easy | 21:28 | ||
| well, except for when we have 8bit strings working properly | |||
| nwc10 | does any standard mandate that wchar_t is 16 bit? | 21:29 | |
| I've generally avoided the wide char stuff because it seemed to be under documented and less than reliably portable | |||
| I might be wrong | |||
| timotimo | fair enough, i should see about that | ||
| wmemset is specced for C99, though | 21:30 | ||
| which we don't have, thanks to MSVC | |||
| seems like on windows it's 16bit, on linux it's 32bit | 21:31 | ||
| or rather "modern unix-like systems" | |||
| "The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers." | |||
| that sucks | |||
| jnthn | timotimo: A tight loop and a good compiler might well end up doing simd code-gen anyway. | 21:32 | |
| timotimo | fair enough. | ||
|
21:44
d4l3k_ joined
|
|||
| timotimo | jnthn: what was your opinion on a JIT project for MoarVM GSoC? | 21:53 | |
| FROGGS | my guess is that jnthn++ wants to do it alone :o) | 21:54 | |
| timotimo | well, that or at least do the design decisions himself | ||
| jnthn | I don't feel any real need to write the code, but yeah, I need to be in on the design. | 21:55 | |
| We need the specializer in place first I think, since JIT will want to re-use lots of that infrastructure. | 21:56 | ||
| [Coke] | specializer? | ||
| jnthn | [Coke]: Thing that takes bytecode + runtime information and produces specialized bytecode out of it. | 21:57 | |
| timotimo | things like "if this parameter to the function is always a vanilla Str object, we can inline methods and stuff" | ||
| jnthn | Right. | ||
|
22:01
colomon joined
23:15
colomon joined
|
|||