4 ms·

But doesn't PHP compile the source code into byte code and then interpret that? The problem described here was in the _compiler_ part of PHP, not in the byte co

But doesn't PHP compile the source code into byte code and then interpret that? The problem described here was in the _compiler_ part of PHP, not in the byte code interpreter.

jiggy2011 12y ago
Why is this downvoted? it is a reasonable question.
- mackal 12y ago
  Because its more aruging about semantics than anything else. At the end of the day, it needs to do this in real time and optimizing would cause a loss of speed for sometimes faster executed code, but since it all counts every time, it would be a waste.
  - jiggy2011 12y ago
    Opcodes can be cached until the source file changes. There may be specific instances when caching cannot happen, but the poster seems to not be clear as to why that would apply in this case, hence the question.
Someone1234 12y ago
All of which needs to occur after the user makes a request but before the request is returned. Regardless of which word you wish to use (compiler, interpreter, lexer, etc) or which part of the process you wish to shift the workload into, that work (finding redundancies and removing them) is still being performed in real time after a request arrives (i.e. a user has to wait while we do this). If the redundancy check costs more than the redundancy itself then removing them is utterly fruitless. The only way to avoid that is to take it out of that pipeline (i.e. pre-optimise the PHP OPCodes before a request arrives). PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). Within which case it might not matter if you used GOTO or While(true) as they'd both likely get optimised down to the GOTO OPCodes. However if you're using the original PHP interpreter then leaving them in might be the most optimal/cheap path to follow.
- masklinn 12y ago
  > The only way to avoid that is to take it out of that pipeline (i.e. pre-optimise the PHP OPCodes before a request arrives). Most production installations of PHP pretty much mandate a bytecode cache and the official distribution bundles one since 5.5[0], so the redundancy check is done once but the optimisation works for any request thereafter. > PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). HHVM is a completely separate VM which does not use (or consume, or care for in any way) the Zend bytecode produced by the Zend VM. HHVM has its own separate and incompatible bytecode format called HHBC[1]. It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. [0] http://php.net/manual/en/opcache.installation.php http://php.net/manual/en/opcache.installation.php [1] https://github.com/facebook/hhvm/blob/master/hphp/doc/bytecode.specification https://github.com/facebook/hhvm/blob/master/hphp/doc/byteco...
  - Someone1234 12y ago
    > It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. Nobody claimed otherwise.
    - masklinn 12y ago
      > Nobody claimed otherwise. You provided HHVM as an example[0] of "PHP pre-compilers and other optimisers". [0] that's literally what 'e.g.' means, it's an abbreviation for "exempli gratia", latin for "for example"
      - Someone1234 12y ago
        Indeed I did, and indeed it is. You tacked on "for the Zend VM." Which was not something I said. I said: > PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). You then said: > HHVM is a completely separate VM which does not use (or consume, or care for in any way) the Zend bytecode produced by the Zend VM. HHVM has its own separate and incompatible bytecode format called HHBC[1]. It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. Which is really answering a point nobody made. It is just completely out of the blue. My post literally does not contain the term "Zend." Nor does it make any claim to what OPCode formats different things use (and really the only reason you could even talk about HipHop was that it was given as a unqualified example). So to this: > It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. Is answering a point nobody made. It is like me saying, "You're wrong, the White House isn't blue, it is white!" When no claims to the blueness of the White House were made by yourself.

But doesn't PHP compile the source code into byte code and then interpret that? The problem described here was in the _compiler_ part of PHP, not in the byte code interpreter.

jiggy2011 12y ago

Why is this downvoted? it is a reasonable question.

mackal 12y ago
Because its more aruging about semantics than anything else. At the end of the day, it needs to do this in real time and optimizing would cause a loss of speed for sometimes faster executed code, but since it all counts every time, it would be a waste.
- jiggy2011 12y ago
  Opcodes can be cached until the source file changes. There may be specific instances when caching cannot happen, but the poster seems to not be clear as to why that would apply in this case, hence the question.

Someone1234 12y ago

All of which needs to occur after the user makes a request but before the request is returned. Regardless of which word you wish to use (compiler, interpreter, lexer, etc) or which part of the process you wish to shift the workload into, that work (finding redundancies and removing them) is still being performed in real time after a request arrives (i.e. a user has to wait while we do this). If the redundancy check costs more than the redundancy itself then removing them is utterly fruitless. The only way to avoid that is to take it out of that pipeline (i.e. pre-optimise the PHP OPCodes before a request arrives). PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). Within which case it might not matter if you used GOTO or While(true) as they'd both likely get optimised down to the GOTO OPCodes. However if you're using the original PHP interpreter then leaving them in might be the most optimal/cheap path to follow.

masklinn 12y ago
> The only way to avoid that is to take it out of that pipeline (i.e. pre-optimise the PHP OPCodes before a request arrives). Most production installations of PHP pretty much mandate a bytecode cache and the official distribution bundles one since 5.5[0], so the redundancy check is done once but the optimisation works for any request thereafter. > PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). HHVM is a completely separate VM which does not use (or consume, or care for in any way) the Zend bytecode produced by the Zend VM. HHVM has its own separate and incompatible bytecode format called HHBC[1]. It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. [0] http://php.net/manual/en/opcache.installation.php http://php.net/manual/en/opcache.installation.php [1] https://github.com/facebook/hhvm/blob/master/hphp/doc/bytecode.specification https://github.com/facebook/hhvm/blob/master/hphp/doc/byteco...
- Someone1234 12y ago
  > It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. Nobody claimed otherwise.
  - masklinn 12y ago
    > Nobody claimed otherwise. You provided HHVM as an example[0] of "PHP pre-compilers and other optimisers". [0] that's literally what 'e.g.' means, it's an abbreviation for "exempli gratia", latin for "for example"
    - Someone1234 12y ago
      Indeed I did, and indeed it is. You tacked on "for the Zend VM." Which was not something I said. I said: > PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). You then said: > HHVM is a completely separate VM which does not use (or consume, or care for in any way) the Zend bytecode produced by the Zend VM. HHVM has its own separate and incompatible bytecode format called HHBC[1]. It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. Which is really answering a point nobody made. It is just completely out of the blue. My post literally does not contain the term "Zend." Nor does it make any claim to what OPCode formats different things use (and really the only reason you could even talk about HipHop was that it was given as a unqualified example). So to this: > It's neither a "pre-compiler" nor an "optimiser" for the Zend VM. Is answering a point nobody made. It is like me saying, "You're wrong, the White House isn't blue, it is white!" When no claims to the blueness of the White House were made by yourself.