develooper Front page | perl.perl5.porters | Postings from January 2013

[perl #116188] [PATCH] hv.c: add some SvREFCNT_dec_NN and S_hv_free_ent_ret NULL check removal

Thread Previous | Thread Next
From:
bulk88 via RT
Date:
January 26, 2013 05:46
Subject:
[perl #116188] [PATCH] hv.c: add some SvREFCNT_dec_NN and S_hv_free_ent_ret NULL check removal
Message ID:
rt-3.6.HEAD-27190-1359179196-1449.116188-15-0@perl.org
On Fri Jan 25 12:44:16 2013, doughera wrote:
> On Sun, 23 Dec 2012, bulk88 wrote:
> 
> > # New Ticket Created by  bulk88 
> > # Please include the string:  [perl #116188]
> > # in the subject line of all future correspondence about this issue. 
> > # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=116188 >
> 
> [minor nit:  This patch breaks a debugging build because embed.fnc 
> incorrectly spells the second argument as 'entryK', while the actual 
> functions use 'entry'.  I fixed this in commit 
> c77ce6f12343471289c57516378e4af4ccce4b6c.  I then tweaked this patch
> to use 'entry' instead of 'entryK'.]
> 
> I tried this patch and tested it on Linux/amd64 with gcc-4.7.2,
> with various optimizer settings.
> 
> It looks like this patch is doing good things -- avoiding redundant NULL 
> checks, avoiding duplicating a test, removing an unnecessary context, 
> etc., and doing it in a set of functions that gets called fairly often.  
> However, I found that it made no difference in performance in running a 
> pattern matching program similar to metaconfig, and (under -O3) the new 
> object files are actually larger than the old ones.
> 

I would say removing a null check is unmeasurable unless you are using
rdtsc. Can you post before and after perl binaries, and the perf numbers
you got in detail? I'd like to see myself how the object files got larger.

> In both cases, gcc inlines the S_hv_free_ent_ret function anyway, and the 
> resulting Perl_hv_free_ent function is exactly the same size before and 
> after the patch.

VC -O1 doesn't inline SvREFCNT_dec_NN or S_hv_free_ent_ret.
__forceinline vs __inline issue specific to VC.

> 
> I also tested with Sun's cc compiler.  It ended up giving the same 
> performance and the same object size before and after the patch.
> 
> So I'm not sure if it's worth applying or not.  What do you think?
> 

I would apply it. There were a couple of other places in hv.c where I
tried a _NN but got segvs. I think that I went through everything I
thought could get an _NN in hv.c and gave it a _NN if possible. This
patch was the only things that were successful in _NN conversion. I
don't remember if I skipped any SvREFCNT_decs due to lack of familiarity.

I use -O1. Are you using a threaded or unthreaded perl? is your sun x86
or sparc?

-- 
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=116188

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About