develooper Front page | perl.perl5.porters | Postings from October 2012

Re: Compile option to disable taint mode: speedup

Thread Previous | Thread Next
From:
Steffen Mueller
Date:
October 10, 2012 10:40
Subject:
Re: Compile option to disable taint mode: speedup
Message ID:
5075B2FA.2070301@cpan.org
On 10/10/2012 02:56 PM, Tim Bunce wrote:
> On Wed, Oct 10, 2012 at 09:09:21AM +0200, Steffen Mueller wrote:
>>
>> [...] around 10-20% faster [...]
>
> That seems surprising to me, given the change. Even for a micro-benchmark.

Same here. I said so before, but other benchmarks showed 1-2%. Callgrind 
showed 1% fewer instructions executed.

>> Of those things, this is left:
>> - Code review.
>> - Test some CPAN against a SILENT_NO_TAINT_SUPPORT perl.
>> - Configure support.
>> - Review the remaining taint test failures of the core modules. Some
>> fail for a reason because they check -T specifically, some should
>> just be skipped if not ${^TAINT} since they test taint compatibility.
>
> + Gain a deeper understanding of where the costs/savings actually are.

Yes, that would be nice. Alas, it's also a project that's 1-2 orders of 
magnitude more work from where I stand. And it's not just work. It 
requires me to become smarter.

Basically, we struggle A LOT with benchmarking these "small" changes. 
Trying to disseminate further must therefore come from complete 
understanding or very detailed profiling/accounting instead of just 
"poke with a stick and see". I'm not good enough a C programmer or 
familiar enough with perl's implementation that I could do that.

> Accessing an interpreter structure element should be very cheap.
> Given the size of the struct perhaps there's some L1 cache thrashing.
> In which case perhaps clustering together hot elements may help
> reduce the cost of taint checking, and perhaps much else besides.

It's a fair number of run-time checks + at least one assignment per 
NEXTSTATE.

> Also, while browsing around I noted that SvTAINTED(sv) is defined as
> (SvMAGICAL(sv) && sv_tainted(sv)) and I wonder if that should include
> a test for TAINTING_get before (or perhaps after) SvMAGICAL.

Sounds like that change alone would fall under the "lost in benchmarking 
noise" category -- maybe. Admittedly, I won't know without trying as per 
what I said above.

> Perhaps there are unexpected costs elsewhere. Basically I'm saying that
> digging deeper here may yield lessons that could be applied elsewhere.

Quite possibly, but it'll be for somebody better than me.

> + Experiment with more static branch prediction.
>
> I recall some previous experiments with using branch prediction hint
> macros.  I think they weren't applied extensively enough to prove a
> difference either way.  There are only 11 in the current code, most in
> utf8.c, and none in headers.
>
> Wrapping TAINT_get, TAINTING_get and SvTAINTED with UNLIKELY(...) may help:
> #   define TAINT_get        UNLIKELY(PL_tainted)
> at least for compilers that support __builtin_expect, i.e. GCC.
> http://linuxkernelpanic.blogspot.ie/2010/06/using-static-branch-prediction-with-gcc.html

In the implementation of Sereal, I used lots of those and found that 
there were one or two cases where it was quite obviously helpful and 
otherwise a wash. On those former cases, it wouldn't have been too hard 
to reorganize the code to have the same effect based on what appears to 
be the default assumption.

--Steffen

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