Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efe
It's huge, but actually, only changes in zend_compile.h are matter. The
rest is obvious renaming.
the main idea - the smaller the zend_op structure, the lees memory traffic
is required to load VM instructions during execution. The patch reduces the
size of each opcode from 48 to 32 bytes (saves 16 bytes for each opcode,
and applications use thousands of opoceds). This reduced the number of CPU
cache misses by 12% and improved performance of real-life apps by 1-2%.
The patch affects how constants and jump targets are represented in VM
during execution. Previously they were implemented as absolute 64-bit
pointers. Now they are relative 32-bit offsets.
In run-time constant now should be accessed as:
RT_CONSTANT(op_array, opine->op1) instead of opline->op1.zv
EX_CONSTANT(opline->op1) instead of opline->op1.zv
Jump targets:
OP_JMP_ADDR(opline, opline->op2) instead of opline->op2.jmp_addr
The patch doesn't change zend_op representation for 32-bit systems. They
still use absolute addresses. The compile-time representation is also kept
the same.
The patch must affect xdebug and may be other very engine depended
extensions, but it must not be a big problem to fix them (only ext/opcache,
ext/reflection and sapi/phpdbg required minor changes).
If nobody objects, I'm going to commit this.
Thanks. Dmitry.
Seems good for me. =)
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efeIt's huge, but actually, only changes in zend_compile.h are matter. The
rest is obvious renaming.the main idea - the smaller the zend_op structure, the lees memory traffic
is required to load VM instructions during execution. The patch reduces the
size of each opcode from 48 to 32 bytes (saves 16 bytes for each opcode,
and applications use thousands of opoceds). This reduced the number of CPU
cache misses by 12% and improved performance of real-life apps by 1-2%.The patch affects how constants and jump targets are represented in VM
during execution. Previously they were implemented as absolute 64-bit
pointers. Now they are relative 32-bit offsets.In run-time constant now should be accessed as:
RT_CONSTANT(op_array, opine->op1) instead of opline->op1.zv
EX_CONSTANT(opline->op1) instead of opline->op1.zvJump targets:
OP_JMP_ADDR(opline, opline->op2) instead of opline->op2.jmp_addrThe patch doesn't change zend_op representation for 32-bit systems. They
still use absolute addresses. The compile-time representation is also kept
the same.The patch must affect xdebug and may be other very engine depended
extensions, but it must not be a big problem to fix them (only ext/opcache,
ext/reflection and sapi/phpdbg required minor changes).If nobody objects, I'm going to commit this.
Thanks. Dmitry.
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Hey:
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efeIt's huge, but actually, only changes in zend_compile.h are matter. The rest
is obvious renaming.the main idea - the smaller the zend_op structure, the lees memory traffic
is required to load VM instructions during execution. The patch reduces the
size of each opcode from 48 to 32 bytes (saves 16 bytes for each opcode, and
applications use thousands of opoceds). This reduced the number of CPU cache
misses by 12% and improved performance of real-life apps by 1-2%.The patch affects how constants and jump targets are represented in VM
during execution. Previously they were implemented as absolute 64-bit
pointers. Now they are relative 32-bit offsets.In run-time constant now should be accessed as:
RT_CONSTANT(op_array, opine->op1) instead of opline->op1.zv
EX_CONSTANT(opline->op1) instead of opline->op1.zvJump targets:
OP_JMP_ADDR(opline, opline->op2) instead of opline->op2.jmp_addrThe patch doesn't change zend_op representation for 32-bit systems. They
still use absolute addresses. The compile-time representation is also kept
the same.The patch must affect xdebug and may be other very engine depended
extensions, but it must not be a big problem to fix them (only ext/opcache,
ext/reflection and sapi/phpdbg required minor changes).If nobody objects, I'm going to commit this.
As I already participated in this patch, I have no problems & objections.
thanks
Thanks. Dmitry.
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi,
2014-12-10 16:27 GMT+01:00 Dmitry Stogov dmitry@zend.com:
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efe
Looks good, but Isn't ZEND_EX_USE_RUN_TIME_CACHE always defined to 1
with your patch?
Regards,
Patrick
Right. Actually ZEND_EX_USE_RUN_TIME_CACHE and ZEND_EX_USE_LITERALS just
control if corresponding fields of executed op_array should be cached in
current call frame (zend_execute_data). VM will have to execute additional
read/write on enter to each function, but then safe 1 read on each access
to run_time_cache and constants. Surprisingly, I found that on some systems
ZEND_EX_USE_LITERALS=1 is slower than ZEND_EX_USE_LITERALS=0. I can explain
it only by increasing of the size of zend_execute_data.
So I decided to introduce ZEND_EX_USE_RUN_TIME_CACHE for consistency (and
to check its effect). It always makes improvement. :)
Thanks. Dmitry,
On Thu, Dec 11, 2014 at 1:05 PM, Patrick ALLAERT patrickallaert@php.net
wrote:
Hi,
2014-12-10 16:27 GMT+01:00 Dmitry Stogov dmitry@zend.com:
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efeLooks good, but Isn't ZEND_EX_USE_RUN_TIME_CACHE always defined to 1
with your patch?Regards,
Patrick
Hi,
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efeIt's huge, but actually, only changes in zend_compile.h are matter. The
rest is obvious renaming.the main idea - the smaller the zend_op structure, the lees memory
traffic is required to load VM instructions during execution. The patch
reduces the size of each opcode from 48 to 32 bytes (saves 16 bytes for
each opcode, and applications use thousands of opoceds). This reduced the
number of CPU cache misses by 12% and improved performance of real-life
apps by 1-2%.The patch affects how constants and jump targets are represented in VM
during execution. Previously they were implemented as absolute 64-bit
pointers. Now they are relative 32-bit offsets.In run-time constant now should be accessed as:
RT_CONSTANT(op_array, opine->op1) instead of opline->op1.zv
EX_CONSTANT(opline->op1) instead of opline->op1.zvJump targets:
OP_JMP_ADDR(opline, opline->op2) instead of opline->op2.jmp_addrThe patch doesn't change zend_op representation for 32-bit systems. They
still use absolute addresses. The compile-time representation is also kept
the same.The patch must affect xdebug and may be other very engine depended
extensions, but it must not be a big problem to fix them (only
ext/opcache, ext/reflection and sapi/phpdbg required minor changes).If nobody objects, I'm going to commit this.
Thanks. Dmitry.
For those willing to test on Windows, a build is available here
http://windows.php.net/downloads/snaps/ostc/zend_op_12/ . Perf tests with
real apps are still outstanding, but from what i've tested so far there
are no regressions.
Regards
anatol