Parrot 6.4.0 "Double-eyed Fig Parrot" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 25 May 2014.
00:24 rurban joined 00:26 rurban1 joined
rurban1 analyzed WB timings. actually vtable methods are a bit faster now, but method calls got a bit slower. 02:01
03:42 rurban joined 04:44 jsut joined 05:36 bighugedog joined 06:49 FROGGS joined 07:33 basiliscos joined 09:47 Psyche^ joined 12:25 rurban joined 13:35 rurban joined 13:47 rurban joined 14:10 bluescreen joined 14:34 basiliscos joined
dalek rrot/rurban/pmc2c_orig2-gh1069: 0fcc744 | rurban++ | docs/pmc.pod:
[docs] more work on pmc.pod

Reformatting and removed UnionVal which was removed with 1.6.0		 14:37
rrot/rurban/pmc2c_orig2-gh1069: 46a7866 | rurban++ | ChangeLog:
ChangeLog: add description for the pmc2c_orig2-gh1069 GSOC project #1

Document how to treat non-core dynpmc's. If they need to be changed or how they can be optimized.
rurban_ Chirag: can you look out for more unneeded WB's? I suspect there are more optimizations possible because we are bit too slow right now. Start with the methods used in the benchmark 14:39
github.com/parrot/parrot-bench 14:40
ResizablePMCArray, CallContext and such 14:41
I suspect 2 more can be found (from the benchmark timings) 14:42
14:45 Chirag joined
Chirag yes.. I will start doing that right away.. 14:46
rurban_ It's just a feeling, but we should be a bit faster, and we were 2-4% faster already 14:49
I'm testing rakudo right now, and then it looks like we can merge it for the next 6.5.0 release 14:50
Chirag nice! 14:53
rurban_ The good thing is, the benchmarks are now pretty stable. the bad, our branch is a bit slower than master 14:54
nqp built fine with the new PMCs 14:57
Chirag even the METHODS need to be checked i think .. I wasnt sure about many of them unlike VTABLE 15:00
rurban_ vtable's are actually a bit faster, methods got slower, yes. But this cannot be as methods always had WBs 15:02
rakudo-p tested fine 15:03
Chirag great.. 15:08
rurban_ the perl6 spectest is also doing fine 15:10
you could check dynpmc's also if you got time 15:11
they are the same, just loaded on request (shared libs) 15:12
but I doubt that there will some opportunities. more likely in nqp/perl6 6model code 15:13
Chirag hmm.. 15:18
15:21 bluescreen_ joined 15:24 wagle joined 16:14 FROGGS joined 17:13 Chirag joined 17:32 rurban joined
Chirag rurban: I am still getting SEGV for gc.t and the build fails 17:34
rurban_ really?
Chirag yeah
rurban_ with my branch and make clean?
Chirag i did a make clean archclean
no my merged branch
rurban_ I'm having another meeting now
Chirag np 17:35
rurban_ I think I got all your latest changes already in
Chirag ya.. our branches are at the same point
your branch is all good... Something wrong with mine 17:41
17:42 basiliscos joined
Chirag did a --hard reset to your branch .. works now 17:53
rurban_ :) 17:57
yeah, I added some github comments to your latest commits
Chirag ya i saw those ... earlier i did a git merge to ur branch.. "checkout --theirs" .. add and commit .. didnt work :P 18:00
rurban_ git fetch; git pull --rebase <branch> is usually easier than merge 18:02
Chirag i ll remember :)
18:25 rurban joined
Chirag rurban: do METHODs and VTABLEs that simply pass on SELF really require a WB?? 18:29
for instance:
METHOD unshift(PMC* value) :manual_wb {
VTABLE_unshift_pmc(INTERP, SELF, value);
}
rurban_ VTABLE_unshift_pmc does the WB here 18:30
and yes, it changes the internal array
push,pop,shift,unshift are all destructive 18:31
Chirag oh
rurban_ perl is not really a functional language
everything side-effects. in perl5 even when just looking at a value will create lots of undef values 18:32
Chirag oh.. i was under an impression that these objects would simply be passed untouched
rurban_ no, aren't they :write? they should be
Chirag vtable.tbl defines only for VTABLEs .. 18:33
so VTABLE_unshift_pmc is a write 18:34
rurban_ hmm unshift is no VTABLE? strange
which pmc is this?
Chirag resizablePmcArray
actually, I was wondering the same thing even for this : 18:37
VTABLE void unshift_pmc(PMC *value) {
do_unshift(INTERP, SELF, value);
}
rurban_ still benchmarking rakudo...
Chirag if SELF goes untouched
rurban_ do_unshift changes SELF
Chirag hmm so both the caller and the callee have to take care of things .. 18:38
rurban_ yes 18:41
do_unshift changes the array size and does a memmove() which is very destructive 18:42
Parrot_ResizablePMCArray_nci_unshift is :manual_wb because VTABLE_unshift_pmc already does the WB 18:44
Chirag understood
rurban_ The next task would be e.g. in Parrot_ResizablePMCArray_nci_unshift to Parrot_pcc_fill_params_from_c_args(interp, _call_object, "PiP",...) to 2 lines of C code to set the 2 values 18:45
1st self and 2nd value 18:46
METHOD append could change the RETURN to return; because SELF is not changed there and no return values need to be prepared 18:48
Chirag so it becomes a no_wb? 18:49
but PMC ** const this_data = PMC_array(SELF) and two more PMCs are assigned 18:50
rurban_ no, we don't care about that one branch with the early exit.
only the frst !m return 18:51
Chirag yes..
the second RETURN should stay right?
dalek rrot/rurban/pmc2c_orig2-gh1069: 7a8611b | rurban++ | src/pmc/resizablepmcarray.pmc:
[pmc] optimize resizablepmcarray.append if other is empty

skip the WB then		 18:52
Chirag shouldnt we make this manual??? otherwise a WB is put in before the return ? 18:53
rurban_ nope, not in this case. check the C file
Chirag hmm.. but why doesnt it add it? 18:54
rurban_ METHODs have their own logic. They just look at RETURN
and add the WB there 18:55
Chirag I have a candidate:
set_pmc
does the first return get a WB before it? 18:56
rurban_ I also just fixed set_pmc. no WB if SELF is not changed 19:00
Chirag yes 19:01
there it was just "SELF == value"
dalek rrot/rurban/pmc2c_orig2-gh1069: a22761a | rurban++ | src/pmc/resizablepmcarray.pmc:
[pmc] optimize ResizablePMCArray WBs

skip some unneeded WBs		 19:06
rurban_ this was a forced push
Chirag One more: 19:07
CallContext -- set_attr_str
rurban_ looks good to me 19:08
Chirag can we put manual WBs in the first two if blocks?
rurban_ not needed since this error doesn't happen
Chirag oh.. ok 19:09
rurban_ we never specialize on exceptions. those branches are almost never taken are slow enough that we don't care if it has a superfluous WB
whow, down to 9.972371830 +- 0.09 19:10
Chirag WOW!
rurban_ But I guess I've changed the compiler, from clang to gcc-4.9 with -O3 19:11
I'll bench now again fully for the 4 last branches, for r in RELEASE_6_3_0 RELEASE_6_4_0 master rurban/pmc2c_orig2-gh1069; do ../bench.sh $r; done 19:12
gcc-4.9 is pretty good actually. looks better than clang-3.4 19:13
Chirag i have never used clang
rurban_ clang is much faster and uses less memory. but it doesn't support -g3. so no macro expansions 19:14
for fulltest I always used clang so far
whow. from 10.437312630 down to 10.156414856 19:17
Chirag .28 ! 19:19
rurban_ maybe we'll find more such
Util #ps in 9m 19:21
rurban_ 2.7% 19:22
Chirag :D 19:23
integer.pmc -- decrement() has a redundant WB? 19:27
rurban_ ah, yes. think so. 19:29
dalek rrot/rurban/pmc2c_orig2-gh1069: 0df5c8e | rurban++ | src/pmc/integer.pmc:
[pmc] optimize Integer.decrement WB

remove one redundant WB, found by Chirag++		 19:33
Chirag rurban: one more : 19:49
float.pmc -- sinh()
rurban_ yes, your turn to commit it :) 19:50
Chirag alright :)
I am not sure about these but 20:01
in string.pmc -- replace() , to_int(), trans() should be manual_wb?
rurban_ : ? 20:06
dalek rrot/rurban/pmc2c_orig2-gh1069: 7af5a55 | ZYROz++ | src/pmc/float.pmc:
optimize Float.sinh WB
 20:13
rurban_ replace: yes. to_int: yes, trans :no_wb 20:15
Chirag will change
rurban_ to_int is actually :no_wb 20:17
Chirag oh
rurban_ `TEST_JOBS=4 perl t/harness` is actually pretty fast 20:21
make -j4 -s && TEST_JOBS=4 perl t/harness 20:22
&& TEST_JOBS=4 perl t/harness --gc-debug t/pmc/*.t 20:23
dalek rrot/rurban/pmc2c_orig2-gh1069: e12e1b1 | ZYROz++ | src/pmc/string.pmc:
[pmc] optimize WBs in some String.METHODs
 20:24
rurban_ 10.052022194 20:25
Chirag :D 20:26
3.7% 20:27
dalek website: ZYROz++ | GSoC 2014 - Report 3 20:43
website: www.parrot.org/zyroz3
rurban_ tada! looks good, Chirag++ 20:44
Chirag thanks! :)
rurban_ you should brag more about how many PMCs you fixed and looked over, and then again, and then again. 20:47
Chirag will do..
:D
rurban_ I only looked over them once, you did 3x 20:48
And it's 95 PMC's with how many methods?
Chirag 7-8 on an avg 20:49
rurban_ 4328 methods at all 20:51
core PMC's, not dynpmc's 20:52
Chirag ooo 20:53
string itself has more than 40
rurban_ and maybe explain for perl6 folks how to check if they need :manual_wb in their own PMCs (see the new docs)
egrep -c '(VTABLE|METHOD|MULTI)' src/pmc/*.pmc | cut -d: -f2 > xx 20:59
Chirag yes 4328 :) 21:06
rurban_ I used lisp for the (+ ...). Forget how to use calc or bc with this
and was too lazy to use perl
Chirag i copy pasted into libre calc :P 21:07
Saying that it "Behaved well even with Rakudo!" is fine right? 21:17
rurban_ No rakudo regressions, right 21:19
No new rakudo benchmarks yet. The last one showed no improvements. And we still don't use parrot -O2 with rakudo yet, because of the old icu problem. Not your beer., well be about 5% I guess 21:21
Chirag hmm.. i ll remove that and say improvement of 5%
rurban_ -O2 was even slower. 21:23
rather say 2.5 - 5% expected
parrot -O2 was 0.9% slower
old pmc2_orig was 0.18% faster 21:24
Chirag ok.. 21:25
argh! "Your submission has triggered the spam filter and will not be accepted." 21:26
rurban_ ??
Chirag blog
how long does one have to wait? 21:27
rurban_ drupal.org/node/353588
I'll check
Looks good. It's online 21:28
Chirag done!
will leave now.. Bye! :) 21:29
rurban_ thank,s, bye
yes, nqp 6model has several WB optimization possibilities 21:49
22:05 GeJ joined 23:23 rurban 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!