develooper Front page | perl.perl5.porters | Postings from December 2007

Re: optimising opcodes

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
December 31, 2007 02:46
Subject:
Re: optimising opcodes
Message ID:
20071231104620.GA23703@plum.flirble.org
On Mon, Dec 31, 2007 at 10:15:53AM +0100, Rafael Garcia-Suarez wrote:
> On 24/12/2007, Nicholas Clark <nick@ccl4.org> wrote:
> > 0: How hard would it be to write some code to take an optree, and copy out all
> >    the live ops into a new optree, skipping any nulled out ops?
> > 1: Would that break the runtime?
> 
> Are we sure we don't use null ops at all ? an idea just crossed my mind:
> some COPs can be nullified, (try with an if() statement for example),
> but does the runtime still fetch a line number in it to add it to a
> warning or an error message ?


Paul Johnson seemed to think so:

On Wed, Dec 26, 2007 at 11:11:06AM +0100, Paul Johnson wrote:

> Note that doing this would reduce the accuracy of some error messages.
> In particular, we can get some line number information from nullops, and
> whilst nothing would /break/ if the nullops weren't there (in this
> sense), some line numbers would be reported incorrectly.
> 
> Unless that information could be copied somehow as the nullops were
> removed.  This fits in with a discussion we were having previously about
> including line numbers (and filenames) in more ops.

However, with pointer games, I think it would be possible to add line number
information to any op type. (By storing it before the op structure, and having
a flag bit in the op to mean "by the way there is a line number structure
before me in memory"). It would be the same sort of pointer arithmetic we're
already using to avoid allocating NVs for the SV types RV, PV and PVIV.


As a first step, it might be viable to reorder ops, not throwing any away.
Copy all the non-null ops in execution order, then put all the null ops
after them. Hopefully this would ease cache pressure, even if it doesn't
save any memory initially. And as far as everything else is concerned, it's
actually totally binary compatible. Not just source compatible.
(Providing you were using the slab allocator)

Nicholas Clark

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