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 = 12345+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)
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 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
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
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
Hi Nuno,
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
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
overwritesstrlen()
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
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
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
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
-----Original Message-----
From: Nuno Lopes [mailto:nlopess@php.net]
Sent: 14 September 2007 18:01
To: PHPdev
Cc: stas@zend.com; andi@php.net; dmitry@php.net
Subject: [PHP-DEV] RFC: mark functions as const for possible
optimizationsHi,
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 = 12345+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)