Re: [PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update
I agree with both (A) and (B). However (B) was done on purpose and has its advantages and disadvantages. Anyway, I've opened https://github.com/zendtech/ZendOptimizerPlus/issues/118 C) file based opcode caching may be interesting as well but all these requests are going to be a part of next major release (may be in php-5.6) Thanks. Dmitry. Thanks. Dmitry. On Tue, Jun 11, 2013 at 2:13 PM, Terry Ellison ellison.te...@gmail.comwrote: On 10/06/13 09:20, Dmitry Stogov wrote: Sorry for slow response. I'm very busy with other work and have no time for MLC OPcache review. I don't think we can include it into main tree before 5.5.0 release anyway. But in general I think we may include your work in the future releases. Also, thanks for useful reports about problems you've found in OPcache :) Thanks. Dmitry. Dmitry, One useful side-effect of writing the MLC support is that I've really had to take apart the core OPcache code to understand how it works. It's probably the first in-depth review that this extension has had from someone _outside_ the Zend team, so its only to be expected that anyone doing this would find a few issues. What I do think needs to be said it that I think that you guys have done a fantastic job here in this development. 9 times out of 10 when I've initially thought why didn't they do it this way? when digging into the code, I've dug down in and discovered that you already had, or had approached it a better way. IMO, the whole OPcache approach is tighter and more sound than that of APC. Take one example of this: the 2-pass algo for compiled scripts which enables the storage for a compiled script be to allocated as a single storage unit. This has two major performance benefits at runtime: 1) The memory allocator overheads of preparing scripts for execution (and deallocation at rundown) are reduced by more than an order of magnitude. 2) The memory needed to execute the script is in a contiguous memory areas, and this gives improved hardware (as in L1/L2/L3) caching which passes through to a runtime performance improvement. There are a couple of things that I would refactor if I had written OPcache. (I'll raise a couple of issues on these to discuss what I mean in more depth. and when the MLC work reaches a plateau if you think its worthwhile I can cut a couple of branches to show you a possible solution.) A) The SMA startup bootstrap is just messy and needs refactoring. B) The simple dead-and-rebirth method of refreshing caches isn't going to scale well on real systems. Terry (Note the new email addr that I am using for php.net work, as this one isn't being blocked by the php.net server)
Re: [PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update
On 10/06/13 09:20, Dmitry Stogov wrote: Sorry for slow response. I'm very busy with other work and have no time for MLC OPcache review. I don't think we can include it into main tree before 5.5.0 release anyway. But in general I think we may include your work in the future releases. Also, thanks for useful reports about problems you've found in OPcache :) Thanks. Dmitry. Dmitry, One useful side-effect of writing the MLC support is that I've really had to take apart the core OPcache code to understand how it works. It's probably the first in-depth review that this extension has had from someone _outside_ the Zend team, so its only to be expected that anyone doing this would find a few issues. What I do think needs to be said it that I think that you guys have done a fantastic job here in this development. 9 times out of 10 when I've initially thought why didn't they do it this way? when digging into the code, I've dug down in and discovered that you already had, or had approached it a better way. IMO, the whole OPcache approach is tighter and more sound than that of APC. Take one example of this: the 2-pass algo for compiled scripts which enables the storage for a compiled script be to allocated as a single storage unit. This has two major performance benefits at runtime: 1) The memory allocator overheads of preparing scripts for execution (and deallocation at rundown) are reduced by more than an order of magnitude. 2) The memory needed to execute the script is in a contiguous memory areas, and this gives improved hardware (as in L1/L2/L3) caching which passes through to a runtime performance improvement. There are a couple of things that I would refactor if I had written OPcache. (I'll raise a couple of issues on these to discuss what I mean in more depth. and when the MLC work reaches a plateau if you think its worthwhile I can cut a couple of branches to show you a possible solution.) A) The SMA startup bootstrap is just messy and needs refactoring. B) The simple dead-and-rebirth method of refreshing caches isn't going to scale well on real systems. Terry (Note the new email addr that I am using for php.net work, as this one isn't being blocked by the php.net server) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update
Hi Terry, Sorry for slow response. I'm very busy with other work and have no time for MLC OPcache review. I don't think we can include it into main tree before 5.5.0 release anyway. But in general I think we may include your work in the future releases. Also, thanks for useful reports about problems you've found in OPcache :) Thanks. Dmitry. On Wed, Jun 5, 2013 at 8:26 PM, Terry te...@ellisons.org.uk wrote: Dmitry, I've just reconciled my test runs for MLC OPcache, and I only had 3 unexplained test failures. Unfortunately on double-checking against standard OPcache, they were all due to the core code and not my additions, so I've raised the corresponding issues. I've cc'ed the internals list, but I suspect that my mail ID is still blacklisted :-( Regards Terry I've just pushed the latest test version to github and I've now got the point where I could benefit from some feedback on the dev-filecache branch...
