|
01:08
FROGGS_ joined
02:05
Util joined
02:17
ventica joined
04:02
ventica_desktop joined
04:25
xiaomiao joined
05:34
cognome joined
06:01
cognome joined
06:28
woolfy joined
07:22
lizmat joined,
cognominal joined
07:37
woolfy left
07:39
FROGGS[mobile] joined
|
|||
| FROGGS_ | jnthn: it must be this: | 08:15 | |
| ==13374== 4,646,152 bytes in 112,982 blocks are still reachable in loss record 1,663 of 1,668 | |||
| ==13374== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) | |||
| ==13374== by 0x4F8590C: deserialize (MVMArray.c:1098) | |||
| ==13374== by 0x4F9FE92: MVM_serialization_deserialize (serialization.c:1987) | |||
| though, that is b2e3884 | |||
| sergot | hi o/ | 08:38 | |
|
08:52
Ven joined
|
|||
| jnthn | FROGGS_: I don't think so; that's just deserializing things at startup...but the leak grows over time. | 08:55 | |
| FROGGS_ | ohh, I am actually still looking at the old run | 09:12 | |
| hi sergot | |||
| hi jnthn :o) | |||
| hmmmm | 09:15 | ||
| jnthn: look at this: paste.scsys.co.uk/409702 | |||
| ohh | 09:16 | ||
| perl6-m -e ':3("111") while 1' | |||
| extend/trunc NYI | |||
| :( | |||
| that explains the non leakness | |||
| with backtrace: paste.scsys.co.uk/409703 | 09:17 | ||
| what is happening here? | |||
| jnthn | FROGGS_: I dunno, maybe you updated Moar to get extop changes, but didn't update Rakudo also? | 09:28 | |
| So now it reads bytecode wrong... | |||
| FROGGS_ | jnthn: correct | 09:29 | |
| will update | |||
|
09:39
tgt joined
10:43
Ven joined
11:01
Ven joined
|
|||
| FROGGS_ | jnthn: must be this then: | 11:07 | |
| ==16116== 40,729,249 (38,335,200 direct, 2,394,049 indirect) bytes in 1,197,975 blocks are definitely lost in loss record 1,656 of 1,656 | |||
| ==16116== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) | |||
| ==16116== by 0x4F49AE0: MVM_args_proc_to_callsite (args.c:68) | |||
| ==16116== by 0x4F49B89: MVM_args_use_capture (args.c:92) | |||
|
11:55
Ven joined
|
|||
| FROGGS_ | jnthn: is that a good approach? gist.github.com/FROGGS/4c459d3daea186e3a5ce | 13:06 | |
| I'm in doubt | |||
|
14:22
Ven joined
14:44
zakharyas joined
|
|||
| carlin | is this the right way to fix the *BSD rand() problem? gist.github.com/carbin/8d35cebb83a7f92fd1ed | 14:53 | |
| jnthn back | 14:56 | ||
| FROGGS_: Yeah, that looks like a serious loss... | 14:57 | ||
| uh, leak | |||
| dalek | arVM/esc: fb4a6cb | jnthn++ | / (4 files): Annotate ops with escape info and store it. Product of escape analysis research/planning hackathon with masak++. Only a handful of ops annotated so far. |
15:03 | |
| jnthn | carlin: Provided all those platforms do indeed have arc4random, probably works. Though may want to make it MP_GEN_RANDOM as a name, just to descrease chance of collisions... | 15:11 | |
| carlin | I've tested moar/rakudo on openbsd and freebsd, and tested that arc4random is on dragonflybsd and netbsd | 15:12 | |
| jnthn | FROGGS_: Don't think the approach you suggested will work, but one I just tried isn't any better... | 15:55 | |
| timotimo | ESCAPE_IRR is IRRELEVANT? | 15:57 | |
|
15:57
FROGGS[mobile] joined
|
|||
| jnthn | yes | 15:58 | |
| timotimo | maybe i'll have someone (masak perhaps?) explain this to me and i'll help annotate ops ... | 16:00 | |
|
16:36
Ven joined
17:06
itz_ joined
|
|||
| dalek | arVM: 815abcb | jnthn++ | src/ (4 files): Allow extops to provide flags and spesh. This means we can mark extops pure so dead code elimination can kill them, as well as provide a spesh function for an extop. |
17:31 | |
| arVM: 9e90ac1 | jnthn++ | src/spesh/optimize.c: Don't keep guards just because of usage analysis. This should allow a few more unrequired guards to be thrown out. |
|||
| jnthn | .tell brrt I did various extop things that should make things a bit better from the JIT side. | 17:33 | |
| Including being able to set the invokey flag, or at least making it easily possible to implement that feature. | 17:34 | ||
| timotimo | jnthn: how about allowing the user to register extra fact discovery routines for extops? | 17:44 | |
| p6box_* for example could probably benefit from setting the known type to Int, Num, Str | 17:45 | ||
| p6parcel as well, i'd say, as well as p6list | |||
| actually, a whole lot of them could benefit from that... if not all | 17:47 | ||
| jnthn | timotimo: Yeah, I suspect so. | 17:53 | |
| timotimo: Interested in adding it at al? Might not be too hard following the patches Idid... | 17:54 | ||
| timotimo | can do | ||
| currently fighting my little ear infection | |||
| jnthn | ugh :( | 17:55 | |
| Sounds less awesome than my little pony | |||
| timotimo | yup | ||
| the pain levels ebb and tide, but it's a strange feeling being practically deaf in one ear | 17:57 | ||
| huh, we have to do a linear scan through the extop records? | 18:03 | ||
| jnthn | It'll be a small list | 18:04 | |
| timotimo | OK | ||
| jnthn | So not worth making a full-on hash thingy for it | ||
| timotimo | it'll probably all land in the cache as one blob anyway | ||
| jnthn | *nod* | 18:05 | |
| dalek | arVM: 603b50f | (Timo Paulssen)++ | src/ (3 files): allow extops to put facts into the spesh fact database. |
18:14 | |
| timotimo | oh, actually ... i messed that up | 18:19 | |
| should have compiled before pushing i s'pose | |||
| ah, here's what i missed | 18:24 | ||
| dalek | arVM: 8ef4455 | (Timo Paulssen)++ | src/ (4 files): allow extops to put facts into the spesh fact database. |
18:25 | |
| timotimo | *force pushed* ... | 18:26 | |
| jnthn | That's almost always a bad idea :P | 18:30 | |
| Now the commit that NQP_REVISION points to doesn't exist, for example... | |||
| FROGGS[mobile] | MOAR_REV points to the right thang | 18:33 | |
|
18:36
zakharyas joined
|
|||
| timotimo | jnthn: i force pushed to *all three repositories* :P | 18:40 | |
| i'm extra bad | |||
| FROGGS[mobile] | uhh | ||
| :p | |||
| timotimo | jnthn: is the result of p6parcel deconted or is it a container? | 18:43 | |
| i think it's not, but what do i know :P | |||
| p6scalarfromdesc should set known type to Scalar. what else? | 18:49 | ||
| should it also - if the scalar descriptor is a known_value - set the deconted value to be known and set the known deconted value to the descriptor's the_default? | 18:51 | ||
| jnthn | I don't think so. | 18:54 | |
| p6parcel should be deconted | |||
| coming out of the op, at least | |||
| timotimo | good | ||
| you don't think so about what exactly? | |||
| jnthn | Everything you said about p6scalarfromdesc except the known type bit. | ||
| timotimo | OK | 18:55 | |
| now i have some fact discovery thingies in place | 18:57 | ||
| i should probably spectest before i push | |||
| oh, i forgot to register the functions %) | |||
| i made discovery functions for known_type for p6box_[ins], p6listiter, p6scalarfromdesc, and p6reprname | 19:00 | ||
| sound about right? | |||
|
19:03
raiph joined
|
|||
| jnthn | Soudns reasonable | 19:05 | |
| timotimo | the only fails in spectests are lock.rakudo.moar and t/spec/integration/99problems-51-to-60.t | ||
| there's a segfault in there | |||
| interestingly, it segfaults in MVM_gc_root_add_frame_roots_to_worklist | 19:06 | ||
| i don't have debug symbols right now; does that happen on master, too? | |||
| oh well, SPESH_DISABLE=1 makes the segfault go a way | 19:07 | ||
| should i set the known type of p6bool's return value to STABLE(True).WHAT? | 19:09 | ||
| TimToady | I assume you mean MVM_SPESH_DISABLE | 19:13 | |
| timotimo | yes | ||
| TimToady | otherwise it would be quite interesting if that "fixed" the problem | 19:14 | |
| timotimo | surely :) | 19:15 | |
| TimToady | nutrition & | 19:16 | |
| timotimo | well, i put a printf into all my discovery functions and it doesn't seem like they get run at all | 19:18 | |
| aaah, here's what i've been missing ... | 19:20 | ||
| dalek | arVM: 4ae0734 | (Timo Paulssen)++ | src/core/ext.c: forgot to resolve discovery function in extop records |
19:21 | |
| timotimo | since my code didn't even really run before and it's only a single test file that segfaults, it'll probably be fine to just push | 19:34 | |
| after all, we're weeks away from the next release | |||
| jnthn | timotimo: The other missing facts thingy you may like to look at is in Moar itself,with the bigint ops | 19:39 | |
| I the ++ microbenchmarks we can eliminate at least one useless decont with that. | |||
|
19:49
colomon joined
|
|||
| carlin | the good news is the the segv with 51-to-60.t was known (RT 122297)... the bad news is it was apparently fixed a couple of days ago and [Coke] unfudged the test | 19:56 | |
| timotimo | oh well :( | ||
| jnthn: which ops need what facting? | 19:57 | ||
| jnthn | add_I, sub_I, etc etc | 19:58 | |
| timotimo | let's see ... | ||
| jnthn | They always come with the result type | 19:59 | |
| timotimo | and the result is never a container? | ||
| i.e. you can't pass anything as the result type that'd cause a container to be the result? | 20:00 | ||
| in that case i guess i can re-use the create_facts function | 20:01 | ||
| jnthn | Correct | ||
| Yeah, create_facts mstm | |||
| timotimo | that'll take care of container/not container | ||
| well, now i get a segfault in the core setting compilation | 20:04 | ||
| jnthn | I can't think of a situation where having a type that was both a scalar container AND a bigint container makes sense :) | 20:05 | |
| timotimo | ah, i was trying to get the 4th argument even for neg_I and abs_I | 20:06 | |
| dalek | arVM: 89658cb | (Timo Paulssen)++ | src/spesh/facts.c: know type and containerness information for bigint ops |
20:08 | |
| timotimo | this ought to be correct | 20:09 | |
| i suppose it's not a gigantic win yet; it would be if we could *ahem* remove redundant set instructions :) | |||
| jnthn | It's to darn hot in here for me to contemplate debugging that one. | 20:10 | |
| timotimo | aye, you should do something simple instead, like escape analysis :D | 20:12 | |
|
20:12
Ven joined
|
|||
| jnthn | Well, currently looking at handler table merging :) | 20:12 | |
| timotimo | ah, good | ||
| jnthn | BOOM SEGV | 20:13 | |
| timotimo | that's what keeps spesh from handling almost all perl6 frames, eh? | ||
| jnthn | Hm | ||
| Well, lexotic will still be an issue in those I guess | 20:14 | ||
| timotimo | that's whenever we throw exceptions or return or do stuff like that? | ||
| jnthn | return in particular | ||
| timotimo | that'd happen quite frequently, i suppose | 20:15 | |
| we do have a little optimization in there that removes redundant returns at the end of functions, thanks to froggs | |||
| jnthn | What we do inline so far is due to an optimization in Perl6::Optimizer that tosses lexotic entirely... | ||
| ah yay, latest version of my patch builds Rakudo and NQP, and passes sanity tests in both | 20:16 | ||
| Should spectest this I guess :) | |||
| aww, a fail | 20:17 | ||
| oh wait, it's Mouq++'s recent push | |||
| (as in, I don't have it) | |||
| timotimo | oh, that sounds lovely! | 20:19 | |
| jnthn | I thought one a case I didn't handle too... | ||
| timotimo | as long as we can safely bail in that one case it should be fine, no? | 20:20 | |
| jnthn | Oh, I handled it. | ||
| jnthn waits on the next spectest run | 20:24 | ||
| timotimo | hum. | 20:28 | |
| well, we have a bogus pointer in a register | |||
| in a frame that has been spesh'd | |||
| oh great! | 20:30 | ||
| when i'm attached to the process with gdb, it runs fine | |||
| jnthn | :/ | ||
| carlin | gdb is really good at fixing bugs, everyone should just run everything inside it | 20:31 | |
| timotimo | aye | 20:32 | |
| dalek | arVM: 54a4961 | jnthn++ | src/spesh/codegen.c: Use handlers from spesh graph at code-gen time. |
20:34 | |
| arVM: 028d7a7 | jnthn++ | src/spesh/inline.c: Support inlining of frames with handlers. |
|||
| timotimo | jnthn: should i look into running a new benchmark with this? | ||
| jnthn | Not sure if it'll make a hgue difference tbh | 20:35 | |
| Well, maybe all the chagnes we've done together will | |||
| timotimo | hm, so inlining these frames won't do much good? | ||
| jnthn | Well, it will, but not sure how many more it gets us without the lexotic stuff | ||
| timotimo | OK | 20:36 | |
| got a clue how much work that is going to be? | |||
| jnthn | Lemme remember how lexotic works these days... | ||
| timotimo | i never knew :) | ||
| Ven | "gdb is really good at fixing bugs, everyone should just run everything inside it" <- quote of the year :) | 20:40 | |
| jnthn | OK, I really dunno why lexotic inlines won't work | 20:43 | |
| I'm probably missing something | |||
| jnthn takes :noinline off them to find out :) | |||
| timotimo | %) | ||
| :noinline means "if we see this in a frame, don't dare inline it", right? | |||
| jnthn | Right | 20:44 | |
| Oh... | |||
| Just remembered that I re-did lexotic a bit. | 20:45 | ||
| So maybe that makes it OK | 20:47 | ||
| timotimo | that's why we can now inline lexotic safely? | ||
| jnthn | Yeah, that's what I@m wondering. | 20:48 | |
| Darn, not so simple | 20:50 | ||
| NQP build and worked out OK | |||
| But in Rakudo's CORE.setting: Stage parse : Label with no handler passed to newlexotic | |||
| timotimo | well, d'oh | 20:51 | |
| jnthn | wtf, 453 basic blocks... | 20:53 | |
| timotimo | a long cascade of ifs? :) | 20:55 | |
| jnthn | No | 20:58 | |
| a complicated token | |||
| or rule | |||
| oh... | 20:59 | ||
| I see | |||
| timotimo | i'm still wondering if we're missing anything special that'd make our parsing faster thanks to spesh | 21:00 | |
| special/specific | |||
|
21:21
Ven joined
|
|||
| timotimo | just run a nqp-moar vs nqp-moar-jit and it doesn't seem to give big differences :( | 21:36 | |
| charrange 556/s 219094/s | 21:37 | ||
| 393.8x 1.0x | |||
| charrange_ignorecase 22890104/s 13288/s | |||
| 1.0x 1722.6x | |||
| what now? o_O | |||
| japhb or japhb_, are you here? | 21:38 | ||
| jnthn | Yeah, I don't think the OSR kicks in really on NQP, though | ||
| As brrt noted a few days back | 21:39 | ||
| timotimo | we don't emit osrpoint instructions there yet? | ||
| jnthn | We do | ||
| But the mainline is varargs or something | |||
| Which upsets OSR | |||
| timotimo | oh? damn. | ||
| hm, actually, no need to bother japhb about this i guess | 21:41 | ||
| i wonder what the F is up with my measurements of the charrange benchs | |||
| dalek | arVM: 6f20346 | jnthn++ | tools/update_ops.p6: Fix missing MVM_PUBLIC in update_ops code-gen. |
21:44 | |
| arVM: 2ce6988 | jnthn++ | src/ (5 files): Enable inlining of lexotic. |
|||
| timotimo | should i run benchmarks with a rakudo after the inlining of lexotics patch? | 21:47 | |
| jnthn | Can try it :) | 21:48 | |
| Also with what I pushed to Rakudo itself just now | |||
| timotimo | will you bump the revision? | 21:49 | |
| that'll also make facts discovery for rakudo's extops actuall yhappen | |||
| nqp/2014.07 seems to win score-wise against the current nqp with or without jit :\ | 21:50 | ||
| jnthn: if the proto can't .soft, shouldn't that be taken as the same as .soft == 0? | 21:51 | ||
| jnthn | It pretty much always can, iirc | 21:55 | |
| It's just guarding agaisnt a crash | |||
| timotimo | OK | ||
| dalek | arVM/esc: 76a6bfa | masak++ | tools/update_ops.p6: [tools/update_ups.p6] factor out some repetition into sub |
21:59 | |
| arVM/esc: 03ac282 | masak++ | tools/update_ops.p6: [tools/update_ops.p6] introduce grammar for ops |
|||
| arVM/esc: 439efca | masak++ | tools/update_ops.p6: [tools/update_ops.p6] integrate two grammars |
|||
| jnthn | Nice :) | 22:02 | |
| masak++ | |||
| masak | well, it's a start. | ||
| jnthn | Fixes the spaces in adverbs thing, at least :) | 22:04 | |
| masak | hm, not quite yet :) | ||
| working on that one now ;) | |||
| jnthn | oh... :) | ||
| jnthn bbi10 | 22:05 | ||
| dalek | arVM/esc: b436429 | masak++ | tools/update_ops.p6: [tools/update_ops.p6] integrate :esc parsing into main parser This kills off another re-parse of the contents of :esc(...) and, as a side bonus, allows us to use spaces between the arguments. |
22:21 | |
| arVM/esc: 96ec3fe | masak++ | src/core/oplist: [src/core/oplist] add some spaces The parser in tools/update_ops.p6 can handle it now. |
|||
| arVM/esc: 6a4d07a | masak++ | tools/update_ops.p6: [tools/update_ups.p6] remove empty line |
22:24 | ||
| jnthn | update_ups? :) | 22:30 | |
| masak | uups. | ||
| I made that typo a number of times, and caught it in time. apparently not this time :) | 22:31 | ||
|
22:31
raiph joined
|
|||
| timotimo | i wonder if we can optimize the random functions in rakudo by knowing when we don't have to do bigint at all ... | 23:03 | |
| but maybe we already do that properly? | |||
| jnthn | Do we know they're a hot spot, or slow? | 23:04 | |
| timotimo | we do have a rand benchmark | 23:05 | |
| í'll see if it's slow or fast soon :) | |||
| it's a bit annoying that the speed benefits are hiding behind these silly reasons, so that we can't get to measure them properly with our benchmarks | 23:07 | ||
| like the slurpy args for the mainline | |||
| how can the mainline even have arguments; does it have an implicit *@ARGV signature? | 23:08 | ||
| jnthn | I think it's that, yeah | ||
| In Rakudo we've got it arranged a bit differently so that doesn't happen. | |||
| timotimo | do we have a solution coming up soon-ish? | ||
| jnthn | I can probably figure something out without too much trouble. | 23:09 | |
| timotimo | would be neat | 23:12 | |
| performance scores look quite good for current rakudo vs the 2 previous releases | 23:14 | ||
| jnthn | ooh | ||
| jnthn awiats les graphicales | 23:15 | ||
| timotimo | oh | ||
| i thought i'd get a rakudo master in first | |||
| jnthn | Oh...I thought "current rakudo" meant "master" :) | 23:16 | |
| timotimo | ah | ||
| current rakudo release* :) | |||
| jnthn | ah, ok | ||
| timotimo | jnthn: t.h8.lv/p6bench/2014-07-27-long-time-rakudo.html | 23:49 | |
| jnthn | Hm. Some minor improvements. | 23:55 | |
| Curious. We got worse at visit_2d_indices_while_native | 23:56 | ||
| In every relesae since 2014.06 | |||
| timotimo | wtf happened with the charrange benchmarks %) | 23:58 | |
| jnthn | no idea | ||
| something's up there | |||
| timotimo | "up" is the right term | 23:59 | |