Parrot 6.5.0 "Black-winged Lovebird" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 9 July 2014.
01:32 FROGGS_ joined 03:21 estrabd joined 03:59 bighugedog joined 04:07 khisanth_ joined 06:47 FROGGS joined 07:20 bighugedog joined 08:15 basiliscos joined 08:31 woosley joined 09:47 Psyche^ joined 10:08 FROGGS joined 12:35 kid51 joined 14:54 Chirag joined
Chirag rurban: Hey! I was wondering if it's a good idea for me to start working on a different task, perhaps on the lexpad optimization for Rakudo (which I had kept optional in my proposal) or if you have some other task in mind? 14:58
rurban As you wish
Jonathan wrote the nqp lexpad parts 14:59
Chirag We havent got anything substantial from our tests.. So, I am just afraid I might fall behind schedule.. 15:00
rurban sure 15:03
The problem is that I don't know those parts that well
Chirag What else do you think I could work on? i was just taking a look at my proposal .. www.google-melange.com/gsoc/proposa...0916475904 15:06
"non-cached sig objects" --done-- although without much improvement 15:08
rurban I only see the short description there. You also?
Chirag no... the complete proposal
wait I ll put it on a gist
rurban Signature handling is pretty much done. ext_call needs to be improved, but that's probably too big for you
Chirag gist.github.com/ZYROz/d443e5490e4ae3026a1c 15:10
The formatting is gone
rurban raw is good
I see: caching sig translations "P->P" into cached object 15:11
compile-time FixedPMCArray: I believe this is done already. Or do you see more possibilities? 15:12
Chirag I didnt take care of slurpy args 15:13
rurban I cannot remember the lexpad stuff
we can ignore slurpy. only needed at run-time
but maybe rakudo does it, haven't checked 15:14
I only know of "Fix NQPLexPad for parrot threads", but this is a tricky threading problem
wiki.enlightenedperl.org/gsoc2014/i...signatures 15:15
I remember now. This is the lexpad issue lists.parrot.org/pipermail/parrot-d...07354.html 15:17
Chirag Whatever you feel is best... or I could work on something outside my proposal's scope.. We could also ask Util
rurban So three minor tasks are open: cache sigs, fixedpmcarray and optional lexpad 15:18
Chirag yes 15:19
rurban and bigger: integrate the return continuation into the call context (16% speedup according to mls)
do you want to contact him, cc parrot-dev@parrot.org
maybe he still has his quick hack around and we can look at it 15:20
lists.parrot.org/pipermail/parrot-d...07354.html
Chirag sure.. Michael Schroeder right? 15:21
rurban the optional lexpad is a "political" API issue. A HLL (rakudo) needs to tell the PCC somehow that the lexpad is not needed 15:22
yes
Chirag I ll mail i and ask if he could provide that piece of code, in case he still has it 15:23
rurban but I haven't look at the optional lexpad yet. My gut feeling is that even rakudo needs it temporarily
Chirag the return continuation part 15:24
rurban the parrot lexpad 15:27
Another option is to speed up CallContext field accesses to call them directly, not via the external API.
See wknight8111.blogspot.com/2009/10/op...arrot.html
bacek also went through and properly encapsulated the Context PMC type so that there were fewer direct accesses of it's internal members
This should be easy 15:29
e.g. inline Parrot_pcc_add_invocant 15:31
make src/call/pcc.i and see the inefficient code 15:32
Chirag sure 15:33
rurban GETATTR_CallContext_arg_flags => arg_flags = ((Parrot_CallContext_attributes *)(call_obj)->data)->arg_flags;
and the 2 vtable calls in Parrot_pcc_add_invocant can be inlined too 15:34
and Parrot_pcc_add_invocant in Parrot_pcc_invoke_method_from_c_args should be expanded.
Chirag its throwing: parrot/pbcversion.h: No such file or directory .. let me check 15:38
yea fone 15:39
done*
rurban need to reconfig
make reconfig 15:40
Chirag did that.. got pcc.c
rurban there are several unneeded checks if CallContext is a proper object 15:41
it is
Chirag will have dinner and be back in a while 15:42
rurban I'll have lunch 15:55
rurban_ Chirag: K. Kaif was actually pretty solid in Zindagi Na Milegi Dobara, not so stiff. But she always plays herself. And Hrithik Roshan blew everyone away. 16:16
Didn't like the movie. Too european camera. Indian camera work is much better. And the story was boring and too predictable 16:17
Chirag yeah story not so much.. I liked the scenic beauty.. Europe way too beautiful :) 16:24
rurban_ Spain is beautiful, but the camera... 16:29
Costa Brava!
Chirag breathtaking yes! 16:30
i cant think of movies that you might like for the story... maybe the two "Munnabhai" movies 16:33
rurban_ : github.com/ZYROz/parrot/commit/f1c...bfb84076ee 17:25
rurban "Your chanTs will be lost" :) 17:52
almost 17:53
The (arg_flags)->vtable is known at compile-time 17:54
the call_obj vtable also
18:08 Chirag joined
Chirag oh.. will fix that 18:09
18:09 Chirag_ joined
rurban not easy fixable as the vtable methods are not exported 18:10
did you measure the speedup already? 18:11
mine looks good
Chirag_ didnt do that.. but u checked without correcting this?
rurban no speedup: 9.70 => 9.88 18:12
Chirag_ but we are still calling unshift_integer and unshift_pmc
rurban yes, unfortunately 18:13
I'm thinking of inlining the unshift_pmc for the invocant. CallContext unshift_pmc assumes that there is always one reserve cell free 18:14
Chirag_ yea .. if we could put a patch to achieve the same functionality.. but yeah I coud not find their definition 18:16
PS: "Your chanTs will be lost" ? I didnt get it 18:17
rurban gist.github.com/rurban/f625d47aa9dbbbe25565 18:18
typo in your patch
I could not measure any improvement 18:19
18:21 FROGGS joined
Chirag_ oh! 18:22
rurban updated gist.github.com/rurban/f625d47aa9dbbbe25565 18:24
Chirag_ so just replacing GETATTR_CallContext_arg_flags 18:25
rurban yes, the others are the same 18:26
we just skip the obj type and flag check
but this was not it 18:27
Chirag_ what more can be done? 18:29
rurban maybe measuring the vtable call overhead 18:34
18:36 Chirag joined
Chirag hmm.. it won't make sense to replace the calls if we won't get any speed improvement 18:37
rurban yes, and how much. maybe inline one such vtable call, and then extrapolate 18:38
or export all CallContext vtable functions, and call them directly 18:40
just for benchmarks
Chirag hmm... that will help in deciding 18:43
rurban Parrot_pcc_build_sig_object_from_op is the current most expensive sig call 18:49
even more than fill_params
perf record ../run-bench.sh; perf report 18:50
18:54 Chirag joined
rurban please see backlog on the web 18:55
18:58 rurban1 joined 19:04 Chirag joined 19:14 Chirag joined 19:24 Chirag joined
Coke rakudo user reported a segfault on rakudo.parrot @ rt.perl.org/Ticket/Display.html?id=122274 - it's in rakudo's C code that interacts with parrot, but figured I'd mentino here in case rurban can fix it. :) 19:26
19:34 Chirag joined 19:44 Chirag joined
rurban Coke: Looks like jonathan's code but I'll have a look 19:51
19:54 Chirag joined 20:04 Chirag joined
rurban Coke: worked fine for me with uptodate perl6-p 20:28
Chirag: So it looks the boxing of signature values is the biggest problem. wiki.enlightenedperl.org/gsoc2014/i...signatures 20:35
"(Refactor CallSignature to store arguments as a typed array, instead of as a PMC array. The types we know from the signature, so can store and retrieve the elements in a type-safe way. This will reduce the number of PMCs created, since integer, number, and string arguments can be stored directly instead of boxed in PMCs.)"
Coke rurban: danke. 20:42
rurban I believe Stables or the optimizations changed a bit recently. I also could not finish the perl6-p spectests recently 20:58
Coke there are some known issues in the perl6-p spectests: 22:06
github.com/coke/perl6-roast-data/b....out#L2902 or so.
the "abort" down at the bottom therewas probably due to a hanging test; I've refudged that, should be better now.
22:12 rurban1 joined 22:34 kid51 joined 23:29 rurban1 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!