Everything

php

Home » Project » Newsgroups » php.internals » RFC: mark functions as const for possible optimizations »

RFC: mark functions as const for possible optimizations

php.internals

Nuno Lopes

18 years ago

Hi,

Following my last post on bytecode optimization
(http://news.php.net/php.internals/32113), I would like to discuss a few
more things.
The patch in that e-mail allowed the engine itself to do transformations
like, e.g.:
$a = 1*2*3*4*5+1-0;   -->  $a = 121;

However the patch is now a bit dead because Stas would like to have more
advanced things that I didn't have time yet to look at (because the proposal
introduces several difficult ambiguities in the grammar).

So, let's move on for now :P

My proposal is the following:
some functions when fed with constant arguments always return a constant
value, too. e.g.:
strlen('abcd') === 4.

This means that an optimizer can and should do this transformation. (and
others like: $a='abcd'; strlen($a); -> 4). I think Ilia created a list of
such functions in his optimizer. But I would like to have that list in the
core, so that everybody can benefit from it.
Basically the only thing needed to do is to change PHP_FE() to
PHP_CONST_FE() in the function entry tables.

The patch: http://web.ist.utl.pt/nuno.lopes/zend_const_function_entry.txt
(includes a few function entries changed as an example)


Nuno

P.S.: the university semester has already started, so don't worry with the
e-mail traffic I'm generating because it'll end pretty soon (until the next
vacations :P)

Hartmut Holzgraefe

18 years ago

Nuno Lopes wrote:

> My proposal is the following:
> some functions when fed with constant arguments always return a constant
> value, too. e.g.:
> strlen('abcd') === 4.

wouldn't that be called "deterministic" and not "const"?

--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html

Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140

Nuno Lopes

18 years ago

> Nuno Lopes wrote:
> > My proposal is the following:
> > some functions when fed with constant arguments always return a constant
> > value, too. e.g.:
> > strlen('abcd') === 4.
>
> wouldn't that be called "deterministic" and not "const"?

yeah, exactly. I was missing the correct wording. (btw, appart of being
deterministic, the function shouldn't have any side-effect).
Nuno

Peter Brodersen

18 years ago

On Fri, 14 Sep 2007 18:01:13 +0100, in php.internals nlopess@php.net
("Nuno Lopes") wrote:

>My proposal is the following:
>some functions when fed with constant arguments always return a constant
>value, too. e.g.:
>strlen('abcd') === 4.

I like the general idea.

Would there be some caveats with stuff like this if it is possible to
change the charset at runtime?

I guess it is important to be aware of whether a function is affected
by different settings (and if these settings can be changed at
runtime) to conclude if a function really is deterministic at this
level.

--
- Peter Brodersen

Nuno Lopes

18 years ago

> >My proposal is the following:
> >some functions when fed with constant arguments always return a constant
> >value, too. e.g.:
> >strlen('abcd') === 4.
>
> I like the general idea.
>
> Would there be some caveats with stuff like this if it is possible to
> change the charset at runtime?
>
> I guess it is important to be aware of whether a function is affected
> by different settings (and if these settings can be changed at
> runtime) to conclude if a function really is deterministic at this
> level.

uhm, damn, right. strlen() wasn't a good example.. my bad, sorry :S
Anyway, you got the idea :)

Nuno

Johannes Schlueter

18 years ago

Hi Nuno,

On Sun, 2007-09-16 at 20:02 +0100, Nuno Lopes wrote:

> > >My proposal is the following:
> > >some functions when fed with constant arguments always return a constant
> > >value, too. e.g.:
> > >strlen('abcd') === 4.
> >
> > I like the general idea.
> >
> > Would there be some caveats with stuff like this if it is possible to
> > change the charset at runtime?
> >
> > I guess it is important to be aware of whether a function is affected
> > by different settings (and if these settings can be changed at
> > runtime) to conclude if a function really is deterministic at this
> > level.
>
> uhm, damn, right. strlen() wasn't a good example.. my bad, sorry :S
> Anyway, you got the idea :)

Nothing wrong with strlen as far as I can tell:

- In PHP 5 we only have binary strings so strlen() works independent
from any charsets and encodings by just counting bytes.
- In PHP 6 we know - assuming the parameter is a constant string - the
encoding at compile time, therefore it could be used.

The only edge-case I see is if somebody uses mbstring.func_overload and
overwrites strlen()

johannes

Nuno Lopes

18 years ago

> On Sun, 2007-09-16 at 20:02 +0100, Nuno Lopes wrote:
>> > >My proposal is the following:
>> > >some functions when fed with constant arguments always return a
>> > >constant
>> > >value, too. e.g.:
>> > >strlen('abcd') === 4.
>> >
>> > I like the general idea.
>> >
>> > Would there be some caveats with stuff like this if it is possible to
>> > change the charset at runtime?
>> >
>> > I guess it is important to be aware of whether a function is affected
>> > by different settings (and if these settings can be changed at
>> > runtime) to conclude if a function really is deterministic at this
>> > level.
>>
>> uhm, damn, right. strlen() wasn't a good example.. my bad, sorry :S
>> Anyway, you got the idea :)
>
> Nothing wrong with strlen as far as I can tell:
>
> - In PHP 5 we only have binary strings so strlen() works independent
>  from any charsets and encodings by just counting bytes.
> - In PHP 6 we know - assuming the parameter is a constant string - the
>  encoding at compile time, therefore it could be used.
>
> The only edge-case I see is if somebody uses mbstring.func_overload and
> overwrites strlen()

exactly. I was thinking in mbstring, too. As long as there is some run-time
setting that can affect a function, we cannot replace its call blindly with
its value. Then only a more intelligent optimizer can do inference on the
code and figure out if it's safe or not to replace the function call.
My proposal was to mark functions susceptible of that "blind" replacement
only.

Nuno

Andrew Brampton

18 years ago

From: "Nuno Lopes" <nlopess@php.net>
To: "PHPdev" <internals@lists.php.net>
Cc: <stas@zend.com>; <andi@php.net>; <dmitry@php.net>

> My proposal is the following:
> some functions when fed with constant arguments always return a constant
> value, too. e.g.:
> strlen('abcd') === 4.
>
> This means that an optimizer can and should do this transformation. (and
> others like: $a='abcd'; strlen($a); -> 4). I think Ilia created a list of
> such functions in his optimizer. But I would like to have that list in the
> core, so that everybody can benefit from it.
> Basically the only thing needed to do is to change PHP_FE() to
> PHP_CONST_FE() in the function entry tables.
>

I had a quick question about this. When would strlen('abcd') be execuated?
Say I had the code:

$a = false; // This set by external input
if ( $a )
$b = strlen('abcd');

Would the optimizer work out the length before the program starts to run? Or
would the optimizer wait until it knows the strlen is going to be called
then convert it to the constant 4?

I could see the optimizer "constifying" many function calls which will never
get called.

thanks
Andrew

Nuno Lopes

18 years ago

> I had a quick question about this. When would strlen('abcd') be execuated?
> Say I had the code:
>
> $a = false; // This set by external input
> if ( $a )
>  $b = strlen('abcd');
>
> Would the optimizer work out the length before the program starts to run?
> Or would the optimizer wait until it knows the strlen is going to be
> called then convert it to the constant 4?

That's not my problem.. My RFC is about making the information available,
not writing the optimizer itself (at least for now). With a naive optimizer,
strlen() would be called, yes.

> I could see the optimizer "constifying" many function calls which will
> never get called.

that's not a problem since you would use a cache..

Nuno

Jared Williams

18 years ago

Hi,

Just a thought, now dl() has been deprecated and disabled in SAPIs (except
CLI,CGI,embed),  would that mean extension_loaded() would become a
optimizable function?

So something like

include extension_loaded('gmp') ? 'GMPFoo.php' : 'PHPFoo.php';

Would be optimized to be more APC friendly?

Jared

Stanislav Malyshev

18 years ago

> Just a thought, now dl() has been deprecated and disabled in SAPIs (except
> CLI,CGI,embed),  would that mean extension_loaded() would become a
> optimizable function?

In non-dl SAPIs probably yes, that would be the consequence.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com