-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
for everyone interested in getting the last bit of speed out of his PHP
I created a small extension that overrides the ZEND_CASE opcode and
optimizes its execution.
On the first execution of a switch statement it builds up a jumptable
for all the cases and later execution of the same switch statement is
then performed by directly looking up the jump target within the jumptable.
You can find more information and the download at
http://www.suspekt.org/switchtable/
I am very interested how it performs with YOUR switch statements. And I
am also very interested if its implementation unexpectedly breaks YOUR
switch statements.
Greeting,
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiQzHoACgkQSuF5XhWr2nh1xwCfbnodynq8pfjuaennWlj+tih6
PNcAoI8GABX3YwoSMRT/34gLxkdGy1dM
=ULxN
-----END PGP SIGNATURE
Stefan Esser wrote:
Neat I hope this works well and can go into the main engine. I did not
look to see if there was a licensing issue.
We have basically done this in PHP land for Phorum. We had a huge
switch in our url creation function. It was the slowest thing in the
app. So, we convered it to an array lookup system instead and got lots
of performance. We also made a Phorum extension to handle the URL
creation for those that need that little extra bump.
--
Brian Moon
Senior Web Engineer
When you care enough to spend the very least.
http://dealnews.com/
Brian Moon schrieb:
Neat I hope this works well and can go into the main engine.
Should it not rather got into the new optimizer extension instead?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Hello Stefan,
please discuss with RMs when to merge this in. IMO such a nice locale
improvment can go in anytime during alpha when RMs approve.
marcus
Wednesday, July 30, 2008, 10:18:02 PM, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
for everyone interested in getting the last bit of speed out of his PHP
I created a small extension that overrides the ZEND_CASE opcode and
optimizes its execution.
On the first execution of a switch statement it builds up a jumptable
for all the cases and later execution of the same switch statement is
then performed by directly looking up the jump target within the jumptable.
You can find more information and the download at
I am very interested how it performs with YOUR switch statements. And I
am also very interested if its implementation unexpectedly breaks YOUR
switch statements.
Greeting,
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiQzHoACgkQSuF5XhWr2nh1xwCfbnodynq8pfjuaennWlj+tih6
PNcAoI8GABX3YwoSMRT/34gLxkdGy1dM
=ULxN
-----END PGP SIGNATURE-----
Best regards,
Marcus
Please note that the extension modifies op_array and run-time and it
definitely will break opcode caches. However, it is probably possible to
reimplement it on compiler level (may be with new opcode).
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Stefan,
please discuss with RMs when to merge this in. IMO such a nice locale
improvment can go in anytime during alpha when RMs approve.marcus
Wednesday, July 30, 2008, 10:18:02 PM, you wrote:
Hi,
for everyone interested in getting the last bit of speed out of his PHP
I created a small extension that overrides the ZEND_CASE opcode and
optimizes its execution.On the first execution of a switch statement it builds up a jumptable
for all the cases and later execution of the same switch statement is
then performed by directly looking up the jump target within the jumptable.You can find more information and the download at
http://www.suspekt.org/switchtable/
I am very interested how it performs with YOUR switch statements. And I
am also very interested if its implementation unexpectedly breaks YOUR
switch statements.Greeting,
Stefan
Best regards,
Marcus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Dmitry,
while I also believe that the extension should not be included in the
core at the moment I strongly believe that it will be compatible with
every well behaving opcode cache.
Because it modifies op_array during execution...
a) the opcode cache is not affected at all because it always provides a
copy of the cached op_array to execute()
or b) the modification will be performed on the cached opcodes in memory
which means the opcode cache either stores (and therefore shares) the
manipulated opcodes (with other processes) or not. Either way any
process loading the opcodes that were manipulated by another process
should recognise the loaded op_array as not yet optimized. Therefore the
optimization will be repeated in the other process again => No problem
at all.
Therefore only on edge cases, where 2 processes share the same memory
addresses for the switchtables a malfunction due to an opcode cache can
happen. (I will improve that by a canary value that is different for
each process and that I will store in the extented_value of the JMPZ
opcode that is following the CASE)
Attention: switchtable is not threadsafe at the moment
Stefan Esser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiS+BMACgkQSuF5XhWr2nhGxQCgn1EPNaZS3ndUZG4DKTQ2+njk
7lwAnjiTWCoInAbR1jTY+4B6vdEm8NLd
=+8w7
-----END PGP SIGNATURE
Hi Stefan,
Opcode caches don't usually copy the op_array.opcodes from shared memory
to process memory, so modification of opcodes may affect other processes
which execute the same op_array.
As you set the extended_value in shared memory to point into process
memory the other process will read it and look into it's own memory, and
of course it won't find proper switch-table there.
It makes sense to do this optimization before storing op_array in shared
memory (in PHP compiler itself or optimizer).
Thanks. Dmitry.
Stefan Esser wrote:
Hello Dmitry,
while I also believe that the extension should not be included in the
core at the moment I strongly believe that it will be compatible with
every well behaving opcode cache.Because it modifies op_array during execution...
a) the opcode cache is not affected at all because it always provides a
copy of the cached op_array to execute()or b) the modification will be performed on the cached opcodes in memory
which means the opcode cache either stores (and therefore shares) the
manipulated opcodes (with other processes) or not. Either way any
process loading the opcodes that were manipulated by another process
should recognise the loaded op_array as not yet optimized. Therefore the
optimization will be repeated in the other process again => No problem
at all.Therefore only on edge cases, where 2 processes share the same memory
addresses for the switchtables a malfunction due to an opcode cache can
happen. (I will improve that by a canary value that is different for
each process and that I will store in the extented_value of the JMPZ
opcode that is following the CASE)Attention: switchtable is not threadsafe at the moment
Stefan Esser
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dmitry,
As you set the extended_value in shared memory to point into process
memory the other process will read it and look into it's own memory, and
of course it won't find proper switch-table there.
In case the opcode cache directly uses op_array mapped in shared memory
the extension should result in a slow down because every . However it
SHOULD detect that the extended_value points to an invalid memory
address, because it checks if it points into the memory allocated. The
heap should be random enough to catch this most of the time.
But yeah I know that there are some (potential) problems ;) That is why
it is experimental. The bigger question is however if the whole idea
fails with some switch() constructs.
Stefan Esser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiTC4QACgkQSuF5XhWr2ni66ACdG2DuhO/q2n1StRU559QCPoMn
iiwAoLpBBcA/jQD0NjBajkD/uRpEWa5M
=kloR
-----END PGP SIGNATURE
The whole idea is great, but it'll work without problems only if
switch-tables are constructed at compile (or optimization) time.
The idea also won't work with variables and unresolved constants as
"case" labels (I saw your extension already carries about this limitation).
I think the proper way to implement the idea is introducing a new opcode
ZEND_SWITCH which has switch table as IS_CONSTANT_ARRAY operand.
Thanks. Dmitry.
Stefan Esser wrote:
Hi Dmitry,
As you set the extended_value in shared memory to point into process
memory the other process will read it and look into it's own memory, and
of course it won't find proper switch-table there.In case the opcode cache directly uses op_array mapped in shared memory
the extension should result in a slow down because every . However it
SHOULD detect that the extended_value points to an invalid memory
address, because it checks if it points into the memory allocated. The
heap should be random enough to catch this most of the time.But yeah I know that there are some (potential) problems ;) That is why
it is experimental. The bigger question is however if the whole idea
fails with some switch() constructs.Stefan Esser
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
The idea also won't work with variables and unresolved constants as
"case" labels (I saw your extension already carries about this limitation).
Yeah constants are the reason why I perform the optimization at runtime.
Because the moment a switch is executed the constants should be
available, because otherwise the switch() does not make sense.
And at that point the constant cannot change anymore.
That is the reason why compiletime / optimization time optimization is a
problem.
And yes variables and function calls in CASEs are a problem. That is why
I am not supporting them (and will not). After all there are people that
"abuse" switch() as OR.
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiTJYkACgkQSuF5XhWr2niH/gCfVhl1xoED9IdEUUPvUgKlxtaI
31gAoJdnpFssybdbqfwYC8XUDpMdfUWY
=8mem
-----END PGP SIGNATURE
The whole idea is great, but it'll work without problems only if
switch-tables are constructed at compile (or optimization) time.The idea also won't work with variables and unresolved constants as
"case" labels (I saw your extension already carries about this limitation).I think the proper way to implement the idea is introducing a new opcode
ZEND_SWITCH which has switch table as IS_CONSTANT_ARRAY operand.
Doesn't this make more sense to do in an optimizer? I thought the
general idea was that we don't try to make the compiler do all the heavy
optimizations.. as there are many more we could do here.
regards,
Derick
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Hello Stefan,
I am very interested how it performs with YOUR switch statements. And I
am also very interested if its implementation unexpectedly breaks YOUR
switch statements.
this is potentially useful for the default parser of PEAR::MDB2_Schema:
http://cvs.php.net/viewvc.cgi/pear/MDB2_Schema/MDB2/Schema/Parser.php?view=markup
Which tool do you want me to use to measure the performance gain ?
regards,
Igor.