Re: Runtime-JIT, the whole enchilada
| From: | Pierre | Date: | Sat, 27 Jan 2007 11:53:19 +0000 |
| Subject: | Re: Runtime-JIT, the whole enchilada | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27686@lists.php.net to get a copy of this message | ||
On 1/27/07, Dmitry Stogov <dmitry@zend.com> wrote:
-----Original Message----- From: Pierre [mailto:pierre.php@gmail.com] Sent: Saturday, January 27, 2007 2:16 PM To: Andrei Zmievski Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; Andi Gutmans; Zeev Suraski; Stanislav Malyshev Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada Hello Andrei, On 1/27/07, Andrei Zmievski <andrei@gravitonic.com> wrote:Oh! It was not a +1 from me for this patch, I still prefer my simpler solution (which has to be written ;). However, as a temporary/test code Sara's patch can do it for now no?Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values.You will be surprised, really :)Really, how much of a performance hit is Sara's patch going to be, compared toother thingsin PHP 6?It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. Agree 100%. The slowdown is not large (may be 1%), but internal dependencies are to complex. This solution may be similar to "indirect modification of overloaded properties" or "return by reference", then mistakes give hundreds of bug reports and takes years for completely fix. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). I cannot restrict commits, I only tell my opinion. If the patch will be fixed for opcode caches, and most of developers will vote for it, it can go.