# 64-bit performance improvement by reducing zend_op size. - Thread: https://externals.io/message/79523 - Original archive: https://news-web.php.net/php.internals/79523 - Started by Dmitry Stogov on 2014-12-10T15:27:16+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #79523 — Dmitry Stogov — 2014-12-10T15:27:16+00:00 URL: https://externals.io/message/79523#79523 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. --- ## #79541 — guilhermeblanco@gmail.com — 2014-12-10T19:34:52+00:00 URL: https://externals.io/message/79523#79541 · In reply to: #79523 Seems good for me. =) > 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. > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #79553 — Xinchen Hui — 2014-12-11T06:42:42+00:00 URL: https://externals.io/message/79523#79553 · In reply to: #79523 Hey: > 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. As I already participated in this patch, I have no problems & objections. thanks > > Thanks. Dmitry. > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #79567 — Patrick ALLAERT — 2014-12-11T10:05:54+00:00 URL: https://externals.io/message/79523#79567 · In reply to: #79523 Hi, 2014-12-10 16:27 GMT+01:00 Dmitry Stogov : > 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 --- ## #79569 — Dmitry Stogov — 2014-12-11T10:30:57+00:00 URL: https://externals.io/message/79523#79569 · In reply to: #79567 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 wrote: > Hi, > > 2014-12-10 16:27 GMT+01:00 Dmitry Stogov : > > […] > > Looks good, but Isn't ZEND_EX_USE_RUN_TIME_CACHE always defined to 1 > with your patch? > > Regards, > Patrick --- ## #79570 — Anatol Belski — 2014-12-11T11:41:48+00:00 URL: https://externals.io/message/79523#79570 · In reply to: #79523 Hi, > 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. > > 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