Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 9 July 2014.
08:16 basiliscos joined 10:19 Tene joined 16:11 rurban1 joined 16:42 Chirag joined
Util # Doing: 19:36
* Parrot release today.
* smolder.parrot.org (still not fixed)
.end
Hello! Who all is in attendance?
Chirag Me 19:39
Util Hi, Chirag! 19:40
Chirag Hey! report in a min :)
Util OK 19:41
Chirag Report- 19:45
#Done:
* Completed running bench.sh on all commits for the version range 2.7-2.8. We now have all the benchmark data for 2.7-3.0 but no strong candidate for the commit that might have slowed down Parrot.
* Tried optimizing src/call/pcc.c by inlining VTABLE calls in Parrot_pcc_add_invocant.
Also, inlining Parrot_pcc_add_invocant in Parrot_pcc_invoke_method_from_c_args.
However, no performance improvement.
#Doing: 19:46
* Discussing new task with rurban - Removing the overhead of "boxing signature values as PMCs" when they can be directly used with their own types. (Parrot <0.9)
#Todo:
* Start new task
* GSoC Weekly Report
rurban1 * helping with benchmarks and the new GSOC task
* looking at older tickets for the upcoming release 19:47
* rakudo parrot still unstable in this release cycle, but a nqp/rakudo issue
* cannot really use perl6 now for benchmarks 19:48
Util Welcome, rurban1
rurban1 yeah, and looking how to avoid the pcc autoboxing overhead. at least we could inline some CallContext field accessors 19:49
but nothing close to whiteknights reported 200% + 200% slowdowns. more like 0.2%
Util Timeframe for a fix for "rakudo parrot"? And do you know who is working on it? 19:50
rurban1 they are working on it, getting better
froggs, jnthn, lizmat
Util OK, thanks 19:51
rurban1 esp. froggs 19:52
I will look into the opengl mavericks problem for the upcoming release 19:53
Util whiteknight (in his post) mentioned info from dukeleto. Perhaps a note to dukeleto or even whiteknight might help pinpoint the commit? Just a thought.
rurban1 it was a complete refactoring. in fact multiple refactorings, some good, some bad 19:55
Util Also, the 200+200 was figured *before* the rewrite of " the naive CallSignature implementation into a much more efficient form"
rurban1 yes, I figured
now we are pretty good with compiled methods and vtables, just run-time methods and overloaded methods are slow
ext overloaded, => ext_call running it's own runloop with new interp 19:56
esp. overloaded
this might be the next big goal, allowing those methods to run in the same loop 19:57
and get rid of autoboxing, at least for the invocant
and up to max_args which could be hold in the callcontext registers 19:58
held 19:59
oops, today is release day, right? 20:00
Util Without Smolder, there is less confidence in a release.
Can either of you think of any reason this release might be less stable that the last? Any reason to delay the release?
rurban1 no chance for opengl then. but not repro for my mavericks system anyway
nope, my smokers ran good. all ok 20:01
very stable
Util Great!
rurban1 perl514.cpanel.net/build/builders but not uptodate 20:02
Util Official: "please hold all commits to the master branch, until I give the all clear notice"
rurban1 sure :) 20:03
and smolder only fails for linux systems, the other reports ran through
This is a supported one, right? 20:04
Util Chirag: to clarify, "boxing signature..." is the GSoC task that you are about to start?
Chirag yes
Util OK, thanks
Chirag I will include it in my report
rurban1 we are looking into some low hanging fruits in the PCC. boxing might be too much.
but we will see, there are several other minor tasks to look at 20:05
Chirag Maybe we can officially document the task like before.. whenever it is convenient, rurban.. 20:06
rurban1 caching string=>sig objects e.g. for run-time methods
all is documented in the enligthened perl wiki
Util +1 # Documenting
Chirag I meant like GH#issue
rurban1 sure, after the evaluation 20:07
we are not sure yet, what task is the best to go forward, and what will not work
Chirag hmm... 20:08
rurban1 fighting the API restrictions e.g. exporting some callcontext methods to use them internally 20:09
avoid the vtable indirect call overhead, and such. but there are several such ideas
Chirag we tried with add_invocant 20:10
rurban1 at least we are not creating useless PMC's per compiled method calls anymore, which was the biggest complaint 20:11
add_invocant adds self to the fron of the args array. there should be something better in the PCC (and there was with Sugalski's design)
so in summary we have several options, but it is not clear yet, which we take 20:13
and it will be not much gain, I fear
<1% or so
Chirag even the autoboxing overhead? 20:14
rurban1 but at least I finished B::C testing, so I can use my machines for proper parrot profiling. Chirag's machine is now also ready for profiling. he got a slow one, so the differences might be better
autoboxing overhead will be ~5% I guess, but it will be harder to undo it 20:15
maybe we can spare the first 4-6 args from autoboxing and hold it in the registers. we'll see, but then the pcc will get more complicated 20:17
Util GSoC standards are to have a complete roadmap, with inchstones (micro-milestones) *before* the first day of coding.
If we have opted for some flexibility instead of rigid adherence to that standard, we will still be held to it in the end.
Rather than a vague "discuss" item-of-work, try something like:
"Profile and evaluate add_invocant, autoboxing, <foo>, <bar>, <baz>, and determine highest overhead; to be used as target for next refactor"
.end 20:18
Chirag Oh thanks! I will follow that.. 20:20
Util Chirag: rurban1 sounds correct at the technical level, that the next task is worth consideration;
I just want to be sure that your hard work does not get documented in a way that sounds like dithering, instead of actual work. 20:21
Chirag yes, I understand.. 'Testing' alone might seem like it 20:22
rurban1 currently it's more guessing and dithering. I cannot really trust the profiling and benchmarks
too much noise currently
maybe switching to a stable rakudo subset of tests to benchmark will be better 20:23
but this will lead to drastically longer build times
Util Even at the risk of choosing wrong, 20:26
I encourage you both to take no more than this *one* week to explore,
and then nail down the remaining items-of-work *in* *detail*.
rurban1 Sure. We'll start documenting the ideas it in the wiki
several are already there
Util Past the mid-terms, the risk is high of mis-timing the workload, and running past the "pencils down" deadline.
Chirag +1 20:27
rurban1 wiki.enlightenedperl.org/gsoc2014/i...tures.edit
Util Any blockers right now?
rurban1 nope: wiki.enlightenedperl.org/gsoc2014/i...signatures
Chirag no other blockers
rurban1 other than the ongoing nqp/perl6 work, none
Util Anything else to discuss? From anyone? 20:28
OK. Thanks everyone! 20:30
Meeting adjourned.
22:44 lizmat joined 23:00 basiliscos 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!