Grant Proposal: Optree Optimsiations for Performance Gains
Thu, 20-Jan-2022 by
Jason A. Crome
edit post
<.
## Timeline
Each of the three optimisations would process through the following stages:
**1. Create an "ideal-case" benchmark test **
Begin by creating a benchmark containing some simple code that is entirely composed of one particular kind of operation, which is the target of the
optimisation. Measure this benchmark case in order to obtain a baseline performance measurement.
**2. Implement the optimisation **
Apply code to the Perl interpreter by defining new opcode flags, adjusting the peephole optimiser, or whatever other techniques may be required to achieve it.
Take a second measurement of performance with the optimisation applied. This should give an indication of the maximal possible gain that could be achieved.
**3. Analyse large programs to estimate extent of application**
While the figure gained in the above step gives a best-case value, it is unlikely that real-world programs would be able to gain as much benefit. It would be useful to analyse the generated optree of real-world programs to get an estimate of how likely these optimisations are to be hit, and a guess at what proportion of the potential benefit could actually be achieve in a real case.
Actually this step could be performed first, for each of the three optimisations, to get a suggestion on which of them are likely to be the most useful, and thus how to assign the remaining project time to each of them.
## Author Information
I am Paul Evans, PEVANS on [CPAN](https://metacpan.org/author/PEVANS) and current member of the Perl Steering Committee.
I have been a CPAN maintainer for over 12 years, and currently have over 200 distributions under my name. Recently I have been working on a variety of perl core features; adding the `isa` operator to Perl 5.32, `try/catch` syntax to 5.34, and the `builtin::` namespace of additional core functions expected to be part of the upcoming 5.36 release.
I have successfully completed two TPF projects before, to improve the implementation of the `Future::AsyncAwait` module; and to create bindings for the `libuv` event system.
## Amount Requested
$3,980 USD
## Appendix
The three optimisations described in more detail:
### `OA_TARGLEX` on `OP_CONST`
Give the `OP_CONST` opcode the `OA_TARGLE` flag, meaning that code such as
```
$var = 123;
```
gains a performance optimisation, discarding the `OP_PADSV` and `OP_SASSIGN` which is normally used to implement scalar lexical variable assignment from a constant, leaving just a single `OP_CONST` in its place.
### `OA_TARGLEX` with `OPpLVAL_INTRO`
Create a new `OA_...` constant, or adjust the semantics of the existing `OA_TARGLEX`, such that it can also apply in `OPpLVAL_INTRO` situations. This would allow the (currently fairly-rare) `OA_TARGLEX` optimisation to
also apply on variables introduced in `my` expressions, such as
```
my $zero = 0;
```
by once again discarding the `OP_PADSV` and `OP_SASSIGN` ops.
### Fold away `OP_PADSV` arguments to `UNOP`s
Create a similar optimisation to the `->targ` opcode field, applicable to `UNOP`s to contain the pad offset of a lexical variable argument for arguments being passed into `UNOP`s. Thus for example a statement like
```
sleep $time;
```
could discard the `OP_PADSV` of its incoming argument, and similarly avoid using the stack for the lexical variable.
]]>
Comments (0)
